From nemo-bounces@ietf.org Thu Sep 01 01:35:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAhji-0001BE-FR; Thu, 01 Sep 2005 01:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAhje-0001B3-Pd for nemo@megatron.ietf.org; Thu, 01 Sep 2005 01:35:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11872 for ; Thu, 1 Sep 2005 01:35:38 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAhlX-0008Oy-Em for nemo@ietf.org; Thu, 01 Sep 2005 01:37:36 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j815ZQW2014344; Thu, 1 Sep 2005 14:35:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j815ZST01823; Thu, 1 Sep 2005 14:35:28 +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 j815ZRj00992; Thu, 1 Sep 2005 14:35:27 +0900 (JST) Received: from mozart.psl.com.sg ([10.68.158.204]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 13:33:21 +0800 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 686F117525B; Thu, 1 Sep 2005 13:38:30 +0800 (SGT) Subject: Re: [nemo] More comments on the RO problem statement draft From: Chan-Wah NG To: Alexandru Petrescu In-Reply-To: <43159CD1.3060609@motorola.com> References: <431328D8.9080002@motorola.com> <43153404.8090204@kddilabs.jp> <43159CD1.3060609@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Thu, 01 Sep 2005 13:38:29 +0800 Message-Id: <1125553110.12976.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2005 05:33:23.0158 (UTC) FILETIME=[AB536F60:01C5AEB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, all, On Wed, 2005-08-31 at 14:04 +0200, Alexandru Petrescu wrote: > Hi Watari, > > Masafumi Watari wrote: > > > Hi, > > > > On 2005/08/30 0:25, Alexandru Petrescu wrote: > > > >> I've just went through the draft, thanks for putting it up in a > >> concise form. > >> > >> First, I'll repeat along the lines of the recent Jari posting about > >> vendors/deployment necessity. Having an RO problem statement is > >> good, at least to acknowledge the protocol issues with moving > >> networks. To that end I see necessity of the Problem Statement > >> draft. However, developping an RO scheme for NEMO should be > >> subject to deployment needs and user experience first. > >> > >> Section 2.5 "Security Policy Prohibiting Traffic From Visiting > >> Nodes" poses problems for my understanding. The title is > >> expressive, however the description is difficult to grasp, IMHO. > >> > >>> it can be expected that in many deployments, policies will be put > >>> in place to prevent untrusted visitors from attaching to the > >>> Mobile Router. [...] A Route Optimization mechanism that would > >>> prevent the multiple re- encapsulation of the packets by nested > >>> Mobile Routers might as a side effect alleviate this limitation > >> > >> > >> In my understanding "policy" is like packet filters on MR, that > >> would simply block anybody else than the known LFNs to connect to > >> that moving network. No RO mechanism could do anything against > >> those policies. If they're in place then nothing could be done > >> about them. > > > >> > > > >> Maybe the moving networks problem was this: any moving network can > >> attach to another moving network and there may be DoS attacks when > >> entities administrated by different separate administrative domains > >> take networking ressources from each other without a formal > >> agreement. In that case a formal agreement may solve the problem, > >> but not an RO solution which is mainly designed to shorten paths. > >> No? > > > > > > RO solution is designed to shorten paths, which means that it's > > providing an alternative paths for the MNNs. Since the alternative > > path is different from the default MRHA tunnel, the MRs may decide to > > forward packets for the vistor through the alternative path since the > > path will not threaten its home network. > > > > We didn't define what the "policy" might be, but if the policy > > prohibits a vistor to connect to its mobile network, as you > > mentioned, then I a RO solution is not designed to solve that > > problem. > > Thanks. I've re-read the section. It says that with typical networks, > maybe T4T is used and nodes do connect to each other without worry. And > it says that with NEMO if VMNs are allowed to connect to moving networks > then the T4T "policy" may no longer apply because traffic goes through > HA, which is another network. And which may make administrators to no > longer apply T4T. But if NEMO used RO then the administrators would > continue to indulge VMNs, because traffic would no longer go through HA. > The actual problem is actually security policy forbiding VMN. The T4T is just an example to illustrate the scenario where you would want to allow VMN. Personally, from comments gathered from people who'd read the draft during Paris meeting, I think the T4T example is clouding people from the real problem. I am inclined to re-arrange the text in that section. > The reasoning sounds complicated to me, it makes assumptions on too many > unknown things (T4T, policies, etc). > > Maybe it would be easier to say something along the lines of this: if > NEMO uses RO then there is more probability that moving networks will be > allowed (policy-wise) to connect to each other. Does this follow? > Perhaps, but it does not sounds like a "problem" to me, more of a motivation. I would've preferred a change of point of view to start off with problem of NEMO-Basic leading to why RO is needed. It's all a matter of wording. > >> Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" > >> has a textual illustration (ASCII art) of a mobility configuration > >> experimented in lab and where MRs can't update their HAs because > >> the tunnels would "cross-over" each other if they were set, instead > >> of "encapsulating" each other (see section B.6 in an expired draft > >> at http://tinyurl.com/4z4kc). > >> > >> Section 5 "Security Considerations" - ok this document does not > >> introduce any security issues, but what about the potential > >> extensions of the (security) RR mechanisms that can't be logically > >> extended to return routability tests for entire prefixes (the MNP > >> instead of HoA)? This was one of the important issues of not > >> looking at RO mechanisms for NEMO, because it was said that > >> extending RR to support prefixes is very unclear. > > > > > > The document is not intend to discuss any potential solutions, but > > perhaps in the Solution Space Analysis draft which is to be published > > soon. > > I agree this document should not have discussion of potential solutions. > I just wanted to mention that there is a "prefix ownership problem" > just like there is an "address ownership problem" (which was addressed > with CGA). It is little feasible to use CGA to address the "prefix > ownership problem". It is little feasible to do return routability > testing for all addresses comprised by a prefix. Without addressing the > "prefix ownership problem" it little feasible IMHO to have RR/RO like > MIP6 is. > > Maybe it's not correctly formulated... > > Maybe something should be said like this: assume RO is needed for NEMO. > It is then needed to use mechanism similar to MIP6 RR. But MIP6 RR is > used to ensure that a certain address is owned by a MN. It can't be > extended to ensure that an entire prefix is owned by an MR. > > "Prefix Ownership": when MR tries to instruct a CN that its MNP is at a > new CoA it should have a means to convince CN that that particular MNP > is actually the MNP that the MR is administratively assigned, in order > to avoid security attacks. > > Maybe still not correctly formulated, but you may get the idea... > As mentioned, please see the RO-Space-Analysis draft, which is already in the I-D Secretariat's queue. We have devoted quite a few paragraphs on this. /rgds /cwng From nemo-bounces@ietf.org Thu Sep 01 04:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAkuL-0000o7-AL; Thu, 01 Sep 2005 04:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAkuI-0000nz-Ni for nemo@megatron.ietf.org; Thu, 01 Sep 2005 04:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04641 for ; Thu, 1 Sep 2005 04:58:48 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAkwB-00067s-CH for nemo@ietf.org; Thu, 01 Sep 2005 05:00:50 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j8198p7Y020144; Thu, 1 Sep 2005 02:08:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j8194ZXf027527; Thu, 1 Sep 2005 04:04:37 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 35CFF865980; Thu, 1 Sep 2005 10:58:18 +0200 (CEST) Message-ID: <4316C2A9.9050508@motorola.com> Date: Thu, 01 Sep 2005 10:58:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] More comments on the RO problem statement draft References: <431328D8.9080002@motorola.com> <43153404.8090204@kddilabs.jp> <43159CD1.3060609@motorola.com> <1125553110.12976.7.camel@localhost> In-Reply-To: <1125553110.12976.7.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah NG wrote: > Hello Alex, all, > > On Wed, 2005-08-31 at 14:04 +0200, Alexandru Petrescu wrote: > >>Hi Watari, >> >>Masafumi Watari wrote: >> >> >>>Hi, >>> >>>On 2005/08/30 0:25, Alexandru Petrescu wrote: >>> >>> >>>>I've just went through the draft, thanks for putting it up in a >>>>concise form. >>>> >>>>First, I'll repeat along the lines of the recent Jari posting about >>>> vendors/deployment necessity. Having an RO problem statement is >>>>good, at least to acknowledge the protocol issues with moving >>>>networks. To that end I see necessity of the Problem Statement >>>>draft. However, developping an RO scheme for NEMO should be >>>>subject to deployment needs and user experience first. >>>> >>>>Section 2.5 "Security Policy Prohibiting Traffic From Visiting >>>>Nodes" poses problems for my understanding. The title is >>>>expressive, however the description is difficult to grasp, IMHO. >>>> >>>> >>>>>it can be expected that in many deployments, policies will be put >>>>>in place to prevent untrusted visitors from attaching to the >>>>>Mobile Router. [...] A Route Optimization mechanism that would >>>>>prevent the multiple re- encapsulation of the packets by nested >>>>>Mobile Routers might as a side effect alleviate this limitation >>>> >>>> >>>>In my understanding "policy" is like packet filters on MR, that >>>>would simply block anybody else than the known LFNs to connect to >>>>that moving network. No RO mechanism could do anything against >>>>those policies. If they're in place then nothing could be done >>>>about them. >>> >>>>Maybe the moving networks problem was this: any moving network can >>>>attach to another moving network and there may be DoS attacks when >>>>entities administrated by different separate administrative domains >>>>take networking ressources from each other without a formal >>>>agreement. In that case a formal agreement may solve the problem, >>>>but not an RO solution which is mainly designed to shorten paths. >>>>No? >>> >>> >>>RO solution is designed to shorten paths, which means that it's >>>providing an alternative paths for the MNNs. Since the alternative >>>path is different from the default MRHA tunnel, the MRs may decide to >>>forward packets for the vistor through the alternative path since the >>>path will not threaten its home network. >>> >>>We didn't define what the "policy" might be, but if the policy >>>prohibits a vistor to connect to its mobile network, as you >>>mentioned, then I a RO solution is not designed to solve that >>>problem. >> >>Thanks. I've re-read the section. It says that with typical networks, >>maybe T4T is used and nodes do connect to each other without worry. And >>it says that with NEMO if VMNs are allowed to connect to moving networks >>then the T4T "policy" may no longer apply because traffic goes through >>HA, which is another network. And which may make administrators to no >>longer apply T4T. But if NEMO used RO then the administrators would >>continue to indulge VMNs, because traffic would no longer go through HA. >> > > > The actual problem is actually security policy forbiding VMN. The T4T > is just an example to illustrate the scenario where you would want to > allow VMN. > > Personally, from comments gathered from people who'd read the draft > during Paris meeting, I think the T4T example is clouding people from > the real problem. I am inclined to re-arrange the text in that section. > > > >>The reasoning sounds complicated to me, it makes assumptions on too many >>unknown things (T4T, policies, etc). >> >>Maybe it would be easier to say something along the lines of this: if >>NEMO uses RO then there is more probability that moving networks will be >>allowed (policy-wise) to connect to each other. Does this follow? >> > > > Perhaps, but it does not sounds like a "problem" to me, more of a > motivation. I would've preferred a change of point of view to start off > with problem of NEMO-Basic leading to why RO is needed. Agree, it does not sound like a "problem" to me either. So if there is no way to meaningfully formulate it as a problem (I'm not excluding the possibility for someone to formulate it as a problem) then maybe it does not fit in the problem statement doc. >>>>Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" >>>>has a textual illustration (ASCII art) of a mobility configuration >>>>experimented in lab and where MRs can't update their HAs because >>>>the tunnels would "cross-over" each other if they were set, instead >>>>of "encapsulating" each other (see section B.6 in an expired draft >>>>at http://tinyurl.com/4z4kc). >>>> >>>>Section 5 "Security Considerations" - ok this document does not >>>>introduce any security issues, but what about the potential >>>>extensions of the (security) RR mechanisms that can't be logically >>>>extended to return routability tests for entire prefixes (the MNP >>>>instead of HoA)? This was one of the important issues of not >>>>looking at RO mechanisms for NEMO, because it was said that >>>>extending RR to support prefixes is very unclear. >>> >>> >>>The document is not intend to discuss any potential solutions, but >>>perhaps in the Solution Space Analysis draft which is to be published >>> soon. >> >>I agree this document should not have discussion of potential solutions. >> I just wanted to mention that there is a "prefix ownership problem" >>just like there is an "address ownership problem" (which was addressed >>with CGA). It is little feasible to use CGA to address the "prefix >>ownership problem". It is little feasible to do return routability >>testing for all addresses comprised by a prefix. Without addressing the >>"prefix ownership problem" it little feasible IMHO to have RR/RO like >>MIP6 is. >> >>Maybe it's not correctly formulated... >> >>Maybe something should be said like this: assume RO is needed for NEMO. >> It is then needed to use mechanism similar to MIP6 RR. But MIP6 RR is >>used to ensure that a certain address is owned by a MN. It can't be >>extended to ensure that an entire prefix is owned by an MR. >> >>"Prefix Ownership": when MR tries to instruct a CN that its MNP is at a >>new CoA it should have a means to convince CN that that particular MNP >>is actually the MNP that the MR is administratively assigned, in order >>to avoid security attacks. >> >>Maybe still not correctly formulated, but you may get the idea... >> > > > As mentioned, please see the RO-Space-Analysis draft, which is already > in the I-D Secretariat's queue. We have devoted quite a few paragraphs > on this. Ok, sorry for pushing. Alex From nemo-bounces@ietf.org Fri Sep 02 17:46:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJMU-000696-7r; Fri, 02 Sep 2005 17:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJMT-00068m-0g for nemo@megatron.ietf.org; Fri, 02 Sep 2005 17:46:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04394 for ; Fri, 2 Sep 2005 17:46:10 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBJOg-00041D-JI for nemo@ietf.org; Fri, 02 Sep 2005 17:48:31 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id EB33864EF for ; Fri, 2 Sep 2005 14:45:21 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02268-01 for ; Fri, 2 Sep 2005 14:45:14 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 4A7F661DF; Fri, 2 Sep 2005 14:45:14 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id E76956532 for ; Fri, 2 Sep 2005 14:45:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: nemo WG From: "T.J. Kniveton" Date: Fri, 2 Sep 2005 14:45:59 -0700 X-Mailer: Apple Mail (2.734) X-Spam-Score: -5.5 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [nemo] Minutes from IETF63 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org The minutes are now posted on the web page, if you want to take a look. http://www.mobilenetworks.org/nemo/ietf63/nemo-ietf63-minutes.html From nemo-bounces@ietf.org Fri Sep 02 18:50:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMq-0008Ow-DV; Fri, 02 Sep 2005 18:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMg-0008MM-Mr; Fri, 02 Sep 2005 18:50:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08632; Fri, 2 Sep 2005 18:50:28 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBKOW-00061d-1a; Fri, 02 Sep 2005 18:52:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EBKMD-0001Zf-9H; Fri, 02 Sep 2005 18:50:01 -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, 02 Sep 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --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-00.txt Pages : 37 Date : 2005-9-2 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-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-space-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-2155652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-space-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-2155652.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Mon Sep 05 12:56:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECKGk-0007BX-3M; Mon, 05 Sep 2005 12:56:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECKGi-0007BS-Hu for nemo@megatron.ietf.org; Mon, 05 Sep 2005 12:56:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24634 for ; Mon, 5 Sep 2005 12:56:25 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECKJT-0002qA-1s for nemo@ietf.org; Mon, 05 Sep 2005 12:59:22 -0400 Received: from [192.168.0.11] (p4080-ipbf903marunouchi.tokyo.ocn.ne.jp [58.88.27.80]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 98ED94CBA5; Tue, 6 Sep 2005 01:56:04 +0900 (JST) In-Reply-To: <4314A955.5050906@iprg.nokia.com> References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> <4314A955.5050906@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--544203449; protocol="application/pkcs7-signature" Message-Id: <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> From: Ryuji Wakikawa Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt Date: Tue, 6 Sep 2005 01:56:08 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-3--544203449 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hello Pascal and Vijay I read the draft and feel the same impression with Vijay. I agree with Vijay. The section 3.2 is not directly related to the NEMO PD. We had the consensus not to include local mobility management in DHCPv6PD at the Minneapolis meeting (forget maybe somewhere else). Here are more comments. Can MR can skip DHCP server discovery sending message to FF02::1:2 ? If MR knows the HA, MR can send request message to the HA without DR discovery. On the other hand, If MR does not know the HA, can MR use DHCP6PD as an alternative HA discovery mechanism? Or, MR rather do DHAAD to know a HA first, then it sends an address request message to the known HA? When there are multiple HAs available at a home link, do you assume only one of HA supports DR? regards, ryuji On 2005/08/31, at 3:45, Vijay Devarapalli wrote: > Pascal Thubert (pthubert) wrote: > >>> >>> I quickly glanced through the draft. looks good. >>> >>> I have one concern. section 3.2 does not belong in this >>> draft. in RFC 3963, the assumption is that the prefixes >>> assigned to the mobile network always comes from the >>> home link. never from the access link. >>> >>> I dont think there was any discussion on the mailing >>> list on this to include it in a WG document. did I miss >>> the discussion? >>> >>> >>> >>>> A Mobile Router may also obtain a temporary delegated prefix from >>>> >> its >> >>>> Access Router (acting as a DHCPv6PD DR) while the MR is roaming >>>> within the AR space. >>>> >>> >>> what is "roaming within the AR space"? the access router >>> is the first hop router to which the mobile router is >>> attached to. >>> >>> >> [] This is an opening to DHCPv6PD based Local Mobility >> Management. >> This is a leftover from the text we removed from the draft (the LMM >> part). We do not specify it any more here, but we do not prevent it >> either. The sentence says it's possible, which is true. But the >> sentence >> can be removed without hurting the rest of the spec. Votes? >> And I agree the AR term is ill chosen. The AR space is some kind of >> domain within which it makes sense to use the delegated prefix for >> LMM. >> > > this is bad. there was never any consensus to include something > like this in DHCPv6 based prefix delegation. I dont think NEMO is > supposed to work on Local Mobility Management. IMO, section 3.2 > needs to be removed. I think the document would advance quickly > without this section. > > Vijay > > --Apple-Mail-3--544203449 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGlDCCAycw ggIPoAMCAQICAg5BMA0GCSqGSIb3DQEBBQUAMD4xCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURF IFByb2plY3QxGDAWBgNVBAsTD21lbWJlcnMgb25seSBDQTAeFw0wNTA2MTMwNjExMjNaFw0wNjA2 MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURFIFByb2plY3QxHDAaBgNVBAMT EzA1MzkgUnl1amkgV2FraWthd2ExIzAhBgkqhkiG9w0BCQEWFHJ5dWppQHNmYy53aWRlLmFkLmpw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7DFXLFGqBmjo20THat6PMRULpJRujbsdcnrJ9 SO78Z1YZ1QjlwWL6hvscgqmf8eFgoB/0CmU/VO89CXYPJodHyTDl1snjDSORDbaVigXzBcMWZwsF UfvWy7umi/k8GNlmvfQfZz3tyRv4gHBDu7DhnG7asN9fZ9jiceMjqQkSeQIDAQABo4GJMIGGMA4G A1UdDwEBAAQEAwIEsDAiBgNVHREBAQAEGDAWgRRyeXVqaUBzZmMud2lkZS5hZC5qcDA2BgNVHR8B AQAELDAqMCigJqAkhiJodHRwOi8vd3d3Lm1vY2Eud2lkZS5hZC5qcC9jcmwuY3JsMBgGA1UdIwEB AAQOMAyAClZzPLqQAvdz6RIwDQYJKoZIhvcNAQEFBQADggEBAF3I8gCooL3tZhbDYoxfuGeB/6Rg pqZd4nFEGXSZYdMmwiEb3uTVL6ryBQBJz2rTP3QbwW/Eingow3AEXJAvAl+LBO/FgdROmAjjmVtR Vfv1/imDu0ynho8iIOoQVohMzRaW6pKjBLfniaPxT5LoKZoeyZm1rhGpCqfUwSMTBaWSQhU/4Cui /JfKwaTZYzqKE1kGIUxvnio7w8/fk6osMN+xq6ToOuXiP4orQa4Jmp16ofimTmuachK2XJp1TY7s vJBBe9OOevAA6RHWIIW24KcTw7MXOMzWBYKDAPFnCHhCVaKOpUrnLcXnTctf22sQVeSpuEfuS1oa 1YfrARFB3N8wggNlMIICTaADAgECAgEiMA0GCSqGSIb3DQEBBQUAMDYxCzAJBgNVBAYTAkpQMRUw EwYDVQQKEwxXSURFIFByb2plY3QxEDAOBgNVBAMTB1JPT1QgQ0EwHhcNMDAwMTI3MDczNzQ3WhcN MDYwNjMwMjM1OTU5WjA+MQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MRgwFgYD VQQLEw9tZW1iZXJzIG9ubHkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCjOT3U 4oOh+xtuEvMCl+E5r2URipsZEggY4wTpDyVziHZK0184q3erZN4JClZko0AzcoGMYNY5wHofOCQ3 7scHwq9PzQCEeBO7SE4YYJE8ACWVWcyASc0qJ2oD10xB68lirou9FSlPna8xBR5zxZ0r1cWThlLE g6go4xj7CvFAMein9d5mKzxj93ckIsYXLLL+utphflsTIJtd+4yT4tDvMDFnX0GUBi/7o0VKeCaf BdMbPQ4hGvooiX0twKQAAP+a43eu1LuQhKSOg5VfgijO0jS83GTswXWxOqed+5QcnHeBoPwrXPTp kObCASoE9GDb1Y3hP9QAMGiYuGphHrNRAgMBAAGjdjB0MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0P AQEABAQDAgH+MDkGA1UdHwEBAAQvMC0wK6ApoCeGJWh0dHA6Ly93d3cud2lkZS5hZC5qcC93aWRl cm9vdGNybC5jcmwwFgYDVR0OAQEABAwEClZzPLqQAvdz6RIwDQYJKoZIhvcNAQEFBQADggEBAEQ1 NcFh6XR/VWroPyKx/GP+28jVFyz3NC6Na+CgRjPRNi9+1iAKfV8rD4Gu4tPIfPbpmx/moYbJUoUY FV1rMdCs5Llk1q8mc6aa4KEvBOhxw2dL9XqJMiHEA3ShQf7zHJ4uJLHHmTDGgsO/Z4uJekzIO5r7 5kAe5VUXy7wY9ej7dE1jvREvMYtaPZBGP3GIWljMfA+XJcCuh1HalaKUZDLuU8DtlUu/o91Cv95c vyrHWhsNpyGrbWVohKFxEoSbGxFB311GFJtRbiqsZiOqvgAjQGkeQHlsBJEPAhJEJ9/S7OG3vlE/ MXwyiUFHA7FKvQmRubW3HMsrUjPPSV3Ji5QxggH3MIIB8wIBATBEMD4xCzAJBgNVBAYTAkpQMRUw EwYDVQQKEwxXSURFIFByb2plY3QxGDAWBgNVBAsTD21lbWJlcnMgb25seSBDQQICDkEwCQYFKw4D AhoFAKCCAQkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTA1 MTY1NjA4WjAjBgkqhkiG9w0BCQQxFgQUWXg7tJG53GxROgPJ3kgic0j0ak0wUwYJKwYBBAGCNxAE MUYwRDA+MQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MRgwFgYDVQQLEw9tZW1i ZXJzIG9ubHkgQ0ECAg5BMFUGCyqGSIb3DQEJEAILMUagRDA+MQswCQYDVQQGEwJKUDEVMBMGA1UE ChMMV0lERSBQcm9qZWN0MRgwFgYDVQQLEw9tZW1iZXJzIG9ubHkgQ0ECAg5BMA0GCSqGSIb3DQEB AQUABIGAoV0NqhUltHXctAJ2boKc550l2id1rLJ9EIZQLqm9y90t2nC5Rt1+JEN4uamZmfbbHHh0 HwZ+eHNS//7jWN6h0Y+pVZyLFNsoK7OesHxdXMY7ig2ojdX3Yf3z0BDmOUhiJU9tZR32rOtA3sPA 3Xch0RvVzjDZsHWgr7IdIWft1UoAAAAAAAA= --Apple-Mail-3--544203449-- From nemo-bounces@ietf.org Tue Sep 06 07:12:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECbNY-0003Na-3O; Tue, 06 Sep 2005 07:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECbNW-0003N5-1E for nemo@megatron.ietf.org; Tue, 06 Sep 2005 07:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20641 for ; Tue, 6 Sep 2005 07:12:33 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECbQR-0001b5-1K for nemo@ietf.org; Tue, 06 Sep 2005 07:15:39 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CD19988EFC; Tue, 6 Sep 2005 13:12:15 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 223D488C8D; Tue, 6 Sep 2005 13:12:14 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" , Masafumi Watari , Fan Zhao , Chan-Wah Ng Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1qdcFGkJuEu7scYj7+K2" Organization: UC3M Date: Tue, 06 Sep 2005 13:12:13 +0200 Message-Id: <1126005133.7897.87.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: IETF NEMO WG Subject: [nemo] Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-1qdcFGkJuEu7scYj7+K2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi draft authors and all, I've read the draft and I have some comments. First of all, a general comment about the structure of the document. IMHO, I'm not quite sure about if it's a good idea to present the different scenarios of NEMO RO in the way it is done now. In my understanding, a discussion about the scenarios of NEMO RO is needed, but more focused in which and how the different aspects that contribute to the inefficiencies due to the use of the NEMO Basic Support protocol could be mitigated/avoided, without taking into account and making any explicit reference to existing solutions. After that, it's fine to present the issues of potential NEMO RO solution, before exploring the solution space (in this section, references to existing solutions are more appropriate, IMHO). Regarding more specific comments of some parts of the document, I have the following: - In the section 3.2.2, it is said "The aim is to reduce the amplification effect of nested tunnels due to the nesting of tunnels between the Visiting Mobile Node and its Home Agent within the tunnel between the parent Mobile Router and the parent Mobile Router's Home Agent". I don't fully understand why it says "Visiting Mobile Node", since there may be several tunnels not only because a VMN visits a NEMO, but also because of several nested MRs. I think that the terminology may lead to confusion in some parts of the document, when Mobile Node, Visiting Mobile Node and Mobile Network Node is used. Again, the text is confusing to me when says "Such a solution will seek to minimize the number of tunnels possibly by collapsing the amount of tunnels required through some form of signaling between Mobile Nodes, or between Mobile Nodes and their Home Agents". - In the section 3.3. it is said that "This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes.". What is nesting of Mobile Nodes? Again, for me the terminology used is confusing. Does it refer to VMNs that connect to a NEMO? - In the section 3.4, the use of delegation of a single prefix to a nested NEMO is pointed out. It is said that in that case, the MRs would have to perform ND on behalf of the MNNs. If so, then the addresses of the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In that case, LFNs would not be supported. I think that some kind of address delegation may be useful for a potential NEMO RO solution, but I'm not so sure about the direct delegation of a prefix to every node in the nested NEMO. OTOH, I have to admit that I have not read the last drafts about prefix delegation, so maybe I'm missing something. - In the section 4, I would add an additional issue (or at least comment somewhere in the document) about the NEMO RO supporting non-mobile routers within a NEMO. Some of the currently proposed solutions does not support/cannot be applied when there is a legacy non-mobile router within a NEMO. Since, the NEMO Basic Support does support it, I think it should be pointed out. - In the section 4.1, it is said that the signalling overhead may scale to be unacceptable, especially to the resource-scarce mobile node. Is it assumed in this section that the MNN is the one that performs the RO tasks? In that case, and IMHO, introducing changes in the protocol operation of the MNNs is even worse than the limited capabilities that these nodes may have. OTOH, if the MR is the one that performs the RO tasks, although the limited capability problem of the MR remains to be valid, I'm not so sure about which nodes we are expecting to play the role of a MR. Maybe, it is not the general case that a limited device plays that role (for example in a NEMO deployed in a bus or a plane). - The section 4.3 points out the problem of the increased delay during handoff that may occur due to NEMO RO. I agree on that, but maybe it'd be worth to say that this problem is similar to the one that is present in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especially because of the Return Routability procedure) also adds latency, but to deal with that problem there are other proposals (e.g., FMIPv6 or HMIPv6) that are somehow independent to the RO problem. - The section 4.4 describes the New functionalities that may be needed for NEMO RO. It says that the smaller number of nodes required to be changed, the better and also points that there are some nodes that would be preferred not to be changed (like LFNs). IMHO, maybe it would be useful also to say that reusing existing protocols (like MIPv6) would make also easier the deployment of new NEMO RO solutions. - The section 5.1.1 describes the RO solution involving the MNN and the CN. IMHO, I'd say "new functionalities would be required" instead of "are required", since for example, MIPv6 capabilities of the nodes may be reused in some solutions falling in this category. The same comment applies to the section 5.1.2. - The section 5.1.3 says that solutions involving MR and CR may scale well, since a single RO session between the MR and CR can achieve RO between any MNN and any CN managed by the CR. I don't see this better scalability so well, I mean, IMHO there is a trade-off, depending on the specific scenario. Of course, if the CR is very close to the CN, the route would be very optimal, but in that case, if a MNN is communicating to several CN located in different physical locations, then several CRs would be needed (so there is here an scalability problem, in terms of number of CRs neede). OTOH, if the CR is not so close to the CNs, there may be less CRs, but then the optimisation is not so optimal. I see something similar with the case described in the section 5.1.4. - In the section 5.2, it is said that the node that is mobile is in the best position to detect its mobility, but what do you mean by "mobile"? that is physically moving or that is changing its point of attachment? Because, if the latter is meant, I don't see a MNN to necessarily be always mobile (e.g., a LFN is not). IMHO, the text needs to be clear. - In the section 5.3, it is said that the detection of the RO capability may incur in additional delay. I suppose that it would be dependant on the specific solution, but as I see it, a NEMO RO solution would use the NEMO Basic Solution while trying to setup a RO session, so I don't see the delay due to the detection capability. - The section 5.5.2 says that adding new options in Router Advertisements is to modify the protocol. IMHO, adding new options is just making use of the protocol, extending it with a new functionality, since new options can be defined (they would be discarded by nodes that do not support them) and implemented easily. - As I've pointed out before, I'm not so sure about the applicability of the Prefix Delegation and Neighbour Discovery Proxy solution with LFNs, since they involve changing the MNN's address when the NEMO moves, or am I missing something? - The section 5.8.1 points out that there are some WGs currently looking at the concern over the authenticity of addresses. We wrote a paper [1] about the general problem of making the NEMO RO secure, exploring some possible solution schemes (using CGAs for example, etc.). We can extend the paper in form of I-D if the WG considers it useful. Some Editorial comments: - Page 5, "lesser" instead of "least" in "... of a least cost ..." ?? - Page 5, "Quality of Service" instead of "Quality of Services" ?? - Page 12, "do" instead of "does" in "... the scenarios described in Section 3 does so ..." ?? - Page 23: "worthwhile" instead of "worth while" ?? - Page 26: "may be" instead of "maybe" in "... transmission maybe disrupted ..." ?? - Page 31: "detailed" instead of "detail" ?? I have some comments about how MIRON (a NEMO RO particular solution cited in the draft that I'm co-author of) is described in the draft, and in general about the Mobile Router as a Proxy family of solutions. I'll send them in a separate mail. Hope this helps. Thanks a lot for writing the draft. Kind regards, Carlos J. =20 [1] Securing Route Optimisation in NEMO Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio Soto Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, 2005. WIOPT 2005. Third International Symposium on=20 3-7 April 2005 Page(s): 248 - 254 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-1qdcFGkJuEu7scYj7+K2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHXmN7QxZUr+JuXQRAqy3AKCdhGTPuSzHuCzslhC0PKVPYDIymACgq7FK RhxqQ7ILy1QsuJnV8HYsmuM= =Q0Dk -----END PGP SIGNATURE----- --=-1qdcFGkJuEu7scYj7+K2-- From nemo-bounces@ietf.org Tue Sep 06 08:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECczG-0002x5-7A; Tue, 06 Sep 2005 08:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECczC-0002wu-R9 for nemo@megatron.ietf.org; Tue, 06 Sep 2005 08:55:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25664 for ; Tue, 6 Sep 2005 08:55:37 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECd2B-0004NI-6t for nemo@ietf.org; Tue, 06 Sep 2005 08:58:43 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j86DG7FZ008857 for ; Tue, 6 Sep 2005 06:16:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j86D2pJh006476 for ; Tue, 6 Sep 2005 08:02:52 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9E5DC865980 for ; Tue, 6 Sep 2005 14:55:34 +0200 (CEST) Message-ID: <431D91C5.2040505@motorola.com> Date: Tue, 06 Sep 2005 14:55:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and thanks for posting this draft. It captures in a single document much of the ro solution space and possibilities. I have read it partially and I have a few comments. I would suggest using the terms "prefix ownership" instead of the mix "identity" of "location" for Mobile Routers. While it is easy to understand that the "identity" of a MH is its Home Address it is difficult to agree that the MNP is the "identity" of a MR. It is easier to understand that MR "owns" a certain prefix and the "identity" of that MR is its Home Address. I would suggest not using the terms "implicitly" and "explicitly" for the two ways of representing an MNN's identity, because of the confusion that may arise with the terms "implicit" and "explicit" of the NEMO modes of operation. The NEMO Basic Support MR uses "implicit" mode of signalling to HA its CoA by _not_ including MNP in the BU and "explicit" mode by including MNP in the BU. The document on ro space analysis uses "implicitly" to represent MNP's identity by the use of MNP and "explicitly" by the use of its address. I would suggest to use "identity" to stand for MR's Home Address exclusively. > Binding Update with Mobile Network Prefix > > This can be viewed as a logical extension to NEMO Basic Support, > where the Mobile Router would send binding updates containing one or > more Mobile Network Prefix options to the Correspondent Agent. The > Correspondent Agent having received the Binding Update, can then set > up a bi-directional tunnel with the Mobile Router at the current > care-of address of the Mobile Router, and inject a route to its > routing table so that packets destined for addresses in the mobile > network prefix will be routed through the bi-directional tunnel. Actually I think the packets addressed to nodes in the moving network will be routed with a routing header and not encapsulated through a bi-directional tunnel. > Although the Return Routability procedure allows the Correspondent > Agent to verify that the care-of and home addresses of the Mobile > Router are indeed collocated, it does not allow the Correspondent > Agent to verify the validity of the Mobile Network Prefix. Right, and additionally it is difficult to design a method for testing the return routability for each and every address falling with the MNP limits. Alex From nemo-bounces@ietf.org Tue Sep 06 09:27:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdUF-00089q-T2; Tue, 06 Sep 2005 09:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdUE-00089i-Si for nemo@megatron.ietf.org; Tue, 06 Sep 2005 09:27:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27053 for ; Tue, 6 Sep 2005 09:27:39 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECdX9-0005DB-33 for nemo@ietf.org; Tue, 06 Sep 2005 09:30:45 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id B227B88DDE; Tue, 6 Sep 2005 15:27:28 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 1168988DDE; Tue, 6 Sep 2005 15:27:28 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng , Fan Zhao , Masafumi Watari , "Pascal Thubert (pthubert)" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XwlleIa3hChRw+RLlnu/" Organization: UC3M Date: Tue, 06 Sep 2005 15:27:27 +0200 Message-Id: <1126013247.7897.115.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: IETF NEMO WG , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Ignacio Soto Campos , Marcelo Bagnulo Subject: [nemo] Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-XwlleIa3hChRw+RLlnu/ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi draft authors and all, I've read the draft and I have some comments regarding MIRON (an specific solution I'm co-author of). I prefer to send them in a different e-mail, to keep them separated from the general ones I've already sent. In the section 3.2.1, MIRON is cited for the first time, as a mechanism that decreases the number of Home Agents in the path in a nested scenario. This is not completely true, since MIRON, as it's currently specified in draft-bernardos-nemo-miron-00.txt, does not deal with nested mobile networks. The main aim of MIRON is to provide a RO mechanisms for LFNs of a NEMO, when they are communicating with CNs, avoiding the MRHA tunnel with the MR's HA. This is done, by the MR performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO. However, nothing prevents this solution to be applied also in a nested NEMO, avoiding the last tunnel, or even all the tunnels if the MR is provided somehow with a topologically valid IPv6 address that is reachable without traversing any HA. This can be done, for example, by providing to every MR in the nested topology with an IPv6 address that belongs to the foreign network that the root-MR is visiting (for example, by using DHCPv6), and enabling (with routing among the MRs and proxy ND) these address to be directly reachable anywhere in the Internet (without needing any special node, such a HA, to be deployed in the infrastructure). In the section 5.5.1, as far as I've understood, MIRON is classified as a NEMO RO solution in which the "Mobile Router acts as a Transparent Proxy". Firstly, for me it is not clear the distinction between "Mobile Router as a Proxy" and "Mobile Router as a Transparent Proxy", since it is said that - in the "Mobile Router as a Proxy" - the Mobile Router uses standard Mobile IPv6 Route Optimisation procedure to bind the address of a Mobile Network Node to the MR's CoA, and that's exactly which MIRON does. Nevertheless, this "proxy" functionality requires the MR to generate also the Return Routability signalling on behalf of the LFNs, not only the Binding Updates messages. Besides, the packets sent/received by the LFNs have to be modified, since they would be sent by the CN addressed to the MR's CoA (carrying a type 2 RH), and the packets sent by the LFN have to have the MR's CoA as their source address (carrying a Home Address Destination Option). OTOH, it is said that the "Mobile Router as a Transparent Proxy" works by modifying MIPv6 RO packets sent to VMNs. This is not possible (at least easily), since the HoTI and HoT messages sent by the VMNs have to be sent using IPsec ESP, so the MR cannot modify these packets to set its CoA as the VMN's CoA. I'd suggest to remove the "Mobile Router as a Transparent Proxy" section and rewrite the "Mobile Router as a Proxy" section (I can provide some text for discussion if you want). The main aim and advantage of MIRON is providing a NEMO RO mechanism suited for LFNs (that is, IPv6 nodes that do not have/use any mobility support), by using the Mobile IPv6 RO already defined mechanism and, therefore, not requiring any change on the operation of LFNs and CNs. Thanks a lot. Kind Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-XwlleIa3hChRw+RLlnu/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHZk/7QxZUr+JuXQRAvVPAJ416vm5HHT9kjQu/BVd2wOsKIrBRQCg3g4R SMqVl1TfsvWAJGETUCVEObw= =5EN1 -----END PGP SIGNATURE----- --=-XwlleIa3hChRw+RLlnu/-- From nemo-bounces@ietf.org Tue Sep 06 09:40:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdgh-0001eK-Nu; Tue, 06 Sep 2005 09:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdgg-0001e7-0j for nemo@megatron.ietf.org; Tue, 06 Sep 2005 09:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27543 for ; Tue, 6 Sep 2005 09:40:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECdje-0005W3-P9 for nemo@ietf.org; Tue, 06 Sep 2005 09:43:39 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Sep 2005 15:40:24 +0200 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 j86De4VZ000042; Tue, 6 Sep 2005 15:40:22 +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.0); Tue, 6 Sep 2005 15:40:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt Date: Tue, 6 Sep 2005 15:40:05 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC013D048D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt Thread-Index: AcWy4pWMAr/gGkDjRaaZk8g34o2D6QABNdKA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 06 Sep 2005 13:40:09.0894 (UTC) FILETIME=[7FF66C60:01C5B2E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex: Thanks for all this? Great comments :) >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Alexandru Petrescu >Sent: Tuesday, September 06, 2005 2:56 PM >To: nemo@ietf.org >Subject: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt > >Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and thanks >for posting this draft. It captures in a single document much of the ro >solution space and possibilities. > >I have read it partially and I have a few comments. > >I would suggest using the terms "prefix ownership" instead of the mix >"identity" of "location" for Mobile Routers. While it is easy to >understand that the "identity" of a MH is its Home Address it is >difficult to agree that the MNP is the "identity" of a MR. It is easier >to understand that MR "owns" a certain prefix and the "identity" of that >MR is its Home Address. >>I would suggest not using the terms "implicitly" and "explicitly" for >the two ways of representing an MNN's identity, because of the confusion >that may arise with the terms "implicit" and "explicit" of the NEMO >modes of operation. The NEMO Basic Support MR uses "implicit" mode of >signalling to HA its CoA by _not_ including MNP in the BU and "explicit" >mode by including MNP in the BU. The document on ro space analysis uses > "implicitly" to represent MNP's identity by the use of MNP and >"explicitly" by the use of its address. > >I would suggest to use "identity" to stand for MR's Home Address >exclusively. > [] Yes, I believe that we have formed the collective understanding that the Home Address is the ID for the MN/MR and for the associated binding, when a bunch of various types of information are bound (the HoA itself, prefixes, IPv4 addresses, DNS names, you name it). >> Binding Update with Mobile Network Prefix >> >> This can be viewed as a logical extension to NEMO Basic Support, >> where the Mobile Router would send binding updates containing one or >> more Mobile Network Prefix options to the Correspondent Agent. The >> Correspondent Agent having received the Binding Update, can then set >> up a bi-directional tunnel with the Mobile Router at the current >> care-of address of the Mobile Router, and inject a route to its >> routing table so that packets destined for addresses in the mobile >> network prefix will be routed through the bi-directional tunnel. > >Actually I think the packets addressed to nodes in the moving network >will be routed with a routing header and not encapsulated through a >bi-directional tunnel. > [] We had in mind that the Correspondent Agent would similarly to a Home Agent: terminate the tunnel. It would get packets from the correspondent en encaps them, which is easier then injecting an RH2 in the middle.=20 >> Although the Return Routability procedure allows the Correspondent >> Agent to verify that the care-of and home addresses of the Mobile >> Router are indeed collocated, it does not allow the Correspondent >> Agent to verify the validity of the Mobile Network Prefix. > >Right, and additionally it is difficult to design a method for testing >the return routability for each and every address falling with the MNP >limits. > [] Yep. RO MR to MR is a very difficult problem to solve in terms of security. OTOH, proxies doing some degree of RO alleviate a lot of the difficulty. They share a common trust model with the infrastructure.=20 Pascal From nemo-bounces@ietf.org Tue Sep 06 10:02:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe1n-0005Co-6y; Tue, 06 Sep 2005 10:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECe1l-0005Cd-C4 for nemo@megatron.ietf.org; Tue, 06 Sep 2005 10:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28427 for ; Tue, 6 Sep 2005 10:02:19 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECe4j-00063i-JV for nemo@ietf.org; Tue, 06 Sep 2005 10:05:26 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j86E1gBO016415; Tue, 6 Sep 2005 07:01:42 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j86E7TqF025282; Tue, 6 Sep 2005 09:07:30 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6AD45865980; Tue, 6 Sep 2005 16:01:39 +0200 (CEST) Message-ID: <431DA143.1090707@motorola.com> Date: Tue, 06 Sep 2005 16:01:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt References: <7892795E1A87F04CADFCCF41FADD00FC013D048D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC013D048D@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Alex: > > Thanks for all this? Great comments :) > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > > Alexandru Petrescu > >>Sent: Tuesday, September 06, 2005 2:56 PM >>To: nemo@ietf.org >>Subject: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt >> >>Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and thanks >>for posting this draft. It captures in a single document much of the > > ro > >>solution space and possibilities. >> >>I have read it partially and I have a few comments. >> >>I would suggest using the terms "prefix ownership" instead of the mix >>"identity" of "location" for Mobile Routers. While it is easy to >>understand that the "identity" of a MH is its Home Address it is >>difficult to agree that the MNP is the "identity" of a MR. It is > > easier > >>to understand that MR "owns" a certain prefix and the "identity" of > > that > >>MR is its Home Address. >> >>>I would suggest not using the terms "implicitly" and "explicitly" for >> >>the two ways of representing an MNN's identity, because of the > > confusion > >>that may arise with the terms "implicit" and "explicit" of the NEMO >>modes of operation. The NEMO Basic Support MR uses "implicit" mode of >>signalling to HA its CoA by _not_ including MNP in the BU and > > "explicit" > >>mode by including MNP in the BU. The document on ro space analysis > > uses > >>"implicitly" to represent MNP's identity by the use of MNP and >>"explicitly" by the use of its address. >> >>I would suggest to use "identity" to stand for MR's Home Address >>exclusively. >> > > > [] Yes, I believe that we have formed the collective understanding > that the Home Address is the ID for the MN/MR and for the associated > binding, when a bunch of various types of information are bound (the HoA > itself, prefixes, IPv4 addresses, DNS names, you name it). Yes, from a certain perspective within a certain IP mobility space. Even though in the CGA space it's the private key that is really _the_ ID. I was thinking "bind" and "bound" are only for Mobile IPv6 binding management, i.e. a Home Address or an MNP are bound to a Care-of Address. That and no more than that. I was not thinking that one would "bind" an IPv4 address to an IPv6 Care-of Address, nor an IPv4 Care-of Address to an IPv6 Home Address. 6to4 gives a method for converting an IPv4 public address into an IPv6 prefix. I was not thinking that a HoA would be bound to a DNS name. Each DNS FQDN is resolved into an IP address and reversely. And back to the draft, I'd suggest not using MNP to be an identifier, but the Home Address. > > > >>>Binding Update with Mobile Network Prefix >>> >>>This can be viewed as a logical extension to NEMO Basic Support, >>>where the Mobile Router would send binding updates containing one or >>>more Mobile Network Prefix options to the Correspondent Agent. The >>>Correspondent Agent having received the Binding Update, can then set >>> up a bi-directional tunnel with the Mobile Router at the current >>>care-of address of the Mobile Router, and inject a route to its >>>routing table so that packets destined for addresses in the mobile >>>network prefix will be routed through the bi-directional tunnel. >> >>Actually I think the packets addressed to nodes in the moving network >>will be routed with a routing header and not encapsulated through a >>bi-directional tunnel. >> > > [] We had in mind that the Correspondent Agent would similarly to a > Home Agent: terminate the tunnel. I see, in that case - yes. Alex From nemo-bounces@ietf.org Tue Sep 06 10:15:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeEN-0007sF-Fd; Tue, 06 Sep 2005 10:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECeEI-0007rm-EM for nemo@megatron.ietf.org; Tue, 06 Sep 2005 10:15:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29786 for ; Tue, 6 Sep 2005 10:15:16 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECeHG-0006Pt-Jn for nemo@ietf.org; Tue, 06 Sep 2005 10:18:23 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j86EEfjX003882; Tue, 6 Sep 2005 23:14:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j86EEgF29661; Tue, 6 Sep 2005 23:14:42 +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 j86EEfB11228; Tue, 6 Sep 2005 23:14:41 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 22:12:34 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 7B61B1ED726; Tue, 6 Sep 2005 22:33:33 +0800 (SGT) From: Chan-Wah Ng To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1126005133.7897.87.camel@acorde> References: <1126005133.7897.87.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 06 Sep 2005 22:33:33 +0800 Message-Id: <1126017213.2181.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 06 Sep 2005 14:12:34.0598 (UTC) FILETIME=[0718B460:01C5B2ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , IETF NEMO WG Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Carlos, Thank you for reading the draft so soon, and the valuable comments. See my response in-line. I will try my best to respond to all your comments, but some I will leave to my other co-authors to address. On Tue, 2005-09-06 at 13:12 +0200, Carlos Jes=FAs Bernardos Cano wrote: > Hi draft authors and all, >=20 > I've read the draft and I have some comments. >=20 > First of all, a general comment about the structure of the document. > IMHO, I'm not quite sure about if it's a good idea to present the > different scenarios of NEMO RO in the way it is done now. In my > understanding, a discussion about the scenarios of NEMO RO is needed, > but more focused in which and how the different aspects that contribute > to the inefficiencies due to the use of the NEMO Basic Support protocol > could be mitigated/avoided, without taking into account and making any > explicit reference to existing solutions. After that, it's fine to > present the issues of potential NEMO RO solution, before exploring the > solution space (in this section, references to existing solutions are > more appropriate, IMHO). So, if I understand your point of view correctly, you feel that all references to existing proposals should be moved to Sect 5? >=20 > Regarding more specific comments of some parts of the document, I have > the following: >=20 > - In the section 3.2.2, it is said "The aim is to reduce the > amplification effect of nested tunnels due to the nesting of tunnels > between the Visiting Mobile Node and its Home Agent within the tunnel > between the parent Mobile Router and the parent Mobile Router's Home > Agent". I don't fully understand why it says "Visiting Mobile Node", > since there may be several tunnels not only because a VMN visits a NEMO, > but also because of several nested MRs. I think that the terminology may > lead to confusion in some parts of the document, when Mobile Node, > Visiting Mobile Node and Mobile Network Node is used. Again, the text is > confusing to me when says "Such a solution will seek to minimize the > number of tunnels possibly by collapsing the amount of tunnels required > through some form of signaling between Mobile Nodes, or between Mobile > Nodes and their Home Agents". We are tyring to be consistent with draft-ietf-nemo-terminology. It is, i think, an unfortunate circumstances that RFC3775 uses the term Mobile Node when Mobile Host is more appropriate. The term VMN refers to both visiting mobile hosts and visiting mobile routers, so the use of VMN includes the case of nested MRs. We are trying to write as concisely as possible here, considering the draft is already 39 pages long. However, we may have overdone it and lose some clarity for the sake of conciseness. I will try to clean up the text a bit to make it less confusing. >=20 > - In the section 3.3. it is said that "This may be used to eliminate > the multiple tunnels caused by nesting of Mobile Nodes.". What is > nesting of Mobile Nodes? Again, for me the terminology used is > confusing. Does it refer to VMNs that connect to a NEMO? >=20 > - In the section 3.4, the use of delegation of a single prefix to a > nested NEMO is pointed out. It is said that in that case, the MRs would > have to perform ND on behalf of the MNNs. If so, then the addresses of > the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In > that case, LFNs would not be supported. I think that some kind of > address delegation may be useful for a potential NEMO RO solution, but > I'm not so sure about the direct delegation of a prefix to every node in > the nested NEMO. OTOH, I have to admit that I have not read the last > drafts about prefix delegation, so maybe I'm missing something. >=20 This is one RO scheme where LFN is not supported. Because if LFN are to be supported, they would break session continuity when the prefix is changed. The latest draft on prefix delegation has nothing to do with RO, AFAICS. The draft we are referring to when the text was written is quite an old draft, draft-leekj-nemo-ro-pd-02.txt > - In the section 4, I would add an additional issue (or at least > comment somewhere in the document) about the NEMO RO supporting > non-mobile routers within a NEMO. Some of the currently proposed > solutions does not support/cannot be applied when there is a legacy > non-mobile router within a NEMO. Since, the NEMO Basic Support does > support it, I think it should be pointed out. Noted. >=20 > - In the section 4.1, it is said that the signalling overhead may scale > to be unacceptable, especially to the resource-scarce mobile node. Is it > assumed in this section that the MNN is the one that performs the RO > tasks? In that case, and IMHO, introducing changes in the protocol > operation of the MNNs is even worse than the limited capabilities that > these nodes may have. OTOH, if the MR is the one that performs the RO > tasks, although the limited capability problem of the MR remains to be > valid, I'm not so sure about which nodes we are expecting to play the > role of a MR. Maybe, it is not the general case that a limited device > plays that role (for example in a NEMO deployed in a bus or a plane). Noted, perhaps a more detailed analysis would be required here. I would follow up on this with a separate mail by this week. >=20 > - The section 4.3 points out the problem of the increased delay during > handoff that may occur due to NEMO RO. I agree on that, but maybe it'd > be worth to say that this problem is similar to the one that is present > in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especially > because of the Return Routability procedure) also adds latency, but to > deal with that problem there are other proposals (e.g., FMIPv6 or > HMIPv6) that are somehow independent to the RO problem. Well, we expect that in some NEMO-RO proposals, the handoff delay will be greater. For instance, consider a node behind 3 MRs. Certain NEMO RO proposals may require each of these MR to signal the CA. Assuming the signaling delay is d, then the delay for the node is anything between (d, d+3d), worse than or at best equal to MIPv6 RO. >=20 > - The section 4.4 describes the New functionalities that may be needed > for NEMO RO. It says that the smaller number of nodes required to be > changed, the better and also points that there are some nodes that would > be preferred not to be changed (like LFNs). IMHO, maybe it would be > useful also to say that reusing existing protocols (like MIPv6) would > make also easier the deployment of new NEMO RO solutions. Hmm.. I thought that is mentioned somewhere, but perhaps not explicitly. Noted. >=20 > - The section 5.1.1 describes the RO solution involving the MNN and the > CN. IMHO, I'd say "new functionalities would be required" instead of > "are required", since for example, MIPv6 capabilities of the nodes may > be reused in some solutions falling in this category. The same comment > applies to the section 5.1.2. Ok. >=20 > - The section 5.1.3 says that solutions involving MR and CR may scale > well, since a single RO session between the MR and CR can achieve RO > between any MNN and any CN managed by the CR. I don't see this better > scalability so well, I mean, IMHO there is a trade-off, depending on the > specific scenario. Of course, if the CR is very close to the CN, the > route would be very optimal, but in that case, if a MNN is communicating > to several CN located in different physical locations, then several CRs > would be needed (so there is here an scalability problem, in terms of > number of CRs neede). OTOH, if the CR is not so close to the CNs, there > may be less CRs, but then the optimisation is not so optimal. I see > something similar with the case described in the section 5.1.4. You mention a very relevant point about tradeoff of the proximity of CR to CN. But the text is not about this. Worst case scenario is that the MR/MNN is communicating with one CR per CN. The number of session maintained is the same as MIPv6 (i.e. 1 RO-session per CN). However, the best case scenario is that the MR/MNN is communicating with multiple CNs behind a CR. SO, using a CR would always result in less or at most equal number of RO sessions. Thus we say the use of CR scales well. >=20 > - In the section 5.2, it is said that the node that is mobile is in the > best position to detect its mobility, but what do you mean by "mobile"? > that is physically moving or that is changing its point of attachment? > Because, if the latter is meant, I don't see a MNN to necessarily be > always mobile (e.g., a LFN is not). IMHO, the text needs to be clear. OK. >=20 > - In the section 5.3, it is said that the detection of the RO > capability may incur in additional delay. I suppose that it would be > dependant on the specific solution, but as I see it, a NEMO RO solution > would use the NEMO Basic Solution while trying to setup a RO session, so > I don't see the delay due to the detection capability. That is if it continues to use the NEMO-BS tunnel while detecting RO. Some RO proposals may make it difficult to do this, for example a RO proposal that embed signaling on-plane. To use NEMO-BS support at the same, require the MR to duplicate a data packet, one to go through the NEMO-BS tunnel, one to try the optimized path. It may not be such a good idea in this case. >=20 > - The section 5.5.2 says that adding new options in Router > Advertisements is to modify the protocol. IMHO, adding new options is > just making use of the protocol, extending it with a new functionality, > since new options can be defined (they would be discarded by nodes that > do not support them) and implemented easily. True. We will look into that. >=20 > - As I've pointed out before, I'm not so sure about the applicability > of the Prefix Delegation and Neighbour Discovery Proxy solution with > LFNs, since they involve changing the MNN's address when the NEMO moves, > or am I missing something? As I responded before, RO this scheme does not support LFN. >=20 > - The section 5.8.1 points out that there are some WGs currently > looking at the concern over the authenticity of addresses. We wrote a > paper [1] about the general problem of making the NEMO RO secure, > exploring some possible solution schemes (using CGAs for example, etc.). > We can extend the paper in form of I-D if the WG considers it useful. Yes, I think I have read the paper before, just that I got lazy trying to seek out the complete bibliography. Thanks. >=20 > Some Editorial comments: >=20 > - Page 5, "lesser" instead of "least" in "... of a least cost ..." ?? > - Page 5, "Quality of Service" instead of "Quality of Services" ?? > - Page 12, "do" instead of "does" in "... the scenarios described in > Section 3 does so ..." ?? > - Page 23: "worthwhile" instead of "worth while" ?? > - Page 26: "may be" instead of "maybe" in "... transmission maybe > disrupted ..." ?? > - Page 31: "detailed" instead of "detail" ?? OK. >=20 > I have some comments about how MIRON (a NEMO RO particular solution > cited in the draft that I'm co-author of) is described in the draft, and > in general about the Mobile Router as a Proxy family of solutions. I'll > send them in a separate mail. You are welcomed. We interpret each proposal in our own way, and its good to have authors of the proposals referred to in the draft to point out to us some of our mis-interpretation. Plus please also remember that (1) we are trying to be concise, (2) we generalize, and (3) we document so many different proposals that we probably confuse ourselves :). /rgds /cwng >=20 > Hope this helps. >=20 > Thanks a lot for writing the draft. >=20 > Kind regards, >=20 > Carlos J. =20 >=20 > [1] Securing Route Optimisation in NEMO > Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio So= to > Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, > 2005. WIOPT 2005. Third International Symposium on=20 > 3-7 April 2005 Page(s): 248 - 254 >=20 From nemo-bounces@ietf.org Tue Sep 06 11:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfCy-0001vt-53; Tue, 06 Sep 2005 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfCw-0001vD-0g for nemo@megatron.ietf.org; Tue, 06 Sep 2005 11:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03391 for ; Tue, 6 Sep 2005 11:17:53 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECfFr-0008Ac-VA for nemo@ietf.org; Tue, 06 Sep 2005 11:21:01 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B7AA88D0C; Tue, 6 Sep 2005 17:17:43 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 172F888C04; Tue, 6 Sep 2005 17:17:43 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng , "Pascal Thubert (pthubert)" , Masafumi Watari , Fan Zhao Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-06AosfvGSo5DojtrLjXm" Organization: UC3M Date: Tue, 06 Sep 2005 17:17:42 +0200 Message-Id: <1126019862.7897.165.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF NEMO WG Subject: [nemo] Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-06AosfvGSo5DojtrLjXm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi draft authors, and all, As presented in Paris, it was agreed to include some changes on the the draft-ietf-nemo-ro-problem-statement-00.txt, to solve some of the issues raised on the ML. Here I propose some text for discussion: In the section 2.1, in the part describing "Longer route leading to increased delay and additional infrastructure load", it is stated that applications such as real-time multimedia streaming may not be able to tolerate the increased delay. I'd suggest adding the following: "Besides, the increase in delay impact also the performance of transport protocols such as TCP, since the rate at which a TCP nodes send packets is driven by the congestion control algorithm, which is related to the RTT perceived by the communication peers. If the RTT is inflated due to the MRHA tunnel, the effective throughput obtained by an application will decrease, especially in those cases in which there are several competing flows sharing a bandwidth-limited link (those flows with less RTT will obtain higher throughput)". A minor remark about the effect of increased packet loss probability when using the MRHA tunnel and the TCP performance may be also included here (or in the "Increased susceptibility to link failure" subsection). In the section B.4.3, I'd suggest to add the following text to comment about the possibility of using the VMN's CoA for communication in short-term communications: "The MNN may also decide to use its Care-of Address as the source address of the packets, thus avoiding the tunnelling with the MNN's HA. This is particularly useful for a short-term communication that may easily be retried if it fails. RFC 3484 (Default Address Selection) provides some mechanisms for controlling the choice of the source address. An API may also be alternatively used for those applications running on the MNN that have enough knowledge of the communication being sent to decide whether to use the MNN's Home Address or the MNN's Care-of Address as the source address of the packets being sent." Hope it helps. Thanks a lot. Kind Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-06AosfvGSo5DojtrLjXm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHbMW7QxZUr+JuXQRAsFzAJ4ww+ramBBFedPhO0hW9kX9h/g8UQCeMzMG QyIyyllqSxCADAyHi2HLfpo= =bVEh -----END PGP SIGNATURE----- --=-06AosfvGSo5DojtrLjXm-- From nemo-bounces@ietf.org Tue Sep 06 22:14:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpSh-00013x-A6; Tue, 06 Sep 2005 22:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpSc-000135-RG for nemo@megatron.ietf.org; Tue, 06 Sep 2005 22:14:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21132 for ; Tue, 6 Sep 2005 22:14:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECpVc-0004pu-Uz for nemo@ietf.org; Tue, 06 Sep 2005 22:18:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j871fmv05681; Tue, 6 Sep 2005 18:41:48 -0700 X-mProtect: <200509070141> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdOa5C7t; Tue, 06 Sep 2005 18:41:46 PDT Message-ID: <431E4CFC.6010108@iprg.nokia.com> Date: Tue, 06 Sep 2005 19:14:20 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> <4314A955.5050906@iprg.nokia.com> <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> In-Reply-To: <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Can MR can skip DHCP server discovery sending message to FF02::1:2 ? > If MR knows the HA, MR can send request message to the HA without DR > discovery. yes, this should be supported. > On the other hand, If MR does not know the HA, can MR use DHCP6PD as an > alternative HA discovery mechanism? no. the MR can't reach the DHCPv6 server on the home link. are you suggesting using the DHCP server on the visited link to allocate a HA from the home link? > Or, MR rather do DHAAD to know a HA first, then it sends an address > request message to the known HA? yes. or use DNS to discover the HA as described in draft-ietf-mip6-bootstrap-split > When there are multiple HAs available at a home link, do you assume > only one of HA supports DR? whats the issue in having all HAs as DHCP relay agents? Vijay From nemo-bounces@ietf.org Wed Sep 07 03:55:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECum3-0007JA-Hu; Wed, 07 Sep 2005 03:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECulz-0007Gt-L4 for nemo@megatron.ietf.org; Wed, 07 Sep 2005 03:55:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03327 for ; Wed, 7 Sep 2005 03:55:08 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECup5-0004e1-80 for nemo@ietf.org; Wed, 07 Sep 2005 03:58:24 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 76B2770902; Wed, 7 Sep 2005 09:54:58 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 599B7708FC; Wed, 7 Sep 2005 09:54:56 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng In-Reply-To: <1126017213.2181.63.camel@localhost> References: <1126005133.7897.87.camel@acorde> <1126017213.2181.63.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NbmKshyY7XcGDz+YWc+Q" Organization: UC3M Date: Wed, 07 Sep 2005 09:54:51 +0200 Message-Id: <1126079691.8358.21.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: "Pascal Thubert \(pthubert\)" , IETF NEMO WG Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-NbmKshyY7XcGDz+YWc+Q Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Chan-Wah, Thanks for your reply. Comments inline... El mar, 06-09-2005 a las 22:33 +0800, Chan-Wah Ng escribi=F3: > Hello Carlos, >=20 > Thank you for reading the draft so soon, and the valuable comments. See > my response in-line. I will try my best to respond to all your > comments, but some I will leave to my other co-authors to address. >=20 >=20 > On Tue, 2005-09-06 at 13:12 +0200, Carlos Jes=FAs Bernardos Cano wrote: > > Hi draft authors and all, > >=20 > > I've read the draft and I have some comments. > >=20 > > First of all, a general comment about the structure of the document. > > IMHO, I'm not quite sure about if it's a good idea to present the > > different scenarios of NEMO RO in the way it is done now. In my > > understanding, a discussion about the scenarios of NEMO RO is needed, > > but more focused in which and how the different aspects that contribute > > to the inefficiencies due to the use of the NEMO Basic Support protocol > > could be mitigated/avoided, without taking into account and making any > > explicit reference to existing solutions. After that, it's fine to > > present the issues of potential NEMO RO solution, before exploring the > > solution space (in this section, references to existing solutions are > > more appropriate, IMHO). >=20 > So, if I understand your point of view correctly, you feel that all > references to existing proposals should be moved to Sect 5? Yes, that's right. I think that references to existing proposals should be in the "Analysis of Solution Space" section (section 5). >=20 > >=20 > > Regarding more specific comments of some parts of the document, I have > > the following: > >=20 > > - In the section 3.2.2, it is said "The aim is to reduce the > > amplification effect of nested tunnels due to the nesting of tunnels > > between the Visiting Mobile Node and its Home Agent within the tunnel > > between the parent Mobile Router and the parent Mobile Router's Home > > Agent". I don't fully understand why it says "Visiting Mobile Node", > > since there may be several tunnels not only because a VMN visits a NEMO= , > > but also because of several nested MRs. I think that the terminology ma= y > > lead to confusion in some parts of the document, when Mobile Node, > > Visiting Mobile Node and Mobile Network Node is used. Again, the text i= s > > confusing to me when says "Such a solution will seek to minimize the > > number of tunnels possibly by collapsing the amount of tunnels required > > through some form of signaling between Mobile Nodes, or between Mobile > > Nodes and their Home Agents". >=20 > We are tyring to be consistent with draft-ietf-nemo-terminology. It is, > i think, an unfortunate circumstances that RFC3775 uses the term Mobile > Node when Mobile Host is more appropriate. >=20 > The term VMN refers to both visiting mobile hosts and visiting mobile > routers, so the use of VMN includes the case of nested MRs. We are > trying to write as concisely as possible here, considering the draft is > already 39 pages long. However, we may have overdone it and lose some > clarity for the sake of conciseness. I will try to clean up the text a > bit to make it less confusing. OK. I was wrong then. I always think of a VMN as a Mobile Host... >=20 > >=20 > > - In the section 3.3. it is said that "This may be used to eliminate > > the multiple tunnels caused by nesting of Mobile Nodes.". What is > > nesting of Mobile Nodes? Again, for me the terminology used is > > confusing. Does it refer to VMNs that connect to a NEMO? > >=20 > > - In the section 3.4, the use of delegation of a single prefix to a > > nested NEMO is pointed out. It is said that in that case, the MRs would > > have to perform ND on behalf of the MNNs. If so, then the addresses of > > the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In > > that case, LFNs would not be supported. I think that some kind of > > address delegation may be useful for a potential NEMO RO solution, but > > I'm not so sure about the direct delegation of a prefix to every node i= n > > the nested NEMO. OTOH, I have to admit that I have not read the last > > drafts about prefix delegation, so maybe I'm missing something. > >=20 >=20 > This is one RO scheme where LFN is not supported. Because if LFN are to > be supported, they would break session continuity when the prefix is > changed. Then, IMHO, maybe it would be good to explicitly say in the document that this RO scheme does not support LFN. >=20 > The latest draft on prefix delegation has nothing to do with RO, AFAICS. > The draft we are referring to when the text was written is quite an old > draft, draft-leekj-nemo-ro-pd-02.txt >=20 >=20 > > - In the section 4, I would add an additional issue (or at least > > comment somewhere in the document) about the NEMO RO supporting > > non-mobile routers within a NEMO. Some of the currently proposed > > solutions does not support/cannot be applied when there is a legacy > > non-mobile router within a NEMO. Since, the NEMO Basic Support does > > support it, I think it should be pointed out. >=20 > Noted. >=20 > >=20 > > - In the section 4.1, it is said that the signalling overhead may scal= e > > to be unacceptable, especially to the resource-scarce mobile node. Is i= t > > assumed in this section that the MNN is the one that performs the RO > > tasks? In that case, and IMHO, introducing changes in the protocol > > operation of the MNNs is even worse than the limited capabilities that > > these nodes may have. OTOH, if the MR is the one that performs the RO > > tasks, although the limited capability problem of the MR remains to be > > valid, I'm not so sure about which nodes we are expecting to play the > > role of a MR. Maybe, it is not the general case that a limited device > > plays that role (for example in a NEMO deployed in a bus or a plane). >=20 > Noted, perhaps a more detailed analysis would be required here. I would > follow up on this with a separate mail by this week. >=20 > >=20 > > - The section 4.3 points out the problem of the increased delay during > > handoff that may occur due to NEMO RO. I agree on that, but maybe it'd > > be worth to say that this problem is similar to the one that is present > > in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especiall= y > > because of the Return Routability procedure) also adds latency, but to > > deal with that problem there are other proposals (e.g., FMIPv6 or > > HMIPv6) that are somehow independent to the RO problem. >=20 > Well, we expect that in some NEMO-RO proposals, the handoff delay will > be greater. For instance, consider a node behind 3 MRs. Certain NEMO > RO proposals may require each of these MR to signal the CA. Assuming > the signaling delay is d, then the delay for the node is anything > between (d, d+3d), worse than or at best equal to MIPv6 RO. Yes, I agree on the fact the some of the NEMO-RO proposals will increase the handover delay. What I was trying to point out is that in Mobile IPv6, the RO also increases the handover delay (Return Routability, Binding Update, etc.), so this increase is not new in NEMO. It could be higher than in MIPv6, but it not a new problem, and in MIPv6 they have dealt with it by designing new protocols focused in optimising the handover delays. >=20 > >=20 > > - The section 4.4 describes the New functionalities that may be needed > > for NEMO RO. It says that the smaller number of nodes required to be > > changed, the better and also points that there are some nodes that woul= d > > be preferred not to be changed (like LFNs). IMHO, maybe it would be > > useful also to say that reusing existing protocols (like MIPv6) would > > make also easier the deployment of new NEMO RO solutions. >=20 > Hmm.. I thought that is mentioned somewhere, but perhaps not explicitly. Maybe I missed it ;-) , I'll try to check it. > Noted. >=20 > >=20 > > - The section 5.1.1 describes the RO solution involving the MNN and th= e > > CN. IMHO, I'd say "new functionalities would be required" instead of > > "are required", since for example, MIPv6 capabilities of the nodes may > > be reused in some solutions falling in this category. The same comment > > applies to the section 5.1.2. >=20 > Ok. >=20 > >=20 > > - The section 5.1.3 says that solutions involving MR and CR may scale > > well, since a single RO session between the MR and CR can achieve RO > > between any MNN and any CN managed by the CR. I don't see this better > > scalability so well, I mean, IMHO there is a trade-off, depending on th= e > > specific scenario. Of course, if the CR is very close to the CN, the > > route would be very optimal, but in that case, if a MNN is communicatin= g > > to several CN located in different physical locations, then several CRs > > would be needed (so there is here an scalability problem, in terms of > > number of CRs neede). OTOH, if the CR is not so close to the CNs, there > > may be less CRs, but then the optimisation is not so optimal. I see > > something similar with the case described in the section 5.1.4. >=20 > You mention a very relevant point about tradeoff of the proximity of CR > to CN. But the text is not about this. Worst case scenario is that the > MR/MNN is communicating with one CR per CN. The number of session > maintained is the same as MIPv6 (i.e. 1 RO-session per CN). However, > the best case scenario is that the MR/MNN is communicating with multiple > CNs behind a CR. SO, using a CR would always result in less or at most > equal number of RO sessions. Thus we say the use of CR scales well. OK, I see now. Anyway, I think that it would be also interesting to include some comments about the problem of scalability and deployability in terms of number of required CRs (and their location). >=20 > >=20 > > - In the section 5.2, it is said that the node that is mobile is in th= e > > best position to detect its mobility, but what do you mean by "mobile"? > > that is physically moving or that is changing its point of attachment? > > Because, if the latter is meant, I don't see a MNN to necessarily be > > always mobile (e.g., a LFN is not). IMHO, the text needs to be clear. >=20 > OK. >=20 > >=20 > > - In the section 5.3, it is said that the detection of the RO > > capability may incur in additional delay. I suppose that it would be > > dependant on the specific solution, but as I see it, a NEMO RO solution > > would use the NEMO Basic Solution while trying to setup a RO session, s= o > > I don't see the delay due to the detection capability. >=20 > That is if it continues to use the NEMO-BS tunnel while detecting RO. > Some RO proposals may make it difficult to do this, for example a RO > proposal that embed signaling on-plane. To use NEMO-BS support at the > same, require the MR to duplicate a data packet, one to go through the > NEMO-BS tunnel, one to try the optimized path. It may not be such a > good idea in this case. OK, I see. Maybe I was thinking in the way MIPv6 performs RO, in which the BT is always used until the CN is first signalled with the BU. Maybe some text clarifying that would be useful in the document. >=20 > >=20 > > - The section 5.5.2 says that adding new options in Router > > Advertisements is to modify the protocol. IMHO, adding new options is > > just making use of the protocol, extending it with a new functionality, > > since new options can be defined (they would be discarded by nodes that > > do not support them) and implemented easily. >=20 > True. We will look into that. >=20 > >=20 > > - As I've pointed out before, I'm not so sure about the applicability > > of the Prefix Delegation and Neighbour Discovery Proxy solution with > > LFNs, since they involve changing the MNN's address when the NEMO moves= , > > or am I missing something? >=20 > As I responded before, RO this scheme does not support LFN. Same comment than in the other case. Maybe it's worth to say that explicitly. >=20 > >=20 > > - The section 5.8.1 points out that there are some WGs currently > > looking at the concern over the authenticity of addresses. We wrote a > > paper [1] about the general problem of making the NEMO RO secure, > > exploring some possible solution schemes (using CGAs for example, etc.)= . > > We can extend the paper in form of I-D if the WG considers it useful. >=20 > Yes, I think I have read the paper before, just that I got lazy trying > to seek out the complete bibliography. Thanks. >=20 > >=20 > > Some Editorial comments: > >=20 > > - Page 5, "lesser" instead of "least" in "... of a least cost ..." ?? > > - Page 5, "Quality of Service" instead of "Quality of Services" ?? > > - Page 12, "do" instead of "does" in "... the scenarios described in > > Section 3 does so ..." ?? > > - Page 23: "worthwhile" instead of "worth while" ?? > > - Page 26: "may be" instead of "maybe" in "... transmission maybe > > disrupted ..." ?? > > - Page 31: "detailed" instead of "detail" ?? >=20 > OK. >=20 > >=20 > > I have some comments about how MIRON (a NEMO RO particular solution > > cited in the draft that I'm co-author of) is described in the draft, an= d > > in general about the Mobile Router as a Proxy family of solutions. I'll > > send them in a separate mail. >=20 > You are welcomed. We interpret each proposal in our own way, and its > good to have authors of the proposals referred to in the draft to point > out to us some of our mis-interpretation. Plus please also remember > that (1) we are trying to be concise, (2) we generalize, and (3) we > document so many different proposals that we probably confuse > ourselves :). >=20 Thanks a lot. Kind Regards, Carlos J. > /rgds > /cwng >=20 > >=20 > > Hope this helps. > >=20 > > Thanks a lot for writing the draft. > >=20 > > Kind regards, > >=20 > > Carlos J. =20 > >=20 > > [1] Securing Route Optimisation in NEMO > > Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio = Soto > > Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, > > 2005. WIOPT 2005. Third International Symposium on=20 > > 3-7 April 2005 Page(s): 248 - 254 > >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-NbmKshyY7XcGDz+YWc+Q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHpzL7QxZUr+JuXQRAmvoAJ90IPNrMEv3l/yxYxzYC9VsZUDwaACghuMW yCA3ZdanpS4oMB9LtEB8FO4= =+/B2 -----END PGP SIGNATURE----- --=-NbmKshyY7XcGDz+YWc+Q-- From nemo-bounces@ietf.org Wed Sep 07 04:05:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuvw-0001id-W2; Wed, 07 Sep 2005 04:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuvs-0001ft-EE for nemo@megatron.ietf.org; Wed, 07 Sep 2005 04:05:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03782 for ; Wed, 7 Sep 2005 04:05:23 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECuyz-0005Ml-3N for nemo@ietf.org; Wed, 07 Sep 2005 04:08:37 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j8783ejX011212; Wed, 7 Sep 2005 17:03:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j8783fe28250; Wed, 7 Sep 2005 17:03:41 +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 j8783fT19212; Wed, 7 Sep 2005 17:03:41 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 16:01:32 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 36B201ED726; Wed, 7 Sep 2005 16:22:36 +0800 (SGT) From: Chan-Wah Ng To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1126013247.7897.115.camel@acorde> References: <1126013247.7897.115.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 07 Sep 2005 16:22:36 +0800 Message-Id: <1126081356.2181.98.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Sep 2005 08:01:32.0620 (UTC) FILETIME=[5C5630C0:01C5B382] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Marcelo Bagnulo Braun , Ignacio Soto Campos , IETF NEMO WG Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Carlos, I think we make the mistake of confusing the MIRON approach with an approach that IIRC was mentioned in the ML by Erik on MR changing the RR packets sent by MNN on the fly. I like to apologise for that, and will made the necessary rectification. On Tue, 2005-09-06 at 15:27 +0200, Carlos Jes=FAs Bernardos Cano wrote: > Hi draft authors and all, >=20 > I've read the draft and I have some comments regarding MIRON (an > specific solution I'm co-author of). I prefer to send them in a > different e-mail, to keep them separated from the general ones I've > already sent. >=20 > In the section 3.2.1, MIRON is cited for the first time, as a mechanism > that decreases the number of Home Agents in the path in a nested > scenario. This is not completely true, since MIRON, as it's currently > specified in draft-bernardos-nemo-miron-00.txt, does not deal with > nested mobile networks. The main aim of MIRON is to provide a RO > mechanisms for LFNs of a NEMO, when they are communicating with CNs, > avoiding the MRHA tunnel with the MR's HA. This is done, by the MR > performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO. >=20 True. Any case, if we decided to defer all reference to proposed solution from Sect 3 to Sect 5, this wouldn't be a problem. > However, nothing prevents this solution to be applied also in a nested > NEMO, avoiding the last tunnel, or even all the tunnels if the MR is > provided somehow with a topologically valid IPv6 address that is > reachable without traversing any HA. This can be done, for example, by > providing to every MR in the nested topology with an IPv6 address that > belongs to the foreign network that the root-MR is visiting (for > example, by using DHCPv6), and enabling (with routing among the MRs and > proxy ND) these address to be directly reachable anywhere in the > Internet (without needing any special node, such a HA, to be deployed in > the infrastructure). Okay. As I see it, to handle nested case, MIRON would most likely require the following: (1) combining with an approach that flatten the nested NEMO, such as using MANET routing, ND-Proxy, or PD from access network; or (2) changes to CA: requiring CA to do recursive look up at its BCE. >=20 > In the section 5.5.1, as far as I've understood, MIRON is classified as > a NEMO RO solution in which the "Mobile Router acts as a Transparent > Proxy". Firstly, for me it is not clear the distinction between "Mobile > Router as a Proxy" and "Mobile Router as a Transparent Proxy", since it > is said that - in the "Mobile Router as a Proxy" - the Mobile Router > uses standard Mobile IPv6 Route Optimisation procedure to bind the > address of a Mobile Network Node to the MR's CoA, and that's exactly > which MIRON does. Nevertheless, this "proxy" functionality requires the > MR to generate also the Return Routability signalling on behalf of the > LFNs, not only the Binding Updates messages. Besides, the packets > sent/received by the LFNs have to be modified, since they would be sent > by the CN addressed to the MR's CoA (carrying a type 2 RH), and the > packets sent by the LFN have to have the MR's CoA as their source > address (carrying a Home Address Destination Option). >=20 OK. I stand corrected: the MIRON approach should be correctly referred to as "Mobile Router as a Proxy" approach, as opposed to "Mobile Router as a Transparent Proxy". > OTOH, it is said that the "Mobile Router as a Transparent Proxy" works > by modifying MIPv6 RO packets sent to VMNs. This is not possible (at > least easily), since the HoTI and HoT messages sent by the VMNs have to > be sent using IPsec ESP, so the MR cannot modify these packets to set > its CoA as the VMN's CoA. Is it a must to ESP the communications between MN and HA? > I'd suggest to remove the "Mobile Router as a Transparent Proxy" section > and rewrite the "Mobile Router as a Proxy" section (I can provide some > text for discussion if you want). Yes, I would like that (the providing text part). But I am not so sure about removing the "Transparent Proxy" part. >=20 > The main aim and advantage of MIRON is providing a NEMO RO mechanism > suited for LFNs (that is, IPv6 nodes that do not have/use any mobility > support), by using the Mobile IPv6 RO already defined mechanism and, > therefore, not requiring any change on the operation of LFNs and CNs. >=20 Yes, now I get the picture. Thanks for your clarification. /rgds /cwng From nemo-bounces@ietf.org Wed Sep 07 04:32:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvM2-0006Y3-I5; Wed, 07 Sep 2005 04:32:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvLz-0006Xr-6p for nemo@megatron.ietf.org; Wed, 07 Sep 2005 04:32:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04640 for ; Wed, 7 Sep 2005 04:32:21 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECvP5-0005zO-Gp for nemo@ietf.org; Wed, 07 Sep 2005 04:35:38 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j878WAYi011551; Wed, 7 Sep 2005 17:32:10 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j878WAj15163; Wed, 7 Sep 2005 17:32:10 +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 j878WAB26065; Wed, 7 Sep 2005 17:32:10 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 16:30:01 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 759971ED726; Wed, 7 Sep 2005 16:51:06 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <431D91C5.2040505@motorola.com> References: <431D91C5.2040505@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 07 Sep 2005 16:51:06 +0800 Message-Id: <1126083066.2181.114.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Sep 2005 08:30:01.0789 (UTC) FILETIME=[5714AED0:01C5B386] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, See responses in-line. On Tue, 2005-09-06 at 14:55 +0200, Alexandru Petrescu wrote: > Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and thanks > for posting this draft. It captures in a single document much of the ro > solution space and possibilities. > > I have read it partially and I have a few comments. Thanks for reading it (albeit partially ;)). > > I would suggest using the terms "prefix ownership" instead of the mix > "identity" of "location" for Mobile Routers. While it is easy to > understand that the "identity" of a MH is its Home Address it is > difficult to agree that the MNP is the "identity" of a MR. It is easier > to understand that MR "owns" a certain prefix and the "identity" of that > MR is its Home Address. Hmm .. wait a minute. We are talking about identity of MNN, not MR. In NEMO, we always assume that it is the MNN behind the MR that is talking to a CN. So the binding at the CA should be a binding between identity of MNN and some location. Assuming the MNN is a LFN, its identity is derived from the MNP. So, the MNP is in fact an aggregation of all identities of MNNs on a Mobile Network Link. So, while I agree that the MNP is definitely not an identity of MR, I maintain that the MNP is an identity for MNNs. Having said that, things get a bit complicated if the MNN is in fact a VMN. In this case, its true identity is actually its own HoA, and has nothing to do with the MNP. However, I would argue in this case that the term "Identity" is used very loosely in the sense of binding between two addresses, one serving as identifier, the other as locator. > > I would suggest not using the terms "implicitly" and "explicitly" for > the two ways of representing an MNN's identity, because of the confusion > that may arise with the terms "implicit" and "explicit" of the NEMO > modes of operation. The NEMO Basic Support MR uses "implicit" mode of > signalling to HA its CoA by _not_ including MNP in the BU and "explicit" > mode by including MNP in the BU. The document on ro space analysis uses > "implicitly" to represent MNP's identity by the use of MNP and > "explicitly" by the use of its address. Hmm.. okay, point taken. But would it really be that confusing? I am willing to change it if I or someone can come up with other expressions. > > I would suggest to use "identity" to stand for MR's Home Address > exclusively. > > > Binding Update with Mobile Network Prefix > > > > This can be viewed as a logical extension to NEMO Basic Support, > > where the Mobile Router would send binding updates containing one or > > more Mobile Network Prefix options to the Correspondent Agent. The > > Correspondent Agent having received the Binding Update, can then set > > up a bi-directional tunnel with the Mobile Router at the current > > care-of address of the Mobile Router, and inject a route to its > > routing table so that packets destined for addresses in the mobile > > network prefix will be routed through the bi-directional tunnel. > > Actually I think the packets addressed to nodes in the moving network > will be routed with a routing header and not encapsulated through a > bi-directional tunnel. Well, both ways could be done. However, using a routing header would mean that the recipient (i.e. MNN) need to be able to support this routing header, which may not be that practical. It also means that the MNN is somewhat aware of the RO session. Using a bi-directional tunnel would keep the MNN completely out of the equation. > > > Although the Return Routability procedure allows the Correspondent > > Agent to verify that the care-of and home addresses of the Mobile > > Router are indeed collocated, it does not allow the Correspondent > > Agent to verify the validity of the Mobile Network Prefix. > > Right, and additionally it is difficult to design a method for testing > the return routability for each and every address falling with the MNP > limits. > Correct. /rgds /cwng From nemo-bounces@ietf.org Wed Sep 07 04:45:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvYt-0000ki-Ef; Wed, 07 Sep 2005 04:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvYr-0000jk-S5 for nemo@megatron.ietf.org; Wed, 07 Sep 2005 04:45:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05238 for ; Wed, 7 Sep 2005 04:45:37 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECvbv-0006L9-T7 for nemo@ietf.org; Wed, 07 Sep 2005 04:48:52 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 9C90E70A27; Wed, 7 Sep 2005 10:45:27 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2F78870A24; Wed, 7 Sep 2005 10:45:26 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng In-Reply-To: <1126081356.2181.98.camel@localhost> References: <1126013247.7897.115.camel@acorde> <1126081356.2181.98.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VMXgoxU0yTSdQZbiDCdP" Organization: UC3M Date: Wed, 07 Sep 2005 10:45:25 +0200 Message-Id: <1126082725.8358.37.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: "Pascal Thubert \(pthubert\)" , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Marcelo Bagnulo Braun , Ignacio Soto Campos , IETF NEMO WG Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-VMXgoxU0yTSdQZbiDCdP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Chan-Wah, Please see comments inline... El mi=E9, 07-09-2005 a las 16:22 +0800, Chan-Wah Ng escribi=F3: > Hello Carlos, >=20 > I think we make the mistake of confusing the MIRON approach with an > approach that IIRC was mentioned in the ML by Erik on MR changing the RR > packets sent by MNN on the fly. >=20 > I like to apologise for that, and will made the necessary rectification. No problem :-) >=20 > On Tue, 2005-09-06 at 15:27 +0200, Carlos Jes=FAs Bernardos Cano wrote: > > Hi draft authors and all, > >=20 > > I've read the draft and I have some comments regarding MIRON (an > > specific solution I'm co-author of). I prefer to send them in a > > different e-mail, to keep them separated from the general ones I've > > already sent. > >=20 > > In the section 3.2.1, MIRON is cited for the first time, as a mechanism > > that decreases the number of Home Agents in the path in a nested > > scenario. This is not completely true, since MIRON, as it's currently > > specified in draft-bernardos-nemo-miron-00.txt, does not deal with > > nested mobile networks. The main aim of MIRON is to provide a RO > > mechanisms for LFNs of a NEMO, when they are communicating with CNs, > > avoiding the MRHA tunnel with the MR's HA. This is done, by the MR > > performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO. > >=20 >=20 > True. Any case, if we decided to defer all reference to proposed > solution from Sect 3 to Sect 5, this wouldn't be a problem. OK >=20 > > However, nothing prevents this solution to be applied also in a nested > > NEMO, avoiding the last tunnel, or even all the tunnels if the MR is > > provided somehow with a topologically valid IPv6 address that is > > reachable without traversing any HA. This can be done, for example, by > > providing to every MR in the nested topology with an IPv6 address that > > belongs to the foreign network that the root-MR is visiting (for > > example, by using DHCPv6), and enabling (with routing among the MRs and > > proxy ND) these address to be directly reachable anywhere in the > > Internet (without needing any special node, such a HA, to be deployed i= n > > the infrastructure). >=20 > Okay. As I see it, to handle nested case, MIRON would most likely > require the following: > (1) combining with an approach that flatten the nested NEMO, such as > using MANET routing, ND-Proxy, or PD from access network; or > (2) changes to CA: requiring CA to do recursive look up at its BCE. >=20 > >=20 > > In the section 5.5.1, as far as I've understood, MIRON is classified as > > a NEMO RO solution in which the "Mobile Router acts as a Transparent > > Proxy". Firstly, for me it is not clear the distinction between "Mobile > > Router as a Proxy" and "Mobile Router as a Transparent Proxy", since it > > is said that - in the "Mobile Router as a Proxy" - the Mobile Router > > uses standard Mobile IPv6 Route Optimisation procedure to bind the > > address of a Mobile Network Node to the MR's CoA, and that's exactly > > which MIRON does. Nevertheless, this "proxy" functionality requires the > > MR to generate also the Return Routability signalling on behalf of the > > LFNs, not only the Binding Updates messages. Besides, the packets > > sent/received by the LFNs have to be modified, since they would be sent > > by the CN addressed to the MR's CoA (carrying a type 2 RH), and the > > packets sent by the LFN have to have the MR's CoA as their source > > address (carrying a Home Address Destination Option). > >=20 >=20 > OK. I stand corrected: the MIRON approach should be correctly referred > to as "Mobile Router as a Proxy" approach, as opposed to "Mobile Router > as a Transparent Proxy". >=20 > > OTOH, it is said that the "Mobile Router as a Transparent Proxy" works > > by modifying MIPv6 RO packets sent to VMNs. This is not possible (at > > least easily), since the HoTI and HoT messages sent by the VMNs have to > > be sent using IPsec ESP, so the MR cannot modify these packets to set > > its CoA as the VMN's CoA. >=20 > Is it a must to ESP the communications between MN and HA? I think so. RFC 3775 says: "10.4.6. Protecting Return Routability Packets The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. Therefore, the home agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure. Support for a non-null encryption transform and authentication algorithm MUST be available." >=20 > > I'd suggest to remove the "Mobile Router as a Transparent Proxy" sectio= n > > and rewrite the "Mobile Router as a Proxy" section (I can provide some > > text for discussion if you want). >=20 > Yes, I would like that (the providing text part). But I am not so sure > about removing the "Transparent Proxy" part. OK, but I'm not sure if it is possible to have such a transparent proxy solution. >=20 > >=20 > > The main aim and advantage of MIRON is providing a NEMO RO mechanism > > suited for LFNs (that is, IPv6 nodes that do not have/use any mobility > > support), by using the Mobile IPv6 RO already defined mechanism and, > > therefore, not requiring any change on the operation of LFNs and CNs. > >=20 >=20 > Yes, now I get the picture. Thanks for your clarification. Thanks. Kind Regards, Carlos J. >=20 > /rgds > /cwng --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-VMXgoxU0yTSdQZbiDCdP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHqil7QxZUr+JuXQRAj9EAKCy6Q1kzhjID2cVgWXFq0BXq3GLMACeOSGo O1tUqz1BeGcdYawMJNspbHI= =XgbH -----END PGP SIGNATURE----- --=-VMXgoxU0yTSdQZbiDCdP-- From nemo-bounces@ietf.org Wed Sep 07 05:44:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwTa-0003cw-G0; Wed, 07 Sep 2005 05:44:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwTY-0003Yb-FU for nemo@megatron.ietf.org; Wed, 07 Sep 2005 05:44:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07182 for ; Wed, 7 Sep 2005 05:44:14 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECwWf-0007nZ-Kr for nemo@ietf.org; Wed, 07 Sep 2005 05:47:32 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j879sfF4007596; Wed, 7 Sep 2005 02:54:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j879q4HR009208; Wed, 7 Sep 2005 04:52:05 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A73D8865980; Wed, 7 Sep 2005 11:43:59 +0200 (CEST) Message-ID: <431EB65F.4050001@motorola.com> Date: Wed, 07 Sep 2005 11:43:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt References: <431D91C5.2040505@motorola.com> <1126083066.2181.114.camel@localhost> In-Reply-To: <1126083066.2181.114.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > Hello Alex, > > See responses in-line. > > > On Tue, 2005-09-06 at 14:55 +0200, Alexandru Petrescu wrote: > >> Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and >> thanks for posting this draft. It captures in a single document >> much of the ro solution space and possibilities. >> >> I have read it partially and I have a few comments. > > > Thanks for reading it (albeit partially ;)). > > >> I would suggest using the terms "prefix ownership" instead of the >> mix "identity" of "location" for Mobile Routers. While it is easy >> to understand that the "identity" of a MH is its Home Address it is >> difficult to agree that the MNP is the "identity" of a MR. It is >> easier to understand that MR "owns" a certain prefix and the >> "identity" of that MR is its Home Address. > > > Hmm .. wait a minute. We are talking about identity of MNN, not MR. > In NEMO, we always assume that it is the MNN behind the MR that is > talking to a CN. So the binding at the CA should be a binding > between identity of MNN and some location. Even so it does not follow. Clearly the MNP can not be the identity of any unique node: not the identity of an MR, not the identity of an MNN, not the identity of an LFN. > Assuming the MNN is a LFN, its identity is derived from the MNP. So, > the MNP is in fact an aggregation of all identities of MNNs on a > Mobile Network Link. > > So, while I agree that the MNP is definitely not an identity of MR, I > maintain that the MNP is an identity for MNNs. Even if MNP is the identity of all the MNNs that derive their addresses from it it's difficult to understand. Identity of a host should be a unique value representative for that host. MNP being an identity for several hosts it means that those hosts have the same identity, indistinguishable from one another. If the MNP is the identity of all LFNs then do LFNs still use their (Home) Address as an identifier? Which is the right identifier for an LFN - its MNP or its Address? > Having said that, things get a bit complicated if the MNN is in fact > a VMN. In this case, its true identity is actually its own HoA, and > has nothing to do with the MNP. I agree. So how about LFN, what best represents the identity of LFN - its address or the MNP? > However, I would argue in this case that the term "Identity" is used > very loosely in the sense of binding between two addresses, one > serving as identifier, the other as locator. The discussion identifier vs locator raised much controversy in the past. I don't see why trying to extend the discussion identifier vs locator from Mobile Hosts to Mobile Routers. Just because for Mobile Hosts the identifier is the Home Address could not mean that we must find a similar identifier for Mobile Routers, right? The RO problem and RO solution space can exist and have been described in illustrative terms w/o using the identifier vs locator discussion. >> I would suggest not using the terms "implicitly" and "explicitly" >> for the two ways of representing an MNN's identity, because of the >> confusion that may arise with the terms "implicit" and "explicit" >> of the NEMO modes of operation. The NEMO Basic Support MR uses >> "implicit" mode of signalling to HA its CoA by _not_ including MNP >> in the BU and "explicit" mode by including MNP in the BU. The >> document on ro space analysis uses "implicitly" to represent MNP's >> identity by the use of MNP and "explicitly" by the use of its >> address. > > > Hmm.. okay, point taken. But would it really be that confusing? I > am willing to change it if I or someone can come up with other > expressions. In my oppinion, "explicit and implicit" ways of representing identities is difficult to understand already because it relates to "identities". > Normally, Route Optimization would mean that a binding between the > Mobile Network Node's identity and location is registered at the > Correspondent Agent. Before exploring into different ways of binding > location to identity (see Section 5.5), one must first ask how the > identity of the Mobile Network Node is represented. Even if there were any particular ways of representing an identity NEMO shouldn't care about it. Maybe HIP, CGA and other WGs - yes. I could well imagine the multihoming space with SHIM or Monami6 also take identity as a central goal. But RO solution space no. > 5.5 How is Identity Bound to Location? ... to the location of the > parent Mobile Router; ... to a sequence of locations ... ... to the > location of the root ... The question doesn't fit the answer. The right question would have been "To what location should the Identity be bound". And, instead of using the terminology "identity vs location" one could re-formulate as: What is the contents of a binding cache entry? 1. MR's CoA, LFN's HoA. 2. MR1's CoA, MR2's CoA... MRn's CoA, LFN's HoA where MR1..MRn are nested. 3. TLMR's CoA, LFN's HoA. >>> This can be viewed as a logical extension to NEMO Basic Support, >>> where the Mobile Router would send binding updates containing one >>> or more Mobile Network Prefix options to the Correspondent Agent. >>> The Correspondent Agent having received the Binding Update, can >>> then set up a bi-directional tunnel with the Mobile Router at the >>> current care-of address of the Mobile Router, and inject a route >>> to its routing table so that packets destined for addresses in >>> the mobile network prefix will be routed through the >>> bi-directional tunnel. >> >> Actually I think the packets addressed to nodes in the moving >> network will be routed with a routing header and not encapsulated >> through a bi-directional tunnel. > > > Well, both ways could be done. However, using a routing header would > mean that the recipient (i.e. MNN) need to be able to support this > routing header, which may not be that practical. It also means that > the MNN is somewhat aware of the RO session. Using a bi-directional > tunnel would keep the MNN completely out of the equation. Yes, sorry, I always seem to forget this aspect. Alex From nemo-bounces@ietf.org Wed Sep 07 07:10:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxpJ-0003HF-3r; Wed, 07 Sep 2005 07:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxpG-0003Gu-SF for nemo@megatron.ietf.org; Wed, 07 Sep 2005 07:10:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10265 for ; Wed, 7 Sep 2005 07:10:44 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECxsP-0001Sg-RN for nemo@ietf.org; Wed, 07 Sep 2005 07:14:03 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7A4F589852; Wed, 7 Sep 2005 14:10:31 +0300 (EEST) Message-ID: <431ECAB3.80005@piuha.net> Date: Wed, 07 Sep 2005 14:10:43 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] More comments on the RO problem statement draft References: <431328D8.9080002@motorola.com> <43153404.8090204@kddilabs.jp> <43159CD1.3060609@motorola.com> In-Reply-To: <43159CD1.3060609@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: >Maybe it would be easier to say something along the lines of this: if >NEMO uses RO then there is more probability that moving networks will be >allowed (policy-wise) to connect to each other. Does this follow? > > Not necessarily. Firstly, there might be networks that want to have all traffic inspected to begin with, even with their own nodes. Secondly, you would need an RO solution that does not need the home network at all, as otherwise this does not alleviate the home network admin's fear that bad packets will be routed to it. Finally, you would assume that someone who deploys nemo routers designs their network in a manner that matches the desired user population, e.g. own users -> their internal network, any users -> only the external network. But I do agree that it sounds somewhat dangerous to let in anyone and route the traffic through your home network, even if its only the external side. Any spam/illegal content etc. problems would first be blamed on you, not the unauthenticated users. There's also the question of whether its NEMO or something else that solves this problem. Presumably if you worry about this then you could also require network access authentication. --Jari From nemo-bounces@ietf.org Wed Sep 07 07:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyIq-0001K7-2V; Wed, 07 Sep 2005 07:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyIn-0001H3-R9 for nemo@megatron.ietf.org; Wed, 07 Sep 2005 07:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13064 for ; Wed, 7 Sep 2005 07:41:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECyLw-0002Oy-7x for nemo@ietf.org; Wed, 07 Sep 2005 07:44:34 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 07 Sep 2005 13:41:06 +0200 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 j87BeSVv029199; Wed, 7 Sep 2005 13:41: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.0); Wed, 7 Sep 2005 13:41:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] More comments on the RO problem statement draft Date: Wed, 7 Sep 2005 13:40:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC013D0814@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] More comments on the RO problem statement draft Thread-Index: AcWznOwLZIK3iDlBQ+qpGfDB4hfJDgAA0z4Q From: "Pascal Thubert \(pthubert\)" To: "Jari Arkko" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Sep 2005 11:41:03.0093 (UTC) FILETIME=[068CE250:01C5B3A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Jari Arkko >Sent: Wednesday, September 07, 2005 1:11 PM >To: Alexandru Petrescu >Cc: IETF NEMO WG >Subject: Re: [nemo] More comments on the RO problem statement draft > >Alexandru Petrescu wrote: > >>Maybe it would be easier to say something along the lines of this: if >>NEMO uses RO then there is more probability that moving networks will be >>allowed (policy-wise) to connect to each other. Does this follow? >> >> >Not necessarily. Firstly, there might be networks >that want to have all traffic inspected to begin with, >even with their own nodes. Secondly, you would >need an RO solution that does not need the home network >at all, as otherwise this does not alleviate the home >network admin's fear that bad packets will be routed >to it. [ [] I really like those words a lot. I believe we should add them to the text in the draft almost as is... Finally, you would assume that someone who >deploys nemo routers designs their network in >a manner that matches the desired user population, >e.g. own users -> their internal network, any users -> >only the external network. > >But I do agree that it sounds somewhat dangerous >to let in anyone and route the traffic through your >home network, even if its only the external side. Any >spam/illegal content etc. problems would first be >blamed on you, not the unauthenticated users. > >There's also the question of whether its NEMO or >something else that solves this problem. Presumably >if you worry about this then you could also require >network access authentication. > [] What we tried to point out in that chapter was that an RO solution might enable the MR to forward blindly the packets in the hot potato fashion (anonymously and innocuously). If such an RO is devised, then it might alleviate some fears about letting some "external network" opened for tit4tat. Same reason we went for RH2, thinking that maybe that would help devising firewall policies. Pascal From nemo-bounces@ietf.org Wed Sep 07 07:53:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyUV-0004Gz-BS; Wed, 07 Sep 2005 07:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyUT-0004Gu-IW for nemo@megatron.ietf.org; Wed, 07 Sep 2005 07:53:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13700 for ; Wed, 7 Sep 2005 07:53:20 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECyXd-0002m6-Km for nemo@ietf.org; Wed, 07 Sep 2005 07:56:38 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j87Br8Yi007400; Wed, 7 Sep 2005 20:53:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j87BrBM02739; Wed, 7 Sep 2005 20:53:11 +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 j87BrBc26550; Wed, 7 Sep 2005 20:53:11 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 19:50:38 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 95BDE1ED726; Wed, 7 Sep 2005 20:11:43 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <431EB65F.4050001@motorola.com> References: <431D91C5.2040505@motorola.com> <1126083066.2181.114.camel@localhost> <431EB65F.4050001@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 07 Sep 2005 20:11:43 +0800 Message-Id: <1126095103.2181.135.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Sep 2005 11:50:38.0289 (UTC) FILETIME=[5D64D410:01C5B3A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, Ok, so you are not happy with the terms identity (vs locator). I am now challenging you to come up with more adequate terms. Yes, I know you suggested going into specific (MR's CoA, LFN's HoA). However, that's what we want to avoid. The good thing about going into specific is that it is not ambiguous. However, it is only suitable for a specification. This draft, however, is trying to generalize the RO solution space. If I use terms "LFN's HoA is bount to MR's CoA", I foresee even more objections: (1) XXX: "Hey, but my proposal is not LFN's HoA is bound to MR's CoA, its bound to MR's HoA" (2) YYY: "Hey, but LFN has no HoA nor CoA. Its simply an *address*." (3) ZZZ: "Hey, you fail to consider VMN's CoA ..." no, its a rat hole I am trying to avoid. I need terms X and Y that are general enough to represent "X is bound to Y", where X can be anything from LFN's address, VMN's CoA, MNN's HoA, MNP, and Y can be anything from MR's HoA, MR's CoA, TLMR's CoA, a series of MRs' CoA, etc ... The best terms I have come up with is location and identity. If you have better suggestions, let me know and I'll appreciate that. Else, I think this debate is going nowhere. /rgds /cwng On Wed, 2005-09-07 at 11:43 +0200, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > Hello Alex, > > > > See responses in-line. > > > > > > On Tue, 2005-09-06 at 14:55 +0200, Alexandru Petrescu wrote: > > > >> Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and > >> thanks for posting this draft. It captures in a single document > >> much of the ro solution space and possibilities. > >> > >> I have read it partially and I have a few comments. > > > > > > Thanks for reading it (albeit partially ;)). > > > > > >> I would suggest using the terms "prefix ownership" instead of the > >> mix "identity" of "location" for Mobile Routers. While it is easy > >> to understand that the "identity" of a MH is its Home Address it is > >> difficult to agree that the MNP is the "identity" of a MR. It is > >> easier to understand that MR "owns" a certain prefix and the > >> "identity" of that MR is its Home Address. > > > > > > Hmm .. wait a minute. We are talking about identity of MNN, not MR. > > In NEMO, we always assume that it is the MNN behind the MR that is > > talking to a CN. So the binding at the CA should be a binding > > between identity of MNN and some location. > > Even so it does not follow. Clearly the MNP can not be the identity of > any unique node: not the identity of an MR, not the identity of an MNN, > not the identity of an LFN. > > > Assuming the MNN is a LFN, its identity is derived from the MNP. So, > > the MNP is in fact an aggregation of all identities of MNNs on a > > Mobile Network Link. > > > > So, while I agree that the MNP is definitely not an identity of MR, I > > maintain that the MNP is an identity for MNNs. > > Even if MNP is the identity of all the MNNs that derive their addresses > from it it's difficult to understand. Identity of a host should be a > unique value representative for that host. MNP being an identity for > several hosts it means that those hosts have the same identity, > indistinguishable from one another. > > If the MNP is the identity of all LFNs then do LFNs still use their > (Home) Address as an identifier? Which is the right identifier for an > LFN - its MNP or its Address? > > > Having said that, things get a bit complicated if the MNN is in fact > > a VMN. In this case, its true identity is actually its own HoA, and > > has nothing to do with the MNP. > > I agree. So how about LFN, what best represents the identity of LFN - > its address or the MNP? > > > However, I would argue in this case that the term "Identity" is used > > very loosely in the sense of binding between two addresses, one > > serving as identifier, the other as locator. > > The discussion identifier vs locator raised much controversy in the > past. I don't see why trying to extend the discussion identifier vs > locator from Mobile Hosts to Mobile Routers. Just because for Mobile > Hosts the identifier is the Home Address could not mean that we must > find a similar identifier for Mobile Routers, right? > > The RO problem and RO solution space can exist and have been described > in illustrative terms w/o using the identifier vs locator discussion. > > >> I would suggest not using the terms "implicitly" and "explicitly" > >> for the two ways of representing an MNN's identity, because of the > >> confusion that may arise with the terms "implicit" and "explicit" > >> of the NEMO modes of operation. The NEMO Basic Support MR uses > >> "implicit" mode of signalling to HA its CoA by _not_ including MNP > >> in the BU and "explicit" mode by including MNP in the BU. The > >> document on ro space analysis uses "implicitly" to represent MNP's > >> identity by the use of MNP and "explicitly" by the use of its > >> address. > > > > > > Hmm.. okay, point taken. But would it really be that confusing? I > > am willing to change it if I or someone can come up with other > > expressions. > > In my oppinion, "explicit and implicit" ways of representing identities > is difficult to understand already because it relates to "identities". > > > Normally, Route Optimization would mean that a binding between the > > Mobile Network Node's identity and location is registered at the > > Correspondent Agent. Before exploring into different ways of binding > > location to identity (see Section 5.5), one must first ask how the > > identity of the Mobile Network Node is represented. > > Even if there were any particular ways of representing an identity NEMO > shouldn't care about it. Maybe HIP, CGA and other WGs - yes. I could > well imagine the multihoming space with SHIM or Monami6 also take > identity as a central goal. But RO solution space no. > > > 5.5 How is Identity Bound to Location? ... to the location of the > > parent Mobile Router; ... to a sequence of locations ... ... to the > > location of the root ... > > The question doesn't fit the answer. The right question would have been > "To what location should the Identity be bound". > > And, instead of using the terminology "identity vs location" one could > re-formulate as: > > What is the contents of a binding cache entry? > 1. MR's CoA, LFN's HoA. > 2. MR1's CoA, MR2's CoA... MRn's CoA, LFN's HoA where MR1..MRn are > nested. > 3. TLMR's CoA, LFN's HoA. > > >>> This can be viewed as a logical extension to NEMO Basic Support, > >>> where the Mobile Router would send binding updates containing one > >>> or more Mobile Network Prefix options to the Correspondent Agent. > >>> The Correspondent Agent having received the Binding Update, can > >>> then set up a bi-directional tunnel with the Mobile Router at the > >>> current care-of address of the Mobile Router, and inject a route > >>> to its routing table so that packets destined for addresses in > >>> the mobile network prefix will be routed through the > >>> bi-directional tunnel. > >> > >> Actually I think the packets addressed to nodes in the moving > >> network will be routed with a routing header and not encapsulated > >> through a bi-directional tunnel. > > > > > > Well, both ways could be done. However, using a routing header would > > mean that the recipient (i.e. MNN) need to be able to support this > > routing header, which may not be that practical. It also means that > > the MNN is somewhat aware of the RO session. Using a bi-directional > > tunnel would keep the MNN completely out of the equation. > > Yes, sorry, I always seem to forget this aspect. > > Alex > From nemo-bounces@ietf.org Wed Sep 07 08:37:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzBX-00057L-Qg; Wed, 07 Sep 2005 08:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzBV-00057F-LD for nemo@megatron.ietf.org; Wed, 07 Sep 2005 08:37:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16205 for ; Wed, 7 Sep 2005 08:37:48 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECzEe-00048H-F7 for nemo@ietf.org; Wed, 07 Sep 2005 08:41:06 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j87CmIbD027199; Wed, 7 Sep 2005 05:48:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j87Ci64f008647; Wed, 7 Sep 2005 07:44:06 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id EB50C8637E6; Wed, 7 Sep 2005 14:37:37 +0200 (CEST) Message-ID: <431EDF11.7070405@motorola.com> Date: Wed, 07 Sep 2005 14:37:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt References: <431D91C5.2040505@motorola.com> <1126083066.2181.114.camel@localhost> <431EB65F.4050001@motorola.com> <1126095103.2181.135.camel@localhost> In-Reply-To: <1126095103.2181.135.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Chan-Wah, thanks for replying. Chan-Wah Ng wrote: > Hello Alex, > > Ok, so you are not happy with the terms identity (vs locator). I am > now challenging you to come up with more adequate terms. > > Yes, I know you suggested going into specific (MR's CoA, LFN's HoA). > However, that's what we want to avoid. The good thing about going > into specific is that it is not ambiguous. However, it is only > suitable for a specification. This draft, however, is trying to > generalize the RO solution space. Generalize the solution space... hmmm. > If I use terms "LFN's HoA is bount to MR's CoA", I foresee even more > objections: > > (1) XXX: "Hey, but my proposal is not LFN's HoA is bound to MR's CoA, > its bound to MR's HoA" Ok, one could say it that way. And I perfectly understand that phrase. I like it much better than saying "MNN identity not bound to MR identity, but bound to MR location". > (2) YYY: "Hey, but LFN has no HoA nor CoA. Its simply an *address*." Ok, and I perfectly agree with using "LFN's address" instead of "LFN's identity". > (3) ZZZ: "Hey, you fail to consider VMN's CoA ..." Using "identifier" and "locator" terms are as useless as using the "VMN" term. "VMN" is in no way different than "MN" in terms of what protocols they implement and code they execute. Other potential discussions that rely on "id vs locator" is "VMN's location belongs to the MR's identity but VMN's identity is not MR's identity". > no, its a rat hole I am trying to avoid. Yes, me too, that is why I suggest not using the locator vs identifier discussion in the ro solution space draft. > I need terms X and Y that are general enough to represent "X is bound > to Y", where X can be anything from LFN's address, VMN's CoA, MNN's > HoA, MNP, and Y can be anything from MR's HoA, MR's CoA, TLMR's CoA, > a series of MRs' CoA, etc ... > > The best terms I have come up with is location and identity. If you > have better suggestions, let me know and I'll appreciate that. Else, > I think this debate is going nowhere. Sorry, I don't mean to get the debate nowhere. Implementation-wise here's terminology: "VMN" term makes no sense: it's either an MH or an MR. "VMN" implements nothing else than Mobile IPv6. "MNN" term makes no sense: it's either an MH or an MR or an LFN. "TLMR" makes no sense: it's an MR. VMN, MNN and TLMR was used in informal discussions to mean the following: VMN is an MH that visits an MR's moving network and that has a different HA than that MR. MNN has same HA. TLMR is an MR that is attaching to a fixed infrastructure and below which several MR's are attaching in a nested manner, none being attached to the fixed infrastructure. That gives: "LFN's address is bound to MR's Home Address" "LFN's address is bound to MR's Care-of Address" "LFN's address is bound to the MR's Care-of Address that is attached to the fixed infrastructure". "LFN's address is bound to a series of MRs' Care-of Addresses within which that LFN is nested" "MH's Care-of Address is bound to ..." "MH's Home Address is bound to ..." "MR's Care-of Address is bound to ..." "MR's Home Address is bound to ..." Which in the end leads to: "In the RO solution space, address bindings maintained at the CN may be structured differently. Addresses or prefixes of a host or of a router may be bound to each other or to addresses or prefixes of another host or router. For example, in a moving network composed of an LFN and an MR, the LFN's address may be bound to MR's CoA. Alternatively, the LFN's address may be bound to the MNP owned by that MR. In another example where two nested moving networks are employed, the LFN's address may be bound to both MR's Care-of Addresses. Each different structure for the binding represents a different RO solution". In my oppinion this stays generic enough and still suggests real behaviour. Just two cents worth. Thanks again for putting up the draft. Alex From nemo-bounces@ietf.org Wed Sep 07 09:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzaF-0003EJ-G4; Wed, 07 Sep 2005 09:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzaB-0003Du-Qz for nemo@megatron.ietf.org; Wed, 07 Sep 2005 09:03:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17902 for ; Wed, 7 Sep 2005 09:03:18 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECzdL-0004xF-21 for nemo@ietf.org; Wed, 07 Sep 2005 09:06:37 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j87D3GBO015494 for ; Wed, 7 Sep 2005 06:03:16 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j87D8gDl015551 for ; Wed, 7 Sep 2005 08:08:43 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C792F865980 for ; Wed, 7 Sep 2005 15:03:13 +0200 (CEST) Message-ID: <431EE511.7050503@motorola.com> Date: Wed, 07 Sep 2005 15:03:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [nemo] RO solution space - CA is Certificate Authority X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Authors of RO solution space draft, thanks for posting it. I keep reading and find it useful. I have terminology comments (it's only terminology, not any paramountly important issue). CA is established as Certificate Authority, it relates to IP and IPsec, it's in wide use in an area where I am looking. Correspondent Agent may not be the right term because it leads to CA abbreviation. Somebody else may propose another term, like e.g. Correspondent Node's Agent, abbreviated into CNA, whose definition could be: a router at one or few IP hops away from the CN to the Internet, potentially offering new IPv6 RO mobility services. This router is much closer to CN than to MR's home or to any other network that MR visits. (Distance between IP entities is preferably evaluated without mobility-related tunnels.) Alex From nemo-bounces@ietf.org Wed Sep 07 09:54:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0Nx-0006FU-A4; Wed, 07 Sep 2005 09:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0Nv-0006DA-OK for nemo@megatron.ietf.org; Wed, 07 Sep 2005 09:54:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20445 for ; Wed, 7 Sep 2005 09:54:38 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0R1-0006Ik-CA for nemo@ietf.org; Wed, 07 Sep 2005 09:57:58 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j87DsPYi024743; Wed, 7 Sep 2005 22:54:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j87DsRj00974; Wed, 7 Sep 2005 22:54:27 +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 j87DsRT11935; Wed, 7 Sep 2005 22:54:27 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 21:52:17 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 6D26D1ED726; Wed, 7 Sep 2005 22:13:23 +0800 (SGT) Subject: Re: [nemo] RO solution space - CA is Certificate Authority From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <431EE511.7050503@motorola.com> References: <431EE511.7050503@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 07 Sep 2005 22:13:23 +0800 Message-Id: <1126102403.2181.141.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Sep 2005 13:52:17.0274 (UTC) FILETIME=[5BED8DA0:01C5B3B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, On Wed, 2005-09-07 at 15:03 +0200, Alexandru Petrescu wrote: > Authors of RO solution space draft, thanks for posting it. > > I keep reading and find it useful. > once again, thanks. > I have terminology comments (it's only terminology, not any paramountly > important issue). > > CA is established as Certificate Authority, it relates to IP and IPsec, > it's in wide use in an area where I am looking. > Yes, we have the same argument among the authors, and I lost :). Our conclusion is that the reader is smart enough to known which CA is referred to base on the context. > Correspondent Agent may not be the right term because it leads to CA > abbreviation. Somebody else may propose another term, like e.g. > Correspondent Node's Agent, abbreviated into CNA, whose definition could be: > a router at one or few IP hops away from the CN to the Internet, > potentially offering new IPv6 RO mobility services. This router is much > closer to CN than to MR's home or to any other network that MR visits. > (Distance between IP entities is preferably evaluated without > mobility-related tunnels.) > Hm..., what you defined seems to be what is defined for Corespondent Router. What is needed here is an entity that terminates the RO session (or that stores the binding). It can be the CR or the CN. /rgds /cwng From nemo-bounces@ietf.org Wed Sep 07 10:11:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0dp-0001ix-Du; Wed, 07 Sep 2005 10:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0dn-0001hG-Iv for nemo@megatron.ietf.org; Wed, 07 Sep 2005 10:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21633 for ; Wed, 7 Sep 2005 10:11:06 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED0gy-0006jv-BG for nemo@ietf.org; Wed, 07 Sep 2005 10:14:25 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j87EB0BO009400; Wed, 7 Sep 2005 07:11:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j87EGpUV015850; Wed, 7 Sep 2005 09:16:52 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CDBCC865980; Wed, 7 Sep 2005 16:10:57 +0200 (CEST) Message-ID: <431EF4F1.2070905@motorola.com> Date: Wed, 07 Sep 2005 16:10:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> In-Reply-To: <1126102403.2181.141.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > Hello Alex, > > On Wed, 2005-09-07 at 15:03 +0200, Alexandru Petrescu wrote: > >>Authors of RO solution space draft, thanks for posting it. >> >>I keep reading and find it useful. >> > > > once again, thanks. > > >>I have terminology comments (it's only terminology, not any paramountly >>important issue). >> >>CA is established as Certificate Authority, it relates to IP and IPsec, >>it's in wide use in an area where I am looking. >> > > > Yes, we have the same argument among the authors, and I lost :). Our > conclusion is that the reader is smart enough to known which CA is > referred to base on the context. Chan-Wah, co-authors :-) this is not a matter of winning or loosing. My own oppinions are not necessarily well grounded and may seem as "just another oppinion on a topic we've hammered a lot already". My conclusion is that a writer is smart enough to assume a very dumb reader and put the least intellectual effort on her/him :-) The draft has this: "A straight-forward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Agent" which abbreviates into "A straight-forward approach to RO in NEMO is for the MR to attempt RO with a CA" - heavy, what's CA? Here's another potential intellectually heavy text: MR, HA and CA trust the same CA so they can securely establish optimal paths. >>a router at one or few IP hops away from the CN to the Internet, >>potentially offering new IPv6 RO mobility services. This router is much >>closer to CN than to MR's home or to any other network that MR visits. >> (Distance between IP entities is preferably evaluated without >>mobility-related tunnels.) >> > > > Hm..., what you defined seems to be what is defined for Corespondent > Router. What is needed here is an entity that terminates the RO session > (or that stores the binding). It can be the CR or the CN. And if I were to wrote "zero or few" instead of "one or few"? Ok, an entity that can be either a CR or a CN could simply be called CRN. Alex From nemo-bounces@ietf.org Wed Sep 07 21:34:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDBIs-00037I-41; Wed, 07 Sep 2005 21:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDBIp-00035y-EQ for nemo@megatron.ietf.org; Wed, 07 Sep 2005 21:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06729 for ; Wed, 7 Sep 2005 21:34:07 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDBM1-0002vz-Tl for nemo@ietf.org; Wed, 07 Sep 2005 21:37:33 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id CB86AEC896; Thu, 8 Sep 2005 10:33:38 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5250FEC88F; Thu, 8 Sep 2005 10:33:37 +0900 (JST) Received: from [IPv6?2001?200?601?200?e814?21c2?975b?b09] (unknown [IPv6:2001:200:601:200:e814:21c2:975b:b09]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 3B2A2340078; Thu, 8 Sep 2005 10:33:37 +0900 (JST) Message-ID: <431F957B.9010802@kddilabs.jp> Date: Thu, 08 Sep 2005 10:35:55 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= References: <1126005133.7897.87.camel@acorde> <1126017213.2181.63.camel@localhost> <1126079691.8358.21.camel@acorde> In-Reply-To: <1126079691.8358.21.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah Ng Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Carlos, Thanks for your comments. We really appreciate them. On 2005/09/07 16:54, Carlos Jes=FAs Bernardos Cano wrote: > Hello Chan-Wah, >=20 > Thanks for your reply. Comments inline... >=20 > El mar, 06-09-2005 a las 22:33 +0800, Chan-Wah Ng escribi=F3: >=20 >>Hello Carlos, >> >>Thank you for reading the draft so soon, and the valuable comments. Se= e >>my response in-line. I will try my best to respond to all your >>comments, but some I will leave to my other co-authors to address. >> >> >>On Tue, 2005-09-06 at 13:12 +0200, Carlos Jes=FAs Bernardos Cano wrote: >> >>>Hi draft authors and all, >>> >>> I've read the draft and I have some comments. >>> >>> First of all, a general comment about the structure of the document. >>>IMHO, I'm not quite sure about if it's a good idea to present the >>>different scenarios of NEMO RO in the way it is done now. In my >>>understanding, a discussion about the scenarios of NEMO RO is needed, >>>but more focused in which and how the different aspects that contribut= e >>>to the inefficiencies due to the use of the NEMO Basic Support protoco= l >>>could be mitigated/avoided, without taking into account and making any >>>explicit reference to existing solutions. After that, it's fine to >>>present the issues of potential NEMO RO solution, before exploring the >>>solution space (in this section, references to existing solutions are >>>more appropriate, IMHO). >> >>So, if I understand your point of view correctly, you feel that all >>references to existing proposals should be moved to Sect 5? >=20 > Yes, that's right. I think that references to existing proposals shoul= d > be in the "Analysis of Solution Space" section (section 5). The list of issues here are just references to give readers some information on the fact that there exists solutions which target such scenario. We didn't intend to discuss any issues of any solution here. Do they seem unuseful to you? >>> Regarding more specific comments of some parts of the document, I hav= e >>>the following: >>> >>> - In the section 3.2.2, it is said "The aim is to reduce the >>>amplification effect of nested tunnels due to the nesting of tunnels >>>between the Visiting Mobile Node and its Home Agent within the tunnel >>>between the parent Mobile Router and the parent Mobile Router's Home >>>Agent". I don't fully understand why it says "Visiting Mobile Node", >>>since there may be several tunnels not only because a VMN visits a NEM= O, >>>but also because of several nested MRs. I think that the terminology m= ay >>>lead to confusion in some parts of the document, when Mobile Node, >>>Visiting Mobile Node and Mobile Network Node is used. Again, the text = is >>>confusing to me when says "Such a solution will seek to minimize the >>>number of tunnels possibly by collapsing the amount of tunnels require= d >>>through some form of signaling between Mobile Nodes, or between Mobile >>>Nodes and their Home Agents". >> >>We are tyring to be consistent with draft-ietf-nemo-terminology. It is= , >>i think, an unfortunate circumstances that RFC3775 uses the term Mobile >>Node when Mobile Host is more appropriate. >> >>The term VMN refers to both visiting mobile hosts and visiting mobile >>routers, so the use of VMN includes the case of nested MRs. We are >>trying to write as concisely as possible here, considering the draft is >>already 39 pages long. However, we may have overdone it and lose some >>clarity for the sake of conciseness. I will try to clean up the text a >>bit to make it less confusing. >=20 >=20 > OK. I was wrong then. I always think of a VMN as a Mobile Host... >=20 >=20 >>> - In the section 3.3. it is said that "This may be used to eliminate >>>the multiple tunnels caused by nesting of Mobile Nodes.". What is >>>nesting of Mobile Nodes? Again, for me the terminology used is >>>confusing. Does it refer to VMNs that connect to a NEMO? >>> >>> - In the section 3.4, the use of delegation of a single prefix to a >>>nested NEMO is pointed out. It is said that in that case, the MRs woul= d >>>have to perform ND on behalf of the MNNs. If so, then the addresses of >>>the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In >>>that case, LFNs would not be supported. I think that some kind of >>>address delegation may be useful for a potential NEMO RO solution, but >>>I'm not so sure about the direct delegation of a prefix to every node = in >>>the nested NEMO. OTOH, I have to admit that I have not read the last >>>drafts about prefix delegation, so maybe I'm missing something. >>> >> >>This is one RO scheme where LFN is not supported. Because if LFN are t= o >>be supported, they would break session continuity when the prefix is >>changed. >=20 > Then, IMHO, maybe it would be good to explicitly say in the document > that this RO scheme does not support LFN. Either that or maybe this example is too solution specific. I mean, this is going into a discussion on the tradeoffs of which nodes are supported and which are not. I don't know whether we should even discuss schemes which doesn't support LFNs... >>The latest draft on prefix delegation has nothing to do with RO, AFAICS= . >>The draft we are referring to when the text was written is quite an old >>draft, draft-leekj-nemo-ro-pd-02.txt >> >> >> >>> - In the section 4, I would add an additional issue (or at least >>>comment somewhere in the document) about the NEMO RO supporting >>>non-mobile routers within a NEMO. Some of the currently proposed >>>solutions does not support/cannot be applied when there is a legacy >>>non-mobile router within a NEMO. Since, the NEMO Basic Support does >>>support it, I think it should be pointed out. >> >>Noted. >> >> >>> - In the section 4.1, it is said that the signalling overhead may sca= le >>>to be unacceptable, especially to the resource-scarce mobile node. Is = it >>>assumed in this section that the MNN is the one that performs the RO >>>tasks? In that case, and IMHO, introducing changes in the protocol >>>operation of the MNNs is even worse than the limited capabilities that >>>these nodes may have. OTOH, if the MR is the one that performs the RO >>>tasks, although the limited capability problem of the MR remains to be >>>valid, I'm not so sure about which nodes we are expecting to play the >>>role of a MR. Maybe, it is not the general case that a limited device >>>plays that role (for example in a NEMO deployed in a bus or a plane). >> >>Noted, perhaps a more detailed analysis would be required here. I woul= d >>follow up on this with a separate mail by this week. >> >> >>> - The section 4.3 points out the problem of the increased delay durin= g >>>handoff that may occur due to NEMO RO. I agree on that, but maybe it'd >>>be worth to say that this problem is similar to the one that is presen= t >>>in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especial= ly >>>because of the Return Routability procedure) also adds latency, but to >>>deal with that problem there are other proposals (e.g., FMIPv6 or >>>HMIPv6) that are somehow independent to the RO problem. >> >>Well, we expect that in some NEMO-RO proposals, the handoff delay will >>be greater. For instance, consider a node behind 3 MRs. Certain NEMO >>RO proposals may require each of these MR to signal the CA. Assuming >>the signaling delay is d, then the delay for the node is anything >>between (d, d+3d), worse than or at best equal to MIPv6 RO. >=20 >=20 > Yes, I agree on the fact the some of the NEMO-RO proposals will > increase the handover delay. What I was trying to point out is that in > Mobile IPv6, the RO also increases the handover delay (Return > Routability, Binding Update, etc.), so this increase is not new in NEMO= . > It could be higher than in MIPv6, but it not a new problem, and in MIPv= 6 > they have dealt with it by designing new protocols focused in optimisin= g > the handover delays. The problem maybe similar to MIP6, but greater which could be critical than MIP6. I would like to rather avoid including such text that may mislead the readers that the problem is simply the same as that of MIP6. watari >>> - The section 4.4 describes the New functionalities that may be neede= d >>>for NEMO RO. It says that the smaller number of nodes required to be >>>changed, the better and also points that there are some nodes that wou= ld >>>be preferred not to be changed (like LFNs). IMHO, maybe it would be >>>useful also to say that reusing existing protocols (like MIPv6) would >>>make also easier the deployment of new NEMO RO solutions. >> >>Hmm.. I thought that is mentioned somewhere, but perhaps not explicitly= . >=20 >=20 > Maybe I missed it ;-) , I'll try to check it. >=20 >=20 >>Noted. >> >> >>> - The section 5.1.1 describes the RO solution involving the MNN and t= he >>>CN. IMHO, I'd say "new functionalities would be required" instead of >>>"are required", since for example, MIPv6 capabilities of the nodes may >>>be reused in some solutions falling in this category. The same comment >>>applies to the section 5.1.2. >> >>Ok. >> >> >>> - The section 5.1.3 says that solutions involving MR and CR may scale >>>well, since a single RO session between the MR and CR can achieve RO >>>between any MNN and any CN managed by the CR. I don't see this better >>>scalability so well, I mean, IMHO there is a trade-off, depending on t= he >>>specific scenario. Of course, if the CR is very close to the CN, the >>>route would be very optimal, but in that case, if a MNN is communicati= ng >>>to several CN located in different physical locations, then several CR= s >>>would be needed (so there is here an scalability problem, in terms of >>>number of CRs neede). OTOH, if the CR is not so close to the CNs, ther= e >>>may be less CRs, but then the optimisation is not so optimal. I see >>>something similar with the case described in the section 5.1.4. >> >>You mention a very relevant point about tradeoff of the proximity of CR >>to CN. But the text is not about this. Worst case scenario is that th= e >>MR/MNN is communicating with one CR per CN. The number of session >>maintained is the same as MIPv6 (i.e. 1 RO-session per CN). However, >>the best case scenario is that the MR/MNN is communicating with multipl= e >>CNs behind a CR. SO, using a CR would always result in less or at most >>equal number of RO sessions. Thus we say the use of CR scales well. >=20 >=20 > OK, I see now. Anyway, I think that it would be also interesting to > include some comments about the problem of scalability and deployabilit= y > in terms of number of required CRs (and their location). >=20 >=20 >>> - In the section 5.2, it is said that the node that is mobile is in t= he >>>best position to detect its mobility, but what do you mean by "mobile"= ? >>>that is physically moving or that is changing its point of attachment? >>>Because, if the latter is meant, I don't see a MNN to necessarily be >>>always mobile (e.g., a LFN is not). IMHO, the text needs to be clear. >> >>OK. >> >> >>> - In the section 5.3, it is said that the detection of the RO >>>capability may incur in additional delay. I suppose that it would be >>>dependant on the specific solution, but as I see it, a NEMO RO solutio= n >>>would use the NEMO Basic Solution while trying to setup a RO session, = so >>>I don't see the delay due to the detection capability. >> >>That is if it continues to use the NEMO-BS tunnel while detecting RO. >>Some RO proposals may make it difficult to do this, for example a RO >>proposal that embed signaling on-plane. To use NEMO-BS support at the >>same, require the MR to duplicate a data packet, one to go through the >>NEMO-BS tunnel, one to try the optimized path. It may not be such a >>good idea in this case. >=20 >=20 > OK, I see. Maybe I was thinking in the way MIPv6 performs RO, in which > the BT is always used until the CN is first signalled with the BU. Mayb= e > some text clarifying that would be useful in the document. >=20 >=20 >>> - The section 5.5.2 says that adding new options in Router >>>Advertisements is to modify the protocol. IMHO, adding new options is >>>just making use of the protocol, extending it with a new functionality= , >>>since new options can be defined (they would be discarded by nodes tha= t >>>do not support them) and implemented easily. >> >>True. We will look into that. >> >> >>> - As I've pointed out before, I'm not so sure about the applicability >>>of the Prefix Delegation and Neighbour Discovery Proxy solution with >>>LFNs, since they involve changing the MNN's address when the NEMO move= s, >>>or am I missing something? >> >>As I responded before, RO this scheme does not support LFN. >=20 >=20 > Same comment than in the other case. Maybe it's worth to say that > explicitly. >=20 >=20 >>> - The section 5.8.1 points out that there are some WGs currently >>>looking at the concern over the authenticity of addresses. We wrote a >>>paper [1] about the general problem of making the NEMO RO secure, >>>exploring some possible solution schemes (using CGAs for example, etc.= ). >>>We can extend the paper in form of I-D if the WG considers it useful. >> >>Yes, I think I have read the paper before, just that I got lazy trying >>to seek out the complete bibliography. Thanks. >> >> >>> Some Editorial comments: >>> >>> - Page 5, "lesser" instead of "least" in "... of a least cost ..." ?? >>> - Page 5, "Quality of Service" instead of "Quality of Services" ?? >>> - Page 12, "do" instead of "does" in "... the scenarios described in >>>Section 3 does so ..." ?? >>> - Page 23: "worthwhile" instead of "worth while" ?? >>> - Page 26: "may be" instead of "maybe" in "... transmission maybe >>>disrupted ..." ?? >>> - Page 31: "detailed" instead of "detail" ?? >> >>OK. >> >> >>> I have some comments about how MIRON (a NEMO RO particular solution >>>cited in the draft that I'm co-author of) is described in the draft, a= nd >>>in general about the Mobile Router as a Proxy family of solutions. I'l= l >>>send them in a separate mail. >> >>You are welcomed. We interpret each proposal in our own way, and its >>good to have authors of the proposals referred to in the draft to point >>out to us some of our mis-interpretation. Plus please also remember >>that (1) we are trying to be concise, (2) we generalize, and (3) we >>document so many different proposals that we probably confuse >>ourselves :). >> >=20 >=20 > Thanks a lot. >=20 > Kind Regards, >=20 > Carlos J. >=20 >=20 >>/rgds >>/cwng >> >> >>> Hope this helps. >>> >>> Thanks a lot for writing the draft. >>> >>> Kind regards, >>> >>> Carlos J. =20 >>> >>>[1] Securing Route Optimisation in NEMO >>>Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio= Soto >>>Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, >>>2005. WIOPT 2005. Third International Symposium on=20 >>>3-7 April 2005 Page(s): 248 - 254 >>> From nemo-bounces@ietf.org Wed Sep 07 21:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDBgY-0000DL-KQ; Wed, 07 Sep 2005 21:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDBgX-0000DC-0x for nemo@megatron.ietf.org; Wed, 07 Sep 2005 21:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08006 for ; Wed, 7 Sep 2005 21:58:39 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDBjn-0003WY-U2 for nemo@ietf.org; Wed, 07 Sep 2005 22:02:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 78770EC8EB; Thu, 8 Sep 2005 10:58:30 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0C537EC8AB; Thu, 8 Sep 2005 10:58:30 +0900 (JST) Received: from [IPv6?2001?200?601?200?e814?21c2?975b?b09] (unknown [IPv6:2001:200:601:200:e814:21c2:975b:b09]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 00363340078; Thu, 8 Sep 2005 10:58:29 +0900 (JST) Message-ID: <431F9B50.4080703@kddilabs.jp> Date: Thu, 08 Sep 2005 11:00:48 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> In-Reply-To: <431EF4F1.2070905@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex, On 2005/09/07 23:10, Alexandru Petrescu wrote: >>>I have terminology comments (it's only terminology, not any paramountly >>>important issue). >>> >>>CA is established as Certificate Authority, it relates to IP and IPsec, >>>it's in wide use in an area where I am looking. >> >>Yes, we have the same argument among the authors, and I lost :). Our >>conclusion is that the reader is smart enough to known which CA is >>referred to base on the context. > > Chan-Wah, co-authors :-) this is not a matter of winning or loosing. I wasn't involved in that btw ;) > My own oppinions are not necessarily well grounded and may seem as "just > another oppinion on a topic we've hammered a lot already". > > My conclusion is that a writer is smart enough to assume a very dumb > reader and put the least intellectual effort on her/him :-) > > The draft has this: "A straight-forward approach to Route Optimization > in NEMO is for the Mobile Router to attempt Route Optimization with a > Correspondent Agent" which abbreviates into "A straight-forward approach > to RO in NEMO is for the MR to attempt RO with a CA" - heavy, what's CA? > > Here's another potential intellectually heavy text: MR, HA and CA trust > the same CA so they can securely establish optimal paths. I see. >>>a router at one or few IP hops away from the CN to the Internet, >>>potentially offering new IPv6 RO mobility services. This router is much >>>closer to CN than to MR's home or to any other network that MR visits. >>> (Distance between IP entities is preferably evaluated without >>>mobility-related tunnels.) >> >>Hm..., what you defined seems to be what is defined for Corespondent >>Router. What is needed here is an entity that terminates the RO session >>(or that stores the binding). It can be the CR or the CN. > > And if I were to wrote "zero or few" instead of "one or few"? > > Ok, an entity that can be either a CR or a CN could simply be called CRN. As in Correspondent Router Node? I'm not sure... IF a MN can be either MH or MR, then CN should be either CH or CR. But we've always used CN as nothing more than CH. If we re-define CN so that it can be both CR and CH, would that solve everything...? Or how about we simply called them "peers" ? or PA: Peer Agent or NA: Nemo Agent or CE: Correspondet Entity or CP: Correspondent Peer... watari From nemo-bounces@ietf.org Wed Sep 07 22:26:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDC7H-0006S3-Kj; Wed, 07 Sep 2005 22:26:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDC7E-0006Ry-V3 for nemo@megatron.ietf.org; Wed, 07 Sep 2005 22:26:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09205 for ; Wed, 7 Sep 2005 22:26:15 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDCAW-00049n-T3 for nemo@ietf.org; Wed, 07 Sep 2005 22:29:41 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 75620EC83E; Thu, 8 Sep 2005 11:26:06 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 77D6CEC833; Thu, 8 Sep 2005 11:26:05 +0900 (JST) Received: from [IPv6?2001?200?601?200?e814?21c2?975b?b09] (unknown [IPv6:2001:200:601:200:e814:21c2:975b:b09]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 645E8340078; Thu, 8 Sep 2005 11:26:05 +0900 (JST) Message-ID: <431FA1C7.3080503@kddilabs.jp> Date: Thu, 08 Sep 2005 11:28:23 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= References: <1126019862.7897.165.camel@acorde> In-Reply-To: <1126019862.7897.165.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah Ng Subject: [nemo] Re: Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Carlos, Thanks for providing the text. On 2005/09/07 0:17, Carlos Jes=FAs Bernardos Cano wrote: > Hi draft authors, and all, >=20 > As presented in Paris, it was agreed to include some changes on the the > draft-ietf-nemo-ro-problem-statement-00.txt, to solve some of the issue= s > raised on the ML. Here I propose some text for discussion: >=20 > In the section 2.1, in the part describing "Longer route leading to > increased delay and additional infrastructure load", it is stated that > applications such as real-time multimedia streaming may not be able to > tolerate the increased delay. I'd suggest adding the following: >=20 > "Besides, the increase in delay impact also the performance of transpor= t > protocols such as TCP, since the rate at which a TCP nodes send packets > is driven by the congestion control algorithm, which is related to the > RTT perceived by the communication peers. If the RTT is inflated due to > the MRHA tunnel, the effective throughput obtained by an application > will decrease, especially in those cases in which there are several > competing flows sharing a bandwidth-limited link (those flows with less > RTT will obtain higher throughput)". The multiple flows sutff may be more to the bottle neck discussion. Besides that, I'm positive on adding the text. I will leave this for Chan-Wah, but how about; "In general, the increase in delay also impact the performance of transport protocols such as TCP, since the rate at which a TCP nodes send packets is driven by the congestion control algorithm, which is related to the RTT perceived by the communication peers. If the RTT is inflated due to the MRHA tunnel, the effective throughput obtained by an application will decrease." > A minor remark about the effect of increased packet loss probability > when using the MRHA tunnel and the TCP performance may be also included > here (or in the "Increased susceptibility to link failure" subsection). I thought we already have some text on the possibility of packet losses... > In the section B.4.3, I'd suggest to add the following text to comment > about the possibility of using the VMN's CoA for communication in > short-term communications: >=20 > "The MNN may also decide to use its Care-of Address as the source > address of the packets, thus avoiding the tunnelling with the MNN's HA. > This is particularly useful for a short-term communication that may > easily be retried if it fails. RFC 3484 (Default Address Selection) > provides some mechanisms for controlling the choice of the source > address. An API may also be alternatively used for those applications > running on the MNN that have enough knowledge of the communication bein= g > sent to decide whether to use the MNN's Home Address or the MNN's > Care-of Address as the source address of the packets being sent." I would rather not go into the API stuff. I think the first part is sufficient for the text here. thanks again, watari From nemo-bounces@ietf.org Wed Sep 07 22:31:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDCCh-0007sn-SS; Wed, 07 Sep 2005 22:31:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDCCf-0007qu-Qm for nemo@megatron.ietf.org; Wed, 07 Sep 2005 22:31:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09356 for ; Wed, 7 Sep 2005 22:31:51 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDCFv-0004GC-JJ for nemo@ietf.org; Wed, 07 Sep 2005 22:35:18 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j882VaGs004538; Thu, 8 Sep 2005 11:31:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j882Vc807598; Thu, 8 Sep 2005 11:31:38 +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 j882VaB27887; Thu, 8 Sep 2005 11:31:36 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 10:29:27 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 09A621ED726; Thu, 8 Sep 2005 10:50:37 +0800 (SGT) Subject: Re: [nemo] RO solution space - CA is Certificate Authority From: Chan-Wah Ng To: Masafumi Watari In-Reply-To: <431F9B50.4080703@kddilabs.jp> References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> <431F9B50.4080703@kddilabs.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 08 Sep 2005 10:50:37 +0800 Message-Id: <1126147837.2181.158.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 08 Sep 2005 02:29:27.0508 (UTC) FILETIME=[22752140:01C5B41D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, Watari-san, and all On Thu, 2005-09-08 at 11:00 +0900, Masafumi Watari wrote: > On 2005/09/07 23:10, Alexandru Petrescu wrote: > >>>I have terminology comments (it's only terminology, not any paramountly > >>>important issue). > >>> > >>>CA is established as Certificate Authority, it relates to IP and IPsec, > >>>it's in wide use in an area where I am looking. > >> > >>Yes, we have the same argument among the authors, and I lost :). Our > >>conclusion is that the reader is smart enough to known which CA is > >>referred to base on the context. > > > > Chan-Wah, co-authors :-) this is not a matter of winning or loosing. > > I wasn't involved in that btw ;) :) > > My own oppinions are not necessarily well grounded and may seem as "just > > another oppinion on a topic we've hammered a lot already". > > > > My conclusion is that a writer is smart enough to assume a very dumb > > reader and put the least intellectual effort on her/him :-) Which is exactly why we follow RFC3963's convention of expanding the whole terms, and not to use abbreviation. In normal ML discussion, the correspondents should know what they are referring to in the context. > > > > The draft has this: "A straight-forward approach to Route Optimization > > in NEMO is for the Mobile Router to attempt Route Optimization with a > > Correspondent Agent" which abbreviates into "A straight-forward approach > > to RO in NEMO is for the MR to attempt RO with a CA" - heavy, what's CA? > > > > Here's another potential intellectually heavy text: MR, HA and CA trust > > the same CA so they can securely establish optimal paths. > > I see. > I know what you are pointing at, in fact the same discussion appeared a while ago on this same ML. The way I see it, we just need a term to refer to. It can be anything, as long as the readers know what we are referring to. > >>>a router at one or few IP hops away from the CN to the Internet, > >>>potentially offering new IPv6 RO mobility services. This router is much > >>>closer to CN than to MR's home or to any other network that MR visits. > >>> (Distance between IP entities is preferably evaluated without > >>>mobility-related tunnels.) > >> > >>Hm..., what you defined seems to be what is defined for Corespondent > >>Router. What is needed here is an entity that terminates the RO session > >>(or that stores the binding). It can be the CR or the CN. > > > > And if I were to wrote "zero or few" instead of "one or few"? Alex, you can, but there is still the problem of the word "router". You have to called it a node, an entity, or something like that. > > > > Ok, an entity that can be either a CR or a CN could simply be called CRN. > > As in Correspondent Router Node? I'm not sure... > IF a MN can be either MH or MR, then CN should be either CH or CR. > But we've always used CN as nothing more than CH. If we re-define > CN so that it can be both CR and CH, would that solve everything...? > Nope. MN and CN are untouchable, set in gold. You will confuse all readers who read RFC3775 first (and that's practically the whole IETF). That is why I always use MNN, instead of simply MN. > Or how about we simply called them "peers" ? or PA: Peer Agent or > NA: Nemo Agent or CE: Correspondet Entity or CP: Correspondent Peer... I would go for Correspondent entity. /rgds /cwng From nemo-bounces@ietf.org Wed Sep 07 22:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDCKM-00019B-5F; Wed, 07 Sep 2005 22:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDCKJ-000192-Lp for nemo@megatron.ietf.org; Wed, 07 Sep 2005 22:39:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09669 for ; Wed, 7 Sep 2005 22:39:45 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDCNb-0004Pa-KB for nemo@ietf.org; Wed, 07 Sep 2005 22:43:12 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j882daYi012622; Thu, 8 Sep 2005 11:39:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j882dbK01339; Thu, 8 Sep 2005 11:39:37 +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 j882dZT29235; Thu, 8 Sep 2005 11:39:35 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 10:37:25 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 0DDF41ED726; Thu, 8 Sep 2005 10:58:36 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <431EDF11.7070405@motorola.com> References: <431D91C5.2040505@motorola.com> <1126083066.2181.114.camel@localhost> <431EB65F.4050001@motorola.com> <1126095103.2181.135.camel@localhost> <431EDF11.7070405@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 08 Sep 2005 10:58:35 +0800 Message-Id: <1126148315.2181.166.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 08 Sep 2005 02:37:25.0364 (UTC) FILETIME=[3F482B40:01C5B41E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, er ... thanks for replying to my replies? :) I kind of like the idea of simply using "address". Anyway that's what this is all about, "binding an address to another address". However, I don't quite agree to your logic behind arriving at using LFN. In fact I see it the other way round. All we want to do is to consider how an address of X is bound to an address of Y. X is any node behind a mobile router (which, by definition, is MNN), and Y is a mobile router, or the TLMR (which is also a mobile router). So, instead we should have used things like "MNN's address is bound to its MR's address" "MNN's address is bound to a sequence of MRs' addresses" All is fine, but with one catch: We try as much not to use abbreviations in the draft, then the expression "MNN's address" would expand to be pretty long. /rgds /cwng On Wed, 2005-09-07 at 14:37 +0200, Alexandru Petrescu wrote: > Hello Chan-Wah, thanks for replying. > > Chan-Wah Ng wrote: > > Hello Alex, > > > > Ok, so you are not happy with the terms identity (vs locator). I am > > now challenging you to come up with more adequate terms. > > > > Yes, I know you suggested going into specific (MR's CoA, LFN's HoA). > > However, that's what we want to avoid. The good thing about going > > into specific is that it is not ambiguous. However, it is only > > suitable for a specification. This draft, however, is trying to > > generalize the RO solution space. > > Generalize the solution space... hmmm. > > > If I use terms "LFN's HoA is bount to MR's CoA", I foresee even more > > objections: > > > > (1) XXX: "Hey, but my proposal is not LFN's HoA is bound to MR's CoA, > > its bound to MR's HoA" > > Ok, one could say it that way. And I perfectly understand that phrase. > I like it much better than saying "MNN identity not bound to MR > identity, but bound to MR location". > > > (2) YYY: "Hey, but LFN has no HoA nor CoA. Its simply an *address*." > > Ok, and I perfectly agree with using "LFN's address" instead of "LFN's > identity". > > > (3) ZZZ: "Hey, you fail to consider VMN's CoA ..." > > Using "identifier" and "locator" terms are as useless as using the "VMN" > term. "VMN" is in no way different than "MN" in terms of what protocols > they implement and code they execute. > > Other potential discussions that rely on "id vs locator" is "VMN's > location belongs to the MR's identity but VMN's identity is not MR's > identity". > > > no, its a rat hole I am trying to avoid. > > Yes, me too, that is why I suggest not using the locator vs identifier > discussion in the ro solution space draft. > > > I need terms X and Y that are general enough to represent "X is bound > > to Y", where X can be anything from LFN's address, VMN's CoA, MNN's > > HoA, MNP, and Y can be anything from MR's HoA, MR's CoA, TLMR's CoA, > > a series of MRs' CoA, etc ... > > > > The best terms I have come up with is location and identity. If you > > have better suggestions, let me know and I'll appreciate that. Else, > > I think this debate is going nowhere. > > Sorry, I don't mean to get the debate nowhere. > > Implementation-wise here's terminology: > > "VMN" term makes no sense: it's either an MH or an MR. "VMN" implements > nothing else than Mobile IPv6. > > "MNN" term makes no sense: it's either an MH or an MR or an LFN. > > "TLMR" makes no sense: it's an MR. > > VMN, MNN and TLMR was used in informal discussions to mean the > following: VMN is an MH that visits an MR's moving network and that has > a different HA than that MR. MNN has same HA. TLMR is an MR that is > attaching to a fixed infrastructure and below which several MR's are > attaching in a nested manner, none being attached to the fixed > infrastructure. > > That gives: > > "LFN's address is bound to MR's Home Address" > "LFN's address is bound to MR's Care-of Address" > "LFN's address is bound to the MR's Care-of Address that is attached to > the fixed infrastructure". > "LFN's address is bound to a series of MRs' Care-of Addresses within > which that LFN is nested" > "MH's Care-of Address is bound to ..." > "MH's Home Address is bound to ..." > "MR's Care-of Address is bound to ..." > "MR's Home Address is bound to ..." > > Which in the end leads to: > > "In the RO solution space, address bindings maintained at the CN may be > structured differently. Addresses or prefixes of a host or of a router > may be bound to each other or to addresses or prefixes of another host > or router. For example, in a moving network composed of an LFN and an > MR, the LFN's address may be bound to MR's CoA. Alternatively, the > LFN's address may be bound to the MNP owned by that MR. In another > example where two nested moving networks are employed, the LFN's > address may be bound to both MR's Care-of Addresses. Each different > structure for the binding represents a different RO solution". > > In my oppinion this stays generic enough and still suggests real behaviour. > > Just two cents worth. Thanks again for putting up the draft. > > Alex > From nemo-bounces@ietf.org Thu Sep 08 05:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIMh-00035R-Gv; Thu, 08 Sep 2005 05:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIMe-00031x-3A for nemo@megatron.ietf.org; Thu, 08 Sep 2005 05:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08422 for ; Thu, 8 Sep 2005 05:06:32 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDIPy-0005fD-2d for nemo@ietf.org; Thu, 08 Sep 2005 05:10:03 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3C1B889CBE; Thu, 8 Sep 2005 11:06:21 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 94B9989C75; Thu, 8 Sep 2005 11:06:19 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <431F957B.9010802@kddilabs.jp> References: <1126005133.7897.87.camel@acorde> <1126017213.2181.63.camel@localhost> <1126079691.8358.21.camel@acorde> <431F957B.9010802@kddilabs.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oQ7UHlwdFUU0GEHAx2FN" Organization: UC3M Date: Thu, 08 Sep 2005 11:06:19 +0200 Message-Id: <1126170379.7199.26.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah Ng Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-oQ7UHlwdFUU0GEHAx2FN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Watari, Please, see comments inline... El jue, 08-09-2005 a las 10:35 +0900, Masafumi Watari escribi=F3: > Hi Carlos, >=20 > Thanks for your comments. We really appreciate them. >=20 > On 2005/09/07 16:54, Carlos Jes=FAs Bernardos Cano wrote: > > Hello Chan-Wah, > >=20 > > Thanks for your reply. Comments inline... > >=20 > > El mar, 06-09-2005 a las 22:33 +0800, Chan-Wah Ng escribi=F3: > >=20 > >>Hello Carlos, > >> > >>Thank you for reading the draft so soon, and the valuable comments. Se= e > >>my response in-line. I will try my best to respond to all your > >>comments, but some I will leave to my other co-authors to address. > >> > >> > >>On Tue, 2005-09-06 at 13:12 +0200, Carlos Jes=FAs Bernardos Cano wrote: > >> > >>>Hi draft authors and all, > >>> > >>> I've read the draft and I have some comments. > >>> > >>> First of all, a general comment about the structure of the document. > >>>IMHO, I'm not quite sure about if it's a good idea to present the > >>>different scenarios of NEMO RO in the way it is done now. In my > >>>understanding, a discussion about the scenarios of NEMO RO is needed, > >>>but more focused in which and how the different aspects that contribut= e > >>>to the inefficiencies due to the use of the NEMO Basic Support protoco= l > >>>could be mitigated/avoided, without taking into account and making any > >>>explicit reference to existing solutions. After that, it's fine to > >>>present the issues of potential NEMO RO solution, before exploring the > >>>solution space (in this section, references to existing solutions are > >>>more appropriate, IMHO). > >> > >>So, if I understand your point of view correctly, you feel that all > >>references to existing proposals should be moved to Sect 5? > >=20 > > Yes, that's right. I think that references to existing proposals shoul= d > > be in the "Analysis of Solution Space" section (section 5). >=20 > The list of issues here are just references to give readers some > information on the fact that there exists solutions which target such > scenario. We didn't intend to discuss any issues of any solution here. > Do they seem unuseful to you? The references are not unuseful. On the contrary, IMO they are useful in a document like this. Nevertheless, I think the reference should be in the analysis of the NEMO RO space solution, not in the description of the scenarios, just to keep them separated (IMHO, providing references in the same section that describes the scenarios may lead to confusion, since solutions and scenarios are not always in a 1-to-1 relation). >=20 > >>> Regarding more specific comments of some parts of the document, I hav= e > >>>the following: > >>> > >>> - In the section 3.2.2, it is said "The aim is to reduce the > >>>amplification effect of nested tunnels due to the nesting of tunnels > >>>between the Visiting Mobile Node and its Home Agent within the tunnel > >>>between the parent Mobile Router and the parent Mobile Router's Home > >>>Agent". I don't fully understand why it says "Visiting Mobile Node", > >>>since there may be several tunnels not only because a VMN visits a NEM= O, > >>>but also because of several nested MRs. I think that the terminology m= ay > >>>lead to confusion in some parts of the document, when Mobile Node, > >>>Visiting Mobile Node and Mobile Network Node is used. Again, the text = is > >>>confusing to me when says "Such a solution will seek to minimize the > >>>number of tunnels possibly by collapsing the amount of tunnels require= d > >>>through some form of signaling between Mobile Nodes, or between Mobile > >>>Nodes and their Home Agents". > >> > >>We are tyring to be consistent with draft-ietf-nemo-terminology. It is= , > >>i think, an unfortunate circumstances that RFC3775 uses the term Mobile > >>Node when Mobile Host is more appropriate. > >> > >>The term VMN refers to both visiting mobile hosts and visiting mobile > >>routers, so the use of VMN includes the case of nested MRs. We are > >>trying to write as concisely as possible here, considering the draft is > >>already 39 pages long. However, we may have overdone it and lose some > >>clarity for the sake of conciseness. I will try to clean up the text a > >>bit to make it less confusing. > >=20 > >=20 > > OK. I was wrong then. I always think of a VMN as a Mobile Host... > >=20 > >=20 > >>> - In the section 3.3. it is said that "This may be used to eliminate > >>>the multiple tunnels caused by nesting of Mobile Nodes.". What is > >>>nesting of Mobile Nodes? Again, for me the terminology used is > >>>confusing. Does it refer to VMNs that connect to a NEMO? > >>> > >>> - In the section 3.4, the use of delegation of a single prefix to a > >>>nested NEMO is pointed out. It is said that in that case, the MRs woul= d > >>>have to perform ND on behalf of the MNNs. If so, then the addresses of > >>>the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In > >>>that case, LFNs would not be supported. I think that some kind of > >>>address delegation may be useful for a potential NEMO RO solution, but > >>>I'm not so sure about the direct delegation of a prefix to every node = in > >>>the nested NEMO. OTOH, I have to admit that I have not read the last > >>>drafts about prefix delegation, so maybe I'm missing something. > >>> > >> > >>This is one RO scheme where LFN is not supported. Because if LFN are t= o > >>be supported, they would break session continuity when the prefix is > >>changed. > >=20 > > Then, IMHO, maybe it would be good to explicitly say in the document > > that this RO scheme does not support LFN. >=20 > Either that or maybe this example is too solution specific. I mean, > this is going into a discussion on the tradeoffs of which nodes are > supported and which are not. I don't know whether we should even > discuss schemes which doesn't support LFNs... The problem is that, IMO, if you don't clarify that some solutions do not support LFNs, the reader may think that they do (since one of the advantages of NEMO is providing mobility support to nodes that have not). I agree, that maybe it'd be better to skip solutions that do not support LFNs, but I'd suggest to keep them but making clear that they do not support LFNs. >=20 > >>The latest draft on prefix delegation has nothing to do with RO, AFAICS= . > >>The draft we are referring to when the text was written is quite an old > >>draft, draft-leekj-nemo-ro-pd-02.txt > >> > >> > >> > >>> - In the section 4, I would add an additional issue (or at least > >>>comment somewhere in the document) about the NEMO RO supporting > >>>non-mobile routers within a NEMO. Some of the currently proposed > >>>solutions does not support/cannot be applied when there is a legacy > >>>non-mobile router within a NEMO. Since, the NEMO Basic Support does > >>>support it, I think it should be pointed out. > >> > >>Noted. > >> > >> > >>> - In the section 4.1, it is said that the signalling overhead may sca= le > >>>to be unacceptable, especially to the resource-scarce mobile node. Is = it > >>>assumed in this section that the MNN is the one that performs the RO > >>>tasks? In that case, and IMHO, introducing changes in the protocol > >>>operation of the MNNs is even worse than the limited capabilities that > >>>these nodes may have. OTOH, if the MR is the one that performs the RO > >>>tasks, although the limited capability problem of the MR remains to be > >>>valid, I'm not so sure about which nodes we are expecting to play the > >>>role of a MR. Maybe, it is not the general case that a limited device > >>>plays that role (for example in a NEMO deployed in a bus or a plane). > >> > >>Noted, perhaps a more detailed analysis would be required here. I woul= d > >>follow up on this with a separate mail by this week. > >> > >> > >>> - The section 4.3 points out the problem of the increased delay durin= g > >>>handoff that may occur due to NEMO RO. I agree on that, but maybe it'd > >>>be worth to say that this problem is similar to the one that is presen= t > >>>in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especial= ly > >>>because of the Return Routability procedure) also adds latency, but to > >>>deal with that problem there are other proposals (e.g., FMIPv6 or > >>>HMIPv6) that are somehow independent to the RO problem. > >> > >>Well, we expect that in some NEMO-RO proposals, the handoff delay will > >>be greater. For instance, consider a node behind 3 MRs. Certain NEMO > >>RO proposals may require each of these MR to signal the CA. Assuming > >>the signaling delay is d, then the delay for the node is anything > >>between (d, d+3d), worse than or at best equal to MIPv6 RO. > >=20 > >=20 > > Yes, I agree on the fact the some of the NEMO-RO proposals will > > increase the handover delay. What I was trying to point out is that in > > Mobile IPv6, the RO also increases the handover delay (Return > > Routability, Binding Update, etc.), so this increase is not new in NEMO= . > > It could be higher than in MIPv6, but it not a new problem, and in MIPv= 6 > > they have dealt with it by designing new protocols focused in optimisin= g > > the handover delays. >=20 > The problem maybe similar to MIP6, but greater which could be critical > than MIP6. I would like to rather avoid including such text that may > mislead the readers that the problem is simply the same as that of MIP6. The problem is not "the same", but it is of the same nature than in MIPv6. Besides, depending on the solution, it could be not greater than in MIPv6. I think that it could be useful so say somehow that the problem could be more severe than in MIPv6, but that is of a similar nature (and therefore, it could be dealt with similarly as well). Kind Regards, Carlos J. >=20 > watari >=20 > >>> - The section 4.4 describes the New functionalities that may be neede= d > >>>for NEMO RO. It says that the smaller number of nodes required to be > >>>changed, the better and also points that there are some nodes that wou= ld > >>>be preferred not to be changed (like LFNs). IMHO, maybe it would be > >>>useful also to say that reusing existing protocols (like MIPv6) would > >>>make also easier the deployment of new NEMO RO solutions. > >> > >>Hmm.. I thought that is mentioned somewhere, but perhaps not explicitly= . > >=20 > >=20 > > Maybe I missed it ;-) , I'll try to check it. > >=20 > >=20 > >>Noted. > >> > >> > >>> - The section 5.1.1 describes the RO solution involving the MNN and t= he > >>>CN. IMHO, I'd say "new functionalities would be required" instead of > >>>"are required", since for example, MIPv6 capabilities of the nodes may > >>>be reused in some solutions falling in this category. The same comment > >>>applies to the section 5.1.2. > >> > >>Ok. > >> > >> > >>> - The section 5.1.3 says that solutions involving MR and CR may scale > >>>well, since a single RO session between the MR and CR can achieve RO > >>>between any MNN and any CN managed by the CR. I don't see this better > >>>scalability so well, I mean, IMHO there is a trade-off, depending on t= he > >>>specific scenario. Of course, if the CR is very close to the CN, the > >>>route would be very optimal, but in that case, if a MNN is communicati= ng > >>>to several CN located in different physical locations, then several CR= s > >>>would be needed (so there is here an scalability problem, in terms of > >>>number of CRs neede). OTOH, if the CR is not so close to the CNs, ther= e > >>>may be less CRs, but then the optimisation is not so optimal. I see > >>>something similar with the case described in the section 5.1.4. > >> > >>You mention a very relevant point about tradeoff of the proximity of CR > >>to CN. But the text is not about this. Worst case scenario is that th= e > >>MR/MNN is communicating with one CR per CN. The number of session > >>maintained is the same as MIPv6 (i.e. 1 RO-session per CN). However, > >>the best case scenario is that the MR/MNN is communicating with multipl= e > >>CNs behind a CR. SO, using a CR would always result in less or at most > >>equal number of RO sessions. Thus we say the use of CR scales well. > >=20 > >=20 > > OK, I see now. Anyway, I think that it would be also interesting to > > include some comments about the problem of scalability and deployabilit= y > > in terms of number of required CRs (and their location). > >=20 > >=20 > >>> - In the section 5.2, it is said that the node that is mobile is in t= he > >>>best position to detect its mobility, but what do you mean by "mobile"= ? > >>>that is physically moving or that is changing its point of attachment? > >>>Because, if the latter is meant, I don't see a MNN to necessarily be > >>>always mobile (e.g., a LFN is not). IMHO, the text needs to be clear. > >> > >>OK. > >> > >> > >>> - In the section 5.3, it is said that the detection of the RO > >>>capability may incur in additional delay. I suppose that it would be > >>>dependant on the specific solution, but as I see it, a NEMO RO solutio= n > >>>would use the NEMO Basic Solution while trying to setup a RO session, = so > >>>I don't see the delay due to the detection capability. > >> > >>That is if it continues to use the NEMO-BS tunnel while detecting RO. > >>Some RO proposals may make it difficult to do this, for example a RO > >>proposal that embed signaling on-plane. To use NEMO-BS support at the > >>same, require the MR to duplicate a data packet, one to go through the > >>NEMO-BS tunnel, one to try the optimized path. It may not be such a > >>good idea in this case. > >=20 > >=20 > > OK, I see. Maybe I was thinking in the way MIPv6 performs RO, in which > > the BT is always used until the CN is first signalled with the BU. Mayb= e > > some text clarifying that would be useful in the document. > >=20 > >=20 > >>> - The section 5.5.2 says that adding new options in Router > >>>Advertisements is to modify the protocol. IMHO, adding new options is > >>>just making use of the protocol, extending it with a new functionality= , > >>>since new options can be defined (they would be discarded by nodes tha= t > >>>do not support them) and implemented easily. > >> > >>True. We will look into that. > >> > >> > >>> - As I've pointed out before, I'm not so sure about the applicability > >>>of the Prefix Delegation and Neighbour Discovery Proxy solution with > >>>LFNs, since they involve changing the MNN's address when the NEMO move= s, > >>>or am I missing something? > >> > >>As I responded before, RO this scheme does not support LFN. > >=20 > >=20 > > Same comment than in the other case. Maybe it's worth to say that > > explicitly. > >=20 > >=20 > >>> - The section 5.8.1 points out that there are some WGs currently > >>>looking at the concern over the authenticity of addresses. We wrote a > >>>paper [1] about the general problem of making the NEMO RO secure, > >>>exploring some possible solution schemes (using CGAs for example, etc.= ). > >>>We can extend the paper in form of I-D if the WG considers it useful. > >> > >>Yes, I think I have read the paper before, just that I got lazy trying > >>to seek out the complete bibliography. Thanks. > >> > >> > >>> Some Editorial comments: > >>> > >>> - Page 5, "lesser" instead of "least" in "... of a least cost ..." ?? > >>> - Page 5, "Quality of Service" instead of "Quality of Services" ?? > >>> - Page 12, "do" instead of "does" in "... the scenarios described in > >>>Section 3 does so ..." ?? > >>> - Page 23: "worthwhile" instead of "worth while" ?? > >>> - Page 26: "may be" instead of "maybe" in "... transmission maybe > >>>disrupted ..." ?? > >>> - Page 31: "detailed" instead of "detail" ?? > >> > >>OK. > >> > >> > >>> I have some comments about how MIRON (a NEMO RO particular solution > >>>cited in the draft that I'm co-author of) is described in the draft, a= nd > >>>in general about the Mobile Router as a Proxy family of solutions. I'l= l > >>>send them in a separate mail. > >> > >>You are welcomed. We interpret each proposal in our own way, and its > >>good to have authors of the proposals referred to in the draft to point > >>out to us some of our mis-interpretation. Plus please also remember > >>that (1) we are trying to be concise, (2) we generalize, and (3) we > >>document so many different proposals that we probably confuse > >>ourselves :). > >> > >=20 > >=20 > > Thanks a lot. > >=20 > > Kind Regards, > >=20 > > Carlos J. > >=20 > >=20 > >>/rgds > >>/cwng > >> > >> > >>> Hope this helps. > >>> > >>> Thanks a lot for writing the draft. > >>> > >>> Kind regards, > >>> > >>> Carlos J. =20 > >>> > >>>[1] Securing Route Optimisation in NEMO > >>>Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio= Soto > >>>Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, > >>>2005. WIOPT 2005. Third International Symposium on=20 > >>>3-7 April 2005 Page(s): 248 - 254 > >>> >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-oQ7UHlwdFUU0GEHAx2FN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDH/8L7QxZUr+JuXQRAii6AJ9Cxh8RJGOqQuA4Oiiw4KNGytaDTgCgm1nB eMWjyw1PKXwIWFU/IiNZYbY= =Nb3j -----END PGP SIGNATURE----- --=-oQ7UHlwdFUU0GEHAx2FN-- From nemo-bounces@ietf.org Thu Sep 08 05:12:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDISA-0004Jl-BJ; Thu, 08 Sep 2005 05:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIS8-0004ID-3J for nemo@megatron.ietf.org; Thu, 08 Sep 2005 05:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08578 for ; Thu, 8 Sep 2005 05:12:13 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDIVR-0005og-VC for nemo@ietf.org; Thu, 08 Sep 2005 05:15:43 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D8BB270DB9; Thu, 8 Sep 2005 11:12:00 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E245670D19; Thu, 8 Sep 2005 11:11:58 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Masafumi Watari In-Reply-To: <431FA1C7.3080503@kddilabs.jp> References: <1126019862.7897.165.camel@acorde> <431FA1C7.3080503@kddilabs.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Rm3d4ZslJ8zwFC3awK8C" Organization: UC3M Date: Thu, 08 Sep 2005 11:11:58 +0200 Message-Id: <1126170718.7199.32.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah Ng Subject: [nemo] Re: Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Rm3d4ZslJ8zwFC3awK8C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Watari, Please, see comments inline... El jue, 08-09-2005 a las 11:28 +0900, Masafumi Watari escribi=F3: > Hello Carlos, >=20 > Thanks for providing the text. >=20 > On 2005/09/07 0:17, Carlos Jes=FAs Bernardos Cano wrote: > > Hi draft authors, and all, > >=20 > > As presented in Paris, it was agreed to include some changes on the the > > draft-ietf-nemo-ro-problem-statement-00.txt, to solve some of the issue= s > > raised on the ML. Here I propose some text for discussion: > >=20 > > In the section 2.1, in the part describing "Longer route leading to > > increased delay and additional infrastructure load", it is stated that > > applications such as real-time multimedia streaming may not be able to > > tolerate the increased delay. I'd suggest adding the following: > >=20 > > "Besides, the increase in delay impact also the performance of transpor= t > > protocols such as TCP, since the rate at which a TCP nodes send packets > > is driven by the congestion control algorithm, which is related to the > > RTT perceived by the communication peers. If the RTT is inflated due to > > the MRHA tunnel, the effective throughput obtained by an application > > will decrease, especially in those cases in which there are several > > competing flows sharing a bandwidth-limited link (those flows with less > > RTT will obtain higher throughput)". >=20 > The multiple flows sutff may be more to the bottle neck discussion. > Besides that, I'm positive on adding the text. I will leave this for > Chan-Wah, but how about; >=20 > "In general, the increase in delay also impact the performance of > transport protocols such as TCP, since the rate at which a TCP nodes > send packets is driven by the congestion control algorithm, which is > related to the RTT perceived by the communication peers. If the RTT is > inflated due to the MRHA tunnel, the effective throughput obtained by an > application will decrease." OK, it's fine for me. >=20 > > A minor remark about the effect of increased packet loss probability > > when using the MRHA tunnel and the TCP performance may be also included > > here (or in the "Increased susceptibility to link failure" subsection). >=20 > I thought we already have some text on the possibility of packet > losses... Yes, you have. I meant adding some text in the effect of packet losses in TCP, but I agree, that maybe it would be going into too much detail. >=20 > > In the section B.4.3, I'd suggest to add the following text to comment > > about the possibility of using the VMN's CoA for communication in > > short-term communications: > >=20 > > "The MNN may also decide to use its Care-of Address as the source > > address of the packets, thus avoiding the tunnelling with the MNN's HA. > > This is particularly useful for a short-term communication that may > > easily be retried if it fails. RFC 3484 (Default Address Selection) > > provides some mechanisms for controlling the choice of the source > > address. An API may also be alternatively used for those applications > > running on the MNN that have enough knowledge of the communication bein= g > > sent to decide whether to use the MNN's Home Address or the MNN's > > Care-of Address as the source address of the packets being sent." >=20 > I would rather not go into the API stuff. I think the first part is > sufficient for the text here. OK. Kind Regards, Carlos J. >=20 > thanks again, > watari --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-Rm3d4ZslJ8zwFC3awK8C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDIABe7QxZUr+JuXQRAsOXAJ9JuCni0uRPo0+/JGin5Ft3TDgO4ACgpkwa ZmiL1FodVQzu1uy28/CAH78= =m0b6 -----END PGP SIGNATURE----- --=-Rm3d4ZslJ8zwFC3awK8C-- From nemo-bounces@ietf.org Thu Sep 08 05:42:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIvd-0002Q4-NE; Thu, 08 Sep 2005 05:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIvb-0002Oh-N7 for nemo@megatron.ietf.org; Thu, 08 Sep 2005 05:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09528 for ; Thu, 8 Sep 2005 05:42:40 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDIyx-0006XL-2H for nemo@ietf.org; Thu, 08 Sep 2005 05:46:11 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j889gL7I013619; Thu, 8 Sep 2005 18:42:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j889gMK11814; Thu, 8 Sep 2005 18:42:22 +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 j889gK416809; Thu, 8 Sep 2005 18:42:20 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 17:40:09 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 57AEA1ED726; Thu, 8 Sep 2005 18:01:22 +0800 (SGT) From: Chan-Wah Ng To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1126170379.7199.26.camel@acorde> References: <1126005133.7897.87.camel@acorde> <1126017213.2181.63.camel@localhost> <1126079691.8358.21.camel@acorde> <431F957B.9010802@kddilabs.jp> <1126170379.7199.26.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 08 Sep 2005 18:01:21 +0800 Message-Id: <1126173681.2181.192.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 08 Sep 2005 09:40:09.0679 (UTC) FILETIME=[4D977DF0:01C5B459] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , IETF NEMO WG Subject: [nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, Carlos, Watari-san, On Thu, 2005-09-08 at 11:06 +0200, Carlos Jes=FAs Bernardos Cano wrote: > > >>> - In the section 3.4, the use of delegation of a single prefix to a > > >>>nested NEMO is pointed out. It is said that in that case, the MRs wo= uld > > >>>have to perform ND on behalf of the MNNs. If so, then the addresses = of > > >>>the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In > > >>>that case, LFNs would not be supported. I think that some kind of > > >>>address delegation may be useful for a potential NEMO RO solution, b= ut > > >>>I'm not so sure about the direct delegation of a prefix to every nod= e in > > >>>the nested NEMO. OTOH, I have to admit that I have not read the last > > >>>drafts about prefix delegation, so maybe I'm missing something. > > >>> > > >> > > >>This is one RO scheme where LFN is not supported. Because if LFN are= to > > >>be supported, they would break session continuity when the prefix is > > >>changed. > > >=20 > > > Then, IMHO, maybe it would be good to explicitly say in the document > > > that this RO scheme does not support LFN. > >=20 > > Either that or maybe this example is too solution specific. I mean, > > this is going into a discussion on the tradeoffs of which nodes are > > supported and which are not. I don't know whether we should even > > discuss schemes which doesn't support LFNs... >=20 > The problem is that, IMO, if you don't clarify that some solutions do > not support LFNs, the reader may think that they do (since one of the > advantages of NEMO is providing mobility support to nodes that have > not). I agree, that maybe it'd be better to skip solutions that do not > support LFNs, but I'd suggest to keep them but making clear that they do > not support LFNs. >=20 I agree that we should mention such solutions do not support unmodified LFN, but I think Sect 3.3 may not be the best place. I am more inclined to adding that in Sect 5. > > >> > > >>> - The section 4.3 points out the problem of the increased delay dur= ing > > >>>handoff that may occur due to NEMO RO. I agree on that, but maybe it= 'd > > >>>be worth to say that this problem is similar to the one that is pres= ent > > >>>in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especi= ally > > >>>because of the Return Routability procedure) also adds latency, but = to > > >>>deal with that problem there are other proposals (e.g., FMIPv6 or > > >>>HMIPv6) that are somehow independent to the RO problem. > > >> > > >>Well, we expect that in some NEMO-RO proposals, the handoff delay wil= l > > >>be greater. For instance, consider a node behind 3 MRs. Certain NEM= O > > >>RO proposals may require each of these MR to signal the CA. Assuming > > >>the signaling delay is d, then the delay for the node is anything > > >>between (d, d+3d), worse than or at best equal to MIPv6 RO. > > >=20 > > >=20 > > > Yes, I agree on the fact the some of the NEMO-RO proposals will > > > increase the handover delay. What I was trying to point out is that i= n > > > Mobile IPv6, the RO also increases the handover delay (Return > > > Routability, Binding Update, etc.), so this increase is not new in NE= MO. > > > It could be higher than in MIPv6, but it not a new problem, and in MI= Pv6 > > > they have dealt with it by designing new protocols focused in optimis= ing > > > the handover delays. > >=20 > > The problem maybe similar to MIP6, but greater which could be critical > > than MIP6. I would like to rather avoid including such text that may > > mislead the readers that the problem is simply the same as that of MIP6= . >=20 > The problem is not "the same", but it is of the same nature than in > MIPv6. Besides, depending on the solution, it could be not greater than > in MIPv6. I think that it could be useful so say somehow that the > problem could be more severe than in MIPv6, but that is of a similar > nature (and therefore, it could be dealt with similarly as well). >=20 I would agree to mention that similar delay are experienced by Mobile IPv6, and also mentioned that principles used in FMIP might be helpful in countering this. /rgds /cwng From nemo-bounces@ietf.org Thu Sep 08 07:42:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDKnE-0002L2-Tz; Thu, 08 Sep 2005 07:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDKnD-0002Kx-Am for nemo@megatron.ietf.org; Thu, 08 Sep 2005 07:42:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13883 for ; Thu, 8 Sep 2005 07:42:09 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDKqa-0000tO-BN for nemo@ietf.org; Thu, 08 Sep 2005 07:45:40 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j88BqTlU014427; Thu, 8 Sep 2005 04:52:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j88BmHj7002194; Thu, 8 Sep 2005 06:48:18 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D0060865980; Thu, 8 Sep 2005 13:41:46 +0200 (CEST) Message-ID: <4320237A.7020802@motorola.com> Date: Thu, 08 Sep 2005 13:41:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> <431F9B50.4080703@kddilabs.jp> <1126147837.2181.158.camel@localhost> In-Reply-To: <1126147837.2181.158.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > Hello Alex, Watari-san, and all > > On Thu, 2005-09-08 at 11:00 +0900, Masafumi Watari wrote: > >>On 2005/09/07 23:10, Alexandru Petrescu wrote: >> >>>>>I have terminology comments (it's only terminology, not any paramountly >>>>>important issue). >>>>> >>>>>CA is established as Certificate Authority, it relates to IP and IPsec, >>>>>it's in wide use in an area where I am looking. >>>> >>>>Yes, we have the same argument among the authors, and I lost :). Our >>>>conclusion is that the reader is smart enough to known which CA is >>>>referred to base on the context. >>> >>>Chan-Wah, co-authors :-) this is not a matter of winning or loosing. >> >>I wasn't involved in that btw ;) > > > :) > > >>>My own oppinions are not necessarily well grounded and may seem as "just >>>another oppinion on a topic we've hammered a lot already". >>> >>>My conclusion is that a writer is smart enough to assume a very dumb >>>reader and put the least intellectual effort on her/him :-) > > > Which is exactly why we follow RFC3963's convention of expanding the > whole terms, and not to use abbreviation. In normal ML discussion, the > correspondents should know what they are referring to in the context. > > >>>The draft has this: "A straight-forward approach to Route Optimization >>>in NEMO is for the Mobile Router to attempt Route Optimization with a >>>Correspondent Agent" which abbreviates into "A straight-forward approach >>>to RO in NEMO is for the MR to attempt RO with a CA" - heavy, what's CA? >>> >>>Here's another potential intellectually heavy text: MR, HA and CA trust >>>the same CA so they can securely establish optimal paths. >> >>I see. >> > > > I know what you are pointing at, in fact the same discussion appeared a > while ago on this same ML. > > The way I see it, we just need a term to refer to. It can be anything, > as long as the readers know what we are referring to. > > >>>>>a router at one or few IP hops away from the CN to the Internet, >>>>>potentially offering new IPv6 RO mobility services. This router is much >>>>>closer to CN than to MR's home or to any other network that MR visits. >>>>>(Distance between IP entities is preferably evaluated without >>>>>mobility-related tunnels.) >>>> >>>>Hm..., what you defined seems to be what is defined for Corespondent >>>>Router. What is needed here is an entity that terminates the RO session >>>>(or that stores the binding). It can be the CR or the CN. >>> >>>And if I were to wrote "zero or few" instead of "one or few"? > > > Alex, you can, but there is still the problem of the word "router". You > have to called it a node, an entity, or something like that. > > >>>Ok, an entity that can be either a CR or a CN could simply be called CRN. >> >>As in Correspondent Router Node? I'm not sure... >>IF a MN can be either MH or MR, then CN should be either CH or CR. Right. >>But we've always used CN as nothing more than CH. If we re-define >>CN so that it can be both CR and CH, would that solve everything...? >> > > > Nope. MN and CN are untouchable, set in gold. You will confuse all > readers who read RFC3775 first (and that's practically the whole IETF). By 3775 CN is a Node, a Node implements IP so can be either a host or a router. People who always assumed that a Node is a Host will be indeed confused. > That is why I always use MNN, instead of simply MN. > > >>Or how about we simply called them "peers" ? or PA: Peer Agent or >>NA: Nemo Agent or CE: Correspondet Entity or CP: Correspondent Peer... I could live with PA (with the minor risk of colliding with PANA Agent). > I would go for Correspondent entity. I could live with CE Correspondent Entity. I could live with simply Entity, or simply host, or simply router. Alex From nemo-bounces@ietf.org Thu Sep 08 07:50:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDKuy-0004Hp-Ho; Thu, 08 Sep 2005 07:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDKuw-0004Hk-Ob for nemo@megatron.ietf.org; Thu, 08 Sep 2005 07:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14188 for ; Thu, 8 Sep 2005 07:50:09 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDKyI-00013d-La for nemo@ietf.org; Thu, 08 Sep 2005 07:53:40 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id C940C80DB; Thu, 8 Sep 2005 13:49:42 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1EDKtM-0002eY-Ar; Thu, 08 Sep 2005 13:48:32 +0200 Date: Thu, 8 Sep 2005 13:48:32 +0200 From: Julien Bournelle To: Alexandru Petrescu Subject: Re: [nemo] RO solution space - CA is Certificate Authority Message-ID: <20050908114832.GP27846@ipv6-3.int-evry.fr> References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> <431F9B50.4080703@kddilabs.jp> <1126147837.2181.158.camel@localhost> <4320237A.7020802@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4320237A.7020802@motorola.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi alex, just a quick recitification to your previous mail: On Thu, Sep 08, 2005 at 01:41:46PM +0200, Alexandru Petrescu wrote: > >>Or how about we simply called them "peers" ? or PA: Peer Agent or > >>NA: Nemo Agent or CE: Correspondet Entity or CP: Correspondent Peer... > > I could live with PA (with the minor risk of colliding with PANA Agent). The acronym for PANA Agent (in fact PANA Authentication Agent) is PAA so no collision. Just my 2 cents. regards, Julien > > > I would go for Correspondent entity. > > I could live with CE Correspondent Entity. > > I could live with simply Entity, or simply host, or simply router. > > Alex > -- julien.bournelle at int-evry.fr From nemo-bounces@ietf.org Thu Sep 08 08:23:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLR5-0003nI-S0; Thu, 08 Sep 2005 08:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLR4-0003nD-6i for nemo@megatron.ietf.org; Thu, 08 Sep 2005 08:23:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15945 for ; Thu, 8 Sep 2005 08:23:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLUQ-00025P-FG for nemo@ietf.org; Thu, 08 Sep 2005 08:26:52 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2005 14:23:11 +0200 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 j88CMYVt025364; Thu, 8 Sep 2005 14:23:08 +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.0); Thu, 8 Sep 2005 14:23:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt Date: Thu, 8 Sep 2005 14:23:02 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC013D0D07@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt Thread-Index: AcWyOs6cv0fBT6WASi2aOVAcncQVIwCHqsYw From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" , "Vijay Devarapalli" X-OriginalArrivalTime: 08 Sep 2005 12:23:07.0121 (UTC) FILETIME=[1166BE10:01C5B470] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Let me add a little bit on Vijay's answer which I agree with btw :) >-----Original Message----- >From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >Sent: Monday, September 05, 2005 6:56 PM >To: Vijay Devarapalli >Cc: Pascal Thubert (pthubert); nemo@ietf.org; Ralph Droms (rdroms) >Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt > >Hello Pascal and Vijay > >I read the draft and feel the same impression with Vijay. I agree >with Vijay. >The section 3.2 is not directly related to the NEMO PD. >We had the consensus not to include local mobility management in >DHCPv6PD >at the Minneapolis meeting (forget maybe somewhere else). > [] I guess it's no problem to remove that part. We might want to discuss that at NETLMM, what do you think? >Here are more comments. > >Can MR can skip DHCP server discovery sending message to FF02::1:2 ? >If MR knows the HA, MR can send request message to the HA without DR >discovery. [] Ralph and I talked about that. His point: "If I understand the question correctly, the suggestion is to skip the Solicit/Advertise messages and go straight to Request/Reply. I would prefer not to make that change to the DHCPv6 protocol. If the concern is in the number of messages, the MR could use Rapid Commit to use a Solicit/Reply message exchange." [] >On the other hand, If MR does not know the HA, can MR use DHCP6PD as >an alternative HA discovery mechanism? [] Same as Vijay >Or, MR rather do DHAAD to know a HA first, then it sends an address >request message to the known HA? > [] Same as Vijay >When there are multiple HAs available at a home link, do you assume >only one of HA supports DR? [] All HAs being DR would be difficult to manage/coordinate. Rather, if you want a symmetrical configuration, then all the HAs are relays and a specific server is DR on the Hone Link. I'm taking your questions as really pointing out where the text is unclear. Ralph and I are already discussing on how to fix this :) Thanks Ryuji... Pascal From nemo-bounces@ietf.org Thu Sep 08 11:28:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOJv-00081T-Fc; Thu, 08 Sep 2005 11:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOJt-00081O-Ur for nemo@megatron.ietf.org; Thu, 08 Sep 2005 11:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26474 for ; Thu, 8 Sep 2005 11:28:07 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDONI-00078m-B4 for nemo@ietf.org; Thu, 08 Sep 2005 11:31:41 -0400 Received: from iseran.local (unknown [IPv6:2002:3dca:b08:1::1]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 469364CCBB for ; Fri, 9 Sep 2005 00:27:38 +0900 (JST) Date: Fri, 9 Sep 2005 00:27:31 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RO solution space - CA is Certificate Authority Message-Id: <20050909002731.07ec2880.ernst@sfc.wide.ad.jp> In-Reply-To: <4320237A.7020802@motorola.com> References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> <431F9B50.4080703@kddilabs.jp> <1126147837.2181.158.camel@localhost> <4320237A.7020802@motorola.com> Organization: Keio University 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-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >>>>>CA is established as Certificate Authority, it relates to IP and > >IPsec,>>>>it's in wide use in an area where I am looking. > >>>> > >>>>Yes, we have the same argument among the authors, and I lost :). > >Our>>>conclusion is that the reader is smart enough to known which CA > >is>>>referred to base on the context. Before been established as an acronym for "Certificate Authority" CA was also established as the acronym of a Frenck bank (Credit Agricole) ;-) I don't think an acronym should be disqualified because of existing acronyms when the topics are different, otherwise this is a dead end. If you look around, there are a bunch of similar acronyms and I think people are clever enough to distinguish between the two particularly when you can simply instantiate them (write the term in full, only use the acronyms in un-ambiguous sentences) My 2 cents, Thierry From nemo-bounces@ietf.org Thu Sep 08 11:57:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOmc-0006q5-AX; Thu, 08 Sep 2005 11:57:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOmb-0006q0-60 for nemo@megatron.ietf.org; Thu, 08 Sep 2005 11:57:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28562 for ; Thu, 8 Sep 2005 11:57:46 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDOpz-00085x-MV for nemo@ietf.org; Thu, 08 Sep 2005 12:01:20 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j88FvfBO005070; Thu, 8 Sep 2005 08:57:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j88G519x001025; Thu, 8 Sep 2005 11:05:02 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D4B3C865980; Thu, 8 Sep 2005 17:57:38 +0200 (CEST) Message-ID: <43205F72.5020206@motorola.com> Date: Thu, 08 Sep 2005 17:57:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <431EE511.7050503@motorola.com> <1126102403.2181.141.camel@localhost> <431EF4F1.2070905@motorola.com> <431F9B50.4080703@kddilabs.jp> <1126147837.2181.158.camel@localhost> <4320237A.7020802@motorola.com> <20050909002731.07ec2880.ernst@sfc.wide.ad.jp> In-Reply-To: <20050909002731.07ec2880.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > >>>>>>>CA is established as Certificate Authority, it relates to IP and >>> >>>IPsec,>>>>it's in wide use in an area where I am looking. >>> >>>>>>Yes, we have the same argument among the authors, and I lost :). >>> >>>Our>>>conclusion is that the reader is smart enough to known which CA >>>is>>>referred to base on the context. > > > Before been established as an acronym for "Certificate Authority" CA was > also established as the acronym of a Frenck bank (Credit Agricole) ;-) :-) but Credit Agricole doesn't risk being mentioned in the same phrase with RO, MR, HA, while Certificate Authority does. > I don't think an acronym should be disqualified because of existing > acronyms when the topics are different, otherwise this is a dead end. > > If you look around, there are a bunch of similar acronyms and I think > people are clever enough to distinguish between the two particularly > when you can simply instantiate them (write the term in full, only use > the acronyms in un-ambiguous sentences) I partially share that view. Alex From nemo-bounces@ietf.org Thu Sep 08 12:59:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDPjx-0001p0-1l; Thu, 08 Sep 2005 12:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDPjv-0001o3-Hw for nemo@megatron.ietf.org; Thu, 08 Sep 2005 12:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03220 for ; Thu, 8 Sep 2005 12:59:04 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDPnJ-0001SU-C1 for nemo@ietf.org; Thu, 08 Sep 2005 13:02:39 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2005 18:58:56 +0200 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 j88GwqVP023409; Thu, 8 Sep 2005 18:58:53 +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.0); Thu, 8 Sep 2005 18:58:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RO solution space - CA is Certificate Authority Date: Thu, 8 Sep 2005 18:58:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO solution space - CA is Certificate Authority Thread-Index: AcW0ikk3a2kfT4QCTXGgNzFfjpL6mwAAiqpQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 08 Sep 2005 16:58:52.0588 (UTC) FILETIME=[9744A6C0:01C5B496] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Yes... OTOH, if there is a risk of a collision then we should change. And that might be the case here. What about Correspondent Side Agent? CSA also exists in France but I do not expect them to participate to our drafts :) >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst >Sent: Thursday, September 08, 2005 5:28 PM >To: nemo@ietf.org >Subject: Re: [nemo] RO solution space - CA is Certificate Authority > > > >> >>>>>CA is established as Certificate Authority, it relates to IP and >> >IPsec,>>>>it's in wide use in an area where I am looking. >> >>>> >> >>>>Yes, we have the same argument among the authors, and I lost :). >> >Our>>>conclusion is that the reader is smart enough to known which CA >> >is>>>referred to base on the context. > >Before been established as an acronym for "Certificate Authority" CA was >also established as the acronym of a Frenck bank (Credit Agricole) ;-) > >I don't think an acronym should be disqualified because of existing >acronyms when the topics are different, otherwise this is a dead end. > >If you look around, there are a bunch of similar acronyms and I think >people are clever enough to distinguish between the two particularly >when you can simply instantiate them (write the term in full, only use >the acronyms in un-ambiguous sentences) > >My 2 cents, >Thierry From nemo-bounces@ietf.org Thu Sep 08 13:35:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQJQ-0002QP-92; Thu, 08 Sep 2005 13:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQJP-0002QE-2a for nemo@megatron.ietf.org; Thu, 08 Sep 2005 13:35:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05014 for ; Thu, 8 Sep 2005 13:35:44 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDQMo-0002Q9-28 for nemo@ietf.org; Thu, 08 Sep 2005 13:39:19 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j88HkDhw021532; Thu, 8 Sep 2005 10:46:13 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j88Hhdag028157; Thu, 8 Sep 2005 12:43:39 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A3103865980; Thu, 8 Sep 2005 19:35:31 +0200 (CEST) Message-ID: <43207663.2030704@motorola.com> Date: Thu, 08 Sep 2005 19:35:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Yes... OTOH, if there is a risk of a collision then we should change. > And that might be the case here. What about Correspondent Side Agent? > CSA also exists in France but I do not expect them to participate to our > drafts :) CSA Correspondent Side Agent is fine with me too, but sounds like it can't be the CN itself, sounds like it must be on its side somewhere, no? Alex > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > > Thierry Ernst > >>Sent: Thursday, September 08, 2005 5:28 PM >>To: nemo@ietf.org >>Subject: Re: [nemo] RO solution space - CA is Certificate Authority >> >> >> >> >>>>>>>>CA is established as Certificate Authority, it relates to IP and >>>> >>>>IPsec,>>>>it's in wide use in an area where I am looking. >>>> >>>>>>>Yes, we have the same argument among the authors, and I lost :). >>>> >>>>Our>>>conclusion is that the reader is smart enough to known which > > CA > >>>>is>>>referred to base on the context. >> >>Before been established as an acronym for "Certificate Authority" CA > > was > >>also established as the acronym of a Frenck bank (Credit Agricole) ;-) >> >>I don't think an acronym should be disqualified because of existing >>acronyms when the topics are different, otherwise this is a dead end. >> >>If you look around, there are a bunch of similar acronyms and I think >>people are clever enough to distinguish between the two particularly >>when you can simply instantiate them (write the term in full, only use >>the acronyms in un-ambiguous sentences) >> >>My 2 cents, >>Thierry > > From nemo-bounces@ietf.org Thu Sep 08 15:19:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRvw-0006K7-UF; Thu, 08 Sep 2005 15:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRvv-0006Jq-4h for nemo@megatron.ietf.org; Thu, 08 Sep 2005 15:19:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12997 for ; Thu, 8 Sep 2005 15:19:36 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDRzL-0005Xj-0A for nemo@ietf.org; Thu, 08 Sep 2005 15:23:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j88Ikbl14204; Thu, 8 Sep 2005 11:46:37 -0700 X-mProtect: <200509081846> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdw46xXi; Thu, 08 Sep 2005 11:46:36 PDT Message-ID: <43208EB2.8030804@iprg.nokia.com> Date: Thu, 08 Sep 2005 12:19:14 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt References: <7892795E1A87F04CADFCCF41FADD00FC013D0D07@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC013D0D07@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Ryuji Wakikawa , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org sounds good to me. Vijay Pascal Thubert (pthubert) wrote: > Let me add a little bit on Vijay's answer which I agree with btw :) > > >>-----Original Message----- >>From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >>Sent: Monday, September 05, 2005 6:56 PM >>To: Vijay Devarapalli >>Cc: Pascal Thubert (pthubert); nemo@ietf.org; Ralph Droms (rdroms) >>Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt >> >>Hello Pascal and Vijay >> >>I read the draft and feel the same impression with Vijay. I agree >>with Vijay. >>The section 3.2 is not directly related to the NEMO PD. >>We had the consensus not to include local mobility management in >>DHCPv6PD >>at the Minneapolis meeting (forget maybe somewhere else). >> > > [] I guess it's no problem to remove that part. We might want to > discuss that at NETLMM, what do you think? > > >>Here are more comments. >> >>Can MR can skip DHCP server discovery sending message to FF02::1:2 ? >>If MR knows the HA, MR can send request message to the HA without DR >>discovery. > > > [] Ralph and I talked about that. His point: > > "If I understand the question correctly, the suggestion is to skip the > Solicit/Advertise messages and go straight to Request/Reply. > > I would prefer not to make that change to the DHCPv6 protocol. If the > concern is in the number of messages, the MR could use Rapid Commit to > use a Solicit/Reply message exchange." > > [] >On the other hand, If MR does not know the HA, can MR use > DHCP6PD as > >>an alternative HA discovery mechanism? > > [] Same as Vijay > > >>Or, MR rather do DHAAD to know a HA first, then it sends an address >>request message to the known HA? >> > > [] Same as Vijay > > >>When there are multiple HAs available at a home link, do you assume >>only one of HA supports DR? > > > [] All HAs being DR would be difficult to manage/coordinate. Rather, > if you want a symmetrical configuration, then all the HAs are relays and > a specific server is DR on the Hone Link. > > I'm taking your questions as really pointing out where the text is > unclear. Ralph and I are already discussing on how to fix this :) Thanks > Ryuji... > > > Pascal > From nemo-bounces@ietf.org Fri Sep 09 02:40:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDcYW-0007bJ-Mp; Fri, 09 Sep 2005 02:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDcYT-0007ay-DE for nemo@megatron.ietf.org; Fri, 09 Sep 2005 02:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12871 for ; Fri, 9 Sep 2005 02:40:08 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDcby-0007Qj-Ri for nemo@ietf.org; Fri, 09 Sep 2005 02:43:48 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A1F474C0DF for ; Fri, 9 Sep 2005 15:39:36 +0900 (JST) Date: Fri, 9 Sep 2005 15:39:36 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20050909153936.39faaa43.ernst@sfc.wide.ad.jp> Organization: Keio University 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-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] cfp - NEMO Workshop (WONEMO) in Japan, January 06. Papers by Oct.31, 2005 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, Please find at the following URL a CFP for a NEMO workshop in which we would be happy to get papers from folks involved at the IETF. The actual submission process is currently under set up, so we will re-issue the announcement once it's finished. In the meantime, please distribute this CFP around you. http://www.nautilus6.org/events/wonemo.html http://www.nautilus6.org/events/wonemo.txt Thierry. From nemo-bounces@ietf.org Fri Sep 09 03:08:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDczV-0003yM-11; Fri, 09 Sep 2005 03:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDczR-0003xz-JT for nemo@megatron.ietf.org; Fri, 09 Sep 2005 03:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14008 for ; Fri, 9 Sep 2005 03:08:00 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDd2y-00087X-JE for nemo@ietf.org; Fri, 09 Sep 2005 03:11:41 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id EAFB6EC835; Fri, 9 Sep 2005 16:07:37 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 49BEBEC833; Fri, 9 Sep 2005 16:07:37 +0900 (JST) Received: from [IPv6?2001?200?601?200?8d3a?3ec4?a950?60aa] (unknown [IPv6:2001:200:601:200:8d3a:3ec4:a950:60aa]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 3B00E340078; Fri, 9 Sep 2005 16:07:37 +0900 (JST) Message-ID: <43213544.2000601@kddilabs.jp> Date: Fri, 09 Sep 2005 16:09:56 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= References: <1126019862.7897.165.camel@acorde> <431FA1C7.3080503@kddilabs.jp> <1126170718.7199.32.camel@acorde> In-Reply-To: <1126170718.7199.32.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Chan-Wah Ng Subject: [nemo] Re: Proposal of some text for draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Carlos, > Hi Watari, >=20 > Please, see comments inline... >=20 > El jue, 08-09-2005 a las 11:28 +0900, Masafumi Watari escribi=F3: >=20 >>Hello Carlos, >> >>Thanks for providing the text. >> >>On 2005/09/07 0:17, Carlos Jes=FAs Bernardos Cano wrote: >> >>>Hi draft authors, and all, >>> >>>As presented in Paris, it was agreed to include some changes on the th= e >>>draft-ietf-nemo-ro-problem-statement-00.txt, to solve some of the issu= es >>>raised on the ML. Here I propose some text for discussion: >>> >>>In the section 2.1, in the part describing "Longer route leading to >>>increased delay and additional infrastructure load", it is stated that >>>applications such as real-time multimedia streaming may not be able to >>>tolerate the increased delay. I'd suggest adding the following: >>> >>>"Besides, the increase in delay impact also the performance of transpo= rt >>>protocols such as TCP, since the rate at which a TCP nodes send packet= s >>>is driven by the congestion control algorithm, which is related to the >>>RTT perceived by the communication peers. If the RTT is inflated due t= o >>>the MRHA tunnel, the effective throughput obtained by an application >>>will decrease, especially in those cases in which there are several >>>competing flows sharing a bandwidth-limited link (those flows with les= s >>>RTT will obtain higher throughput)". >> >>The multiple flows sutff may be more to the bottle neck discussion. >>Besides that, I'm positive on adding the text. I will leave this for >>Chan-Wah, but how about; >> >>"In general, the increase in delay also impact the performance of >>transport protocols such as TCP, since the rate at which a TCP nodes >>send packets is driven by the congestion control algorithm, which is >>related to the RTT perceived by the communication peers. If the RTT is >>inflated due to the MRHA tunnel, the effective throughput obtained by a= n >>application will decrease." >=20 > OK, it's fine for me. It's been applied for -01. >>>A minor remark about the effect of increased packet loss probability >>>when using the MRHA tunnel and the TCP performance may be also include= d >>>here (or in the "Increased susceptibility to link failure" subsection)= . >> >>I thought we already have some text on the possibility of packet >>losses... >=20 > Yes, you have. I meant adding some text in the effect of packet losses > in TCP, but I agree, that maybe it would be going into too much detail. Ok. Let's keep the document short. >>>In the section B.4.3, I'd suggest to add the following text to comment >>>about the possibility of using the VMN's CoA for communication in >>>short-term communications: >>> >>>"The MNN may also decide to use its Care-of Address as the source >>>address of the packets, thus avoiding the tunnelling with the MNN's HA= . >>>This is particularly useful for a short-term communication that may >>>easily be retried if it fails. RFC 3484 (Default Address Selection) >>>provides some mechanisms for controlling the choice of the source >>>address. An API may also be alternatively used for those applications >>>running on the MNN that have enough knowledge of the communication bei= ng >>>sent to decide whether to use the MNN's Home Address or the MNN's >>>Care-of Address as the source address of the packets being sent." >> >>I would rather not go into the API stuff. I think the first part is >>sufficient for the text here. > OK. Also added for -01. thanks again, watari From nemo-bounces@ietf.org Fri Sep 09 09:44:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDjBb-0007Jg-Hx; Fri, 09 Sep 2005 09:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDjBZ-0007JX-Vs for nemo@megatron.ietf.org; Fri, 09 Sep 2005 09:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02090 for ; Fri, 9 Sep 2005 09:44:55 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDjF7-0002BA-UT for nemo@ietf.org; Fri, 09 Sep 2005 09:48:39 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7343789848 for ; Fri, 9 Sep 2005 16:44:40 +0300 (EEST) Message-ID: <432191D4.1060803@piuha.net> Date: Fri, 09 Sep 2005 16:44:52 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Subject: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I've read this draft. Very nice document, and a good view to the solution space. In fact, I got a bit scared after having read this document, given the various issues with deep nesting, signaling storms, security, and the very different solutions that have been proposed. Some comments: > o Avoid the Security Policy Issue > > Security policy may forbid Mobile Routers from tunneling traffic > of Visiting Mobile Nodes into the home network of Mobile Router. > Route Optimization can be used to avoid this issue by forwarding > traffic from Visiting Mobile Nodes directly to their destination > without going through the home network of the Mobile Router. > > o Avoid the Instability and Deadlock > > [1] described a potential deadlock situation when a Home Agent is > nested within a Mobile Network. Route Optimization may circumvent > such deadlock situations by directly forwarding traffic upstream. As discussed on the list earlier, I believe the above presents a slightly too simplistic view. In the second item its possible that some RO signaling needs to go via the home network anyway, which wouldn't be able to run if there was really a loop. In the first item we need to realize that there are multiple different types of security policies. One type in conflict with the above is the "route all traffic to the inspection point at home" -policy. Another issue is that a MR that simply lets all traffic flow from its own attachment point would still be subject to be held responsible for illegal traffic & attacks from its MNNs. Where this is an issue, the solution may exist in some other layers than in NEMO, such as in network access control mechanisms. (Also, is there a need to talk about a similar form of "route optimization" that is already present in Mobile IPv6 with hosts deciding to use care-of address for some of their short-lived communications? If the hosts behind the MR actually were able to learn their true "care of addresses", this might be possible -- with impacts to these hosts and prefix discovery, of course.) > We start off with a scenario where nesting of Mobile Routers is not > considered, and Route Optimization is initiated and performed between > a Mobile Router and its peer Mobile Router, also known as a > Correspondent Router. This solution appears to have very limited applicability, given that it requires nemo devices on both ends, likely reducing deployment to only conversations between two mobile networks. > Since Mobile IPv6 defines its own > Route Optimization mechanism, providing optimal path for such hosts > will require interaction with the protocol and may require an > altering of the messages exchanged during the Return Routability > procedure with the Correspondent Node. This sounds interesting. I realize there are complexity issues, but it would be preferrable to have a single RO mechanism for CNs rather than two. Extensions to base mechanism would be needed, of course, and I have not looked at how hard that is. > One advantage of NEMO Basic Support is that the Correspondent Nodes > and Mobile Network Nodes need not be aware of the actual location and > mobility of the mobile network. With Route Optimization, it might be > necessary to reveal the point of attachment of the Mobile Router to > other nodes, such as the Mobile Network Nodes or their Correspondent > Nodes. This may mean a tradeoff between location privacy [16] (and > mobility transparency) and Route Optimization. > > In Mobile IPv6, a mobile node can decide whether or not to perform > Route Optimization with a given Correspondent Node. Thus, the mobile > node is in control of whether to trade location privacy for an > optimized route. In NEMO Route Optimization, if the decision to > perform Router Optimization is made by the Mobile Router, it will be > difficult for Mobile Network Nodes to control the decision of having > this tradeoff. This seems problematic. I'd like the MNNs to be in control of this (if they want to; some MNNs are probably unmodified IP hosts). > 4.8 Security Consideration The text in this section is good, but it seems to miss an important part which is explaining the difference between host themselves performing RO vs routers performing it for them. It appears to be a harder problem in terms of, say, seeing inside the tunneled packets, proving ownership of the addresses or sessions, etc. > All these concerns over the authenticity of addresses might suggest > that perhaps a more radical and robust approach is necessary. This > is currently under extensive study in various Working Groups of the > IETF, and many related documents might be of interest here, such as > Securing Neighbor Discovery (SEND) [28], the use of Cryptographically > Generated Addresses (CGA) [29], various enhancements to the Route > Optimization scheme of Mobile IPv6 [30][31], and possibly Host > Identity Protocol (HIP) [32] with end-host mobility considerations > [33]. You may wish to take a look also at the paper by Jukka Ylitalo in NDSS'05 workshop. This is based on a delegation approach, where MNNs delegate some rights to MRs, they in turn may delegate them further etc. Also, presumably you could use techniques such as those in [31] to allow a secure communication between a home agent and correspondent nodes, and use this to tell the CN that a specific MR exists at a specific location for the prefix. The good thing with this approach is that its aggregatable for all hosts within the prefix, i.e., you need to tell the CN only once. > Although a standardized NEMO Route > Optimization solution has yet to materialize, one can expect it to > show some of the following benefits: > (a set of benefits snipped, then later some disadvantages are listed:) > This may lead to an issue that impacts NEMO Route Optimization, known > as the phenomenon of "Binding Update Storm", or more generally, > "Signaling Storm". This occurs when a change in point of attachment > of the mobile network is accompanied with a sudden burst of signaling > messages, resulting in temporary congestion, packet delays or even > packet loss. This effect will be especially significant for wireless > environment where bandwidth is relatively limited. Obviously the choice of the mechanism affects this (e.g. MR doing this vs. MNNs doing it). But I'm worried that this may still not be enough, because even MR-based mechanisms have to deal with a large number of different endpoints; potentially multiple flows from each MNN to all different CNs. This would seem to imply that there has to be some adaptive behavior that depends on the number of signaling connections that would have to be updated vs. the effort needed to tunnel home. Another architectural issue is the amount of state needed in the MRs. Traditionally, we've tried to avoid additional state per pair of peers in the routers. --Jari From nemo-bounces@ietf.org Mon Sep 12 06:07:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EElE6-0008NU-UC; Mon, 12 Sep 2005 06:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EElE0-0008LZ-K4 for nemo@megatron.ietf.org; Mon, 12 Sep 2005 06:07:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08504 for ; Mon, 12 Sep 2005 06:07:29 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EElHy-0006sX-2m for nemo@ietf.org; Mon, 12 Sep 2005 06:11:51 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id EC686EC833; Mon, 12 Sep 2005 19:07:00 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id E1804EC874; Mon, 12 Sep 2005 19:06:59 +0900 (JST) Received: from [IPv6?2001?200?601?200?fcd0?2adc?8bb9?d122] (unknown [IPv6:2001:200:601:200:fcd0:2adc:8bb9:d122]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id C38F3340078; Mon, 12 Sep 2005 19:06:59 +0900 (JST) Message-ID: <432553D1.2020804@kddilabs.jp> Date: Mon, 12 Sep 2005 19:09:21 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 References: <432191D4.1060803@piuha.net> In-Reply-To: <432191D4.1060803@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Thanks for your review. Please find my comments inline; On 2005/09/09 22:44, Jari Arkko wrote: > > I've read this draft. Very nice document, and a good > view to the solution space. In fact, I got a bit scared > after having read this document, given the various > issues with deep nesting, signaling storms, security, > and the very different solutions that have been > proposed. > > Some comments: > >> o Avoid the Security Policy Issue >> >> Security policy may forbid Mobile Routers from tunneling traffic >> of Visiting Mobile Nodes into the home network of Mobile Router. >> Route Optimization can be used to avoid this issue by forwarding >> traffic from Visiting Mobile Nodes directly to their destination >> without going through the home network of the Mobile Router. >> >> o Avoid the Instability and Deadlock >> >> [1] described a potential deadlock situation when a Home Agent is >> nested within a Mobile Network. Route Optimization may circumvent >> such deadlock situations by directly forwarding traffic upstream. > > > As discussed on the list earlier, I believe the above presents > a slightly too simplistic view. In the second item its possible > that some RO signaling needs to go via the home network anyway, > which wouldn't be able to run if there was really a loop. Right. I think the assumption here was that such RO mechanism would allow the MR to find its HA somewhere in the nest, avoiding the loop problem. > In the first item we need to realize that there are multiple > different types of security policies. One type in conflict > with the above is the "route all traffic to the inspection > point at home" -policy. Another issue is that a MR that > simply lets all traffic flow from its own attachment point > would still be subject to be held responsible for > illegal traffic & attacks from its MNNs. Where this is > an issue, the solution may exist in some other layers > than in NEMO, such as in network access control > mechanisms. Well, if the MR forwards all packets from a VMN to the HA of that VMN, it wouldn't threanten its home and would simple work as any transit router. Illegal traffic from the MNNs would eventually look as if they were originated from their home network, thus MR should not be held reposible for that. Such path would involve atleast one of the HAs, however the path should still be effective in some cases. This is just an example. OTOH, the MR would be held reponsible for attacks to its MNNs, but I don't think that NEMO is a solution for that either. But I agree that this contradicts the problem of not having RO singaling messages to travel home. > (Also, is there a need to talk about a similar form of "route > optimization" that is already present in Mobile IPv6 > with hosts deciding to use care-of address for some > of their short-lived communications? If the hosts behind > the MR actually were able to learn their true "care of > addresses", this might be possible -- with impacts to > these hosts and prefix discovery, of course.) I couldn't catch what the issue is with this one. >> We start off with a scenario where nesting of Mobile Routers is not >> considered, and Route Optimization is initiated and performed between >> a Mobile Router and its peer Mobile Router, also known as a >> Correspondent Router. > > This solution appears to have very limited applicability, > given that it requires nemo devices on both ends, > likely reducing deployment to only conversations > between two mobile networks. This is perhaps the most simple case, i.e. does not involve nesting so it may sound limited. But, if you consider moving vehicles, they would each have nemo devices provindg optimal path for all its MNNs, so there are some reasonable applicabilities. >> Since Mobile IPv6 defines its own >> Route Optimization mechanism, providing optimal path for such hosts >> will require interaction with the protocol and may require an >> altering of the messages exchanged during the Return Routability >> procedure with the Correspondent Node. > > This sounds interesting. I realize there are complexity > issues, but it would be preferrable to have a single RO > mechanism for CNs rather than two. Extensions > to base mechanism would be needed, of course, > and I have not looked at how hard that is. The most simple case is to have the CN establish bindings for both MR and its VMN, and have it do a recursive binding lookup. But there are a lot of issues with it, such as authorizing the prefix ownership of the MR, tunnel overhead, singaling and such... watari >> One advantage of NEMO Basic Support is that the Correspondent Nodes >> and Mobile Network Nodes need not be aware of the actual location and >> mobility of the mobile network. With Route Optimization, it might be >> necessary to reveal the point of attachment of the Mobile Router to >> other nodes, such as the Mobile Network Nodes or their Correspondent >> Nodes. This may mean a tradeoff between location privacy [16] (and >> mobility transparency) and Route Optimization. >> >> In Mobile IPv6, a mobile node can decide whether or not to perform >> Route Optimization with a given Correspondent Node. Thus, the mobile >> node is in control of whether to trade location privacy for an >> optimized route. In NEMO Route Optimization, if the decision to >> perform Router Optimization is made by the Mobile Router, it will be >> difficult for Mobile Network Nodes to control the decision of having >> this tradeoff. > > > This seems problematic. I'd like the MNNs to be in control of this > (if they want to; some MNNs are probably unmodified IP hosts). > >> 4.8 Security Consideration > > > The text in this section is good, but it seems to miss an > important part which is explaining the difference between > host themselves performing RO vs routers performing it for > them. It appears to be a harder problem in terms of, say, > seeing inside the tunneled packets, proving ownership of > the addresses or sessions, etc. > >> All these concerns over the authenticity of addresses might suggest >> that perhaps a more radical and robust approach is necessary. This >> is currently under extensive study in various Working Groups of the >> IETF, and many related documents might be of interest here, such as >> Securing Neighbor Discovery (SEND) [28], the use of Cryptographically >> Generated Addresses (CGA) [29], various enhancements to the Route >> Optimization scheme of Mobile IPv6 [30][31], and possibly Host >> Identity Protocol (HIP) [32] with end-host mobility considerations >> [33]. > > > You may wish to take a look also at the paper by Jukka Ylitalo > in NDSS'05 workshop. This is based on a delegation approach, > where MNNs delegate some rights to MRs, they in turn may > delegate them further etc. > > Also, presumably you could use techniques such as those in > [31] to allow a secure communication between a home agent > and correspondent nodes, and use this to tell the CN that > a specific MR exists at a specific location for the prefix. The > good thing with this approach is that its aggregatable > for all hosts within the prefix, i.e., you need to tell the CN > only once. > >> Although a standardized NEMO Route >> Optimization solution has yet to materialize, one can expect it to >> show some of the following benefits: > > >> (a set of benefits snipped, then later some disadvantages are listed:) > > >> This may lead to an issue that impacts NEMO Route Optimization, known >> as the phenomenon of "Binding Update Storm", or more generally, >> "Signaling Storm". This occurs when a change in point of attachment >> of the mobile network is accompanied with a sudden burst of signaling >> messages, resulting in temporary congestion, packet delays or even >> packet loss. This effect will be especially significant for wireless >> environment where bandwidth is relatively limited. > > > Obviously the choice of the mechanism affects this (e.g. MR doing this > vs. MNNs doing it). But I'm worried that this may still not be enough, > because even MR-based mechanisms have to deal with a large number > of different endpoints; potentially multiple flows from each MNN to > all different CNs. > > This would seem to imply that there has to be some adaptive > behavior that depends on the number of signaling connections > that would have to be updated vs. the effort needed to tunnel > home. > > Another architectural issue is the amount of state needed in > the MRs. Traditionally, we've tried to avoid additional state > per pair of peers in the routers. > > --Jari > > > > From nemo-bounces@ietf.org Mon Sep 12 06:30:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEla1-0003a5-Qk; Mon, 12 Sep 2005 06:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EElZw-0003ZL-Iu for nemo@megatron.ietf.org; Mon, 12 Sep 2005 06:30:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09370 for ; Mon, 12 Sep 2005 06:30:22 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEle6-0007R0-Dq for nemo@ietf.org; Mon, 12 Sep 2005 06:34:43 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9646FEC833; Mon, 12 Sep 2005 19:30:13 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 7DB97EC870; Mon, 12 Sep 2005 19:30:12 +0900 (JST) Received: from [IPv6?2001?200?601?200?fcd0?2adc?8bb9?d122] (unknown [IPv6:2001:200:601:200:fcd0:2adc:8bb9:d122]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 6D97C340078; Mon, 12 Sep 2005 19:30:12 +0900 (JST) Message-ID: <43255942.3030408@kddilabs.jp> Date: Mon, 12 Sep 2005 19:32:34 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> In-Reply-To: <43207663.2030704@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On 2005/09/09 2:35, Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > >>Yes... OTOH, if there is a risk of a collision then we should change. >>And that might be the case here. What about Correspondent Side Agent? >>CSA also exists in France but I do not expect them to participate to our >>drafts :) > > CSA Correspondent Side Agent is fine with me too, but sounds like it > can't be the CN itself, sounds like it must be on its side somewhere, no? I agree. In that sense, the term Agent to me sounds more like a router and not a host (as in HA/FA). If we are to avoid CN, I would also suggest PN: Peer Node or RN: Remote Node or something like that. I could live with CE: Correspondent Entity too. Just my thoughts. watari >>>-----Original Message----- >>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of >> >>Thierry Ernst >> >> >>>Sent: Thursday, September 08, 2005 5:28 PM >>>To: nemo@ietf.org >>>Subject: Re: [nemo] RO solution space - CA is Certificate Authority >>> >>> >>> >>> >>> >>>>>>>>>CA is established as Certificate Authority, it relates to IP and >>>>> >>>>>IPsec,>>>>it's in wide use in an area where I am looking. >>>>> >>>>> >>>>>>>>Yes, we have the same argument among the authors, and I lost :). >>>>> >>>>>Our>>>conclusion is that the reader is smart enough to known which >> >>CA >> >> >>>>>is>>>referred to base on the context. >>> >>>Before been established as an acronym for "Certificate Authority" CA >> >>was >> >> >>>also established as the acronym of a Frenck bank (Credit Agricole) ;-) >>> >>>I don't think an acronym should be disqualified because of existing >>>acronyms when the topics are different, otherwise this is a dead end. >>> >>>If you look around, there are a bunch of similar acronyms and I think >>>people are clever enough to distinguish between the two particularly >>>when you can simply instantiate them (write the term in full, only use >>>the acronyms in un-ambiguous sentences) >>> >>>My 2 cents, >>>Thierry >> >> > > > > From nemo-bounces@ietf.org Mon Sep 12 07:32:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmY0-00030V-Lk; Mon, 12 Sep 2005 07:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmXx-0002zy-C7 for nemo@megatron.ietf.org; Mon, 12 Sep 2005 07:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11869 for ; Mon, 12 Sep 2005 07:32:16 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmbz-0000Qc-SU for nemo@ietf.org; Mon, 12 Sep 2005 07:36:37 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Sep 2005 13:32:06 +0200 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 j8CBVqVZ024027; Mon, 12 Sep 2005 13:32:04 +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.0); Mon, 12 Sep 2005 13:31:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 Date: Mon, 12 Sep 2005 13:31:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0140CC0B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 Thread-Index: AcW3grzt3p097JMvTAqKwAwZ34tZawACXoQw From: "Pascal Thubert \(pthubert\)" To: "Masafumi Watari" , "Jari Arkko" X-OriginalArrivalTime: 12 Sep 2005 11:31:56.0472 (UTC) FILETIME=[94CDE380:01C5B78D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >Thanks for your review. Please find my comments inline; > >On 2005/09/09 22:44, Jari Arkko wrote: >> >> I've read this draft. Very nice document, and a good >> view to the solution space. In fact, I got a bit scared >> after having read this document, given the various >> issues with deep nesting, signaling storms, security, >> and the very different solutions that have been >> proposed. >> >> Some comments: >> >>> o Avoid the Security Policy Issue >>> >>> Security policy may forbid Mobile Routers from tunneling traffic >>> of Visiting Mobile Nodes into the home network of Mobile Router. >>> Route Optimization can be used to avoid this issue by forwarding >>> traffic from Visiting Mobile Nodes directly to their destination >>> without going through the home network of the Mobile Router. >>> >>> o Avoid the Instability and Deadlock >>> >>> [1] described a potential deadlock situation when a Home Agent is >>> nested within a Mobile Network. Route Optimization may circumvent >>> such deadlock situations by directly forwarding traffic upstream. >> >> >> As discussed on the list earlier, I believe the above presents >> a slightly too simplistic view. In the second item its possible >> that some RO signaling needs to go via the home network anyway, >> which wouldn't be able to run if there was really a loop. > >Right. I think the assumption here was that such RO mechanism >would allow the MR to find its HA somewhere in the nest, >avoiding the loop problem. [] Note that the nesting exists with RFC 3963 and the first thing that might happen with a mobile router and a 2 radio interfaces is that the egress attaches to the ingress; So the question of loop avoidance is NOT an RO issue. RO, just like NEMO, assumes that the problem is fixed some way. Steve Deering asked that same question when NEMO was just a BOF, how do we avoid those loops? This is the reason why we proposed: http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-02.txt=20 But the draft is still looking for a WG to host it. The best fit seems to be MANEMO (Manet for NEMO). A mailaing list was created some time ago: http://www.mobileip.jp/mailman/listinfo/manemo It might be time to move forward with it, in parallel with nested RO, what do you think? Pascal=20 From nemo-bounces@ietf.org Mon Sep 12 07:43:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmiQ-0004lF-9G; Mon, 12 Sep 2005 07:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmiP-0004lA-Hx for nemo@megatron.ietf.org; Mon, 12 Sep 2005 07:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12411 for ; Mon, 12 Sep 2005 07:43:10 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmmW-0000gL-4f for nemo@ietf.org; Mon, 12 Sep 2005 07:47:31 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j8CBvDdR024707; Mon, 12 Sep 2005 04:57:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j8CBoQMX024266; Mon, 12 Sep 2005 06:50:27 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 53EC3865980; Mon, 12 Sep 2005 13:42:55 +0200 (CEST) Message-ID: <432569BD.5070201@motorola.com> Date: Mon, 12 Sep 2005 13:42:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] RO solution space - CA is Certificate Authority References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> <43255942.3030408@kddilabs.jp> In-Reply-To: <43255942.3030408@kddilabs.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: > On 2005/09/09 2:35, Alexandru Petrescu wrote: > >> Pascal Thubert (pthubert) wrote: >> >>> Yes... OTOH, if there is a risk of a collision then we should change. >>> And that might be the case here. What about Correspondent Side Agent? >>> CSA also exists in France but I do not expect them to participate to our >>> drafts :) >> >> >> CSA Correspondent Side Agent is fine with me too, but sounds like it >> can't be the CN itself, sounds like it must be on its side somewhere, no? > > > I agree. In that sense, the term Agent to me sounds more like a router > and not a host (as in HA/FA). If we are to avoid CN, I would also > suggest PN: Peer Node or RN: Remote Node or something like that. Right, PN sounds better. > I could live with CE: Correspondent Entity too. Ok with CE too. Maybe "Correspondent" is better because is akin to Correspondent in "CN". Alex From nemo-bounces@ietf.org Mon Sep 12 07:50:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmpS-00061R-O3; Mon, 12 Sep 2005 07:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmpR-000615-Lr for nemo@megatron.ietf.org; Mon, 12 Sep 2005 07:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12675 for ; Mon, 12 Sep 2005 07:50:18 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmtR-0000po-7F for nemo@ietf.org; Mon, 12 Sep 2005 07:54:39 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 643A989848; Mon, 12 Sep 2005 14:50:03 +0300 (EEST) Message-ID: <43256B78.9030908@piuha.net> Date: Mon, 12 Sep 2005 14:50:16 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 References: <432191D4.1060803@piuha.net> <432553D1.2020804@kddilabs.jp> In-Reply-To: <432553D1.2020804@kddilabs.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: >> In the first item we need to realize that there are multiple >> different types of security policies. One type in conflict >> with the above is the "route all traffic to the inspection >> point at home" -policy. Another issue is that a MR that >> simply lets all traffic flow from its own attachment point >> would still be subject to be held responsible for >> illegal traffic & attacks from its MNNs. Where this is >> an issue, the solution may exist in some other layers >> than in NEMO, such as in network access control >> mechanisms. > > > Well, if the MR forwards all packets from a VMN to the HA of that VMN, > it wouldn't threanten its home and would simple work as any transit router Right, although this is not the only possible solution. The other solution is network access control, where someone in the access network who is who and can send in the police to the right person. > Illegal traffic from the MNNs would eventually look as if they > were originated from their home network, thus MR should not be held > reposible for that. Such path would involve atleast one of the HAs, > however the path should still be effective in some cases. This is just > an example. OTOH, the MR would be held reponsible for attacks to its > MNNs, but I don't think that NEMO is a solution for that either. Right, it shouldn't be. > But I agree that this contradicts the problem of not having > RO singaling messages to travel home. Yes. >> (Also, is there a need to talk about a similar form of "route >> optimization" that is already present in Mobile IPv6 >> with hosts deciding to use care-of address for some >> of their short-lived communications? If the hosts behind >> the MR actually were able to learn their true "care of >> addresses", this might be possible -- with impacts to >> these hosts and prefix discovery, of course.) > > > I couldn't catch what the issue is with this one. I meant the possibility that a MNN would learn its true local care-of address, and be able to use either that or the more stable address provided by NEMO. > This is perhaps the most simple case, i.e. does not involve nesting > so it may sound limited. But, if you consider moving vehicles, they > would each have nemo devices provindg optimal path for all its MNNs, so > there are some reasonable applicabilities. Perhaps. But the work ahead of us seems pretty big, so this would be an excellent time to think what our priorities are and what problems are most useful ones to solve. That's part of the problem definition phase, not just listing what problems that could be solved, but also what ones we really want to solve. --Jari From nemo-bounces@ietf.org Mon Sep 12 07:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmpn-00062E-55; Mon, 12 Sep 2005 07:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmpm-000622-3U for nemo@megatron.ietf.org; Mon, 12 Sep 2005 07:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12684 for ; Mon, 12 Sep 2005 07:50:41 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmtp-0000qL-SX for nemo@ietf.org; Mon, 12 Sep 2005 07:55:02 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F199A89848; Mon, 12 Sep 2005 14:50:32 +0300 (EEST) Message-ID: <43256B95.6090308@piuha.net> Date: Mon, 12 Sep 2005 14:50:45 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 References: <7892795E1A87F04CADFCCF41FADD00FC0140CC0B@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0140CC0B@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert wrote: >Note that the nesting exists with RFC 3963 and the first thing >that might happen with a mobile router and a 2 radio interfaces is that >the egress attaches to the ingress; So the question of loop avoidance is >NOT an RO issue. RO, just like NEMO, assumes that the problem is fixed >some way. Steve Deering asked that same question when NEMO was just a >BOF, how do we avoid those loops? > >This is the reason why we proposed: (snip) > > I like the idea of separating loop detection and route optimization from each other. I can't comment on the specific proposal, I have not read it. --Jari From nemo-bounces@ietf.org Tue Sep 13 15:31:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVJ-00040H-28; Tue, 13 Sep 2005 15:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF6wY-0000R9-3z for nemo@megatron.ietf.org; Tue, 13 Sep 2005 05:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11458 for ; Tue, 13 Sep 2005 05:18:54 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF70g-0005Ny-Bv for nemo@ietf.org; Tue, 13 Sep 2005 05:23:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D7E20EC833; Tue, 13 Sep 2005 18:18:27 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 463C1EC82B; Tue, 13 Sep 2005 18:18:27 +0900 (JST) Received: from [IPv6?2001?200?601?200?d566?6bc5?8b34?6aa5] (unknown [IPv6:2001:200:601:200:d566:6bc5:8b34:6aa5]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 2DC70340078; Tue, 13 Sep 2005 18:18:27 +0900 (JST) Message-ID: <432699F2.9010407@kddilabs.jp> Date: Tue, 13 Sep 2005 18:20:50 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 References: <432191D4.1060803@piuha.net> <432553D1.2020804@kddilabs.jp> <43256B78.9030908@piuha.net> In-Reply-To: <43256B78.9030908@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On 2005/09/12 20:50, Jari Arkko wrote: > Masafumi Watari wrote: > >>> In the first item we need to realize that there are multiple >>> different types of security policies. One type in conflict >>> with the above is the "route all traffic to the inspection >>> point at home" -policy. Another issue is that a MR that >>> simply lets all traffic flow from its own attachment point >>> would still be subject to be held responsible for >>> illegal traffic & attacks from its MNNs. Where this is >>> an issue, the solution may exist in some other layers >>> than in NEMO, such as in network access control >>> mechanisms. >> >> Well, if the MR forwards all packets from a VMN to the HA of that VMN, >> it wouldn't threanten its home and would simple work as any transit >> router > > Right, although this is not the only possible solution. The other > solution is network access control, where someone in the access > network who is who and can send in the police to the right person. Right. >> Illegal traffic from the MNNs would eventually look as if they >> were originated from their home network, thus MR should not be held >> reposible for that. Such path would involve atleast one of the HAs, >> however the path should still be effective in some cases. This is just >> an example. OTOH, the MR would be held reponsible for attacks to its >> MNNs, but I don't think that NEMO is a solution for that either. > > Right, it shouldn't be. > >> But I agree that this contradicts the problem of not having >> RO singaling messages to travel home. > > Yes. > >>> (Also, is there a need to talk about a similar form of "route >>> optimization" that is already present in Mobile IPv6 >>> with hosts deciding to use care-of address for some >>> of their short-lived communications? If the hosts behind >>> the MR actually were able to learn their true "care of >>> addresses", this might be possible -- with impacts to >>> these hosts and prefix discovery, of course.) >> >> I couldn't catch what the issue is with this one. > > I meant the possibility that a MNN would learn its true > local care-of address, and be able to use either that > or the more stable address provided by NEMO. Ok and I agree, we should mention that somewhere in Section 5. >> This is perhaps the most simple case, i.e. does not involve nesting >> so it may sound limited. But, if you consider moving vehicles, they >> would each have nemo devices provindg optimal path for all its MNNs, so >> there are some reasonable applicabilities. > > Perhaps. But the work ahead of us seems pretty big, so this would > be an excellent time to think what our priorities are and what > problems are most useful ones to solve. That's part of the > problem definition phase, not just listing what problems that > could be solved, but also what ones we really want to solve. Right. So I guess this goes back to your comment on the problem statement draft about seeking interests of the service providers wishing to deploy NEMO (and MIP6 because the two could interact in some scenarios). We also had a similar discussion during the last meeting on such priorities and I believe this is also concerned with the WG rechartering. watari From nemo-bounces@ietf.org Wed Sep 14 04:37:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSlZ-00059d-Nl; Wed, 14 Sep 2005 04:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSlX-00059Y-Ig for nemo@megatron.ietf.org; Wed, 14 Sep 2005 04:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28464 for ; Wed, 14 Sep 2005 04:37:13 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFSq5-00038o-Im for nemo@ietf.org; Wed, 14 Sep 2005 04:41:59 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j8E8ogfd013662; Wed, 14 Sep 2005 01:50:42 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j8E8gWMt003774; Wed, 14 Sep 2005 03:42:33 -0500 (CDT) Message-ID: <4327E123.90302@motorola.com> Date: Wed, 14 Sep 2005 10:36:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 References: <432191D4.1060803@piuha.net> <432553D1.2020804@kddilabs.jp> <43256B78.9030908@piuha.net> <432699F2.9010407@kddilabs.jp> In-Reply-To: <432699F2.9010407@kddilabs.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: > On 2005/09/12 20:50, Jari Arkko wrote: > >> Masafumi Watari wrote: >> >>>> In the first item we need to realize that there are multiple >>>> different types of security policies. One type in conflict >>>> with the above is the "route all traffic to the inspection >>>> point at home" -policy. Another issue is that a MR that >>>> simply lets all traffic flow from its own attachment point >>>> would still be subject to be held responsible for >>>> illegal traffic & attacks from its MNNs. Where this is >>>> an issue, the solution may exist in some other layers >>>> than in NEMO, such as in network access control >>>> mechanisms. >>> >>> >>> Well, if the MR forwards all packets from a VMN to the HA of that VMN, >>> it wouldn't threanten its home and would simple work as any transit >>> router >> >> >> Right, although this is not the only possible solution. The other >> solution is network access control, where someone in the access >> network who is who and can send in the police to the right person. > > > Right. > >>> Illegal traffic from the MNNs would eventually look as if they >>> were originated from their home network, thus MR should not be held >>> reposible for that. Such path would involve atleast one of the HAs, >>> however the path should still be effective in some cases. This is just >>> an example. OTOH, the MR would be held reponsible for attacks to its >>> MNNs, but I don't think that NEMO is a solution for that either. >> >> >> Right, it shouldn't be. >> >>> But I agree that this contradicts the problem of not having >>> RO singaling messages to travel home. >> >> >> Yes. >> >>>> (Also, is there a need to talk about a similar form of "route >>>> optimization" that is already present in Mobile IPv6 >>>> with hosts deciding to use care-of address for some >>>> of their short-lived communications? If the hosts behind >>>> the MR actually were able to learn their true "care of >>>> addresses", this might be possible -- with impacts to >>>> these hosts and prefix discovery, of course.) >>> >>> >>> I couldn't catch what the issue is with this one. >> >> >> I meant the possibility that a MNN would learn its true >> local care-of address, and be able to use either that >> or the more stable address provided by NEMO. > > > Ok and I agree, we should mention that somewhere in Section 5. > >>> This is perhaps the most simple case, i.e. does not involve nesting >>> so it may sound limited. But, if you consider moving vehicles, they >>> would each have nemo devices provindg optimal path for all its MNNs, so >>> there are some reasonable applicabilities. >> >> >> Perhaps. But the work ahead of us seems pretty big, so this would >> be an excellent time to think what our priorities are and what >> problems are most useful ones to solve. That's part of the >> problem definition phase, not just listing what problems that >> could be solved, but also what ones we really want to solve. > > > Right. So I guess this goes back to your comment on the problem > statement draft about seeking interests of the service providers wishing > to deploy NEMO (and MIP6 because the two could interact in some > scenarios). We also had a similar discussion during the last meeting on > such priorities and I believe this is also concerned with the WG > rechartering. I agree that given the priorities and that the work ahead seems pretty big, probably yhe first issue to tackle is the use of CoA for app-level communications within the nested moving network (when the HAs are not available). Alex From nemo-bounces@ietf.org Wed Sep 14 08:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWVO-0006ru-36; Wed, 14 Sep 2005 08:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWVM-0006rm-0k for nemo@megatron.ietf.org; Wed, 14 Sep 2005 08:36:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07753 for ; Wed, 14 Sep 2005 08:36:46 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFWZu-0000gI-EU for nemo@ietf.org; Wed, 14 Sep 2005 08:41:33 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2005 14:36:36 +0200 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 j8ECZuVr023364; Wed, 14 Sep 2005 14:36:33 +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.0); Wed, 14 Sep 2005 14:36:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 Date: Wed, 14 Sep 2005 14:36:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01449E57@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-ro-space-analysis-00 Thread-Index: AcW3kJsSGuLaZPeuTji1fX2eSS4ubABmA2bA From: "Pascal Thubert \(pthubert\)" To: "Jari Arkko" X-OriginalArrivalTime: 14 Sep 2005 12:36:30.0459 (UTC) FILETIME=[EEB4E4B0:01C5B928] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >Pascal Thubert wrote: > >>Note that the nesting exists with RFC 3963 and the first thing >>that might happen with a mobile router and a 2 radio interfaces is that >>the egress attaches to the ingress; So the question of loop avoidance is >>NOT an RO issue. RO, just like NEMO, assumes that the problem is fixed >>some way. Steve Deering asked that same question when NEMO was just a >>BOF, how do we avoid those loops? >> >>This is the reason why we proposed: (snip) >> >> >I like the idea of separating loop detection and route optimization >from each other. (snap) > [] Right; it seems to me that fixing the loop detection is a prereq for working on the route optimization for nested NEMO. We should really move forward with MANEMO asap... Pascal From nemo-bounces@ietf.org Wed Sep 14 18:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgBA-0007m6-Gu; Wed, 14 Sep 2005 18:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgB8-0007m1-PB for nemo@megatron.ietf.org; Wed, 14 Sep 2005 18:56:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17628 for ; Wed, 14 Sep 2005 18:56:31 -0400 (EDT) Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFgFn-0002lV-Og for nemo@ietf.org; Wed, 14 Sep 2005 19:01:25 -0400 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.3/8.13.1/it-std-5.2.0) with ESMTP id j8EMuOcs004138; Wed, 14 Sep 2005 15:56:24 -0700 (PDT) Date: Wed, 14 Sep 2005 15:56:24 -0700 (PDT) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: Alexandru Petrescu Subject: Re: [nemo] RO solution space - CA is Certificate Authority In-Reply-To: <432569BD.5070201@motorola.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> <43255942.3030408@kddilabs.jp> <432569BD.5070201@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, On Mon, 12 Sep 2005, Alexandru Petrescu wrote: > Masafumi Watari wrote: > > On 2005/09/09 2:35, Alexandru Petrescu wrote: > > > >> Pascal Thubert (pthubert) wrote: > >> > >>> Yes... OTOH, if there is a risk of a collision then we should change. > >>> And that might be the case here. What about Correspondent Side Agent? > >>> CSA also exists in France but I do not expect them to participate to our > >>> drafts :) > >> > >> > >> CSA Correspondent Side Agent is fine with me too, but sounds like it > >> can't be the CN itself, sounds like it must be on its side somewhere, no? > > > > > > I agree. In that sense, the term Agent to me sounds more like a router > > and not a host (as in HA/FA). If we are to avoid CN, I would also > > suggest PN: Peer Node or RN: Remote Node or something like that. > > Right, PN sounds better. IMHO I think "agent" does not imply router or host, it totally depends on how we are going to define it. In MIP4/6 (yes, a very close field to NEMO) HA/FA is defined as a router, but there are many terms like mobile agent, software agent in other fields. Thus I think a clear definition that CA could be either router or host should be ok from my side. > > > I could live with CE: Correspondent Entity too. > > Ok with CE too. Maybe "Correspondent" is better because is akin to > Correspondent in "CN". If I recall correctly, there was a term "CE" (customer edge) in PPVPN WG. So the fundamental problem is there is no naming convention defined within IETF scope and in history, thus there are conflicts between the new term to be defined and those already defined in other WG or in history. So we can either just use CA and assume it is within the context of NEMO or define explicitly NCA (NEMO Correspondent Agent) with "NEMO" as a prefix to qualify CA. I am basically ok with any term above. Sincerely, fan > > Alex > From nemo-bounces@ietf.org Fri Sep 23 11:08:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpAI-0004Jl-UO; Fri, 23 Sep 2005 11:08:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIpAH-0004Jd-7I for nemo@megatron.ietf.org; Fri, 23 Sep 2005 11:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20546 for ; Fri, 23 Sep 2005 11:08:38 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIpGi-0000fw-05 for nemo@ietf.org; Fri, 23 Sep 2005 11:15:21 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3E90889852 for ; Fri, 23 Sep 2005 18:08:06 +0300 (EEST) Message-ID: <43341A61.8080000@piuha.net> Date: Fri, 23 Sep 2005 18:08:17 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Subject: [nemo] review of draft-ietf-nemo-home-network-models-04.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I was asked to review this document. Overall, I found this document to be quite useful. The complexity of the network scenarios can be surprising, and its good to have IETF produce guidance on the use of its mechanisms. The content of the draft is mostly OK. Some questions and issues were noted below, however. What troubled me perhaps most was that the document suggests a mechanism to emulate returning home when a virtual home link implementation is being used at the home agent. I'm not convinced that this is necessary, and if it is, this is probably something that should be done for Mobile IPv6 and not just nemo. Getting rid of this part of the document would also remove one normative behaviour requirement (which currently does not feel appropriate in an informational document such as this one). Technical: > In implicit mode, the Home Agent has the necessary information to > continue routing to the MNPs in the absence of registration, and the > participation of the Mobile Router to the Home IGP is not required. This may be a lack of understanding of RFC 3963 on my part, but how does this actually work? Is the traffic to the MR routed through home agent in all cases even when there's no registration? > When connecting to the Home Link, the Mobile Router also need to > autoconfigure an address on the egress interface as opposed to > assigning its Home Address to the interface. And how does this work wrt. routing of the actual data packets? Does this mean that the MR needs perform a registration to its home agent, even if its on the home link? > 5.5 Applicability > ... > > Also, when the Home Address is derived from the prefix on the Home > Link, the Home Agent behavior on the link trivially extends that of > MIP and the support should for that configuration should be available > with all implementations. But Section 5 appeared to be talking also about the case when the MR's home address is not derived from the home link prefix. > Alternatively, the Mobile Router might perform ND proxying for all > addresses in its MNPs, between the egress and the related ingress > interface. Since the prefixes on the egress and ingress interfaces > are overlapping, routing is disallowed. Reference to the ND proxy spec is appropriate here. But that is experimental (and under discussion) -- is ND proxying what we really want to do here? > Alternatives based on a routing protocol or ICMP redirect may apply > in some cases. It would be interesting know what cases these are. > /48 eg: A:B:C::/48 > HA > | /64 A:C:C:E::/64 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N > > > > Figure 5: Virtual Home Network Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64... > In order for a Mobile Router to emulate returning Home, it can > connect to one or more access link(s) configured for that purpose on > the Home Agent. ... > However, the Mobile Router must register its binding as if it was > accessing a foreign link. I suspect this is the same as saying "in order to emulate returning home link, the MR can connect to some other link and behave as if it was accessing a foreign link" :-) Or am I missing something? Suggest deleting or reformulating paragraph. Its clear that we can set up networks and links close to the home agent, but in a virtual network you don't return home, even if home might be just one router hop away. I would also suggest deleting appendix A. > There can be only one Home Agent since Mobile IPv6 relies on > Neighbor Discovery on the Home Link for other Home Agent discovery > and for Duplicate Address Detection. As I have understood the Mobile IPv6 base requirements, there's no mandate that you have to do home agent discovery only that way - you could also configure things. And in theory you could construct virtual links even across multiple home agents (such as via private tunnels) but this would void the primary benefits of the virtual approach i.e. ability to ignore what other nodes on the link are doing. Suggested reformulation: As there is no physical link, this also implies that there can only be a single home agent per home prefix; multiple home agents would not be able to communicate with each other. > 7.2 Applicability > > At some point in the future, NEMO basic support may be extended to > operate fully at L3 for instance if the HAHA protocol [11] gets > standardized and deployed. Until then, NEMO operations still inherit > from mobile IPv6 [7] for the Home Agent to Home Agent communication, > which is basically based on Neighbor Discovery extensions over the > Home Link. Making that link virtual bars the deployment of multiple > Home Agents, which may be desirable for reasons of load balancing. > Please refer to the NEMO multihoming issues [12] draft for more on > this. I'm not sure its useful to speculate about this. Also, this text appears to be saying that Neighbor Discovery is not at L3. Pointing to NEMO multihoming draft is good, though. > Alternatively, the > Home Agent may indicate that the Mobile Router has moved to the > virtual Home Access Links as a status code in the binding > acknowledgement. The status code implies that Home Agent successsful > de-register the binding at the virtual Home Access Link. Which status code would this be? Neither RFC 3775 or 3963 appear to define a code for this particular purpose. Editorial: > acknowledgement. The status code implies that Home Agent successsful Typo. > of its own MNPs. . Extra space. > physical maintenance or to hardware problems, so it is more > available than a physical link. The high availability of the > Home Link is critical for the mobility service. ... problems, so it has higher availability than a physical link. This is critical ... > update with null lifetime sourced at the CareOf. Alternatively, the s/CareOf/care of address/ > acknowledgement. The status code implies that Home Agent successsful > de-register the binding at the virtual Home Access Link. Detection .. successfully de-registered ... --Jari From nemo-bounces@ietf.org Fri Sep 23 19:45:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIxEF-0004gO-1Z; Fri, 23 Sep 2005 19:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIxED-0004gJ-Ap for nemo@megatron.ietf.org; Fri, 23 Sep 2005 19:45:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22840 for ; Fri, 23 Sep 2005 19:45:14 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIxKj-0006vU-OO for nemo@ietf.org; Fri, 23 Sep 2005 19:52:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j8NNBba15943; Fri, 23 Sep 2005 16:11:37 -0700 X-mProtect: <200509232311> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdXEQYOv; Fri, 23 Sep 2005 16:11:36 PDT Message-ID: <43349373.7040805@iprg.nokia.com> Date: Fri, 23 Sep 2005 16:44:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt References: <43341A61.8080000@piuha.net> In-Reply-To: <43341A61.8080000@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Jari Arkko wrote: > I was asked to review this document. thanks for the review. > What troubled me perhaps most was that the > document suggests a mechanism to emulate returning > home when a virtual home link implementation is > being used at the home agent. I'm not convinced that this > is necessary, and if it is, this is probably something that should > be done for Mobile IPv6 and not just nemo. Getting rid of this > part of the document would also remove one normative behaviour > requirement (which currently does not feel appropriate in > an informational document such as this one). there is a problem when there is a virtual home link and a mobile router returns home. where does it connect to? does it de-register? does it start sending routing protocol updates in case it is capable of sending routing updates? the last question especially is very important and is specific only to NEMO. the text we currently have is to address the above questions. even for MIPv6, we need to address returning home in case the home link is a virtual link, but the problem is not the same. there are no routing updates from the mobile node that could screw up route aggregation on the home network. also for some reason the thinking was that in MIPv6 if the home link is virtual the MN never goes home. the same may not be true for mobile networks. > Technical: > >> In implicit mode, the Home Agent has the necessary information to >> continue routing to the MNPs in the absence of registration, and the >> participation of the Mobile Router to the Home IGP is not required. > > > This may be a lack of understanding of RFC 3963 on my part, but > how does this actually work? Is the traffic to the MR routed through > home agent in all cases even when there's no registration? for implicit mode, it is assumed the routes for MNPs exist all the time. but the forwarding entry would point to a virtual tunnel interface that wouldnt exist if the mobile router does not have a valid binding cache entry at the HA. in practice, the routes dont have to exist. there could be some state on the HA which says, if the MR sends a binding update in the implicit sate, create routes for these MNPs, don't look for MNPs in the binding update. this is implementation dependent. >> When connecting to the Home Link, the Mobile Router also need to >> autoconfigure an address on the egress interface as opposed to >> assigning its Home Address to the interface. > > > And how does this work wrt. routing of the actual data packets? > Does this mean that the MR needs perform a registration to its > home agent, even if its on the home link? this text is only specific to the case where the home address of the MR is configured from the MNP. if the MR is capable of sending routing protocol updates, it just sends an update for the MNP. another option is to send an ICMP redirect for the MNP. the MR shouldn't register with the home agent. >> 5.5 Applicability >> ... >> >> Also, when the Home Address is derived from the prefix on the Home >> Link, the Home Agent behavior on the link trivially extends that of >> MIP and the support should for that configuration should be available >> with all implementations. > > > But Section 5 appeared to be talking also about the case > when the MR's home address is not derived from the home > link prefix. right. thats why we have the following text in section 5.3 For all these reasons, this submode of extended is no more a trivial extension to the MIPv6 Home Model, and it might not be compatible with all implementations. configuring a home address from the home prefix is the default mechanism. configuring from the MNP may not work all the time. >> Alternatively, the Mobile Router might perform ND proxying for all >> addresses in its MNPs, between the egress and the related ingress >> interface. Since the prefixes on the egress and ingress interfaces >> are overlapping, routing is disallowed. > > > Reference to the ND proxy spec is appropriate here. But that > is experimental (and under discussion) -- is ND proxying what > we really want to do here? RFC 2461 allows a router to proxy for a host, right? that should be sufficient. I dont think we are talking about the ND proxying draft currently being discussed in the IPv6 WG. Pascal, Ryuji, correct me if I am wrong. >> /48 eg: A:B:C::/48 >> HA >> | /64 A:C:C:E::/64 >> --+-----+--+- . -+- . -+-- >> | | | | >> MR1 MR2 MRi MRN >> /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N >> >> >> >> Figure 5: Virtual Home Network > > > Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64... I think so... > >> In order for a Mobile Router to emulate returning Home, it can >> connect to one or more access link(s) configured for that purpose on >> the Home Agent. ... >> However, the Mobile Router must register its binding as if it was >> accessing a foreign link. > > > I suspect this is the same as saying "in order to emulate returning > home link, the MR can connect to some other link and behave as > if it was accessing a foreign link" :-) Or am I missing something? > > Suggest deleting or reformulating paragraph. Its clear that we can set up > networks and links close to the home agent, but in a virtual > network you don't return home, even if home might be just one > router hop away. > > I would also suggest deleting appendix A. well, we need to say something about returning home and virtual home links. the alternative is to say, returning home for virtual home links is not supported. > >> There can be only one Home Agent since Mobile IPv6 relies on >> Neighbor Discovery on the Home Link for other Home Agent discovery >> and for Duplicate Address Detection. > > > As I have understood the Mobile IPv6 base requirements, there's > no mandate that you have to do home agent discovery only that way - > you could also configure things. And in theory you could construct > virtual links even across multiple home agents (such as via private > tunnels) but this would void the primary benefits of the virtual > approach i.e. ability to ignore what other nodes on the link are > doing. Suggested reformulation: > > As there is no physical link, this also implies that there can > only be a single home agent per home prefix; multiple home > agents would not be able to communicate with each other. ok. > >> 7.2 Applicability >> >> At some point in the future, NEMO basic support may be extended to >> operate fully at L3 for instance if the HAHA protocol [11] gets >> standardized and deployed. Until then, NEMO operations still inherit >> from mobile IPv6 [7] for the Home Agent to Home Agent communication, >> which is basically based on Neighbor Discovery extensions over the >> Home Link. Making that link virtual bars the deployment of multiple >> Home Agents, which may be desirable for reasons of load balancing. >> Please refer to the NEMO multihoming issues [12] draft for more on >> this. > > > I'm not sure its useful to speculate about this. Also, this text > appears to be saying that Neighbor Discovery is not at L3. > Pointing to NEMO multihoming draft is good, though. you are right. should be re-written. > >> Alternatively, the >> Home Agent may indicate that the Mobile Router has moved to the >> virtual Home Access Links as a status code in the binding >> acknowledgement. The status code implies that Home Agent successsful >> de-register the binding at the virtual Home Access Link. > > > Which status code would this be? Neither RFC 3775 or 3963 appear to > define a code for this particular purpose. looks like we need a new status code. :) Vijay From nemo-bounces@ietf.org Mon Sep 26 10:12:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJti4-0006eQ-U8; Mon, 26 Sep 2005 10:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJti3-0006eI-Ch for nemo@megatron.ietf.org; Mon, 26 Sep 2005 10:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29407 for ; Mon, 26 Sep 2005 10:11:57 -0400 (EDT) From: pthubert@cisco.com Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJtp6-0006OQ-HE for nemo@ietf.org; Mon, 26 Sep 2005 10:19:17 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 16:11:51 +0200 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 j8QEB7W3029187; Mon, 26 Sep 2005 16:11:46 +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.0); Mon, 26 Sep 2005 16:11:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Date: Mon, 26 Sep 2005 16:11:33 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC014CC40F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXAmWwNEhgSSdu3R4mQYPG3FDiS5AB9tPXw To: "Vijay Devarapalli" , "Jari Arkko" X-OriginalArrivalTime: 26 Sep 2005 14:11:40.0114 (UTC) FILETIME=[36E21B20:01C5C2A4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Jari: Thanks a bunch for all this. Please find some proposal changes inline. Actually, all interested in the draft are welcome to enter this discussion, as it might be the last chance before publication... >> What troubled me perhaps most was that the >> document suggests a mechanism to emulate returning >> home when a virtual home link implementation is >> being used at the home agent. I'm not convinced that this >> is necessary, and if it is, this is probably something that should >> be done for Mobile IPv6 and not just nemo. Getting rid of this >> part of the document would also remove one normative behaviour >> requirement (which currently does not feel appropriate in >> an informational document such as this one). > >there is a problem when there is a virtual home link and a >mobile router returns home. where does it connect to? does >it de-register? does it start sending routing protocol >updates in case it is capable of sending routing updates? >the last question especially is very important and is >specific only to NEMO. > >the text we currently have is to address the above questions. >even for MIPv6, we need to address returning home in case >the home link is a virtual link, but the problem is not the >same. there are no routing updates from the mobile node that >could screw up route aggregation on the home network. also >for some reason the thinking was that in MIPv6 if the home >link is virtual the MN never goes home. the same may not be >true for mobile networks. []=20 [] I understand that Jari suggests removing that piece of text;=20 or maybe changing it to fit an informational document.=20 Current text: In order for a Mobile Router to emulate returning Home, it can connect to one or more access link(s) configured for that purpose on the Home Agent. The Mobile Router, after connecting to the access link, SHOULD not send any routing protocol updates on the egress interface because the routing information from the Mobile Router might adversely affect IPv6 route aggregation on the Home Network. However, the Mobile Router must register its binding as if it was accessing a foreign link. Proposed fix: RFC 3775 and 3963 do not provide the specific support for a=20 Mobile Node to emulate returning Home on a Virtual Home Network. In particular, in the case of NEMO, the routing information from=20 the Mobile Router being injected on the IGP might adversely affect=20 IPv6 route aggregation on the Home Network. > >> Technical: >> >>> In implicit mode, the Home Agent has the necessary information to >>> continue routing to the MNPs in the absence of registration, and the >>> participation of the Mobile Router to the Home IGP is not required. >> >> >> This may be a lack of understanding of RFC 3963 on my part, but >> how does this actually work? Is the traffic to the MR routed through >> home agent in all cases even when there's no registration? > >for implicit mode, it is assumed the routes for MNPs exist >all the time. but the forwarding entry would point to a >virtual tunnel interface that wouldnt exist if the mobile >router does not have a valid binding cache entry at the HA. > >in practice, the routes dont have to exist. there could be >some state on the HA which says, if the MR sends a binding >update in the implicit sate, create routes for these MNPs, >don't look for MNPs in the binding update. this is >implementation dependent. > [] How do we translate that into a fix in the text?=20 When read separately, the text is misleading and seems to say that there's some magic that allows the HA to route to MR at all times. In context (returning Home in extended mode) the text makes more sense hopefully. Current text: In implicit mode, the Home Agent has the necessary information to continue routing to the MNPs in the absence of registration, and the participation of the Mobile Router to the Home IGP is not required. Proposed fix: In implicit mode, the Home Agent has the necessary information to continue routing to the MNPs in the absence of registration,=20 assuming that the Mobile Router is at Home, and the participation of the Mobile Router to the Home IGP is not required. >>> When connecting to the Home Link, the Mobile Router also need to >>> autoconfigure an address on the egress interface as opposed to >>> assigning its Home Address to the interface. >> >> >> And how does this work wrt. routing of the actual data packets? >> Does this mean that the MR needs perform a registration to its >> home agent, even if its on the home link? > >this text is only specific to the case where the home address >of the MR is configured from the MNP. if the MR is capable of >sending routing protocol updates, it just sends an update for >the MNP. another option is to send an ICMP redirect for the MNP. >the MR shouldn't register with the home agent. [] Note: The HA being a router, it might not process the redirect, though. =20 But yes, again the excerpt needs to be read in context. As Vijay says, the MNP is a different /64 then the prefix on the Home Link. The HA owns the aggregation (say /48) and has more specific routes (one /64 connected to the Home link acting as a RFC 3775 home prefix, and other /64 used as MNPs attached to the ingress of the MRs). If the MR takes its Home Address from the /64 on the Home Link, all is very classical. But if it wishes to take its Home Address from the MNP, then the Home Address is not located ion the Home Link. The HA itself does not have route to the /48, but acts as an ABR to aggregate the /64s into that /48 and call the result Home. Instead, the HA has /64 routes (to MNPs) via the CareOf address of the MR (for which it has a connected /64 so the route lookup ends up there). This is the whole purpose of extended Home Network. I do not have a simple fix to propose to make it clearer. If you still think a change is required, can you please be more specific? >>> 5.5 Applicability >>> ... >>> >>> Also, when the Home Address is derived from the prefix on the Home >>> Link, the Home Agent behavior on the link trivially extends that of >>> MIP and the support should for that configuration should be available >>> with all implementations. >> >> >> But Section 5 appeared to be talking also about the case >> when the MR's home address is not derived from the home >> link prefix. > >right. thats why we have the following text in section 5.3 > > For all these reasons, this submode of extended is no more a trivial > extension to the MIPv6 Home Model, and it might not be compatible > with all implementations. > >configuring a home address from the home prefix is the default >mechanism. configuring from the MNP may not work all the time. > []=20 [] Do we need to add a last sentence in 5.5 to say that?=20 >>> Alternatively, the Mobile Router might perform ND proxying for all >>> addresses in its MNPs, between the egress and the related ingress >>> interface. Since the prefixes on the egress and ingress interfaces >>> are overlapping, routing is disallowed. >> >> >> Reference to the ND proxy spec is appropriate here. But that >> is experimental (and under discussion) -- is ND proxying what >> we really want to do here? > >RFC 2461 allows a router to proxy for a host, right? that >should be sufficient. I dont think we are talking about the >ND proxying draft currently being discussed in the IPv6 WG. >Pascal, Ryuji, correct me if I am wrong. > [] There might be related issues, like MTU being different, even though there's no tunneling. I believe it's OK to add the non normative reference to draft-ietf-ipv6-ndproxy-03.txt? Consider this picture from Dave's draft, and say that "the rest of the network" is the Home Link, "local hosts" are lfns and A is our MR. Isn't this our config should the MR return Home over 802.11? | +-------+ +--------+ local |Ethernet | | Wireless | Access | +---------+ A +-))) (((-+ +--> rest of network hosts | | | link | Point | | +-------+ +--------+ For the latter question, if the 2 interfaces are compatible, then the MR could bridge. It might be more of a problem if they are different (like one is PPP, between an embedded MR and a single device). But what else could we do? The router sees overlapping prefixes (and connected routes) on its interfaces and that's not a valid condition at L3. >>> /48 eg: A:B:C::/48 >>> HA >>> | /64 A:C:C:E::/64 >>> --+-----+--+- . -+- . -+-- >>> | | | | >>> MR1 MR2 MRi MRN >>> /64 /64 /64 /64 A:B:C:i::/64 0 < i <=3D N >>> >>> >>> >>> Figure 5: Virtual Home Network >> >> >> Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64... > >I think so... [] Well, the text says that=20 The Extended Home Network and the Aggregated Home Network models can be adapted for virtual links. So both A:B:C::/64 (extended) or A:B:C::/48 (aggregated) could have worked too. Since there's no need to waste any prefix, we left the whole range of the /48 to MNP, as an alternate to the other 2 cases. > >> >>> In order for a Mobile Router to emulate returning Home, it can >>> connect to one or more access link(s) configured for that purpose on >>> the Home Agent. ... >>> However, the Mobile Router must register its binding as if it was >>> accessing a foreign link. >> >> >> I suspect this is the same as saying "in order to emulate returning >> home link, the MR can connect to some other link and behave as >> if it was accessing a foreign link" :-) Or am I missing something? >> >> Suggest deleting or reformulating paragraph. Its clear that we can set up >> networks and links close to the home agent, but in a virtual >> network you don't return home, even if home might be just one >> router hop away. >> >> I would also suggest deleting appendix A. > >well, we need to say something about returning home and virtual >home links. the alternative is to say, returning home for >virtual home links is not supported. [] This refers back to the first and main comment on the draft. The proposed change is actually to recognize that with the current standards, it's not supported. Does everyone agree? Does everyone agree that I remove appendix A? It's always a pain to remove text but sometime we have to admit that it's either too early or in the wrong doc and act on it. > >> >>> There can be only one Home Agent since Mobile IPv6 relies on >>> Neighbor Discovery on the Home Link for other Home Agent discovery >>> and for Duplicate Address Detection. >> >> >> As I have understood the Mobile IPv6 base requirements, there's >> no mandate that you have to do home agent discovery only that way - >> you could also configure things. And in theory you could construct >> virtual links even across multiple home agents (such as via private >> tunnels) but this would void the primary benefits of the virtual >> approach i.e. ability to ignore what other nodes on the link are >> doing. Suggested reformulation: >> >> As there is no physical link, this also implies that there can >> only be a single home agent per home prefix; multiple home >> agents would not be able to communicate with each other. > >ok. > [] Great, Thanks :) >> >>> 7.2 Applicability >>> >>> At some point in the future, NEMO basic support may be extended to >>> operate fully at L3 for instance if the HAHA protocol [11] gets >>> standardized and deployed. Until then, NEMO operations still inherit >>> from mobile IPv6 [7] for the Home Agent to Home Agent communication, >>> which is basically based on Neighbor Discovery extensions over the >>> Home Link. Making that link virtual bars the deployment of multiple >>> Home Agents, which may be desirable for reasons of load balancing. >>> Please refer to the NEMO multihoming issues [12] draft for more on >>> this. >> >> >> I'm not sure its useful to speculate about this. Also, this text >> appears to be saying that Neighbor Discovery is not at L3. >> Pointing to NEMO multihoming draft is good, though. > >you are right. should be re-written. [] Note that the NEMO RO PS also details some related issues. [] Proposed change is to remove the first sentence, with the same rationale as appendix A... NEMO operations still inherit from mobile IPv6 [7] for the Home Agent to=20 Home Agent communication, which is based on Neighbor Discovery extension over the Home Link. Making that link virtual bars the deployment of multiple Home Agents, which may be desirable for reasons of load balancing. Please refer to the NEMO multihoming issues [12] draft for more on this. > >> >>> Alternatively, the >>> Home Agent may indicate that the Mobile Router has moved to the >>> virtual Home Access Links as a status code in the binding >>> acknowledgement. The status code implies that Home Agent successsful >>> de-register the binding at the virtual Home Access Link. >> >> >> Which status code would this be? Neither RFC 3775 or 3963 appear to >> define a code for this particular purpose. > >looks like we need a new status code. :) [] For the future :) But for this doc, we need to drop this text together with the support of coming home on a virtual home.=20 [] What do you think? =20 Pascal From nemo-bounces@ietf.org Mon Sep 26 15:02:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJyEt-0000UG-0e; Mon, 26 Sep 2005 15:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJyEr-0000U9-3Q for nemo@megatron.ietf.org; Mon, 26 Sep 2005 15:02:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01449 for ; Mon, 26 Sep 2005 15:02:07 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJyLp-0003Tb-W0 for nemo@ietf.org; Mon, 26 Sep 2005 15:09:29 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j8QJ9VTm029932 for ; Mon, 26 Sep 2005 12:09:31 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j8QJ9wNu013891 for ; Mon, 26 Sep 2005 14:09:59 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Sep 2005 14:01:52 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A7455@il02exm13> From: Narayanan Vidya-CVN065 To: "'Vijay Devarapalli'" , Jari Arkko Subject: Virtual Link and Returning Home (was RE: [nemo] review of draft-i etf-nemo-home-network-models-04.txt) Date: Mon, 26 Sep 2005 14:01:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > there is a problem when there is a virtual home link and a > mobile router returns home. where does it connect to? does it > de-register? does it start sending routing protocol updates > in case it is capable of sending routing updates? the last > question especially is very important and is specific only to NEMO. > > the text we currently have is to address the above questions. > even for MIPv6, we need to address returning home in case the > home link is a virtual link, but the problem is not the same. > there are no routing updates from the mobile node that could > screw up route aggregation on the home network. also for some > reason the thinking was that in MIPv6 if the home link is > virtual the MN never goes home. the same may not be true for > mobile networks. Why is it different for mobile networks? Vidya From nemo-bounces@ietf.org Mon Sep 26 17:29:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK0X0-0001Xw-LB; Mon, 26 Sep 2005 17:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK0Wy-0001Xb-Ka for nemo@megatron.ietf.org; Mon, 26 Sep 2005 17:29:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10839 for ; Mon, 26 Sep 2005 17:28:58 -0400 (EDT) Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK0e5-0007eb-OW for nemo@ietf.org; Mon, 26 Sep 2005 17:36:22 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4AE3137E56; Mon, 26 Sep 2005 23:28:43 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id CFFC237E50 for ; Mon, 26 Sep 2005 23:28:42 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9E08937E44 for ; Mon, 26 Sep 2005 23:28:42 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EK0Wg-0006Ed-BB for nemo@ietf.org; Mon, 26 Sep 2005 23:28:42 +0200 Message-ID: <43386809.10403@levkowetz.com> Date: Mon, 26 Sep 2005 23:28:41 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 089da5e32269fece1072c9ff54523f20 Content-Transfer-Encoding: 7bit Subject: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I was asked to review this draft. As you'll see, there are some places where my comments overlap with Jari's - I did this review before reading through his - but there are also a number of separate issues. Overall comments: This draft is quite clear and informative, with some exceptions where language blemishes makes understanding less easy than it could be. The major comment I have that I miss a clear explanation of the benefits of Extended vs. Aggregated Home Networks. For the Virtual Home Network and the Mobile Home (which I really would have called Nested Mobile Networks...) the merits and drawbacks are discussed adequately. A second overall comment is that the Appendix doesn't belong in this document. The rest of the document is, as is said in the Abstract, a documentation of usage and issues, while the Appendix is a proposal for protocol enhancement. It should be removed and if desired proposed in a separate document. Detailed Review: Section 1., para. 2: > In order to read this document properly, the distinction between the > concepts of Home Link and of Home Network must be very clear. A Home > Link is a physical or a virtual Link, attached to a Home Agent. A > Home Network is an aggregation that can be further subnetted. As a > result, the Home Network is not necessarily contained on a Home Link. > In fact, the Mobile Network Prefixes are subnets of the Home Network. > How the two concepts relate in a given deployment depend on the > organization of the Home Network, as described below. Unfortunately, the above description does not at all make the distinction clear to me. Are the Home Network prefixes a subset of the Home Link prefixes? A superset? Or something else? I'm more confused after reading the above than before... Section 1., para. 5: > NEMO Extended Home Network: In this disposition, the Home Network is > only one subnet of a larger aggregation that encompasses the > Mobile Networks, called extended Home Network. When at Home, a > Mobile Router performs normal routing between the Home Link and > the Mobile Networks. More in Section 5. Disposition? Maybe say layout or configuration instead? [Disposition: * your usual mood; "he has a happy disposition" * disposal: the act or means of getting rid of something * inclination: an attitude of mind especially one that favors one alternative over others; "he had an inclination to give up too easily"; "a tendency to be too strict" * a natural or acquired habit or characteristic tendency in a person or thing; "a swelling with a disposition to rupture" * Determination of the final arrangement or settlement of a case following judgment. ] Section 1., para. 9: > In all cases, the Home Agents collectively advertise only the > aggregation of the Mobile Networks. The dichotomy is kept within the > Home Agents and the Mobile Routers, as opposed to advertised by means > of routing protocols to other parties. Umm - not sure I see a dichotomy here? Maybe use some other word? [Dichotomy: A dichotomy is a division into two non-overlapping or mutually exclusive and jointly exhaustive parts. They are often contrasting and spoken of as "opposites". The term comes from dichotomos (divided): dich- ([in] two) temnein (to cut).] Section 4., para. 1: > With Mobile IPv6 (MIP6) specification [7] Mobile Nodes are at Home > when they are connected to their Home Link, where they recognize > their Home Prefix in Router Advertisement messages. Also, a binding > is checked using of Duplicate Address Detection on the Home Link, and > Home Agents discover each other by means of Neighbor Discovery > extensions over that link. s/With Mobile IPv6/In the Mobile IPv6/ s/using of/using/ Section 4., para. 2: > The Home Prefix, that is advertised on the Home Link, is a final > prefix, as opposed to an aggregation, and it may be used by hosts on > the Home Link for autoconfiguration purposes. s/The Home Prefix,/The Home Prefix/ s/Home Link,/Home Link/ Section 5.2, para. 4: > In implicit mode, the Home Agent has the necessary information to > continue routing to the MNPs in the absence of registration, and the > participation of the Mobile Router to the Home IGP is not required. IGP is not defined - please do so. Section 5.2, para. 6: > Alternate procedures for ensuring the connectivity of the Mobile > Networks when at home are described in Section 7. s/Alternate/Alternative/ Section 5.3, para. 2: > In that case, the Home Address does not match the Home Link Prefix, > and there is a need to configure the Home Agent in a specific mode > with the support for the extended Home Network and the range of the > Mobile Network Prefixes. Based on that new configuration, the Home > Agent can accept a Home Address that is not from the Home Link, and > it will know that it should not perform any DAD. Consistency: s/extended Home Network/Extended Home Network/ - above and in the rest of the document Section 5.3, para. 5: > For all these reasons, this submode of extended is no more a trivial > extension to the MIPv6 Home Model, and it might not be compatible > with all implementations. s/submode of extended/submode of an Extended Home Network/ s/is no more a/is not a/ Section 5.4.1, para. 1: > In explicit mode, the routing to the MNP via the Mobile Router must > be restored when the Mobile Router is at Home. This is normally > performed by the Mobile Router by means of the existing IGP. In that > case, a specific support is required on the Mobile Router to control > the routing protocol operation, enabling the participation to the IGP > if and only if the Mobile Router is at home. This support might not > be present in all implementations. s/participation to the IGP/participation in the IGP/ Section 5.5, para. 1: > The extended Home Network keeps the MIP6 concept of a Home Network > for both Mobile Nodes and Mobile Routers to take their Home Address > from. Since there is no overlap between the prefixes that are > affected to MNPs and prefix(es) that are dedicated to the Home Link, > it is possible for MNs and Mobile Routers to coexist with that model. s/affected to/associated with/ - or possibly s/affected to/assigned to/ Section 6., para. 0: > Also, when the Home Address is derived from the prefix on the Home > Link, the Home Agent behavior on the link trivially extends that of > MIP and the support should for that configuration should be available > with all implementations. s/the support should for that/support for that/ Section 6.1, para. 7: > Note that in that case, it makes sense for a Mobile Router to > register using a Home Address from one of its own MNPs. Taking the > Home Address from its own range guarantees the uniqueness of the > suffix. That uniqueness can be checked by the Mobile Router on its > ingress network using DAD. Maybe add a reference to RFC 3753 for the first use of ingress and egress interface / network? Section 6.2, para. 3: > Note that it must expect a shorter prefix than that of its Mobile > Networks, even if its Home Address is formed out of one of its MNPs, > but that the Home Address still matches the Home Network Prefix. This paragraph needs a bit of re-write. Maybe something like: - Note that it must expect a shorter prefix than that of its Mobile Network(s). Even if its Home Address is formed out of one of its MNPs, the Home Address must still match the Home Network Prefix. Section 6.2.1, para. 0: 6.2.1 Returning Home by egress Maybe better 'Returning Home with the Egress Interface' ? Section 6.2.1, para. 3: > Alternatively, the Mobile Router might perform ND proxying for all > addresses in its MNPs, between the egress and the related ingress > interface. Since the prefixes on the egress and ingress interfaces > are overlapping, routing is disallowed. This paragraph is not too clear to me. So, here we aren't bridging, and we aren't routing, so how can traffic flow? Section 6.2.1, para. 6: > Figure 3: Bridging between egress and ingress I don't see the difference between Figure 2 and Figure 3. Should I? Section 6.2.2, para. 0: 6.2.2 Returning Home by ingress Maybe better 'Returning Home with the Ingress Interface' ? Section 6.2.2, para. 4: > This fits the connected route model, since the Aggregated Home is > truly located on that network. Note that in that case, it makes > sense for a Mobile Router to register using a Home Address from one > of its own MNPs. . Spurious full stop (".") Additionally, the above paragraph seems to say that it does _not_ make sense for the Mobile Router to register using a Home Address from one of its own MNPs as described in Section 5.3 ... Could the document be more clear - maybe clearly recommend that the Section 5.3 mode not be used? Section 6.3, para. 1: > With this model, there is no specific space for independent nodes as > any address in the aggregation belongs to a MNP, and thus to a Mobile > Router. This configuration excludes the cohabitation with MIP6 MNs > on the Home Link. s/independent nodes as/independent nodes, as/ Section 6.3, para. 2: > A Mobile Router that is at Home must own an address from the > aggregation on its egress interface and an address from its MNP -a > subnet of that aggregation- on its ingress interface. A pure router > will reject that configuration, and the Mobile Router needs to act as > a bridge to enable it. In order to deploy the aggregated Home > Network model, one must check whether that support is available in > the Mobile Routers if returning Home is required. Isn't this a clear deployment caveat, belonging in the next section? Section 6.4.1, para. 1: > A node on the Home Link discovers that the Aggregated Home Network is > actually a subnet on the Home Link and may use the prefix on the Home > Link to autoconfigure a Home Address. Such a node may also install a > connected route to the Aggregated Home Network over the Home Link. I'm having a bit of trouble with the formulation here. Do you mean to say: "If a node were to discovers that the Aggregated Home Network is actually a subnet on the Home Link it might use the prefix on the Home Link to autoconfigure a Home Address. ..." ? - if so, maybe say that :-) and also adjust the rest of the text and the next paragraph accordingly. Section 6.4.2, para. 2: > Also, note that NEMO authorizes multiple registrations for a same MNP > by different Mobile Routers. This is a case of multihoming, and it > normally means that the Mobile Routers are interconnected by the > ingress network that bears the common MNP. But there is no provision > in NEMO basic support to test that this condition is met at binding > time and maintained overtime. s/overtime/over time/ Section 6.4.2, para. 3: > It is thus possible for 2 different Mobile Routers to register a same > prefix with different Home Addresses, and this will cause an > undetected problem if the corresponding ingress links are not > connected. s/register a same/register the same/ Section 7., para. 0: > When the Home Address of a Mobile Router is derived from its MNP, > there is thus an additional risk of an undetected misconfiguration if > the Home Address is autoconfigured from the ingress link as opposed > to statically assigned with the MNP itself. s/assigned with the MNP itself/assigned to the MR/ ?? Section 7.1, para. 1: > The Home Link can be configured on the Home Agent on a virtual link, > in which case there's no physical Home Link for Mobile Routers to > return Home or for Home Agents to discover each others and perform > the ND level interactions as described in Mobile IPv6. [7] s/return Home or/return Home to, or/ s/interactions as/interactions on, as/ Section 7.1, para. 2: > /48 eg: A:B:C::/48 > HA > | /64 A:C:C:E::/64 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N s/eg/e.g./ Section 7.1, para. 15: > Some solutions can be proposed in order to perform an equivalent of > returning Home on a virtual Home Network. One such approach is > sketched in appendix as an illustration. s/appendix/Appendix A/ Section 7.2, para. 1: > At some point in the future, NEMO basic support may be extended to > operate fully at L3 for instance if the HAHA protocol [11] gets > standardized and deployed. Until then, NEMO operations still inherit > from mobile IPv6 [7] for the Home Agent to Home Agent communication, > which is basically based on Neighbor Discovery extensions over the > Home Link. Making that link virtual bars the deployment of multiple > Home Agents, which may be desirable for reasons of load balancing. > Please refer to the NEMO multihoming issues [12] draft for more on > this. s/from mobile IPv6 [7] for the Home Agent to Home Agent communication, /the Home Agent to Home Agent communication from Mobile IPv6 [7]./ s/which is basically/This is basically/ - Although I'm not sure if this paragraph should be kept in the published document - it's speculative and may not make sense to have there in 2 or 20 years? Section 8.1, para. 1: > In this disposition, there is a bitwise hierarchy of Home Networks. > A global Home Network is advertised to the infrastructure by a head > Home Agent(s) and further subnetted into Mobile Networks. As a > result, only the Home Agent(s) responsible for the most global > (shortest prefix) aggregation receive all the packets for all the > MNPs, which are leaves in the hierarchy tree. s/disposition/set-up/ (or something else -- not disposition) Section 8.1, para. 3: > An example of that is the Cab Co configuration. When a Taxi Company > owns a /32 prefix, this prefix is advertised at a fixed point in the > Head Quarters. Regional offices are deployed around the world. Even > though these regional offices are relatively stable in terms of > location and prefix requirement -say this changes every few years- > making them mobile allows a simpler management when a move has to > take place, or should the ISP service change. s/example of that/example of this/ Section 8.1, para. 6: > Figure 6: CAB Company HQ configuration Really cute addresses. Really. Section 8.1, para. 11: > Figure 7: CAB Company regional configuration "Home addrSsync" ?? Section 8.1, para. 12: > Note that the hierarchy occurs at a configuration level and may not > be reflected in the actual connection between nodes. For instance in > the Cab Co case, cabs are roaming within the city, each one attaching > to a different hot spot, while the regional office is connected to > the infrastructure using some ISP connection. Sorry, I don't understand what you want to say with the first sentence of this paragraph. Section 8.1, para. 13: > But it is also possible to reflect the organizational hierarchy in a > moving cloud of Mobile Router. If a Mobile Home Agent acts as > root-MR for a nested configuration of its own Mobile Routers, then > the communication between Mobile Routers is confined within the > nested structure. s/cloud of Mobile Router/cloud of Mobile Routers/ Section 8.1, para. 15: > If SFO is also the root-MR of a nested structure of cabs, the > communication between cabs is relayed by SFO and does not require the > satellite link. SFO recursively terminates the nested tunnels to the > cabs and re-encapsulates all the packets between the nested cloud and > correspondents in the infrastructure in a single tunnel to CA5A, this > providing for nested NEMO Route Optimization. The difference between the two cases discussed here isn't too clear to me. Does it consist only of where the tunnels are terminated, or is there also a difference with respect to the routing geometry (which nodes the traffic from the leaf nodes pass through?) Section 8.2, para. 1: > This complex topology applies to large distributed fleet, mostly if > there is a single interchange point with the internet (e.g. a NAT or s/large distributed fleet/a large distributed fleet/ Section 12., para. 0: > Issue 6: Pass idnits. Thanks Henrik for this great tool :) You're welcome :-) Appendix A.: The language of the following appendix is less polished than the language of the main body of the document, but I'm not reviewing it in detail; instead I suggest that it belongs in a separate document, as it's a proposal of a possible protocol enhancement and not just a description of usage scenarios of the basic protocol. From nemo-bounces@ietf.org Tue Sep 27 14:21:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKK58-0008Ma-Ro; Tue, 27 Sep 2005 14:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKK4q-0008IB-Sq for nemo@megatron.ietf.org; Tue, 27 Sep 2005 14:21:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29646 for ; Tue, 27 Sep 2005 14:21:15 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKKC8-0005RT-HQ for nemo@ietf.org; Tue, 27 Sep 2005 14:28:50 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j8RHlJY21871; Tue, 27 Sep 2005 10:47:19 -0700 X-mProtect: <200509271747> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdiFiqDu; Tue, 27 Sep 2005 10:47:18 PDT Message-ID: <43398D7B.2060108@iprg.nokia.com> Date: Tue, 27 Sep 2005 11:20:43 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pthubert@cisco.com Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC014CC40F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC014CC40F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org pthubert@cisco.com wrote: > Hi Jari: > > Thanks a bunch for all this. Please find some proposal changes inline. > Actually, all interested in the draft are welcome to enter this > discussion, as it might be the last chance before publication... > > >>>What troubled me perhaps most was that the >>>document suggests a mechanism to emulate returning >>>home when a virtual home link implementation is >>>being used at the home agent. I'm not convinced that this >>>is necessary, and if it is, this is probably something that should >>>be done for Mobile IPv6 and not just nemo. Getting rid of this >>>part of the document would also remove one normative behaviour >>>requirement (which currently does not feel appropriate in >>>an informational document such as this one). >> >>there is a problem when there is a virtual home link and a >>mobile router returns home. where does it connect to? does >>it de-register? does it start sending routing protocol >>updates in case it is capable of sending routing updates? >>the last question especially is very important and is >>specific only to NEMO. >> >>the text we currently have is to address the above questions. >>even for MIPv6, we need to address returning home in case >>the home link is a virtual link, but the problem is not the >>same. there are no routing updates from the mobile node that >>could screw up route aggregation on the home network. also >>for some reason the thinking was that in MIPv6 if the home >>link is virtual the MN never goes home. the same may not be >>true for mobile networks. > > [] > [] I understand that Jari suggests removing that piece of text; > or maybe changing it to fit an informational document. > > Current text: > > In order for a Mobile Router to emulate returning Home, it can > connect to one or more access link(s) configured for that purpose on > the Home Agent. The Mobile Router, after connecting to the access > link, SHOULD not send any routing protocol updates on the egress > interface because the routing information from the Mobile Router > might adversely affect IPv6 route aggregation on the Home Network. > However, the Mobile Router must register its binding as if it was > accessing a foreign link. > > Proposed fix: > > RFC 3775 and 3963 do not provide the specific support for a > Mobile Node to emulate returning Home on a Virtual Home Network. > In particular, in the case of NEMO, the routing information from > the Mobile Router being injected on the IGP might adversely affect > IPv6 route aggregation on the Home Network. but why? informational documents can describe some behavior for the mobile router. I dont understand the part about not fitting an informational document. Vijay From nemo-bounces@ietf.org Wed Sep 28 01:59:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKUyd-0004Xm-J6; Wed, 28 Sep 2005 01:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKUyc-0004XI-FD for nemo@megatron.ietf.org; Wed, 28 Sep 2005 01:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16570 for ; Wed, 28 Sep 2005 01:59:33 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKV5y-0001RM-9K for nemo@ietf.org; Wed, 28 Sep 2005 02:07:13 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2005 07:59:23 +0200 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 j8S5xJVP001353; Wed, 28 Sep 2005 07:59:19 +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.0); Wed, 28 Sep 2005 07:59:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 28 Sep 2005 07:59:13 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151A41C@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXDkDuR5lbcWjh6TeSE3CliZJ+eYwAYIe2g From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 28 Sep 2005 05:59:18.0594 (UTC) FILETIME=[C3976220:01C5C3F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org The way I understand it, we should not be specifying a behavior in this document, which is oriented on deployment; and you know that the SHOULD in the copied text is not really part of RFC 3963.=20 There might be a need of some standard track work on the matter of virtual home for NEMO and MIP. Maybe associated to the HAHA protocol, which is needed for multiple HAs sharing a virtual Home. Do I miss something? Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Tuesday, September 27, 2005 8:21 PM >To: Pascal Thubert (pthubert) >Cc: Jari Arkko; IETF NEMO WG >Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt > >pthubert@cisco.com wrote: >> Hi Jari: >> >> Thanks a bunch for all this. Please find some proposal changes inline. >> Actually, all interested in the draft are welcome to enter this >> discussion, as it might be the last chance before publication... >> >> >>>>What troubled me perhaps most was that the >>>>document suggests a mechanism to emulate returning >>>>home when a virtual home link implementation is >>>>being used at the home agent. I'm not convinced that this >>>>is necessary, and if it is, this is probably something that should >>>>be done for Mobile IPv6 and not just nemo. Getting rid of this >>>>part of the document would also remove one normative behaviour >>>>requirement (which currently does not feel appropriate in >>>>an informational document such as this one). >>> >>>there is a problem when there is a virtual home link and a >>>mobile router returns home. where does it connect to? does >>>it de-register? does it start sending routing protocol >>>updates in case it is capable of sending routing updates? >>>the last question especially is very important and is >>>specific only to NEMO. >>> >>>the text we currently have is to address the above questions. >>>even for MIPv6, we need to address returning home in case >>>the home link is a virtual link, but the problem is not the >>>same. there are no routing updates from the mobile node that >>>could screw up route aggregation on the home network. also >>>for some reason the thinking was that in MIPv6 if the home >>>link is virtual the MN never goes home. the same may not be >>>true for mobile networks. >> >> [] >> [] I understand that Jari suggests removing that piece of text; >> or maybe changing it to fit an informational document. >> >> Current text: >> >> In order for a Mobile Router to emulate returning Home, it can >> connect to one or more access link(s) configured for that purpose on >> the Home Agent. The Mobile Router, after connecting to the access >> link, SHOULD not send any routing protocol updates on the egress >> interface because the routing information from the Mobile Router >> might adversely affect IPv6 route aggregation on the Home Network. >> However, the Mobile Router must register its binding as if it was >> accessing a foreign link. >> >> Proposed fix: >> >> RFC 3775 and 3963 do not provide the specific support for a >> Mobile Node to emulate returning Home on a Virtual Home Network. >> In particular, in the case of NEMO, the routing information from >> the Mobile Router being injected on the IGP might adversely affect >> IPv6 route aggregation on the Home Network. > >but why? informational documents can describe some behavior >for the mobile router. I dont understand the part about >not fitting an informational document. > >Vijay From nemo-bounces@ietf.org Wed Sep 28 04:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKXJi-0006cL-U6; Wed, 28 Sep 2005 04:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKXJh-0006cD-N5 for nemo@megatron.ietf.org; Wed, 28 Sep 2005 04:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22028 for ; Wed, 28 Sep 2005 04:29:28 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKXR6-0005lu-S1 for nemo@ietf.org; Wed, 28 Sep 2005 04:37:10 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2005 10:29:19 +0200 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 j8S8SrVl011270; Wed, 28 Sep 2005 10:29:16 +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.0); Wed, 28 Sep 2005 10:29:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 28 Sep 2005 10:29:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151A4B5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXDkDuR5lbcWjh6TeSE3CliZJ+eYwAdlfEA From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 28 Sep 2005 08:29:09.0354 (UTC) FILETIME=[B2807CA0:01C5C406] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I will be tracking that specific discussion as issue 7: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issue7.txt At the moment it is open. Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Tuesday, September 27, 2005 8:21 PM >To: Pascal Thubert (pthubert) >Cc: Jari Arkko; IETF NEMO WG >Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt > >pthubert@cisco.com wrote: >> Hi Jari: >> >> Thanks a bunch for all this. Please find some proposal changes inline. >> Actually, all interested in the draft are welcome to enter this >> discussion, as it might be the last chance before publication... >> >> >>>>What troubled me perhaps most was that the >>>>document suggests a mechanism to emulate returning >>>>home when a virtual home link implementation is >>>>being used at the home agent. I'm not convinced that this >>>>is necessary, and if it is, this is probably something that should >>>>be done for Mobile IPv6 and not just nemo. Getting rid of this >>>>part of the document would also remove one normative behaviour >>>>requirement (which currently does not feel appropriate in >>>>an informational document such as this one). >>> >>>there is a problem when there is a virtual home link and a >>>mobile router returns home. where does it connect to? does >>>it de-register? does it start sending routing protocol >>>updates in case it is capable of sending routing updates? >>>the last question especially is very important and is >>>specific only to NEMO. >>> >>>the text we currently have is to address the above questions. >>>even for MIPv6, we need to address returning home in case >>>the home link is a virtual link, but the problem is not the >>>same. there are no routing updates from the mobile node that >>>could screw up route aggregation on the home network. also >>>for some reason the thinking was that in MIPv6 if the home >>>link is virtual the MN never goes home. the same may not be >>>true for mobile networks. >> >> [] >> [] I understand that Jari suggests removing that piece of text; >> or maybe changing it to fit an informational document. >> >> Current text: >> >> In order for a Mobile Router to emulate returning Home, it can >> connect to one or more access link(s) configured for that purpose on >> the Home Agent. The Mobile Router, after connecting to the access >> link, SHOULD not send any routing protocol updates on the egress >> interface because the routing information from the Mobile Router >> might adversely affect IPv6 route aggregation on the Home Network. >> However, the Mobile Router must register its binding as if it was >> accessing a foreign link. >> >> Proposed fix: >> >> RFC 3775 and 3963 do not provide the specific support for a >> Mobile Node to emulate returning Home on a Virtual Home Network. >> In particular, in the case of NEMO, the routing information from >> the Mobile Router being injected on the IGP might adversely affect >> IPv6 route aggregation on the Home Network. > >but why? informational documents can describe some behavior >for the mobile router. I dont understand the part about >not fitting an informational document. > >Vijay From nemo-bounces@ietf.org Wed Sep 28 08:27:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKb2M-0003Jz-OX; Wed, 28 Sep 2005 08:27:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKb2K-0003Jj-Ov for nemo@megatron.ietf.org; Wed, 28 Sep 2005 08:27:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02655 for ; Wed, 28 Sep 2005 08:27:47 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKb9k-0003DE-Hk for nemo@ietf.org; Wed, 28 Sep 2005 08:35:31 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2005 14:27:35 +0200 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 j8SCRWVP020644; Wed, 28 Sep 2005 14:27:32 +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.0); Wed, 28 Sep 2005 14:27:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 28 Sep 2005 14:27:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151A608@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXC4XsCJk+qkca2TL+xc4Vj63l24gBF9djA From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" , X-OriginalArrivalTime: 28 Sep 2005 12:27:31.0720 (UTC) FILETIME=[FF605880:01C5C427] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Henrik: Thanks a lot for this detailed review. This is a very detailed work. Many comments were just accepted as is and you'll find the result in the pre 05 version, but I cut them from this mail, and left only the discussions. All is available at: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issues.html Please note that the RFC editors do a great job in helping us international writers finalize the text with all the appropriate language.=20 They might not get all the thanks they deserve, so this is an occasions :) >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Henrik Levkowetz >Sent: Monday, September 26, 2005 11:29 PM >To: nemo@ietf.org >Subject: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt > >I was asked to review this draft. > >As you'll see, there are some places where my comments overlap with >Jari's - I did this review before reading through his - but there are >also a number of separate issues. > >Overall comments: > > This draft is quite clear and informative, with some exceptions > where language blemishes makes understanding less easy than it > could be. > > The major comment I have that I miss a clear explanation of the > benefits of Extended vs. Aggregated Home Networks. For the > Virtual Home Network and the Mobile Home (which I really > would have called Nested Mobile Networks...) the merits and > drawbacks are discussed adequately. > > A second overall comment is that the Appendix doesn't belong in > this document. The rest of the document is, as is said in the > Abstract, a documentation of usage and issues, while the > Appendix is a proposal for protocol enhancement. It should be > removed and if desired proposed in a separate document. > [] Thanks Henrik :) >Detailed Review: > >Section 1., para. 2: > >> In order to read this document properly, the distinction between the >> concepts of Home Link and of Home Network must be very clear. A Home >> Link is a physical or a virtual Link, attached to a Home Agent. A >> Home Network is an aggregation that can be further subnetted. As a >> result, the Home Network is not necessarily contained on a Home Link. >> In fact, the Mobile Network Prefixes are subnets of the Home Network. >> How the two concepts relate in a given deployment depend on the >> organization of the Home Network, as described below. > > Unfortunately, the above description does not at all make the > distinction clear to me. Are the Home Network prefixes a subset of > the Home Link prefixes? A superset? Or something else? I'm more > confused after reading the above than before... []=20 [] The Home Network is a whole network whereas the Home Link just has a subnet. The sentence that covers this is: " the Home Network is not necessarily contained on a Home Link". We can add a few words there to make it more specific like " the Home Network is not necessarily contained on a Home Link, but can be distributed between the Home Link and the Mobile Networks" Is that better? > > >Section 1., para. 5: > >> NEMO Extended Home Network: In this disposition, the Home Network is >> only one subnet of a larger aggregation that encompasses the >> Mobile Networks, called extended Home Network. When at Home, a >> Mobile Router performs normal routing between the Home Link and >> the Mobile Networks. More in Section 5. > > Disposition? Maybe say layout or configuration instead? > [Disposition: > * your usual mood; "he has a happy disposition" > * disposal: the act or means of getting rid of something > * inclination: an attitude of mind especially one that favors one > alternative over others; "he had an inclination to give up too > easily"; "a tendency to be too strict" > * a natural or acquired habit or characteristic tendency in a person > or thing; "a swelling with a disposition to rupture" > * Determination of the final arrangement or settlement of a case > following judgment. ] > > [] Help anyone native in English? Seems that the last * is the one covering what is meant here. The trouble with configuration is that in our domain, it is often used as the configuration of a device, as opposed to the arrangement of things is a larger system. >Section 6.2, para. 3: > >> Note that it must expect a shorter prefix than that of its Mobile >> Networks, even if its Home Address is formed out of one of its MNPs, >> but that the Home Address still matches the Home Network Prefix. > > This paragraph needs a bit of re-write. Maybe something like: > - > Note that it must expect a shorter prefix than that of its Mobile > Network(s). Even if its Home Address is formed out of one of its MNPs, > the Home Address must still match the Home Network Prefix. > > [] What about:=20 When the forms its Home Address out of one of its Mobile Network Prefixes, since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address actually matches both prefixes. As a result, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed. =20 > >Section 6.2.1, para. 3: > >> Alternatively, the Mobile Router might perform ND proxying for all >> addresses in its MNPs, between the egress and the related ingress >> interface. Since the prefixes on the egress and ingress interfaces >> are overlapping, routing is disallowed. > > This paragraph is not too clear to me. So, here we aren't > bridging, and we aren't routing, so how can traffic flow? > [] We can not be routing. We are either proxying or bridging. Depends if the interfaces are compatible for bridging... From Jari's comment on that same part, I guess we will focus on proxying with a ref to Dave's draft. > >Section 6.2.1, para. 6: > >> Figure 3: Bridging between egress and ingress > > I don't see the difference between Figure 2 and Figure 3. > Should I? > > [] We want to show the difference between fig 3 and fig 4 actually. These are about how things actually plug physically. Fig 2 is a configuration thing, stressing where the prefixes are assigned and it compares to fig 1. I still think it's OK like that. Too many words might clouds things even more, and bore some readers. >Section 6.2.2, para. 4: > >> This fits the connected route model, since the Aggregated Home is >> truly located on that network. Note that in that case, it makes >> sense for a Mobile Router to register using a Home Address from one >> of its own MNPs. . > > Spurious full stop (".") > Additionally, the above paragraph seems to say that it does _not_ > make sense for the Mobile Router to register using a Home Address > from one of its own MNPs as described in Section 5.3 ... > Could the document be more clear - maybe clearly recommend that > the Section 5.3 mode not be used? > [] Yes. There is a comment by Jari around the same aspect. Maybe we need to add a last sentence in 5.5 to say that we do not recommend=20 it for that reasons? I made that issue 8. http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issue8.txt []=20 >Section 6.3, para. 2: > >> A Mobile Router that is at Home must own an address from the >> aggregation on its egress interface and an address from its MNP -a >> subnet of that aggregation- on its ingress interface. A pure router >> will reject that configuration, and the Mobile Router needs to act as >> a bridge to enable it. In order to deploy the aggregated Home >> Network model, one must check whether that support is available in >> the Mobile Routers if returning Home is required. > > Isn't this a clear deployment caveat, belonging in the next > section? > [] I moved it; comments anyone? >Section 6.4.1, para. 1: > >> A node on the Home Link discovers that the Aggregated Home Network is >> actually a subnet on the Home Link and may use the prefix on the Home >> Link to autoconfigure a Home Address. Such a node may also install a >> connected route to the Aggregated Home Network over the Home Link. > > I'm having a bit of trouble with the formulation here. Do you mean > to say: > "If a node were to discovers that the Aggregated Home Network is > actually a subnet on the Home Link it might use the prefix on the > Home Link to autoconfigure a Home Address. ..." ? > - if so, maybe say that :-) and also adjust the rest of the text > and the next paragraph accordingly. > [] Not necessarily a Home address. Just plug any Host on that link. We meant something like this:=20 A node on the Home Link receiving a Router Advertisement that includes the Aggregated Home Network prefix might use that prefix for Address Autoconfiguration. Such a node may also install a connected route to the Aggregated Home Network over the Home Link. As a result, unless the node has a better (longest match) route to a given Mobile Network Prefix, it will lookup all MNNs on that MNP using Neighbor Discovery over its interface to the Home Link. > >Section 7., para. 0: > >> When the Home Address of a Mobile Router is derived from its MNP, >> there is thus an additional risk of an undetected misconfiguration if >> the Home Address is autoconfigured from the ingress link as opposed >> to statically assigned with the MNP itself. > > s/assigned with the MNP itself/assigned to the MR/ ?? > [] In fact, when you configure the address on the interface, you also configure the MNP by providing the prefix length. I think the text is OK? > >Section 7.2, para. 1: > >> At some point in the future, NEMO basic support may be extended to >> operate fully at L3 for instance if the HAHA protocol [11] gets >> standardized and deployed. Until then, NEMO operations still inherit >> from mobile IPv6 [7] for the Home Agent to Home Agent communication, >> which is basically based on Neighbor Discovery extensions over the >> Home Link. Making that link virtual bars the deployment of multiple >> Home Agents, which may be desirable for reasons of load balancing. >> Please refer to the NEMO multihoming issues [12] draft for more on >> this. > > s/from mobile IPv6 [7] for the Home Agent to Home Agent communication, > /the Home Agent to Home Agent communication from Mobile IPv6 [7]./ > s/which is basically/This is basically/ > - > Although I'm not sure if this paragraph should be kept in the > published document - it's speculative and may not make sense > to have there in 2 or 20 years? [] Same from Jari... I removed the first sentence > > >Section 8.1, para. 12: > >> Note that the hierarchy occurs at a configuration level and may not >> be reflected in the actual connection between nodes. For instance in >> the Cab Co case, cabs are roaming within the city, each one attaching >> to a different hot spot, while the regional office is connected to >> the infrastructure using some ISP connection. > > Sorry, I don't understand what you want to say with the first > sentence of this paragraph. > [] Trying to say that the hierarchy is a configuration thing. Nothing to do with the way things will be interconnected. What about :=20 Note that this is a hierarchy in terms of configuration, which may not be reflected in the actual connection between nodes. > > >Section 8.1, para. 15: > >> If SFO is also the root-MR of a nested structure of cabs, the >> communication between cabs is relayed by SFO and does not require the >> satellite link. SFO recursively terminates the nested tunnels to the >> cabs and re-encapsulates all the packets between the nested cloud and >> correspondents in the infrastructure in a single tunnel to CA5A, this >> providing for nested NEMO Route Optimization. > > The difference between the two cases discussed here isn't too > clear to me. Does it consist only of where the tunnels are > terminated, or is there also a difference with respect to the > routing geometry (which nodes the traffic from the leaf nodes > pass through?) > [] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs belong to a same HA, then the HA terminates recursively a number of nested tunnels. Once the inner packet is obtained, SFO will pass it to CASA over its own MRHA tunnel.=20 Some deployments failed to use that 'trick' causing extensive use of sat links. This is also an advantage of shared proxies in the global HAHA case. > > >Appendix A.: > > The language of the following appendix is less polished than the > language of the main body of the document, but I'm not reviewing > it in detail; instead I suggest that it belongs in a separate > document, as it's a proposal of a possible protocol enhancement > and not just a description of usage scenarios of the basic > protocol. []=20 [] We got pretty much the same from Jari. Comments anyone? I guess that this is part of issue 7. Again, thanks a lot. Pascal From nemo-bounces@ietf.org Wed Sep 28 08:49:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbNF-0008PD-O5; Wed, 28 Sep 2005 08:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbND-0008O4-E2 for nemo@megatron.ietf.org; Wed, 28 Sep 2005 08:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03675 for ; Wed, 28 Sep 2005 08:49:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbUd-0003kR-Uc for nemo@ietf.org; Wed, 28 Sep 2005 08:57:06 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 05:49:12 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="346297169:sNHT32908604" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8SCmo4j010487; Wed, 28 Sep 2005 05:49:10 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 08:48:48 -0400 Received: from 10.86.242.74 ([10.86.242.74]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Sep 2005 12:48:47 +0000 Received: from localhost.localdomain by email.cisco.com; 28 Sep 2005 12:48:56 +0000 Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt From: Ralph Droms To: Ryuji Wakikawa In-Reply-To: <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> <4314A955.5050906@iprg.nokia.com> <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 28 Sep 2005 08:48:55 -0400 Message-Id: <1127911736.16351.108.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 28 Sep 2005 12:48:48.0045 (UTC) FILETIME=[F82015D0:01C5C42A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org (picking up an old thread; I'm revising draft-ietf-nemo-dhcpv6-pd-00.txt based on these comments) On Tue, 2005-09-06 at 01:56 +0900, Ryuji Wakikawa wrote: > Hello Pascal and Vijay > > I read the draft and feel the same impression with Vijay. I agree > with Vijay. > The section 3.2 is not directly related to the NEMO PD. > We had the consensus not to include local mobility management in > DHCPv6PD > at the Minneapolis meeting (forget maybe somewhere else). > > Here are more comments. > > Can MR can skip DHCP server discovery sending message to FF02::1:2 ? > If MR knows the HA, MR can send request message to the HA without DR > discovery. I'm leery of making this fundamental change to the specification in RFC 3315 without dhc WG review. Uf the goal is to reduce the number of messages exchanged, the Rapid Commit option allows a 2 message exchange for PD. (remainder of earlier message elided) From nemo-bounces@ietf.org Wed Sep 28 09:10:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbhw-00073I-M8; Wed, 28 Sep 2005 09:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbhu-0006zY-9u for nemo@megatron.ietf.org; Wed, 28 Sep 2005 09:10:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05275 for ; Wed, 28 Sep 2005 09:10:44 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbpM-0004TB-F3 for nemo@ietf.org; Wed, 28 Sep 2005 09:18:29 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 17FD189871; Wed, 28 Sep 2005 16:10:32 +0300 (EEST) Message-ID: <433A9652.5030505@piuha.net> Date: Wed, 28 Sep 2005 16:10:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pthubert@cisco.com Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC014CC40F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC014CC40F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal, >Proposed fix: > > RFC 3775 and 3963 do not provide the specific support for a > Mobile Node to emulate returning Home on a Virtual Home Network. > In particular, in the case of NEMO, the routing information from > the Mobile Router being injected on the IGP might adversely affect > IPv6 route aggregation on the Home Network. > > This would work for me. >[] How do we translate that into a fix in the text? > >When read separately, the text is misleading and seems to say that >there's some magic that allows the HA to route to MR at all times. > >In context (returning Home in extended mode) the text makes more sense >hopefully. > >Current text: > > In implicit mode, the Home Agent has the necessary information to > continue routing to the MNPs in the absence of registration, and the > participation of the Mobile Router to the Home IGP is not required. > >Proposed fix: > > In implicit mode, the Home Agent has the necessary information to > continue routing to the MNPs in the absence of registration, > assuming that the Mobile Router is at Home, and the > participation of the Mobile Router to the Home IGP is not required. > > Looks good. >>>> When connecting to the Home Link, the Mobile Router also need to >>>> autoconfigure an address on the egress interface as opposed to >>>> assigning its Home Address to the interface. >>>> >>>> >>>And how does this work wrt. routing of the actual data packets? >>>Does this mean that the MR needs perform a registration to its >>>home agent, even if its on the home link? >>> >>> >>this text is only specific to the case where the home address >>of the MR is configured from the MNP. if the MR is capable of >>sending routing protocol updates, it just sends an update for >>the MNP. another option is to send an ICMP redirect for the MNP. >>the MR shouldn't register with the home agent. >> >> > >[] Note: The HA being a router, it might not process the redirect, >though. > >But yes, again the excerpt needs to be read in context. As Vijay says, >the MNP is a different /64 then the prefix on the Home Link. The HA owns >the aggregation (say /48) and has more specific routes (one /64 >connected to the Home link acting as a RFC 3775 home prefix, and other >/64 used as MNPs attached to the ingress of the MRs). > >If the MR takes its Home Address from the /64 on the Home Link, all is >very classical. But if it wishes to take its Home Address from the MNP, >then the Home Address is not located ion the Home Link. > >The HA itself does not have route to the /48, but acts as an ABR to >aggregate the /64s into that /48 and call the result Home. Instead, the >HA has /64 routes (to MNPs) via the CareOf address of the MR (for which >it has a connected /64 so the route lookup ends up there). > >This is the whole purpose of extended Home Network. I do not have a >simple fix to propose to make it clearer. If you still think a change is >required, can you please be more specific? > > No, I understand it now. Thanks, the above was very clear. >>>Reference to the ND proxy spec is appropriate here. But that >>>is experimental (and under discussion) -- is ND proxying what >>>we really want to do here? >>> >>> >>RFC 2461 allows a router to proxy for a host, right? that >>should be sufficient. I dont think we are talking about the >>ND proxying draft currently being discussed in the IPv6 WG. >>Pascal, Ryuji, correct me if I am wrong. >> >> >> >[] There might be related issues, like MTU being different, even >though there's no tunneling. I believe it's OK to add the non normative >reference to draft-ietf-ipv6-ndproxy-03.txt? >Consider this picture from Dave's draft, and say that "the rest of the >network" is the Home Link, "local hosts" are lfns and A is our MR. Isn't >this our config should the MR return Home over 802.11? > > | +-------+ +--------+ > local |Ethernet | | Wireless | Access | > +---------+ A +-))) (((-+ +--> rest of network > hosts | | | link | Point | > | +-------+ +--------+ > >For the latter question, if the 2 interfaces are compatible, then the MR >could bridge. It might be more of a problem if they are different (like >one is PPP, between an embedded MR and a single device). But what else >could we do? The router sees overlapping prefixes (and connected routes) >on its interfaces and that's not a valid condition at L3. > > This looks OK to me - my concern was not that I disagreed with what the draft said, but the lack of detail and what specific ND proxying (if there are multiple) we mean here. >[] Well, the text says that > The Extended Home Network and the Aggregated Home Network models can > be adapted for virtual links. > >So both A:B:C::/64 (extended) or A:B:C::/48 (aggregated) could have >worked too. Since there's no need to waste any prefix, we left the whole >range of the /48 to MNP, as an alternate to the other 2 cases. > > Ok. --Jari From nemo-bounces@ietf.org Wed Sep 28 09:15:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbmb-0008Nc-Fy; Wed, 28 Sep 2005 09:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbmX-0008Lc-Gy for nemo@megatron.ietf.org; Wed, 28 Sep 2005 09:15:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05590 for ; Wed, 28 Sep 2005 09:15:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbtz-0004cW-O0 for nemo@ietf.org; Wed, 28 Sep 2005 09:23:16 -0400 Received: from p130.piuha.net ([193.234.218.130]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EKbmV-0002h0-HB for nemo@ietf.org; Wed, 28 Sep 2005 09:15:31 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9A60689870; Wed, 28 Sep 2005 16:09:58 +0300 (EEST) Message-ID: <433A9631.2030203@piuha.net> Date: Wed, 28 Sep 2005 16:10:09 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt References: <43341A61.8080000@piuha.net> <43349373.7040805@iprg.nokia.com> In-Reply-To: <43349373.7040805@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay, > there is a problem when there is a virtual home link and a > mobile router returns home. where does it connect to? does > it de-register? does it start sending routing protocol > updates in case it is capable of sending routing updates? > the last question especially is very important and is > specific only to NEMO. I agree that the routing protocol update issue is important. But its only important if you actually do return home. NEMO works fine without ever returning home, I suppose. >> This may be a lack of understanding of RFC 3963 on my part, but >> how does this actually work? Is the traffic to the MR routed through >> home agent in all cases even when there's no registration? > > > for implicit mode, it is assumed the routes for MNPs exist > all the time. but the forwarding entry would point to a > virtual tunnel interface that wouldnt exist if the mobile > router does not have a valid binding cache entry at the HA. > > in practice, the routes dont have to exist. there could be > some state on the HA which says, if the MR sends a binding > update in the implicit sate, create routes for these MNPs, > don't look for MNPs in the binding update. this is > implementation dependent. Ok. >>> When connecting to the Home Link, the Mobile Router also need to >>> autoconfigure an address on the egress interface as opposed to >>> assigning its Home Address to the interface. >> >> >> >> And how does this work wrt. routing of the actual data packets? >> Does this mean that the MR needs perform a registration to its >> home agent, even if its on the home link? > > > this text is only specific to the case where the home address > of the MR is configured from the MNP. if the MR is capable of > sending routing protocol updates, it just sends an update for > the MNP. another option is to send an ICMP redirect for the MNP. > the MR shouldn't register with the home agent. Ok. >>> 5.5 Applicability >>> ... >>> >>> Also, when the Home Address is derived from the prefix on the Home >>> Link, the Home Agent behavior on the link trivially extends that of >>> MIP and the support should for that configuration should be >>> available >>> with all implementations. >> >> >> >> But Section 5 appeared to be talking also about the case >> when the MR's home address is not derived from the home >> link prefix. > > > right. thats why we have the following text in section 5.3 > > For all these reasons, this submode of extended is no more a trivial > extension to the MIPv6 Home Model, and it might not be compatible > with all implementations. > > configuring a home address from the home prefix is the default > mechanism. configuring from the MNP may not work all the time. Right. I was asking whether this should be stated in 5.5, the applicability section... --Jari From nemo-bounces@ietf.org Wed Sep 28 09:41:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKcBv-0008FO-Ae; Wed, 28 Sep 2005 09:41:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKcBt-0008E6-Sw for nemo@megatron.ietf.org; Wed, 28 Sep 2005 09:41:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07454 for ; Wed, 28 Sep 2005 09:41:44 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKcJL-0005Tr-66 for nemo@ietf.org; Wed, 28 Sep 2005 09:49:29 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9518789870; Wed, 28 Sep 2005 16:41:34 +0300 (EEST) Message-ID: <433A9D99.2060602@piuha.net> Date: Wed, 28 Sep 2005 16:41:45 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Vijay Devarapalli Subject: Re: [nemo] review of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC0151A41C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0151A41C@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal and Vijay, Its indeed possible to have some informational documents that define protocol extensions or behaviour. Of course, if we believe a particular function is generally useful its most often targeted as a proposed standard. But we don't have a theoretical reason why we couldn't have the extension in this doc. However, my opinion that we should pursue the behaviour in a separate document was based on two things: - The nature of the document is really about explaining how you can use NEMO, and what different network setups make sense. This may not fit detail-level protocol behaviour recommendations. Even the name is such that you don't expect to find new functional extensions in it. - Gut feeling that we need more review & wider discussion about the extension. --Jari >The way I understand it, we should not be specifying a behavior in this >document, which is oriented on deployment; and you know that the SHOULD >in the copied text is not really part of RFC 3963. > >There might be a need of some standard track work on the matter of >virtual home for NEMO and MIP. Maybe associated to the HAHA protocol, >which is needed for multiple HAs sharing a virtual Home. > >Do I miss something? > >Pascal > > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Tuesday, September 27, 2005 8:21 PM >>To: Pascal Thubert (pthubert) >>Cc: Jari Arkko; IETF NEMO WG >>Subject: Re: [nemo] review of >> >> >draft-ietf-nemo-home-network-models-04.txt > > >>pthubert@cisco.com wrote: >> >> >>>Hi Jari: >>> >>>Thanks a bunch for all this. Please find some proposal changes >>> >>> >inline. > > >>>Actually, all interested in the draft are welcome to enter this >>>discussion, as it might be the last chance before publication... >>> >>> >>> >>> >>>>>What troubled me perhaps most was that the >>>>>document suggests a mechanism to emulate returning >>>>>home when a virtual home link implementation is >>>>>being used at the home agent. I'm not convinced that this >>>>>is necessary, and if it is, this is probably something that should >>>>>be done for Mobile IPv6 and not just nemo. Getting rid of this >>>>>part of the document would also remove one normative behaviour >>>>>requirement (which currently does not feel appropriate in >>>>>an informational document such as this one). >>>>> >>>>> >>>>there is a problem when there is a virtual home link and a >>>>mobile router returns home. where does it connect to? does >>>>it de-register? does it start sending routing protocol >>>>updates in case it is capable of sending routing updates? >>>>the last question especially is very important and is >>>>specific only to NEMO. >>>> >>>>the text we currently have is to address the above questions. >>>>even for MIPv6, we need to address returning home in case >>>>the home link is a virtual link, but the problem is not the >>>>same. there are no routing updates from the mobile node that >>>>could screw up route aggregation on the home network. also >>>>for some reason the thinking was that in MIPv6 if the home >>>>link is virtual the MN never goes home. the same may not be >>>>true for mobile networks. >>>> >>>> >>>[] >>>[] I understand that Jari suggests removing that piece of text; >>>or maybe changing it to fit an informational document. >>> >>>Current text: >>> >>> In order for a Mobile Router to emulate returning Home, it can >>> connect to one or more access link(s) configured for that purpose >>> >>> >on > > >>> the Home Agent. The Mobile Router, after connecting to the access >>> link, SHOULD not send any routing protocol updates on the egress >>> interface because the routing information from the Mobile Router >>> might adversely affect IPv6 route aggregation on the Home Network. >>> However, the Mobile Router must register its binding as if it was >>> accessing a foreign link. >>> >>>Proposed fix: >>> >>> RFC 3775 and 3963 do not provide the specific support for a >>> Mobile Node to emulate returning Home on a Virtual Home Network. >>> In particular, in the case of NEMO, the routing information from >>> the Mobile Router being injected on the IGP might adversely affect >>> IPv6 route aggregation on the Home Network. >>> >>> >>but why? informational documents can describe some behavior >>for the mobile router. I dont understand the part about >>not fitting an informational document. >> >>Vijay >> >> > > > > From nemo-bounces@ietf.org Wed Sep 28 11:11:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKdaj-00013B-Ic; Wed, 28 Sep 2005 11:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKdai-000134-Oh for nemo@megatron.ietf.org; Wed, 28 Sep 2005 11:11:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13621 for ; Wed, 28 Sep 2005 11:11:26 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKdiA-0007t8-Ku for nemo@ietf.org; Wed, 28 Sep 2005 11:19:12 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j8SFMT4E024284 for ; Wed, 28 Sep 2005 08:22:29 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j8SFIPkg024254 for ; Wed, 28 Sep 2005 10:18:25 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Sep 2005 10:11:16 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A746C@il02exm13> From: Narayanan Vidya-CVN065 To: "'Jari Arkko'" , Vijay Devarapalli Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 28 Sep 2005 10:11:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay, > > there is a problem when there is a virtual home link and a mobile > > router returns home. where does it connect to? does it de-register? > > does it start sending routing protocol updates in case it > is capable > > of sending routing updates? the last question especially is very > > important and is specific only to NEMO. > > I agree that the routing protocol update issue is > important. But its only important if you actually > do return home. NEMO works fine without ever > returning home, I suppose. > So, asking again :) - why is it felt that a NEMO mobile router needs to be able to return "home" even though the home link is virtual? I'm confused why this is any different from the case of a mobile node. Vidya From nemo-bounces@ietf.org Wed Sep 28 11:38:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKe1L-0001di-7e; Wed, 28 Sep 2005 11:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKe1K-0001cV-3T for nemo@megatron.ietf.org; Wed, 28 Sep 2005 11:38:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15289 for ; Wed, 28 Sep 2005 11:38:55 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKe8n-0000GZ-0y for nemo@ietf.org; Wed, 28 Sep 2005 11:46:42 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2005 17:38:48 +0200 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 j8SFcBVr024707; Wed, 28 Sep 2005 17:38:45 +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.0); Wed, 28 Sep 2005 17:38:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 28 Sep 2005 17:38:18 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151A76E@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] review of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXEPz8Y7UKJj0xZSue9z6U0OnsCDAAAm79A From: "Pascal Thubert \(pthubert\)" To: "Narayanan Vidya-CVN065" , "Jari Arkko" , "Vijay Devarapalli" X-OriginalArrivalTime: 28 Sep 2005 15:38:38.0603 (UTC) FILETIME=[B22BD5B0:01C5C442] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Narayanan Vidya-CVN065 >Sent: Wednesday, September 28, 2005 5:11 PM >To: 'Jari Arkko'; Vijay Devarapalli >Cc: IETF NEMO WG >Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt > >Hi Vijay, > >> > there is a problem when there is a virtual home link and a mobile >> > router returns home. where does it connect to? does it de-register? >> > does it start sending routing protocol updates in case it >> is capable >> > of sending routing updates? the last question especially is very >> > important and is specific only to NEMO. >> >> I agree that the routing protocol update issue is >> important. But its only important if you actually >> do return home. NEMO works fine without ever >> returning home, I suppose. >> > >So, asking again :) - why is it felt that a NEMO mobile router needs to be able to return "home" even >though the home link is virtual? I'm confused why this is any different from the case of a mobile >node. > [] The idea was that there is an environment (no more a link but more like a home area) where the MR should inject its routes, and an environment where it shouldn't. In the environment where it should inject its routes, it should also drop its bindings for its prefixes. And maybe drop its binding at all if maintaining reachability to the Home Address is not critical (the MR can always be reached at one of its addresses on an MNP). I guess this all revolves around getting rid of the Home-Link-centric / ND based behavior inherited from MIP6, which is one key benefit of HAHA. I think I follow Jari on this: the idea needs to mature more, and that would be outside of this document. My favorite place would be local HAHA. Pascal From nemo-bounces@ietf.org Wed Sep 28 17:07:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKj94-0005I9-CJ; Wed, 28 Sep 2005 17:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKj91-0005HA-Pq for nemo@megatron.ietf.org; Wed, 28 Sep 2005 17:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12455 for ; Wed, 28 Sep 2005 17:07:13 -0400 (EDT) Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKjGX-0003hc-IY for nemo@ietf.org; Wed, 28 Sep 2005 17:15:02 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id B20FA37F93; Wed, 28 Sep 2005 23:07:00 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7279D37F93; Wed, 28 Sep 2005 23:07:00 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3F3E237E42; Wed, 28 Sep 2005 23:07:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EKj8l-0004AZ-Vp; Wed, 28 Sep 2005 23:07:00 +0200 Message-ID: <433B05F3.1000206@levkowetz.com> Date: Wed, 28 Sep 2005 23:06:59 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC0151A608@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0151A608@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 17cf8eab1d6bbd2874a56f9e3554d91d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, on 2005-09-28 14:27 Pascal Thubert (pthubert) said the following: > Hi Henrik: > > Thanks a lot for this detailed review. This is a very detailed work. > Many comments were just accepted as is and you'll find the result in the > pre 05 version, but I cut them from this mail, and left only the > discussions. Makes sense. > All is available at: > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issues.html > > > Please note that the RFC editors do a great job in helping us > international writers finalize the text with all the appropriate > language. > > They might not get all the thanks they deserve, so this is an occasions > :) > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > Henrik Levkowetz >>Sent: Monday, September 26, 2005 11:29 PM >>To: nemo@ietf.org >>Subject: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt >> >>I was asked to review this draft. >> >>As you'll see, there are some places where my comments overlap with >>Jari's - I did this review before reading through his - but there are >>also a number of separate issues. >> >>Overall comments: >> >> This draft is quite clear and informative, with some exceptions >> where language blemishes makes understanding less easy than it >> could be. >> >> The major comment I have that I miss a clear explanation of the >> benefits of Extended vs. Aggregated Home Networks. For the >> Virtual Home Network and the Mobile Home (which I really >> would have called Nested Mobile Networks...) the merits and >> drawbacks are discussed adequately. >> >> A second overall comment is that the Appendix doesn't belong in >> this document. The rest of the document is, as is said in the >> Abstract, a documentation of usage and issues, while the >> Appendix is a proposal for protocol enhancement. It should be >> removed and if desired proposed in a separate document. >> > [] Thanks Henrik :) > >>Detailed Review: >> >>Section 1., para. 2: >> >>> In order to read this document properly, the distinction between the >>> concepts of Home Link and of Home Network must be very clear. A Home >>> Link is a physical or a virtual Link, attached to a Home Agent. A >>> Home Network is an aggregation that can be further subnetted. As a >>> result, the Home Network is not necessarily contained on a Home Link. >>> In fact, the Mobile Network Prefixes are subnets of the Home Network. >>> How the two concepts relate in a given deployment depend on the >>> organization of the Home Network, as described below. >> >> Unfortunately, the above description does not at all make the >> distinction clear to me. Are the Home Network prefixes a subset of >> the Home Link prefixes? A superset? Or something else? I'm more >> confused after reading the above than before... > [] > [] The Home Network is a whole network whereas the Home Link just > has a subnet. The sentence that covers this is: > " the Home Network is not necessarily contained on a Home Link". > We can add a few words there to make it more specific like > > " the Home Network is not necessarily contained on a Home Link, but can > be distributed between the Home Link and the Mobile Networks" > > Is that better? Slightly, but not enough, I think. After trying out various formulations, I actually think it would be better to reduce the paragraph to this: In order to read this document properly, it is important to realise there is a distinction between the concepts of Home Link and Home Network, and in a NEMO context these may not at all be equivalent. How the two concepts relate in a given deployment depend on the organization of the Home Network, as described below. Then you don't get into trouble by trying to capture the fine distinctions which is explained in the rest of the document in just one or two sentences :-) >> >>Section 1., para. 5: >> >>> NEMO Extended Home Network: In this disposition, the Home Network is >>> only one subnet of a larger aggregation that encompasses the >>> Mobile Networks, called extended Home Network. When at Home, a >>> Mobile Router performs normal routing between the Home Link and >>> the Mobile Networks. More in Section 5. >> >> Disposition? Maybe say layout or configuration instead? >> [Disposition: >> * your usual mood; "he has a happy disposition" >> * disposal: the act or means of getting rid of something >> * inclination: an attitude of mind especially one that favors one >> alternative over others; "he had an inclination to give up too >> easily"; "a tendency to be too strict" >> * a natural or acquired habit or characteristic tendency in a person >> or thing; "a swelling with a disposition to rupture" >> * Determination of the final arrangement or settlement of a case >> following judgment. ] >> >> > [] Help anyone native in English? Seems that the last * is the one > covering what is meant here. The trouble with configuration is that in > our domain, it is often used as the configuration of a device, as > opposed to the arrangement of things is a larger system. The last bullet is about court cases, and not directly applicable here. We need a different word. What about "arrangement"? > >>Section 6.2, para. 3: >> >>> Note that it must expect a shorter prefix than that of its Mobile >>> Networks, even if its Home Address is formed out of one of its MNPs, >>> but that the Home Address still matches the Home Network Prefix. >> >> This paragraph needs a bit of re-write. Maybe something like: >> - >> Note that it must expect a shorter prefix than that of its Mobile >> Network(s). Even if its Home Address is formed out of one of its MNPs, >> the Home Address must still match the Home Network Prefix. >> >> > [] What about: > When the forms its Home Address out of one of its Mobile Network Prefixes, > since the Home Network prefix is an aggregation that encompasses all > the MNPs, the Home Address actually matches both prefixes. As a result, > the MR must expect a shorter prefix than that of the Mobile Network from > which the Home Address was formed. Looks better. s/When the/When the MR/ in the first line. Changing the order of the first sentence may be even better. What about: Since the Home Network prefix is an aggregation that encompasses all the MNPs, a Home Address that an MR forms from one of its Mobile Network Prefixes, will actually match both the Home Network prefix and its Mobile Network prefix. To properly identify the Home Network, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed. >> >>Section 6.2.1, para. 3: >> >>> Alternatively, the Mobile Router might perform ND proxying for all >>> addresses in its MNPs, between the egress and the related ingress >>> interface. Since the prefixes on the egress and ingress interfaces >>> are overlapping, routing is disallowed. >> >> This paragraph is not too clear to me. So, here we aren't >> bridging, and we aren't routing, so how can traffic flow? >> > [] We can not be routing. We are either proxying or bridging. > Depends if the interfaces are compatible for bridging... From Jari's > comment on that same part, I guess we will focus on proxying with a ref > to Dave's draft. Ok. >> >>Section 6.2.1, para. 6: >> >>> Figure 3: Bridging between egress and ingress >> >> I don't see the difference between Figure 2 and Figure 3. >> Should I? >> >> > [] We want to show the difference between fig 3 and fig 4 actually. > These are about how things actually plug physically. Fig 2 is a > configuration thing, stressing where the prefixes are assigned and it > compares to fig 1. I still think it's OK like that. Too many words might > clouds things even more, and bore some readers. The problem is that now a reader (at least this reader) is wondering why you don't just refer back to Fig. 2. So why not just refer back to Fig. 2? :-) >>Section 6.2.2, para. 4: >> >>> This fits the connected route model, since the Aggregated Home is >>> truly located on that network. Note that in that case, it makes >>> sense for a Mobile Router to register using a Home Address from one >>> of its own MNPs. . >> >> Spurious full stop (".") >> Additionally, the above paragraph seems to say that it does _not_ >> make sense for the Mobile Router to register using a Home Address >> from one of its own MNPs as described in Section 5.3 ... >> Could the document be more clear - maybe clearly recommend that >> the Section 5.3 mode not be used? >> > [] Yes. There is a comment by Jari around the same aspect. > Maybe we need to add a last sentence in 5.5 to say that we do not recommend > it for that reasons? I made that issue 8. > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issue8.txt Sounds appropriate. [...] > >>Section 6.4.1, para. 1: >> >>> A node on the Home Link discovers that the Aggregated Home Network is >>> actually a subnet on the Home Link and may use the prefix on the Home >>> Link to autoconfigure a Home Address. Such a node may also install a >>> connected route to the Aggregated Home Network over the Home Link. >> >> I'm having a bit of trouble with the formulation here. Do you mean >> to say: >> "If a node were to discovers that the Aggregated Home Network is >> actually a subnet on the Home Link it might use the prefix on the >> Home Link to autoconfigure a Home Address. ..." ? >> - if so, maybe say that :-) and also adjust the rest of the text >> and the next paragraph accordingly. >> > [] Not necessarily a Home address. Just plug any Host on that link. > We meant something like this: > A node on the Home Link receiving a Router Advertisement that > includes the Aggregated Home Network prefix might use that prefix > for Address Autoconfiguration. Such a node may also install a > connected route to the Aggregated Home Network over the Home Link. > > As a result, unless the node has a better (longest match) route to > a given Mobile Network Prefix, it will lookup all MNNs on that MNP > using Neighbor Discovery over its interface to the Home Link. Ok. But you need to use 'might', 'would', 'could' etc. to distinguish this possible but undesirable behaviour from something which should be done. Looking forward to seeing some adjusted text. >>Section 7., para. 0: >> >>> When the Home Address of a Mobile Router is derived from its MNP, >>> there is thus an additional risk of an undetected misconfiguration if >>> the Home Address is autoconfigured from the ingress link as opposed >>> to statically assigned with the MNP itself. >> >> s/assigned with the MNP itself/assigned to the MR/ ?? >> > [] In fact, when you configure the address on the interface, you > also configure the MNP by providing the prefix length. I think the text > is OK? No, the language as it stands doesn't really make sense. A fix is needed. Maybe s/assigned with the MNP itself/assigning an address and MNP/ ? >>Section 7.2, para. 1: >> >>> At some point in the future, NEMO basic support may be extended to >>> operate fully at L3 for instance if the HAHA protocol [11] gets >>> standardized and deployed. Until then, NEMO operations still inherit >>> from mobile IPv6 [7] for the Home Agent to Home Agent communication, >>> which is basically based on Neighbor Discovery extensions over the >>> Home Link. Making that link virtual bars the deployment of multiple >>> Home Agents, which may be desirable for reasons of load balancing. >>> Please refer to the NEMO multihoming issues [12] draft for more on >>> this. >> >> s/from mobile IPv6 [7] for the Home Agent to Home Agent communication, >> /the Home Agent to Home Agent communication from Mobile IPv6 [7]./ >> s/which is basically/This is basically/ >> - >> Although I'm not sure if this paragraph should be kept in the >> published document - it's speculative and may not make sense >> to have there in 2 or 20 years? > > [] Same from Jari... I removed the first sentence That could work, supposing you've also adjusted the start of the second sentence. >>Section 8.1, para. 12: >> >>> Note that the hierarchy occurs at a configuration level and may not >>> be reflected in the actual connection between nodes. For instance in >>> the Cab Co case, cabs are roaming within the city, each one attaching >>> to a different hot spot, while the regional office is connected to >>> the infrastructure using some ISP connection. >> >> Sorry, I don't understand what you want to say with the first >> sentence of this paragraph. >> > [] Trying to say that the hierarchy is a configuration thing. > Nothing to do with the way things will be interconnected. What about : > Note that this is a hierarchy in terms of configuration, which may not > be reflected in the actual connection between nodes. Mmm. Maybe. But I'm still not sure I understand it. Maybe two small parallel examples are needed to illustrate the distinction. >>Section 8.1, para. 15: >> >>> If SFO is also the root-MR of a nested structure of cabs, the >>> communication between cabs is relayed by SFO and does not require the >>> satellite link. SFO recursively terminates the nested tunnels to the >>> cabs and re-encapsulates all the packets between the nested cloud and >>> correspondents in the infrastructure in a single tunnel to CA5A, this >>> providing for nested NEMO Route Optimization. >> >> The difference between the two cases discussed here isn't too >> clear to me. Does it consist only of where the tunnels are >> terminated, or is there also a difference with respect to the >> routing geometry (which nodes the traffic from the leaf nodes >> pass through?) >> > [] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs > belong to a same HA, then the HA terminates recursively a number of > nested tunnels. Once the inner packet is obtained, SFO will pass it to > CASA over its own MRHA tunnel. > > Some deployments failed to use that 'trick' causing extensive use of sat > links. > > This is also an advantage of shared proxies in the global HAHA case. Ok, so the distinction is one of where the tunnels are terminated, then? Avoiding unnecessary traffic up and back down over the common link is a by-product of terminating the tunnels at the common HA, no? I think the text needs to be clearer here. >> >> >>Appendix A.: >> >> The language of the following appendix is less polished than the >> language of the main body of the document, but I'm not reviewing >> it in detail; instead I suggest that it belongs in a separate >> document, as it's a proposal of a possible protocol enhancement >> and not just a description of usage scenarios of the basic >> protocol. > [] > [] We got pretty much the same from Jari. Comments anyone? I guess > that this is part of issue 7. Right. > Again, thanks a lot. You're welcome. Regards, Henrik From nemo-bounces@ietf.org Wed Sep 28 17:18:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjJX-0006o0-RJ; Wed, 28 Sep 2005 17:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjJV-0006nk-5D for nemo@megatron.ietf.org; Wed, 28 Sep 2005 17:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13039 for ; Wed, 28 Sep 2005 17:18:03 -0400 (EDT) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKjR1-0003zq-4e for nemo@ietf.org; Wed, 28 Sep 2005 17:25:52 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 999CF38039; Wed, 28 Sep 2005 23:13:16 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8364A37ED7; Wed, 28 Sep 2005 23:13:16 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3470F37E50; Wed, 28 Sep 2005 23:17:54 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EKjJK-0007QT-34; Wed, 28 Sep 2005 23:17:54 +0200 Message-ID: <433B0881.80504@levkowetz.com> Date: Wed, 28 Sep 2005 23:17:53 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC0151A608@xmb-ams-337.emea.cisco.com> <433B05F3.1000206@levkowetz.com> In-Reply-To: <433B05F3.1000206@levkowetz.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org A small correction to one of my comments: on 2005-09-28 23:06 Henrik Levkowetz said the following: [...] >> [] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs >> belong to a same HA, then the HA terminates recursively a number of >> nested tunnels. Once the inner packet is obtained, SFO will pass it to >> CASA over its own MRHA tunnel. >> >> Some deployments failed to use that 'trick' causing extensive use of sat >> links. >> >> This is also an advantage of shared proxies in the global HAHA case. > > Ok, so the distinction is one of where the tunnels are terminated, then? > Avoiding unnecessary traffic up and back down over the common link is > a by-product of terminating the tunnels at the common HA, no? That should be: "... over the common link is a side-effect of terminating the tunnels at the common HA, no?" Henrik From nemo-bounces@ietf.org Thu Sep 29 12:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1Oy-0003Qw-88; Thu, 29 Sep 2005 12:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1Ow-0003Qr-7j for nemo@megatron.ietf.org; Thu, 29 Sep 2005 12:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21644 for ; Thu, 29 Sep 2005 12:36:51 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1Wc-0006u0-WB for nemo@ietf.org; Thu, 29 Sep 2005 12:44:51 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Sep 2005 18:36:45 +0200 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 j8TGafVP007758; Thu, 29 Sep 2005 18:36:42 +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.0); Thu, 29 Sep 2005 18:36:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Thu, 29 Sep 2005 18:36:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151AC64@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXEcLhNt9BId2jfQ4OmQYY2CWCdpwAhTagg From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 29 Sep 2005 16:36:41.0440 (UTC) FILETIME=[F8845600:01C5C513] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org [] second round, same rules :) >>>Section 1., para. 2: >>> >>>> In order to read this document properly, the distinction between the >>>> concepts of Home Link and of Home Network must be very clear. A Home >>>> Link is a physical or a virtual Link, attached to a Home Agent. A >>>> Home Network is an aggregation that can be further subnetted. As a >>>> result, the Home Network is not necessarily contained on a Home Link. >>>> In fact, the Mobile Network Prefixes are subnets of the Home Network. >>>> How the two concepts relate in a given deployment depend on the >>>> organization of the Home Network, as described below. >>> >>> Unfortunately, the above description does not at all make the >>> distinction clear to me. Are the Home Network prefixes a subset of >>> the Home Link prefixes? A superset? Or something else? I'm more >>> confused after reading the above than before... >> [] >> [] The Home Network is a whole network whereas the Home Link just >> has a subnet. The sentence that covers this is: >> " the Home Network is not necessarily contained on a Home Link". >> We can add a few words there to make it more specific like >> >> " the Home Network is not necessarily contained on a Home Link, but can >> be distributed between the Home Link and the Mobile Networks" >> >> Is that better? > >Slightly, but not enough, I think. After trying out various formulations, >I actually think it would be better to reduce the paragraph to this: > > In order to read this document properly, it is important to realise > there is a distinction between the concepts of Home Link and Home > Network, and in a NEMO context these may not at all be equivalent. > How the two concepts relate in a given deployment depend on the > organization of the Home Network, as described below. > [] What about: In order to read this document properly, it is important to realize that in a NEMO context, the Home Network is not bounded by the Home Link. How the two concepts relate in a given deployment depends on the organization of the Home Network, as described below. >>> >>>Section 6.2.1, para. 6: >>> >>>> Figure 3: Bridging between egress and ingress >>> >>> I don't see the difference between Figure 2 and Figure 3. >>> Should I? >>> >>> >> [] We want to show the difference between fig 3 and fig 4 actually. >> These are about how things actually plug physically. Fig 2 is a >> configuration thing, stressing where the prefixes are assigned and it >> compares to fig 1. I still think it's OK like that. Too many words might >> clouds things even more, and bore some readers. > >The problem is that now a reader (at least this reader) is wondering why >you don't just refer back to Fig. 2. So why not just refer back to Fig. 2? :-) > []=20 I see your point. 2 reasons, none great. First is that the picture is collocated with the text so the reader does not have to search for it. Second is that even is some actual drawing is the common, one refers to configuration and the other to arrangement, per our agreed upon terms. I'm afraid of an additional confusion if a same picture is used to reflect the 2. >>>Section 6.4.1, para. 1: >>> >>>> A node on the Home Link discovers that the Aggregated Home Network is >>>> actually a subnet on the Home Link and may use the prefix on the Home >>>> Link to autoconfigure a Home Address. Such a node may also install a >>>> connected route to the Aggregated Home Network over the Home Link. >>> >>> I'm having a bit of trouble with the formulation here. Do you mean >>> to say: >>> "If a node were to discovers that the Aggregated Home Network is >>> actually a subnet on the Home Link it might use the prefix on the >>> Home Link to autoconfigure a Home Address. ..." ? >>> - if so, maybe say that :-) and also adjust the rest of the text >>> and the next paragraph accordingly. >>> >> [] Not necessarily a Home address. Just plug any Host on that link. >> We meant something like this: >> A node on the Home Link receiving a Router Advertisement that >> includes the Aggregated Home Network prefix might use that prefix >> for Address Autoconfiguration. Such a node may also install a >> connected route to the Aggregated Home Network over the Home Link. >> >> As a result, unless the node has a better (longest match) route to >> a given Mobile Network Prefix, it will lookup all MNNs on that MNP >> using Neighbor Discovery over its interface to the Home Link. > >Ok. But you need to use 'might', 'would', 'could' etc. to distinguish >this possible but undesirable behaviour from something which should be >done. Looking forward to seeing some adjusted text. > [] Well, it is normal for a Node to autoconf, and the result is undesirable in that case: A node on the Home Link receiving a Router Advertisement that includes the Aggregated Home Network prefix might use that prefix for Address Autoconfiguration. Such a node would also install a connected route to the Aggregated Home Network over the Home Link. As a result, unless the node has a better (longest match) route to a given Mobile Network Prefix, it would lookup all MNNs on that MNP using Neighbor Discovery over its interface to the Home Link, and fail. []=20 > >>>Section 8.1, para. 12: >>> >>>> Note that the hierarchy occurs at a configuration level and may not >>>> be reflected in the actual connection between nodes. For instance in >>>> the Cab Co case, cabs are roaming within the city, each one attaching >>>> to a different hot spot, while the regional office is connected to >>>> the infrastructure using some ISP connection. >>> >>> Sorry, I don't understand what you want to say with the first >>> sentence of this paragraph. >>> >> [] Trying to say that the hierarchy is a configuration thing. >> Nothing to do with the way things will be interconnected. What about : >> Note that this is a hierarchy in terms of configuration, which may not >> be reflected in the actual connection between nodes. > >Mmm. Maybe. But I'm still not sure I understand it. Maybe two small >parallel examples are needed to illustrate the distinction. [] What about: " Note that this is a hierarchy in terms of configuration, which may not be reflected in the actual arrangement of nodes at a given point of time. For instance in the Cab Co case, some Cabs might roam to a different city, or even attach to the Headquarters. " > > >>>Section 8.1, para. 15: >>> >>>> If SFO is also the root-MR of a nested structure of cabs, the >>>> communication between cabs is relayed by SFO and does not require the >>>> satellite link. SFO recursively terminates the nested tunnels to the >>>> cabs and re-encapsulates all the packets between the nested cloud and >>>> correspondents in the infrastructure in a single tunnel to CA5A, this >>>> providing for nested NEMO Route Optimization. >>> >>> The difference between the two cases discussed here isn't too >>> clear to me. Does it consist only of where the tunnels are >>> terminated, or is there also a difference with respect to the >>> routing geometry (which nodes the traffic from the leaf nodes >>> pass through?) >>> >> [] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs >> belong to a same HA, then the HA terminates recursively a number of >> nested tunnels. Once the inner packet is obtained, SFO will pass it to >> CASA over its own MRHA tunnel. >> >> Some deployments failed to use that 'trick' causing extensive use of sat >> links. >> >> This is also an advantage of shared proxies in the global HAHA case. > >Ok, so the distinction is one of where the tunnels are terminated, then? >Avoiding unnecessary traffic up and back down over the common link is >a by-product of terminating the tunnels at the common HA, no? > >I think the text needs to be clearer here. > [] What about: If SFO is also the root-MR of a nested structure of its own cabs, the communication between cabs is relayed by SFO and does not require the satellite link. As of traffic to the outside of the nested NEMO, SFO recursively terminates the nested tunnels from its cabs and reencapsulates all the packets between the nested cloud and correspondents in the infrastructure in a single tunnel to CA5A. As a result, the unwanted effect of nesting of tunnels is avoided over the Internet part of the packet path. Thanks again :) Pascal From nemo-bounces@ietf.org Thu Sep 29 13:09:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1uM-00030v-Um; Thu, 29 Sep 2005 13:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1uL-00030n-6b for nemo@megatron.ietf.org; Thu, 29 Sep 2005 13:09:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22992 for ; Thu, 29 Sep 2005 13:09:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL220-0007gr-8n for nemo@ietf.org; Thu, 29 Sep 2005 13:17:18 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Sep 2005 19:09:11 +0200 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 j8TH94VP016692 for ; Thu, 29 Sep 2005 19:09:07 +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.0); Thu, 29 Sep 2005 19:09:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C518.7E7EFC3A" Date: Thu, 29 Sep 2005 19:08:57 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151AC79@xmb-ams-337.emea.cisco.com> Thread-Topic: solving Home Network models issue 7 Thread-Index: AcXFGHq4QRiZsohjT5qi0UyQ1S/SDQ== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 29 Sep 2005 17:09:04.0450 (UTC) FILETIME=[7EA42220:01C5C518] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Subject: [nemo] solving Home Network models issue 7 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C518.7E7EFC3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 I'm trying to get a consensus to solve issue 7: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mode= ls-issue7.txt=20 =20 The idea is to remove the text around going home in a virtual Home = network. This includes some text in the main document and the related = appendix. Thoughts anyone? =20 =20 =20 =20 Pascal Thubert software engineer=20 Cisco Systems Village d'Entreprises GREEN SIDE 400, Avenue Roumanille B=E2timent T3 06410 BIOT - Sophia-Antipolis=20 pthubert@cisco.com =20 tel:=20 mobile:=20 +33 4 97 23 26 34 +33 6 19 98 29 85=20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5C518.7E7EFC3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

I’m trying to get a consensus to solve = issue 7:

http://www.mobilenetworks.org/~pthubert/draft-ietf= -nemo-home-network-models-issue7.txt

 

The idea is to remove the text around going home in a virtual Home network. This includes some text in the main document and = the related appendix. Thoughts anyone?

 

 

 

 

Pascal Thubert
software = engineer

Cisco = Systems
Village d'Entreprises GREEN SIDE
400, Avenue Roumanille
B=E2timent T3
06410 BIOT - Sophia-Antipolis

pthubert@cisco.com

tel:
mobile:

+33 4 97 23 26 34
+33 6 19 98 29 85

 

 

 

 

 

------_=_NextPart_001_01C5C518.7E7EFC3A-- From nemo-bounces@ietf.org Thu Sep 29 13:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1wt-0003rg-Mt; Thu, 29 Sep 2005 13:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1wr-0003rY-5j for nemo@megatron.ietf.org; Thu, 29 Sep 2005 13:11:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23187 for ; Thu, 29 Sep 2005 13:11:53 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL24Y-0007mU-9e for nemo@ietf.org; Thu, 29 Sep 2005 13:19:54 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Sep 2005 19:11:49 +0200 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 j8THBeVT017458 for ; Thu, 29 Sep 2005 19:11:45 +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.0); Thu, 29 Sep 2005 19:11:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C518.DDF493AA" Date: Thu, 29 Sep 2005 19:11:41 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151AC7C@xmb-ams-337.emea.cisco.com> Thread-Topic: solving Home Network models issue 8 Thread-Index: AcXFGNxE0kj++Qx6Ts6trJ3wjS2TJw== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 29 Sep 2005 17:11:44.0666 (UTC) FILETIME=[DE2327A0:01C5C518] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Subject: [nemo] solving Home Network models issue 8 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C518.DDF493AA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 I'm trying to get a consensus to solve issue 8: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mode= ls-issue8.txt=20 =20 The idea is to add some text to say that we do not recommend forming a = home address from MNP in extended Home Network case. Thoughts anyone? =20 =20 =20 =20 =20 Pascal Thubert software engineer=20 Cisco Systems Village d'Entreprises GREEN SIDE 400, Avenue Roumanille B=E2timent T3 06410 BIOT - Sophia-Antipolis=20 pthubert@cisco.com =20 tel:=20 mobile:=20 +33 4 97 23 26 34 +33 6 19 98 29 85=20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5C518.DDF493AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

I’m trying to get a consensus to solve = issue 8:

http://www.mobilenetworks.org/~pthubert/draft-ietf= -nemo-home-network-models-issue8.txt

 

The idea is to add some text to say that we do not = recommend forming a home address from MNP in extended Home Network case. Thoughts = anyone?

 

 

 

 

 

Pascal Thubert
software = engineer

Cisco = Systems
Village d'Entreprises GREEN SIDE
400, Avenue Roumanille
B=E2timent T3
06410 BIOT - Sophia-Antipolis

pthubert@cisco.com

tel:
mobile:

+33 4 97 23 26 34
+33 6 19 98 29 85

 

 

 

 

 

------_=_NextPart_001_01C5C518.DDF493AA-- From nemo-bounces@ietf.org Thu Sep 29 14:17:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2xq-0005Jp-22; Thu, 29 Sep 2005 14:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2xo-0005JG-Bc for nemo@megatron.ietf.org; Thu, 29 Sep 2005 14:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26474 for ; Thu, 29 Sep 2005 14:16:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL35U-00011q-VF for nemo@ietf.org; Thu, 29 Sep 2005 14:24:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j8THeqO16072; Thu, 29 Sep 2005 10:40:52 -0700 X-mProtect: <200509291740> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdkIuWNd; Thu, 29 Sep 2005 10:40:50 PDT Message-ID: <433C2EFD.3060205@iprg.nokia.com> Date: Thu, 29 Sep 2005 11:14:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> <4314A955.5050906@iprg.nokia.com> <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> <1127911736.16351.108.camel@localhost.localdomain> In-Reply-To: <1127911736.16351.108.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Ralph Droms wrote: > (picking up an old thread; I'm revising draft-ietf-nemo-dhcpv6-pd-00.txt > based on these comments) > > On Tue, 2005-09-06 at 01:56 +0900, Ryuji Wakikawa wrote: > >>Hello Pascal and Vijay >> >>I read the draft and feel the same impression with Vijay. I agree >>with Vijay. >>The section 3.2 is not directly related to the NEMO PD. >>We had the consensus not to include local mobility management in >>DHCPv6PD >>at the Minneapolis meeting (forget maybe somewhere else). >> >>Here are more comments. >> >>Can MR can skip DHCP server discovery sending message to FF02::1:2 ? >>If MR knows the HA, MR can send request message to the HA without DR >>discovery. > > > I'm leery of making this fundamental change to the specification in RFC > 3315 without dhc WG review. > > Uf the goal is to reduce the number of messages exchanged, the Rapid > Commit option allows a 2 message exchange for PD. I am fine with this. Vijay From nemo-bounces@ietf.org Thu Sep 29 15:24:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL41R-0007dc-Fd; Thu, 29 Sep 2005 15:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL41O-0007dC-Km for nemo@megatron.ietf.org; Thu, 29 Sep 2005 15:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00340 for ; Thu, 29 Sep 2005 15:24:44 -0400 (EDT) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL495-0002Zw-Hn for nemo@ietf.org; Thu, 29 Sep 2005 15:32:45 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 3131837F90; Thu, 29 Sep 2005 21:24:21 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 19EE837F19; Thu, 29 Sep 2005 21:24:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8C0DA37E42; Thu, 29 Sep 2005 21:24:20 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EL40y-0007vh-6V; Thu, 29 Sep 2005 21:24:20 +0200 Message-ID: <433C3F63.3000205@levkowetz.com> Date: Thu, 29 Sep 2005 21:24:19 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC0151AC64@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0151AC64@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, on 2005-09-29 18:36 Pascal Thubert (pthubert) said the following: > > [] second round, same rules :) > >>>>Section 1., para. 2: >>>> >>>>> In order to read this document properly, the distinction between the >>>>> concepts of Home Link and of Home Network must be very clear. A Home >>>>> Link is a physical or a virtual Link, attached to a Home Agent. A >>>>> Home Network is an aggregation that can be further subnetted. As a >>>>> result, the Home Network is not necessarily contained on a Home Link. >>>>> In fact, the Mobile Network Prefixes are subnets of the Home Network. >>>>> How the two concepts relate in a given deployment depend on the >>>>> organization of the Home Network, as described below. >>>> >>>> Unfortunately, the above description does not at all make the >>>> distinction clear to me. Are the Home Network prefixes a subset of >>>> the Home Link prefixes? A superset? Or something else? I'm more >>>> confused after reading the above than before... >>> [] >>> [] The Home Network is a whole network whereas the Home Link just >>> has a subnet. The sentence that covers this is: >>> " the Home Network is not necessarily contained on a Home Link". >>> We can add a few words there to make it more specific like >>> >>> " the Home Network is not necessarily contained on a Home Link, but can >>> be distributed between the Home Link and the Mobile Networks" >>> >>> Is that better? >> >>Slightly, but not enough, I think. After trying out various formulations, >>I actually think it would be better to reduce the paragraph to this: >> >> In order to read this document properly, it is important to realise >> there is a distinction between the concepts of Home Link and Home >> Network, and in a NEMO context these may not at all be equivalent. >> How the two concepts relate in a given deployment depend on the >> organization of the Home Network, as described below. >> > > [] What about: > > In order to read this document properly, it is important to realize > that in a NEMO context, the Home Network is not bounded by the Home Link. > How the two concepts relate in a given deployment depends on the > organization of the Home Network, as described below. No - remember, this is at the very beginning of the document. Reading this would still leave me wondering - what is meant here - bounded? Physically? logically? prefix-wise? what?? My earlier suggestion still seems to me like a good one - would you consider it again? > >>>> >>>>Section 6.2.1, para. 6: >>>> >>>>> Figure 3: Bridging between egress and ingress >>>> >>>> I don't see the difference between Figure 2 and Figure 3. >>>> Should I? >>>> >>>> >>> [] We want to show the difference between fig 3 and fig 4 actually. >>> These are about how things actually plug physically. Fig 2 is a >>> configuration thing, stressing where the prefixes are assigned and it >>> compares to fig 1. I still think it's OK like that. Too many words might >>> clouds things even more, and bore some readers. >> >>The problem is that now a reader (at least this reader) is wondering why >>you don't just refer back to Fig. 2. So why not just refer back to Fig. 2? :-) >> > [] > > I see your point. 2 reasons, none great. First is that the picture is > collocated with the text so the reader does not have to search for it. > Second is that even is some actual drawing is the common, one refers to > configuration and the other to arrangement, per our agreed upon terms. > I'm afraid of an additional confusion if a same picture is used to > reflect the 2. No, that would be OK - now there is confusion because this reader doesn't understand what the difference is and why the need for another figure. >>>>Section 6.4.1, para. 1: >>>> >>>>> A node on the Home Link discovers that the Aggregated Home Network is >>>>> actually a subnet on the Home Link and may use the prefix on the Home >>>>> Link to autoconfigure a Home Address. Such a node may also install a >>>>> connected route to the Aggregated Home Network over the Home Link. >>>> >>>> I'm having a bit of trouble with the formulation here. Do you mean >>>> to say: >>>> "If a node were to discovers that the Aggregated Home Network is >>>> actually a subnet on the Home Link it might use the prefix on the >>>> Home Link to autoconfigure a Home Address. ..." ? >>>> - if so, maybe say that :-) and also adjust the rest of the text >>>> and the next paragraph accordingly. >>>> >>> [] Not necessarily a Home address. Just plug any Host on that link. >>> We meant something like this: >>> A node on the Home Link receiving a Router Advertisement that >>> includes the Aggregated Home Network prefix might use that prefix >>> for Address Autoconfiguration. Such a node may also install a >>> connected route to the Aggregated Home Network over the Home Link. >>> >>> As a result, unless the node has a better (longest match) route to >>> a given Mobile Network Prefix, it will lookup all MNNs on that MNP >>> using Neighbor Discovery over its interface to the Home Link. >> >>Ok. But you need to use 'might', 'would', 'could' etc. to distinguish >>this possible but undesirable behaviour from something which should be >>done. Looking forward to seeing some adjusted text. >> > [] Well, it is normal for a Node to autoconf, and the result is > undesirable in that case: > > A node on the Home Link receiving a Router Advertisement that includes the > Aggregated Home Network prefix might use that prefix for Address Autoconfiguration. > Such a node would also install a connected route to the Aggregated > Home Network over the Home Link. > > As a result, unless the node has a better (longest match) route to a given > Mobile Network Prefix, it would lookup all MNNs on that MNP using Neighbor Discovery > over its interface to the Home Link, and fail. Looks good to me. >> >>>>Section 8.1, para. 12: >>>> >>>>> Note that the hierarchy occurs at a configuration level and may not >>>>> be reflected in the actual connection between nodes. For instance in >>>>> the Cab Co case, cabs are roaming within the city, each one attaching >>>>> to a different hot spot, while the regional office is connected to >>>>> the infrastructure using some ISP connection. >>>> >>>> Sorry, I don't understand what you want to say with the first >>>> sentence of this paragraph. >>>> >>> [] Trying to say that the hierarchy is a configuration thing. >>> Nothing to do with the way things will be interconnected. What about : >>> Note that this is a hierarchy in terms of configuration, which may not >>> be reflected in the actual connection between nodes. >> >>Mmm. Maybe. But I'm still not sure I understand it. Maybe two small >>parallel examples are needed to illustrate the distinction. > [] What about: > " > Note that this is a hierarchy in terms of configuration, which may not > be reflected in the actual arrangement of nodes at a given point of time. > For instance in the Cab Co case, some Cabs might roam to a different city, > or even attach to the Headquarters. > " Ahh! *That* I can understand. Of course, I then wonder if that will actually work - what happens if a Cab attaches to a HA in a different city which doesn't have a matching prefix? >> >> >>>>Section 8.1, para. 15: >>>> >>>>> If SFO is also the root-MR of a nested structure of cabs, the >>>>> communication between cabs is relayed by SFO and does not require the >>>>> satellite link. SFO recursively terminates the nested tunnels to the >>>>> cabs and re-encapsulates all the packets between the nested cloud and >>>>> correspondents in the infrastructure in a single tunnel to CA5A, this >>>>> providing for nested NEMO Route Optimization. >>>> >>>> The difference between the two cases discussed here isn't too >>>> clear to me. Does it consist only of where the tunnels are >>>> terminated, or is there also a difference with respect to the >>>> routing geometry (which nodes the traffic from the leaf nodes >>>> pass through?) >>>> >>> [] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs >>> belong to a same HA, then the HA terminates recursively a number of >>> nested tunnels. Once the inner packet is obtained, SFO will pass it to >>> CASA over its own MRHA tunnel. >>> >>> Some deployments failed to use that 'trick' causing extensive use of sat >>> links. >>> >>> This is also an advantage of shared proxies in the global HAHA case. >> >>Ok, so the distinction is one of where the tunnels are terminated, then? >>Avoiding unnecessary traffic up and back down over the common link is >>a by-product of terminating the tunnels at the common HA, no? >> >>I think the text needs to be clearer here. >> > [] What about: > > If SFO is also the root-MR of a nested structure of its own cabs, the > communication between cabs is relayed by SFO and does not require the > satellite link. As of traffic to the outside of the nested NEMO, SFO > recursively terminates the nested tunnels from its cabs and reencapsulates > all the packets between the nested cloud and correspondents in the > infrastructure in a single tunnel to CA5A. As a result, the unwanted > effect of nesting of tunnels is avoided over the Internet part of the > packet path. Clearly better. In the second sentence, s/As of/As for/. Otherwise good. > Thanks again :) You're welcome! Henrik From nemo-bounces@ietf.org Thu Sep 29 19:59:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL8JL-000679-JP; Thu, 29 Sep 2005 19:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL8JK-00063x-Fi for nemo@megatron.ietf.org; Thu, 29 Sep 2005 19:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24337 for ; Thu, 29 Sep 2005 19:59:32 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL8R4-0004OB-GN for nemo@ietf.org; Thu, 29 Sep 2005 20:07:35 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 712C86625; Thu, 29 Sep 2005 16:56:27 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73346-03; Thu, 29 Sep 2005 16:56:26 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id D175F6623; Thu, 29 Sep 2005 16:56:26 -0700 (PDT) Received: from [10.0.0.72] (unknown [85.101.248.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 0ED8F60ED; Thu, 29 Sep 2005 16:56:23 -0700 (PDT) In-Reply-To: References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> <43255942.3030408@kddilabs.jp> <432569BD.5070201@motorola.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A109AE5-5DAC-4720-9677-2400CF1BFA47@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] RO solution space - CA is Certificate Authority Date: Fri, 30 Sep 2005 01:39:14 +0300 To: Fan Zhao X-Mailer: Apple Mail (2.734) X-Spam-Score: -3.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Sep 15, 2005, at 1:56 AM, Fan Zhao wrote: > On Mon, 12 Sep 2005, Alexandru Petrescu wrote: > > >> Masafumi Watari wrote: >> >>> On 2005/09/09 2:35, Alexandru Petrescu wrote: >>> >>> >>>> Pascal Thubert (pthubert) wrote: >>>> >>>> >>>>> Yes... OTOH, if there is a risk of a collision then we should >>>>> change. >>>>> And that might be the case here. What about Correspondent Side >>>>> Agent? >>>>> CSA also exists in France but I do not expect them to >>>>> participate to our >>>>> drafts :) >>>>> >>>> >>>> >>>> CSA Correspondent Side Agent is fine with me too, but sounds >>>> like it >>>> can't be the CN itself, sounds like it must be on its side >>>> somewhere, no? >>>> >>> >>> >>> I agree. In that sense, the term Agent to me sounds more like a >>> router >>> and not a host (as in HA/FA). If we are to avoid CN, I would also >>> suggest PN: Peer Node or RN: Remote Node or something like that. >>> >> >> Right, PN sounds better. >> > IMHO I think "agent" does not imply router or host, it totally > depends on how we are going to define it. In MIP4/6 (yes, a very > close field to NEMO) HA/FA is defined as a router, but there are > many terms like mobile agent, software agent in other fields. > Thus I think a clear definition > that CA could be either router or host should be ok from my side. > There hasn't been any more discussion on this topic, so I don't know what the resolution was. Just remember, an agent is defined as an entity that does something on behalf of someone else. So it would be quite rare for a CN to be an agent for itself. That is probably why Alexandru made the comment that an agent sounds more like a router than a host. What do the authors want to do to resolve this naming question? From nemo-bounces@ietf.org Thu Sep 29 22:37:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELAlr-0000Z3-KJ; Thu, 29 Sep 2005 22:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELAln-0000Yo-H8 for nemo@megatron.ietf.org; Thu, 29 Sep 2005 22:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00216 for ; Thu, 29 Sep 2005 22:37:04 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELAtY-0007bQ-Dg for nemo@ietf.org; Thu, 29 Sep 2005 22:45:10 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j8U2ZMf6000112; Fri, 30 Sep 2005 11:35:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j8U2ZN604392; Fri, 30 Sep 2005 11:35:23 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j8U2ZMM27641; Fri, 30 Sep 2005 11:35:22 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Sep 2005 10:32:56 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 5B9BD20AC0C; Fri, 30 Sep 2005 10:34:09 +0800 (SGT) Subject: Re: [nemo] RO solution space - CA is Certificate Authority From: Chan-Wah Ng To: "T.J. Kniveton" In-Reply-To: <2A109AE5-5DAC-4720-9677-2400CF1BFA47@kniveton.com> References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> <43255942.3030408@kddilabs.jp> <432569BD.5070201@motorola.com> <2A109AE5-5DAC-4720-9677-2400CF1BFA47@kniveton.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 30 Sep 2005 10:34:09 +0800 Message-Id: <1128047649.8910.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 30 Sep 2005 02:32:57.0035 (UTC) FILETIME=[446EE9B0:01C5C567] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Fri, 2005-09-30 at 01:39 +0300, T.J. Kniveton wrote: > On Sep 15, 2005, at 1:56 AM, Fan Zhao wrote: > > > On Mon, 12 Sep 2005, Alexandru Petrescu wrote: > >> Masafumi Watari wrote: > >> > >>> On 2005/09/09 2:35, Alexandru Petrescu wrote: > >>> > >>>> Pascal Thubert (pthubert) wrote: > >>>>> Yes... OTOH, if there is a risk of a collision then we should > >>>>> change. > >>>>> And that might be the case here. What about Correspondent Side > >>>>> Agent? > >>>>> CSA also exists in France but I do not expect them to > >>>>> participate to our > >>>>> drafts :) > >>>> > >>>> CSA Correspondent Side Agent is fine with me too, but sounds > >>>> like it > >>>> can't be the CN itself, sounds like it must be on its side > >>>> somewhere, no? > >>> > >>> I agree. In that sense, the term Agent to me sounds more like a > >>> router > >>> and not a host (as in HA/FA). If we are to avoid CN, I would also > >>> suggest PN: Peer Node or RN: Remote Node or something like that. > >> > >> Right, PN sounds better. > >> > > IMHO I think "agent" does not imply router or host, it totally > > depends on how we are going to define it. In MIP4/6 (yes, a very > > close field to NEMO) HA/FA is defined as a router, but there are > > many terms like mobile agent, software agent in other fields. > > Thus I think a clear definition > > that CA could be either router or host should be ok from my side. > > > > There hasn't been any more discussion on this topic, so I don't know > what the resolution was. Just remember, an agent is defined as an > entity that does something on behalf of someone else. So it would be > quite rare for a CN to be an agent for itself. That is probably why > Alexandru made the comment that an agent sounds more like a router > than a host. > > What do the authors want to do to resolve this naming question? > As far as i see, we have a few different alternatives: - Correspondent Entity (CE) - Peer Node/Entity (PN/PE) - Remote Node/Entity (RN/RE) I personally would go for CE, seeing as it resembles CN. Base on all posts in the ML, I see no strong position against using CE. So, I would use the term CE to replace CA if there is no strong opposition from now til -01 is published. /rgds /cwng From nemo-bounces@ietf.org Fri Sep 30 05:06:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELGqh-0002yZ-Tr; Fri, 30 Sep 2005 05:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELGqg-0002y2-9F for nemo@megatron.ietf.org; Fri, 30 Sep 2005 05:06:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00024 for ; Fri, 30 Sep 2005 05:06:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELGyV-00089g-Ng for nemo@ietf.org; Fri, 30 Sep 2005 05:14:40 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Sep 2005 11:06:26 +0200 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 j8U967Vb028998; Fri, 30 Sep 2005 11:06:22 +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.0); Fri, 30 Sep 2005 11:06:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Fri, 30 Sep 2005 11:06:05 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0151AE71@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXFK7QYgJx8IrhNTmeEn2/jsLEtfAAcHuZQ From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 30 Sep 2005 09:06:09.0711 (UTC) FILETIME=[32C393F0:01C5C59E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >>>>>Section 1., para. 2: >>>>> >>>>>> In order to read this document properly, the distinction between the >>>>>> concepts of Home Link and of Home Network must be very clear. A Home >>>>>> Link is a physical or a virtual Link, attached to a Home Agent. A >>>>>> Home Network is an aggregation that can be further subnetted. As a >>>>>> result, the Home Network is not necessarily contained on a Home Link. >>>>>> In fact, the Mobile Network Prefixes are subnets of the Home Network. >>>>>> How the two concepts relate in a given deployment depend on the >>>>>> organization of the Home Network, as described below. >>>>> >>>>> Unfortunately, the above description does not at all make the >>>>> distinction clear to me. Are the Home Network prefixes a subset of >>>>> the Home Link prefixes? A superset? Or something else? I'm more >>>>> confused after reading the above than before... >>>> [] >>>> [] The Home Network is a whole network whereas the Home Link just >>>> has a subnet. The sentence that covers this is: >>>> " the Home Network is not necessarily contained on a Home Link". >>>> We can add a few words there to make it more specific like >>>> >>>> " the Home Network is not necessarily contained on a Home Link, but can >>>> be distributed between the Home Link and the Mobile Networks" >>>> >>>> Is that better? >>> >>>Slightly, but not enough, I think. After trying out various formulations, >>>I actually think it would be better to reduce the paragraph to this: >>> >>> In order to read this document properly, it is important to realise >>> there is a distinction between the concepts of Home Link and Home >>> Network, and in a NEMO context these may not at all be equivalent. >>> How the two concepts relate in a given deployment depend on the >>> organization of the Home Network, as described below. >>> >> >> [] What about: >> >> In order to read this document properly, it is important to realize >> that in a NEMO context, the Home Network is not bounded by the Home Link. >> How the two concepts relate in a given deployment depends on the >> organization of the Home Network, as described below. > >No - remember, this is at the very beginning of the document. Reading this >would still leave me wondering - what is meant here - bounded? Physically? >logically? prefix-wise? what?? > >My earlier suggestion still seems to me like a good one - would you consider >it again? [] The problem that I tried to change was in the comparison of a Link (usually a L2 term) and a Network (usually a L3 term). I wanted to say that in MIP, the Network overlaps with - is congruent to, whatever - the Link. But in NEMO, the network is much wider as it spans the Home Link and all the Links that the MRs carry with them. =20 Could you then reword a bit? > >> >>>>> >>>>>Section 6.2.1, para. 6: >>>>> >>>>>> Figure 3: Bridging between egress and ingress >>>>> >>>>> I don't see the difference between Figure 2 and Figure 3. >>>>> Should I? >>>>> >>>>> >>>> [] We want to show the difference between fig 3 and fig 4 actually. >>>> These are about how things actually plug physically. Fig 2 is a >>>> configuration thing, stressing where the prefixes are assigned and it >>>> compares to fig 1. I still think it's OK like that. Too many words might >>>> clouds things even more, and bore some readers. >>> >>>The problem is that now a reader (at least this reader) is wondering why >>>you don't just refer back to Fig. 2. So why not just refer back to Fig. 2? :-) >>> >> [] >> >> I see your point. 2 reasons, none great. First is that the picture is >> collocated with the text so the reader does not have to search for it. >> Second is that even is some actual drawing is the common, one refers to >> configuration and the other to arrangement, per our agreed upon terms. >> I'm afraid of an additional confusion if a same picture is used to >> reflect the 2. > >No, that would be OK - now there is confusion because this reader doesn't >understand what the difference is and why the need for another figure. [] Or we can change the figures to reflect the fact that one is config and the other arrangement? []=20 > >> Note that this is a hierarchy in terms of configuration, which may not >> be reflected in the actual arrangement of nodes at a given point of time. >> For instance in the Cab Co case, some Cabs might roam to a different city, >> or even attach to the Headquarters. >> " > >Ahh! *That* I can understand. > >Of course, I then wonder if that will actually work - what happens if a Cab >attaches to a HA in a different city which doesn't have a matching prefix? [] Attaching is building a CoA, not binding. The CoA is formed from a prefix that is exposed by another city, and globally reachable, so it works. In terms of tunnels, it is an interesting story :) I have deployed the whole thing using my implementation to check the configuration. It works, cabs can be attached to other cabs, etc... When you add RRH to the picture, you can even have SFO attach to one of its cabs :) Thanks again :) Pascal From nemo-bounces@ietf.org Fri Sep 30 13:29:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOhM-00047t-EL; Fri, 30 Sep 2005 13:29:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOhK-00047j-L7 for nemo@megatron.ietf.org; Fri, 30 Sep 2005 13:29:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22097 for ; Fri, 30 Sep 2005 13:29:23 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELOpC-0002nM-SE for nemo@ietf.org; Fri, 30 Sep 2005 13:37:37 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 03CF16625; Fri, 30 Sep 2005 10:26:22 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81872-06; Fri, 30 Sep 2005 10:26:21 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 69FD46623; Fri, 30 Sep 2005 10:26:21 -0700 (PDT) Received: from [10.0.0.73] (unknown [85.101.248.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id DCB12619A; Fri, 30 Sep 2005 10:26:19 -0700 (PDT) In-Reply-To: <1128047649.8910.33.camel@localhost> References: <7892795E1A87F04CADFCCF41FADD00FC0140C3BA@xmb-ams-337.emea.cisco.com> <43207663.2030704@motorola.com> <43255942.3030408@kddilabs.jp> <432569BD.5070201@motorola.com> <2A109AE5-5DAC-4720-9677-2400CF1BFA47@kniveton.com> <1128047649.8910.33.camel@localhost> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10ACB6F2-1D1F-4A26-A3AA-D8354B24BA4E@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] RO solution space - CA is Certificate Authority Date: Fri, 30 Sep 2005 20:29:10 +0300 To: Chan-Wah Ng X-Mailer: Apple Mail (2.734) X-Spam-Score: -2.7 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Sep 30, 2005, at 5:34 AM, Chan-Wah Ng wrote: > On Fri, 2005-09-30 at 01:39 +0300, T.J. Kniveton wrote: > > >> >> There hasn't been any more discussion on this topic, so I don't know >> what the resolution was. Just remember, an agent is defined as an >> entity that does something on behalf of someone else. So it would be >> quite rare for a CN to be an agent for itself. That is probably why >> Alexandru made the comment that an agent sounds more like a router >> than a host. >> >> What do the authors want to do to resolve this naming question? >> >> >> > > As far as i see, we have a few different alternatives: > > - Correspondent Entity (CE) > - Peer Node/Entity (PN/PE) > - Remote Node/Entity (RN/RE) > > I personally would go for CE, seeing as it resembles CN. Base on all > posts in the ML, I see no strong position against using CE. > > So, I would use the term CE to replace CA if there is no strong > opposition from now til -01 is published. > My personal opinion: I don't like using the word "entity". It is a synonym for "thing" and doesn't really add any meaning to a phrase. OTOH, I don't have any alternative that springs to mind. TJ