From nemo-admin@ietf.org Tue Jul 1 01:14:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01954 for ; Tue, 1 Jul 2003 01:14:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDSq-00038f-Ub; Tue, 01 Jul 2003 01:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDSO-00038T-Bl for nemo@optimus.ietf.org; Tue, 01 Jul 2003 01:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01899 for ; Tue, 1 Jul 2003 01:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XDSC-0007Dr-00 for nemo@ietf.org; Tue, 01 Jul 2003 01:13:20 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19XDS0-0007Cq-00 for nemo@ietf.org; Tue, 01 Jul 2003 01:13:09 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h6154n407084; Tue, 1 Jul 2003 13:04:49 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 8791B10E95DA; Tue, 1 Jul 2003 13:12:00 +0800 (SGT) Subject: Re: [nemo] Vienna Agenda From: Chan-Wah Ng To: Thierry Ernst Cc: IETF NEMO WG , "T.J. Kniveton" In-Reply-To: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1057036320.1483.11.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 01 Jul 2003 13:12:00 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Thierry and T.J., I'll like to request a slot for discussion on multi-homing issues in the Vienna Meeting. One more thing, I understand the basic solution will be the most important agenda item. Julien is actually finishing a multihoming evaluation of the basic solution. So I don't know if its okay for me to talk about that within the slot in Vienna. We have missed the I-D publish deadline, but will make it available for public viewing via a URL. /rgds /cwng On Mon, 2003-06-02 at 16:56, Thierry Ernst wrote: > Dear all, > > The Vienna meeting is fast approaching and we need to set up an agenda. > > Before we request a time slot, could you please let us know what items > should be added on the agenda in addition to the ones below. Please > motivate your request and let us know about drafts, if any, that the > discussion would be based on. > > # Definitely on the agenda > o Terminology and Requirements > draft-ietf-nemo-requirements-01.txt > draft-ietf-nemo-terminology-00.txt > - comments > - what to do next > > o Report from the Design Team > draft-ietf-nemo-????? > - status / consensus > - draft ? > > # Might be good to speak about: > - multihoming > Based on the active discussion on the mailing list, I guess a discussion > on multihoming would be useful. > > - Threat analysis L > Let me remind you "threat analysis" is one of our milestones, is there > is any input regarding this ? That would be MORE than highly appreciated. > > The chairs. > > > > > > From exim@www1.ietf.org Tue Jul 1 01:14:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01969 for ; Tue, 1 Jul 2003 01:14:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h615EAv12118 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 01:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDT0-00039N-BV for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 01:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01914 for ; Tue, 1 Jul 2003 01:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XDSx-0007ED-00 for nemo-web-archive@ietf.org; Tue, 01 Jul 2003 01:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XDSs-0007EA-00 for nemo-web-archive@ietf.org; Tue, 01 Jul 2003 01:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDSq-00038f-Ub; Tue, 01 Jul 2003 01:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDSO-00038T-Bl for nemo@optimus.ietf.org; Tue, 01 Jul 2003 01:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01899 for ; Tue, 1 Jul 2003 01:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XDSC-0007Dr-00 for nemo@ietf.org; Tue, 01 Jul 2003 01:13:20 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19XDS0-0007Cq-00 for nemo@ietf.org; Tue, 01 Jul 2003 01:13:09 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h6154n407084; Tue, 1 Jul 2003 13:04:49 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 8791B10E95DA; Tue, 1 Jul 2003 13:12:00 +0800 (SGT) Subject: Re: [nemo] Vienna Agenda From: Chan-Wah Ng To: Thierry Ernst Cc: IETF NEMO WG , "T.J. Kniveton" In-Reply-To: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1057036320.1483.11.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 01 Jul 2003 13:12:00 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Thierry and T.J., I'll like to request a slot for discussion on multi-homing issues in the Vienna Meeting. One more thing, I understand the basic solution will be the most important agenda item. Julien is actually finishing a multihoming evaluation of the basic solution. So I don't know if its okay for me to talk about that within the slot in Vienna. We have missed the I-D publish deadline, but will make it available for public viewing via a URL. /rgds /cwng On Mon, 2003-06-02 at 16:56, Thierry Ernst wrote: > Dear all, > > The Vienna meeting is fast approaching and we need to set up an agenda. > > Before we request a time slot, could you please let us know what items > should be added on the agenda in addition to the ones below. Please > motivate your request and let us know about drafts, if any, that the > discussion would be based on. > > # Definitely on the agenda > o Terminology and Requirements > draft-ietf-nemo-requirements-01.txt > draft-ietf-nemo-terminology-00.txt > - comments > - what to do next > > o Report from the Design Team > draft-ietf-nemo-????? > - status / consensus > - draft ? > > # Might be good to speak about: > - multihoming > Based on the active discussion on the mailing list, I guess a discussion > on multihoming would be useful. > > - Threat analysis L > Let me remind you "threat analysis" is one of our milestones, is there > is any input regarding this ? That would be MORE than highly appreciated. > > The chairs. > > > > > > From nemo-admin@ietf.org Tue Jul 1 08:40:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15998 for ; Tue, 1 Jul 2003 08:40:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKQT-0003dy-7f; Tue, 01 Jul 2003 08:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKQ0-0003dF-S8 for nemo@optimus.ietf.org; Tue, 01 Jul 2003 08:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15963 for ; Tue, 1 Jul 2003 08:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XKPz-0003yP-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:39:31 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19XKPo-0003xs-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:39:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h61Ccv6M000705; Tue, 1 Jul 2003 05:38:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h61Ba2rN017986; Tue, 1 Jul 2003 06:36:03 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BB5542EC86; Tue, 1 Jul 2003 14:38:52 +0200 (CEST) Message-ID: <3F0180DC.2090401@motorola.com> Date: Tue, 01 Jul 2003 14:38:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Chan-Wah Ng , MATSUMOTO Taisuke , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> <3EFC7CF5.C9EEBCC@iprg.nokia.com> In-Reply-To: <3EFC7CF5.C9EEBCC@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > >> Should HA respond to RS on behalf of MR if the R-bit was set in the >> BU? Regardless of the answer, this need to be explained in the >> Draft, IMHO. > > > RS is typically sent to the all routers multicast address. it is not > sent to a particular address. I was thinking that a neighbour on the home link might target a RS to a specific IP address (not multicast), sometimes. > so there is no question of HA responding to an RS on MR's behalf. Maybe it is worth considering that HA joins the multicast groups at home to which the MR joined prior to movement. That means that HA replies to neighbours requesting info about the MR. One might consider "Reachable Time" as a value in the RA sent by HA on behalf of MR in order to gracefully indicate the neighbouring nodes on the home link that MR is gone and that HA takes its place. > and anyway this information is useless. One might also want to consider what are the interactions of HA sending RA on behalf of MR, and the Mobile Prefix Solicitation mechanisms of Mobile IPv6. Alex GBU From exim@www1.ietf.org Tue Jul 1 08:41:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16071 for ; Tue, 1 Jul 2003 08:41:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61CeeU14202 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 08:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKR6-0003gz-7b for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 08:40:40 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15999 for ; Tue, 1 Jul 2003 08:40:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKQT-0003dy-7f; Tue, 01 Jul 2003 08:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKQ0-0003dF-S8 for nemo@optimus.ietf.org; Tue, 01 Jul 2003 08:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15963 for ; Tue, 1 Jul 2003 08:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XKPz-0003yP-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:39:31 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19XKPo-0003xs-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:39:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h61Ccv6M000705; Tue, 1 Jul 2003 05:38:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h61Ba2rN017986; Tue, 1 Jul 2003 06:36:03 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BB5542EC86; Tue, 1 Jul 2003 14:38:52 +0200 (CEST) Message-ID: <3F0180DC.2090401@motorola.com> Date: Tue, 01 Jul 2003 14:38:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Chan-Wah Ng , MATSUMOTO Taisuke , IETF NEMO WG Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> <3EFC7CF5.C9EEBCC@iprg.nokia.com> In-Reply-To: <3EFC7CF5.C9EEBCC@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > >> Should HA respond to RS on behalf of MR if the R-bit was set in the >> BU? Regardless of the answer, this need to be explained in the >> Draft, IMHO. > > > RS is typically sent to the all routers multicast address. it is not > sent to a particular address. I was thinking that a neighbour on the home link might target a RS to a specific IP address (not multicast), sometimes. > so there is no question of HA responding to an RS on MR's behalf. Maybe it is worth considering that HA joins the multicast groups at home to which the MR joined prior to movement. That means that HA replies to neighbours requesting info about the MR. One might consider "Reachable Time" as a value in the RA sent by HA on behalf of MR in order to gracefully indicate the neighbouring nodes on the home link that MR is gone and that HA takes its place. > and anyway this information is useless. One might also want to consider what are the interactions of HA sending RA on behalf of MR, and the Mobile Prefix Solicitation mechanisms of Mobile IPv6. Alex GBU From nemo-admin@ietf.org Tue Jul 1 08:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16284 for ; Tue, 1 Jul 2003 08:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKWG-0003rU-Ha; Tue, 01 Jul 2003 08:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKVe-0003r3-P8 for nemo@optimus.ietf.org; Tue, 01 Jul 2003 08:45:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16220 for ; Tue, 1 Jul 2003 08:45:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XKVd-000437-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:45:21 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19XKVS-000434-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:45:10 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h61Cixj1020053; Tue, 1 Jul 2003 05:44:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h61CisSR022131; Tue, 1 Jul 2003 07:44:56 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 13C082EC86; Tue, 1 Jul 2003 14:44:54 +0200 (CEST) Message-ID: <3F018245.4020203@motorola.com> Date: Tue, 01 Jul 2003 14:44:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? References: <3F00E142.9090500@eng.monash.edu.au> In-Reply-To: <3F00E142.9090500@eng.monash.edu.au> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greg Daley wrote: >> - Where should the HA be placed, in DMZ or something? > > > This is worth consideration. I think that if we're talking about > Basic NEMO with bidirectional IKE/ESP tunnels, then we have no > greater risk to the network from attacks occurring on the NEMO from > the Internet. We're possibly providing carriage for untrusted hosts > though, which significantly changes how we'd handle things compared > to MIPv6. I think there is a direct relationship between the possibility of HA being placed in the DMZ and the possibility that HA does not perform proxy Neighbour Discovery on behalf of the Mobile Router's Home Address. I mean, it is highly probable that if HA doesn't perform proxy ND then HA can be placed in the DMZ. And, if HA performs proxy ND then HA can't be placed in the DMZ. Alex GBU From exim@www1.ietf.org Tue Jul 1 08:46:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16334 for ; Tue, 1 Jul 2003 08:46:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61CkVo14945 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 08:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKWl-0003sy-Jg for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 08:46:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16285 for ; Tue, 1 Jul 2003 08:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKWG-0003rU-Ha; Tue, 01 Jul 2003 08:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKVe-0003r3-P8 for nemo@optimus.ietf.org; Tue, 01 Jul 2003 08:45:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16220 for ; Tue, 1 Jul 2003 08:45:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XKVd-000437-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:45:21 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19XKVS-000434-00 for nemo@ietf.org; Tue, 01 Jul 2003 08:45:10 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h61Cixj1020053; Tue, 1 Jul 2003 05:44:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h61CisSR022131; Tue, 1 Jul 2003 07:44:56 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 13C082EC86; Tue, 1 Jul 2003 14:44:54 +0200 (CEST) Message-ID: <3F018245.4020203@motorola.com> Date: Tue, 01 Jul 2003 14:44:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? References: <3F00E142.9090500@eng.monash.edu.au> In-Reply-To: <3F00E142.9090500@eng.monash.edu.au> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg Daley wrote: >> - Where should the HA be placed, in DMZ or something? > > > This is worth consideration. I think that if we're talking about > Basic NEMO with bidirectional IKE/ESP tunnels, then we have no > greater risk to the network from attacks occurring on the NEMO from > the Internet. We're possibly providing carriage for untrusted hosts > though, which significantly changes how we'd handle things compared > to MIPv6. I think there is a direct relationship between the possibility of HA being placed in the DMZ and the possibility that HA does not perform proxy Neighbour Discovery on behalf of the Mobile Router's Home Address. I mean, it is highly probable that if HA doesn't perform proxy ND then HA can be placed in the DMZ. And, if HA performs proxy ND then HA can't be placed in the DMZ. Alex GBU From sip-admin@ietf.org Tue Jul 1 09:02:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17646 for ; Tue, 1 Jul 2003 09:02:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKlM-0005lS-Mq for nemo-archive@lists.ietf.org; Tue, 01 Jul 2003 09:01:36 -0400 Date: Tue, 01 Jul 2003 09:01:36 -0400 Message-ID: <20030701130136.18162.47921.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From exim@www1.ietf.org Tue Jul 1 09:16:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22209 for ; Tue, 1 Jul 2003 09:16:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61DG1925921 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 09:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKzJ-0006k0-O4 for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 09:16:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22050 for ; Tue, 1 Jul 2003 09:15:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKyp-0006RM-ED for nemo-web-archive@ietf.org; Tue, 01 Jul 2003 09:15:31 -0400 Date: Tue, 01 Jul 2003 09:15:31 -0400 Message-ID: <20030701131531.18162.41954.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From nemo-admin@ietf.org Tue Jul 1 09:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25562 for ; Tue, 1 Jul 2003 09:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLC0-0004v7-BX; Tue, 01 Jul 2003 09:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLBJ-0004ZY-6i for nemo@optimus.ietf.org; Tue, 01 Jul 2003 09:28:25 -0400 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25269 for ; Tue, 1 Jul 2003 09:28:21 -0400 (EDT) Received: from localhost (unknown [203.178.138.13]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 8DCDF5D020; Tue, 1 Jul 2003 22:27:50 +0900 (JST) Date: Tue, 1 Jul 2003 22:27:50 +0900 From: Julien Charbon To: IETF NEMO WG Cc: Chan-Wah Ng , Koshiro Mitsuya , Thierry Ernst Message-Id: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, We have written an Internet-Draft on the evaluation of Multi-homing support by NEMO Basic solution. You can check this draft at this URL: [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt] The Cut-off Internet Draft for initial document (-00) submission is over for the 57th IETF Meeting [23th of June]. But we want to open it up for comments to facilitate further discussions. Thanks. -- Julien Charbon & Chan-Wah Ng From exim@www1.ietf.org Tue Jul 1 09:30:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25692 for ; Tue, 1 Jul 2003 09:30:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61DTdg19827 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 09:29:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLCV-00059f-07 for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 09:29:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25563 for ; Tue, 1 Jul 2003 09:29:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLC0-0004v7-BX; Tue, 01 Jul 2003 09:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLBJ-0004ZY-6i for nemo@optimus.ietf.org; Tue, 01 Jul 2003 09:28:25 -0400 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25269 for ; Tue, 1 Jul 2003 09:28:21 -0400 (EDT) Received: from localhost (unknown [203.178.138.13]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 8DCDF5D020; Tue, 1 Jul 2003 22:27:50 +0900 (JST) Date: Tue, 1 Jul 2003 22:27:50 +0900 From: Julien Charbon To: IETF NEMO WG Cc: Chan-Wah Ng , Koshiro Mitsuya , Thierry Ernst Message-Id: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, We have written an Internet-Draft on the evaluation of Multi-homing support by NEMO Basic solution. You can check this draft at this URL: [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt] The Cut-off Internet Draft for initial document (-00) submission is over for the 57th IETF Meeting [23th of June]. But we want to open it up for comments to facilitate further discussions. Thanks. -- Julien Charbon & Chan-Wah Ng From nemo-admin@ietf.org Tue Jul 1 12:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06704 for ; Tue, 1 Jul 2003 12:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XO6q-0005oS-Ue; Tue, 01 Jul 2003 12:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XO5t-0005gm-Dj for nemo@optimus.ietf.org; Tue, 01 Jul 2003 12:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06655 for ; Tue, 1 Jul 2003 12:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XO5p-0006Fy-00 for nemo@ietf.org; Tue, 01 Jul 2003 12:34:57 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19XO5e-0006FL-00 for nemo@ietf.org; Tue, 01 Jul 2003 12:34:47 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61GWhIn006738 for ; Tue, 1 Jul 2003 09:32:44 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-19.cisco.com [10.82.224.19]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI78303; Tue, 1 Jul 2003 12:32:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Jul 2003 12:30:16 -0400 To: From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , All, Following up on our conversation a couple of months ago about using DHCPv6 PD for prefix delegation to mobile routers, I've published "DHCPv6 Prefix Delegation for NEMO" . This draft describes the use of DHCPv6 to meet my understanding of the requirements for prefix delegation to mobile routers. Comments welcome... - Ralph From exim@www1.ietf.org Tue Jul 1 12:36:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06725 for ; Tue, 1 Jul 2003 12:36:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61GaKg22428 for nemo-archive@odin.ietf.org; Tue, 1 Jul 2003 12:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XO7A-0005pf-LL for nemo-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 12:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06678 for ; Tue, 1 Jul 2003 12:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XO77-0006GY-00 for nemo-web-archive@ietf.org; Tue, 01 Jul 2003 12:36:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XO71-0006GR-00 for nemo-web-archive@ietf.org; Tue, 01 Jul 2003 12:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XO6q-0005oS-Ue; Tue, 01 Jul 2003 12:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XO5t-0005gm-Dj for nemo@optimus.ietf.org; Tue, 01 Jul 2003 12:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06655 for ; Tue, 1 Jul 2003 12:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XO5p-0006Fy-00 for nemo@ietf.org; Tue, 01 Jul 2003 12:34:57 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19XO5e-0006FL-00 for nemo@ietf.org; Tue, 01 Jul 2003 12:34:47 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61GWhIn006738 for ; Tue, 1 Jul 2003 09:32:44 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-19.cisco.com [10.82.224.19]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAI78303; Tue, 1 Jul 2003 12:32:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Jul 2003 12:30:16 -0400 To: From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , All, Following up on our conversation a couple of months ago about using DHCPv6 PD for prefix delegation to mobile routers, I've published "DHCPv6 Prefix Delegation for NEMO" . This draft describes the use of DHCPv6 to meet my understanding of the requirements for prefix delegation to mobile routers. Comments welcome... - Ralph From exim@www1.ietf.org Tue Jul 1 13:48:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08455 for ; Tue, 1 Jul 2003 13:48:19 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R4HCp10331 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 00:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vkfg-0002gY-IS for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 00:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04228 for ; Fri, 27 Jun 2003 00:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vkfe-00011U-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 00:17:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VkfY-00011R-00 for nemo-web-archive@ietf.org; Fri, 27 Jun 2003 00:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VkfV-0002fk-IB; Fri, 27 Jun 2003 00:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vkf0-0002Mp-Hh for nemo@optimus.ietf.org; Fri, 27 Jun 2003 00:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04210 for ; Fri, 27 Jun 2003 00:16:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vkej-000114-00 for nemo@ietf.org; Fri, 27 Jun 2003 00:16:13 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19VkeY-00010o-00 for nemo@ietf.org; Fri, 27 Jun 2003 00:16:02 -0400 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KXLBQ5WMZ89B933S@vaxh.its.monash.edu.au> for nemo@ietf.org; Fri, 27 Jun 2003 14:15:19 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 00D6D12C028; Fri, 27 Jun 2003 14:15:18 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id CF04612C01F; Fri, 27 Jun 2003 14:15:17 +1000 (EST) Date: Fri, 27 Jun 2003 14:15:17 +1000 From: Greg Daley Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: Vijay Devarapalli Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EFBC4D5.2090703@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Vijay, Vijay Devarapalli wrote: > Greg Daley wrote: > >>Do you think that we need to handle multicast >>issues for hosts on the NEMO in the base draft? > > > I dont think so. I think more work needs to be done > on this and is best handled through a separate > specification. Good. That's what I was checking. > >>I was thinking that getting Multicast ironed out >>for moving hosts (rather than networks) would be a >>good idea first, > > > you mean for MIPv6 mobile nodes? if yes, I guess > Mobile IPv6 would be the right WG for this work. Actually, it may even be a MAGMA issue since there's no global signalling (but certainly not NEMO yet). >>and then see if we need a document >>on multicast routing or multicast-ro. >> >>Maybe we just need to add a line regarding multicast >>routing protocols on the MR to section 8? > > > for this you would need both the Home Agent and the > Mobile Router to run a multicast routing protocol. I > am not sure if we should talk about it in the basic > support draft.... OK. We'll let people read between the lines when it says "dynamic routing protocol". I've been having a think about this issue too, and may get a short draft out after the meeting. Greg From exim@www1.ietf.org Tue Jul 1 13:48:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08417 for ; Tue, 1 Jul 2003 13:48:15 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIeNi19783 for nemo-archive@odin.ietf.org; Fri, 27 Jun 2003 14:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy8m-0004yy-P9 for nemo-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:40:23 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11977 for ; Fri, 27 Jun 2003 14:40:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7x-0004JC-3I; Fri, 27 Jun 2003 14:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VwvS-0002RS-Sk for nemo@optimus.ietf.org; Fri, 27 Jun 2003 13:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08021 for ; Fri, 27 Jun 2003 13:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VwvQ-0004oS-00 for nemo@ietf.org; Fri, 27 Jun 2003 13:22:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19VwvA-0004oC-00 for nemo@ietf.org; Fri, 27 Jun 2003 13:22:01 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20174; Fri, 27 Jun 2003 10:20:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5RHKsx13191; Fri, 27 Jun 2003 10:20:54 -0700 X-mProtect: <200306271720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRVWPl2; Fri, 27 Jun 2003 10:20:52 PDT Message-ID: <3EFC7CF5.C9EEBCC@iprg.nokia.com> Date: Fri, 27 Jun 2003 10:20:53 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: MATSUMOTO Taisuke , IETF NEMO WG , Alexandru Petrescu Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <1056428391.1789.56.camel@beethoven> <3EF849C3.9080502@motorola.com> <200306241452.h5OEqapB025063@mrit.mrit.mei.co.jp> <3EF86F27.9010402@motorola.com> <200306250157.h5P1vEpB090502@mrit.mrit.mei.co.jp> <1056682489.1485.44.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Should HA respond to RS on behalf of MR if the R-bit was set in the BU? > Regardless of the answer, this need to be explained in the Draft, IMHO. RS is typically sent to the all routers multicast address. it is not sent to a particular address. so there is no question of HA responding to an RS on MR's behalf. and anyway this information is useless. > Should the HA broadcast a RA on behalf of MR if the R-bit was set in the > BU? no. the MR is not on the home link. there is no point. > Or should the MR send RA broadcast to the home link via the MRHA > tunnel? it could. but the information is useless again. the HA cant do anything with it. > I think it was suggested in the Draft that MR may do so, > provided the Lifetime field is set to 0. this is when the MR is at home and sends a RA on the link with which it is connected to the home link. the router lifetime is set to 0, so that no other node configures the MR as a default router. Vijay From nemo-admin@ietf.org Wed Jul 2 05:38:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29711 for ; Wed, 2 Jul 2003 05:38:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe2v-0007uh-Gt; Wed, 02 Jul 2003 05:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe2g-0007tn-QI for nemo@optimus.ietf.org; Wed, 02 Jul 2003 05:36:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29672 for ; Wed, 2 Jul 2003 05:36:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xe2d-0007mc-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:36:43 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Xe2c-0007mY-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:36:42 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h629r1K24835; Wed, 2 Jul 2003 18:53:01 +0900 (KST) (envelope-from eun) Date: Wed, 2 Jul 2003 18:53:01 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Cc: hscho@mmlab.snu.ac.kr Subject: [eun@mmlab.snu.ac.kr: FW: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Message-ID: <20030702185301.A24813@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Thank you for sharing your experiments. It seems that you did a lot. While I read this draft, I found an interesting scenario in Figure 5. Could you explain the example situation that will meet the scenario in Figure 5 ? I am curios what the role of HA in the mobile network is. And I have another question on the implementation of nested mobile networks. For example, let's think about following topology. Internet | AR | Parent MR | Child MR In the figure, Parent MR may autoconfigure its CoA after it listens RA of AR. Then, Child MR may autoconfigure its CoA after it listens RA of Parent MR. After that, if Parent MR listens Child MR's RA, Parent MR configures new CoA according to Child MR's RA ? If it happens it would be wrong CoA since Parent MR have to connect to the Internet through AR. I wonder if you encountered such a problem while you implemented. Regards, Eun Kyoung > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, June 27, 2003 12:09 AM > To: IETF-Announce: > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Laboratory and 'Field' Experiments with > IPv6 Mobile > Networks in Vehicular Environments > Author(s) : H. Lach et al. > Filename : draft-lach-nemo-experiments-overdrive-00.txt > Pages : 10 > Date : 2003-6-26 > > This document gives a short high-level overview of several > practical experiments performed with mobile networks using Mobile > IPv6-based NEMO extensions in the context of the IST OverDRiVE > project. Laboratory experiments include simple and nested mobile > networks in a pure IPv6 environment while 'field' experiments > demonstrated continuous IPv6 vehicular connectivity over two > publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN > 802.11b deployed around and inside a metropolitan area. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-ov erdrive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lach-nemo-experiments-overdrive-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-lach-nemo-experiments-overdrive-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. ----- End forwarded message ----- From exim@www1.ietf.org Wed Jul 2 05:38:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29729 for ; Wed, 2 Jul 2003 05:38:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe3h-0008CT-Og for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 05:37:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h629bnaY031515 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 05:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe3h-0008CE-LC for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 05:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29702 for ; Wed, 2 Jul 2003 05:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xe3e-0007nM-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 05:37:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xe3d-0007nJ-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 05:37:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe2v-0007uh-Gt; Wed, 02 Jul 2003 05:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xe2g-0007tn-QI for nemo@optimus.ietf.org; Wed, 02 Jul 2003 05:36:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29672 for ; Wed, 2 Jul 2003 05:36:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xe2d-0007mc-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:36:43 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Xe2c-0007mY-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:36:42 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h629r1K24835; Wed, 2 Jul 2003 18:53:01 +0900 (KST) (envelope-from eun) Date: Wed, 2 Jul 2003 18:53:01 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Cc: hscho@mmlab.snu.ac.kr Subject: [eun@mmlab.snu.ac.kr: FW: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Message-ID: <20030702185301.A24813@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Thank you for sharing your experiments. It seems that you did a lot. While I read this draft, I found an interesting scenario in Figure 5. Could you explain the example situation that will meet the scenario in Figure 5 ? I am curios what the role of HA in the mobile network is. And I have another question on the implementation of nested mobile networks. For example, let's think about following topology. Internet | AR | Parent MR | Child MR In the figure, Parent MR may autoconfigure its CoA after it listens RA of AR. Then, Child MR may autoconfigure its CoA after it listens RA of Parent MR. After that, if Parent MR listens Child MR's RA, Parent MR configures new CoA according to Child MR's RA ? If it happens it would be wrong CoA since Parent MR have to connect to the Internet through AR. I wonder if you encountered such a problem while you implemented. Regards, Eun Kyoung > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, June 27, 2003 12:09 AM > To: IETF-Announce: > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Laboratory and 'Field' Experiments with > IPv6 Mobile > Networks in Vehicular Environments > Author(s) : H. Lach et al. > Filename : draft-lach-nemo-experiments-overdrive-00.txt > Pages : 10 > Date : 2003-6-26 > > This document gives a short high-level overview of several > practical experiments performed with mobile networks using Mobile > IPv6-based NEMO extensions in the context of the IST OverDRiVE > project. Laboratory experiments include simple and nested mobile > networks in a pure IPv6 environment while 'field' experiments > demonstrated continuous IPv6 vehicular connectivity over two > publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN > 802.11b deployed around and inside a metropolitan area. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-ov erdrive-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lach-nemo-experiments-overdrive-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-lach-nemo-experiments-overdrive-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. ----- End forwarded message ----- From nemo-admin@ietf.org Wed Jul 2 05:51:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29991 for ; Wed, 2 Jul 2003 05:51:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeFV-0008Nr-RF; Wed, 02 Jul 2003 05:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeEs-0008NA-0R for nemo@optimus.ietf.org; Wed, 02 Jul 2003 05:49:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29937 for ; Wed, 2 Jul 2003 05:49:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeEo-00009v-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:49:18 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19XeEn-00009r-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:49:17 -0400 Received: (from hscho@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h62A5aU25024 for nemo@ietf.org; Wed, 2 Jul 2003 19:05:36 +0900 (KST) (envelope-from hscho) Date: Wed, 2 Jul 2003 19:05:36 +0900 From: hscho To: nemo@ietf.org Subject: RE: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt] Message-ID: <20030702190536.A24968@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi. I have read this draft lately. I cannot understand why MR must register his address and parent MR's address together. Does TLMR have to know them to make topology of child MRs? Regards, Hosik, Cho -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 27, 2003 12:09 AM To: IETF-Announce: Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router Author(s) : H. Kang et al. Filename : draft-hkang-nemo-ro-tlmr-00.txt Pages : 9 Date : 2003-6-26 This document shows how to route optimization by using bi-directional tunnel between home agent and top level mobile router. A packet will be transmitted directly from the home link of the mobile node to top level mobile router of the correspondent node through this tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-hkang-nemo-ro-tlmr-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-hkang-nemo-ro-tlmr-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. ----- End forwarded message ----- From exim@www1.ietf.org Wed Jul 2 05:51:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00010 for ; Wed, 2 Jul 2003 05:51:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeGE-0008RA-21 for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 05:50:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h629okf2032426 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 05:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeGD-0008Qv-Uo for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 05:50:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29977 for ; Wed, 2 Jul 2003 05:50:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeGA-0000Az-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 05:50:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XeG9-0000Aw-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 05:50:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeFV-0008Nr-RF; Wed, 02 Jul 2003 05:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XeEs-0008NA-0R for nemo@optimus.ietf.org; Wed, 02 Jul 2003 05:49:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29937 for ; Wed, 2 Jul 2003 05:49:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XeEo-00009v-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:49:18 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19XeEn-00009r-00 for nemo@ietf.org; Wed, 02 Jul 2003 05:49:17 -0400 Received: (from hscho@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h62A5aU25024 for nemo@ietf.org; Wed, 2 Jul 2003 19:05:36 +0900 (KST) (envelope-from hscho) Date: Wed, 2 Jul 2003 19:05:36 +0900 From: hscho To: nemo@ietf.org Subject: RE: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt] Message-ID: <20030702190536.A24968@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi. I have read this draft lately. I cannot understand why MR must register his address and parent MR's address together. Does TLMR have to know them to make topology of child MRs? Regards, Hosik, Cho -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 27, 2003 12:09 AM To: IETF-Announce: Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-hkang-nemo-ro-tlmr-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router Author(s) : H. Kang et al. Filename : draft-hkang-nemo-ro-tlmr-00.txt Pages : 9 Date : 2003-6-26 This document shows how to route optimization by using bi-directional tunnel between home agent and top level mobile router. A packet will be transmitted directly from the home link of the mobile node to top level mobile router of the correspondent node through this tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hkang-nemo-ro-tlmr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-hkang-nemo-ro-tlmr-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-hkang-nemo-ro-tlmr-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. ----- End forwarded message ----- From nemo-admin@ietf.org Wed Jul 2 06:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00541 for ; Wed, 2 Jul 2003 06:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XekT-0000qI-Dh; Wed, 02 Jul 2003 06:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xeju-0000pu-Q9 for nemo@optimus.ietf.org; Wed, 02 Jul 2003 06:21:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00513 for ; Wed, 2 Jul 2003 06:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xejq-0000Yy-00 for nemo@ietf.org; Wed, 02 Jul 2003 06:21:23 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Xejq-0000Yv-00 for nemo@ietf.org; Wed, 02 Jul 2003 06:21:22 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h62ALNj1007804; Wed, 2 Jul 2003 03:21:23 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h62ALJxE003404; Wed, 2 Jul 2003 05:21:20 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 958C12EC86; Wed, 2 Jul 2003 12:21:18 +0200 (CEST) Message-ID: <3F02B21E.6040102@motorola.com> Date: Wed, 02 Jul 2003 12:21:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [eun@mmlab.snu.ac.kr: FW: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] References: <20030702185301.A24813@mmlab.snu.ac.kr> In-Reply-To: <20030702185301.A24813@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eun Kyoung Paik wrote: > Hi, > > Thank you for sharing your experiments. It seems that you did a lot. Thanks for appreciation. > While I read this draft, I found an interesting scenario in Figure 5. > Could you explain the example situation that will meet the scenario > in Figure 5 ? I am curios what the role of HA in the mobile network > is. Having a Home Agent inside a mobile network allows for Mobile Nodes to move around inside the mobile network, or outside. Some terminology calls those nodes 'LMN' or 'VMN'. In the particular context reported in that draft, an example situation is the following: there is a mobile network deployed in the car; there is a tablet PC at the right of the wheel giving driving directions; the tablet PC is also used by the driver to open the window on the roof. At some point in time, driver gets off the car, takes the tablet PC with her and goes somewhere. At some point in time, she realizes she forgot the window open, so use that tablet PC to remotely close that window. A possible implementation of this scenario to work is to have a Home Agent in the car mobile network to take care of the absence of the tablet PC. Of course, that is not the only example situation and it is easy to come up with a large set of example situations where a Home Agent in a mobile network is needed. > And I have another question on the implementation of nested mobile > networks. For example, let's think about following topology. > > Internet | AR | Parent MR | Child MR > > In the figure, Parent MR may autoconfigure its CoA after it listens > RA of AR. Then, Child MR may autoconfigure its CoA after it listens > RA of Parent MR. After that, if Parent MR listens Child MR's RA, > Parent MR configures new CoA according to Child MR's RA ? In this particular configuration, I do not think that Parent MR configures a CoA based on the Child MR RA. There are two reasons for that. One is that according to the stateless autoconfiguration mechanisms a router will not autoconfigure an address on an interface based on received RA's. Parent MR is a router, so. The other is that Child MR is, in fact, visiting the network of Parent MR; when a MR is visiting, it acts as a host on its egress interface, not as a router. Thus it will not send RA's on its egress interface if it is not at home, so Parent MR does not get RA's from Child MR. I guess I have it right that way... > If it happens it would be wrong CoA since Parent MR have to connect > to the Internet through AR. I wonder if you encountered such a > problem while you implemented. We have encountered some problems with having a Home Agent placed in a mobile network, indeed. For example, there is a configuration named "cross-over" tunnels, reported in section B.6 of draft-petrescu-nemo-mrha-02.txt But that problem is not related to the way routers configure their addresses. There is also a widely acknolwedged problem of "disconnected" operation that was mentioned very early. Have you encountered some similar problems? Alex GBU From exim@www1.ietf.org Wed Jul 2 06:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00557 for ; Wed, 2 Jul 2003 06:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XekV-0000rF-Ov for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 06:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62AM3Xm003291 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 06:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XekV-0000r0-KP for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00523 for ; Wed, 2 Jul 2003 06:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XekR-0000Zb-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 06:21:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XekR-0000ZY-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 06:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XekT-0000qI-Dh; Wed, 02 Jul 2003 06:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xeju-0000pu-Q9 for nemo@optimus.ietf.org; Wed, 02 Jul 2003 06:21:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00513 for ; Wed, 2 Jul 2003 06:21:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xejq-0000Yy-00 for nemo@ietf.org; Wed, 02 Jul 2003 06:21:23 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Xejq-0000Yv-00 for nemo@ietf.org; Wed, 02 Jul 2003 06:21:22 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h62ALNj1007804; Wed, 2 Jul 2003 03:21:23 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h62ALJxE003404; Wed, 2 Jul 2003 05:21:20 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 958C12EC86; Wed, 2 Jul 2003 12:21:18 +0200 (CEST) Message-ID: <3F02B21E.6040102@motorola.com> Date: Wed, 02 Jul 2003 12:21:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [eun@mmlab.snu.ac.kr: FW: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] References: <20030702185301.A24813@mmlab.snu.ac.kr> In-Reply-To: <20030702185301.A24813@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eun Kyoung Paik wrote: > Hi, > > Thank you for sharing your experiments. It seems that you did a lot. Thanks for appreciation. > While I read this draft, I found an interesting scenario in Figure 5. > Could you explain the example situation that will meet the scenario > in Figure 5 ? I am curios what the role of HA in the mobile network > is. Having a Home Agent inside a mobile network allows for Mobile Nodes to move around inside the mobile network, or outside. Some terminology calls those nodes 'LMN' or 'VMN'. In the particular context reported in that draft, an example situation is the following: there is a mobile network deployed in the car; there is a tablet PC at the right of the wheel giving driving directions; the tablet PC is also used by the driver to open the window on the roof. At some point in time, driver gets off the car, takes the tablet PC with her and goes somewhere. At some point in time, she realizes she forgot the window open, so use that tablet PC to remotely close that window. A possible implementation of this scenario to work is to have a Home Agent in the car mobile network to take care of the absence of the tablet PC. Of course, that is not the only example situation and it is easy to come up with a large set of example situations where a Home Agent in a mobile network is needed. > And I have another question on the implementation of nested mobile > networks. For example, let's think about following topology. > > Internet | AR | Parent MR | Child MR > > In the figure, Parent MR may autoconfigure its CoA after it listens > RA of AR. Then, Child MR may autoconfigure its CoA after it listens > RA of Parent MR. After that, if Parent MR listens Child MR's RA, > Parent MR configures new CoA according to Child MR's RA ? In this particular configuration, I do not think that Parent MR configures a CoA based on the Child MR RA. There are two reasons for that. One is that according to the stateless autoconfiguration mechanisms a router will not autoconfigure an address on an interface based on received RA's. Parent MR is a router, so. The other is that Child MR is, in fact, visiting the network of Parent MR; when a MR is visiting, it acts as a host on its egress interface, not as a router. Thus it will not send RA's on its egress interface if it is not at home, so Parent MR does not get RA's from Child MR. I guess I have it right that way... > If it happens it would be wrong CoA since Parent MR have to connect > to the Internet through AR. I wonder if you encountered such a > problem while you implemented. We have encountered some problems with having a Home Agent placed in a mobile network, indeed. For example, there is a configuration named "cross-over" tunnels, reported in section B.6 of draft-petrescu-nemo-mrha-02.txt But that problem is not related to the way routers configure their addresses. There is also a widely acknolwedged problem of "disconnected" operation that was mentioned very early. Have you encountered some similar problems? Alex GBU From nemo-admin@ietf.org Wed Jul 2 07:55:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07872 for ; Wed, 2 Jul 2003 07:55:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgCT-0005lT-83; Wed, 02 Jul 2003 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgC8-0005l0-Lm for nemo@optimus.ietf.org; Wed, 02 Jul 2003 07:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07760 for ; Wed, 2 Jul 2003 07:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XgC6-0002oc-00 for nemo@ietf.org; Wed, 02 Jul 2003 07:54:38 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19XgC4-0002oY-00 for nemo@ietf.org; Wed, 02 Jul 2003 07:54:37 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h61CWij1012278; Tue, 1 Jul 2003 05:32:44 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h61CTUOC024994; Tue, 1 Jul 2003 07:29:32 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 44E172EC86; Tue, 1 Jul 2003 14:29:30 +0200 (CEST) Message-ID: <3F017EA9.1090908@motorola.com> Date: Tue, 01 Jul 2003 14:29:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Chan-Wah Ng , IETF NEMO WG References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> In-Reply-To: <3EF8C394.F91C155F@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: typo (Was: Design Team draft for NEMO Basic Solution) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> In [Section 4.4, page 13], the explanation of Prefix Length field >> seems to be questionable. It says "length of the IPv6 prefix >> contained in the option", but there is no prefix in this option. >> Also, a full-stop punctuation is missing. > > > changed it to > > 8 bit unsigned integer indicating the prefix length of the IPv6 > prefix from which the Home Address included in the Binding Update was > configured from. Typo, redundant double occurence of "from". Could be: 8 bit unsigned integer indicating the length of the IPv6 prefix derived from the Home Address appearing in the Binding Update. Alex GBU From exim@www1.ietf.org Wed Jul 2 07:56:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07893 for ; Wed, 2 Jul 2003 07:56:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgCy-0005mi-6J for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 07:55:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62BtWAs022230 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 07:55:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgCx-0005mT-Um for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 07:55:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07829 for ; Wed, 2 Jul 2003 07:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XgCx-0002pt-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 07:55:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XgCw-0002pq-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 07:55:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgCT-0005lT-83; Wed, 02 Jul 2003 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgC8-0005l0-Lm for nemo@optimus.ietf.org; Wed, 02 Jul 2003 07:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07760 for ; Wed, 2 Jul 2003 07:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XgC6-0002oc-00 for nemo@ietf.org; Wed, 02 Jul 2003 07:54:38 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19XgC4-0002oY-00 for nemo@ietf.org; Wed, 02 Jul 2003 07:54:37 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h61CWij1012278; Tue, 1 Jul 2003 05:32:44 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h61CTUOC024994; Tue, 1 Jul 2003 07:29:32 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 44E172EC86; Tue, 1 Jul 2003 14:29:30 +0200 (CEST) Message-ID: <3F017EA9.1090908@motorola.com> Date: Tue, 01 Jul 2003 14:29:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Chan-Wah Ng , IETF NEMO WG References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> In-Reply-To: <3EF8C394.F91C155F@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: typo (Was: Design Team draft for NEMO Basic Solution) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> In [Section 4.4, page 13], the explanation of Prefix Length field >> seems to be questionable. It says "length of the IPv6 prefix >> contained in the option", but there is no prefix in this option. >> Also, a full-stop punctuation is missing. > > > changed it to > > 8 bit unsigned integer indicating the prefix length of the IPv6 > prefix from which the Home Address included in the Binding Update was > configured from. Typo, redundant double occurence of "from". Could be: 8 bit unsigned integer indicating the length of the IPv6 prefix derived from the Home Address appearing in the Binding Update. Alex GBU From nemo-admin@ietf.org Wed Jul 2 08:59:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14305 for ; Wed, 2 Jul 2003 08:59:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhCP-0007fK-D2; Wed, 02 Jul 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhBm-0007el-0T for nemo@optimus.ietf.org; Wed, 02 Jul 2003 08:58:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14228 for ; Wed, 2 Jul 2003 08:58:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhBk-00057l-00 for nemo@ietf.org; Wed, 02 Jul 2003 08:58:20 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19XhBj-00057h-00 for nemo@ietf.org; Wed, 02 Jul 2003 08:58:19 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h62CwEnr024752; Wed, 2 Jul 2003 05:58:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h62CwASR014196; Wed, 2 Jul 2003 07:58:11 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 047652EC86; Wed, 2 Jul 2003 14:58:10 +0200 (CEST) Message-ID: <3F02D6E1.5020701@motorola.com> Date: Wed, 02 Jul 2003 14:58:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph Droms wrote: > Following up on our conversation a couple of months ago about using > DHCPv6 PD for prefix delegation to mobile routers, I've published > "DHCPv6 Prefix Delegation for NEMO" > . This draft describes the use of > DHCPv6 to meet my understanding of the requirements for prefix > delegation to mobile routers. Comments welcome... I'm happy this draft exists and is up for comments. I think that the way it suggests behaviour of PD between MR and HA is very good for the simplest mobile network configurations. > The requirements for basic network mobility support [8] include the > ability of the MR to receive delegated prefixes that can then be > assigned to links in the mobile network. DHCPv6PD can be used to > meet this requirement for prefix delegation. Just a short note to mention that the requirements draft is not [8] but [7] and [7] does not impose that HA MUST be able to delegate prefixes. But I also think that HA delegating prefixes is a good feature that would help with dynamic assignment of prefixes. > The DHCPv6PD DR function MUST be implemented in the HA for the MR. > The use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR > delegating router: the router that acts as a DHCP server, and is > responding to the prefix request.] So I understand HA for Mobile Routers must be a DHCPv6 Server. But in the case of Mobile Hosts, the HA can also be a DHCPv6 Relay only, so it would be nice if HA for Mobile Routers also could act as a Relay only. Or otherwise the HA for Mobile Hosts be a Server. > Other updates to the HA data structures required as a side effect of > prefix delegation are specified by the particular network mobility > protocol. For example, in the case of "Basic Network Mobility > Support" [8], the HA would add an entry in its binding cache > registering the delegated prefix to the MR to which the prefix was > delegated. I don't think that any proposed solution would involve triggering additions of BC entries as a result of PD operations. Adding entries in the BC is exclusively a result of Binding messaging, in my understanding. On another hand, and trying an implementation-independent formulation, one would say that forwarding information would be updated on the HA as a result of assigning a prefix to a MR. And along the same lines, the same happens at MR: when MR receives a prefix it necessarily adds a route to its routing table. Please correct me where I'm wrong with the above. Other: I was wondering about the necessity to explain what happens when there is a FR (fixed router, moves together with MR, sits below MR) inside the mobile network, and that needs to have its own prefix, supposedly a sub-prefix of the prefix assigned by HA to MR. Does the MR (acting as a RR requesting router) have the power to become a DR and delegate sub-prefixes to FR? Or, maybe FR will be itself a RR and request a prefix from the HA (acting as a DR)? Thanks for providing the draft for discussion, Alex GBU From exim@www1.ietf.org Wed Jul 2 08:59:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14320 for ; Wed, 2 Jul 2003 08:59:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhCb-0007gp-Ek for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 08:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62CxDH6029553 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 08:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhCb-0007ga-B1 for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 08:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14286 for ; Wed, 2 Jul 2003 08:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhCZ-000591-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 08:59:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhCY-00058y-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 08:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhCP-0007fK-D2; Wed, 02 Jul 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhBm-0007el-0T for nemo@optimus.ietf.org; Wed, 02 Jul 2003 08:58:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14228 for ; Wed, 2 Jul 2003 08:58:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhBk-00057l-00 for nemo@ietf.org; Wed, 02 Jul 2003 08:58:20 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19XhBj-00057h-00 for nemo@ietf.org; Wed, 02 Jul 2003 08:58:19 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h62CwEnr024752; Wed, 2 Jul 2003 05:58:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h62CwASR014196; Wed, 2 Jul 2003 07:58:11 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 047652EC86; Wed, 2 Jul 2003 14:58:10 +0200 (CEST) Message-ID: <3F02D6E1.5020701@motorola.com> Date: Wed, 02 Jul 2003 14:58:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Cc: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ralph Droms wrote: > Following up on our conversation a couple of months ago about using > DHCPv6 PD for prefix delegation to mobile routers, I've published > "DHCPv6 Prefix Delegation for NEMO" > . This draft describes the use of > DHCPv6 to meet my understanding of the requirements for prefix > delegation to mobile routers. Comments welcome... I'm happy this draft exists and is up for comments. I think that the way it suggests behaviour of PD between MR and HA is very good for the simplest mobile network configurations. > The requirements for basic network mobility support [8] include the > ability of the MR to receive delegated prefixes that can then be > assigned to links in the mobile network. DHCPv6PD can be used to > meet this requirement for prefix delegation. Just a short note to mention that the requirements draft is not [8] but [7] and [7] does not impose that HA MUST be able to delegate prefixes. But I also think that HA delegating prefixes is a good feature that would help with dynamic assignment of prefixes. > The DHCPv6PD DR function MUST be implemented in the HA for the MR. > The use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR > delegating router: the router that acts as a DHCP server, and is > responding to the prefix request.] So I understand HA for Mobile Routers must be a DHCPv6 Server. But in the case of Mobile Hosts, the HA can also be a DHCPv6 Relay only, so it would be nice if HA for Mobile Routers also could act as a Relay only. Or otherwise the HA for Mobile Hosts be a Server. > Other updates to the HA data structures required as a side effect of > prefix delegation are specified by the particular network mobility > protocol. For example, in the case of "Basic Network Mobility > Support" [8], the HA would add an entry in its binding cache > registering the delegated prefix to the MR to which the prefix was > delegated. I don't think that any proposed solution would involve triggering additions of BC entries as a result of PD operations. Adding entries in the BC is exclusively a result of Binding messaging, in my understanding. On another hand, and trying an implementation-independent formulation, one would say that forwarding information would be updated on the HA as a result of assigning a prefix to a MR. And along the same lines, the same happens at MR: when MR receives a prefix it necessarily adds a route to its routing table. Please correct me where I'm wrong with the above. Other: I was wondering about the necessity to explain what happens when there is a FR (fixed router, moves together with MR, sits below MR) inside the mobile network, and that needs to have its own prefix, supposedly a sub-prefix of the prefix assigned by HA to MR. Does the MR (acting as a RR requesting router) have the power to become a DR and delegate sub-prefixes to FR? Or, maybe FR will be itself a RR and request a prefix from the HA (acting as a DR)? Thanks for providing the draft for discussion, Alex GBU From nemo-admin@ietf.org Wed Jul 2 10:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23047 for ; Wed, 2 Jul 2003 10:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTl-0004J2-T5; Wed, 02 Jul 2003 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTL-0004If-TX for nemo@optimus.ietf.org; Wed, 02 Jul 2003 10:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22973 for ; Wed, 2 Jul 2003 10:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiTJ-0000Kq-00 for nemo@ietf.org; Wed, 02 Jul 2003 10:20:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19XiTI-0000KP-00 for nemo@ietf.org; Wed, 02 Jul 2003 10:20:33 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62EK0fq005480; Wed, 2 Jul 2003 10:20:00 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ39450; Wed, 2 Jul 2003 10:19:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 10:19:56 -0400 To: Alexandru Petrescu From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Cc: nemo@ietf.org In-Reply-To: <3F02D6E1.5020701@motorola.com> References: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 02:58 PM 7/2/2003 +0200, Alexandru Petrescu wrote: >Ralph Droms wrote: >>Following up on our conversation a couple of months ago about using >>DHCPv6 PD for prefix delegation to mobile routers, I've published "DHCPv6 >>Prefix Delegation for NEMO" . This >>draft describes the use of >> DHCPv6 to meet my understanding of the requirements for prefix >> delegation to mobile routers. Comments welcome... > >I'm happy this draft exists and is up for comments. I think that the way >it suggests behaviour of PD between MR and HA is very good for the >simplest mobile network configurations. > >>The requirements for basic network mobility support [8] include the >>ability of the MR to receive delegated prefixes that can then be assigned >>to links in the mobile network. DHCPv6PD can be used to meet this >>requirement for prefix delegation. > >Just a short note to mention that the requirements draft is not [8] but >[7] and [7] does not impose that HA MUST be able to delegate prefixes. >But I also think that HA delegating prefixes is a good feature that >would help with dynamic assignment of prefixes. OK ... the definition of HA in section 2 of "Basic Network Mobility Support" [8] states: "HA MUST be able to delegate a prefix to a MR by any delegation protocols." By "requirements for basic network mobility support", I was referring to this requirement from . >>The DHCPv6PD DR function MUST be implemented in the HA for the MR. The >>use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR delegating >>router: the router that acts as a DHCP server, and is responding to the >>prefix request.] > >So I understand HA for Mobile Routers must be a DHCPv6 Server. But in >the case of Mobile Hosts, the HA can also be a DHCPv6 Relay only, so it >would be nice if HA for Mobile Routers also could act as a Relay only. >Or otherwise the HA for Mobile Hosts be a Server. At present, DHCPv6 prefix delegation requires that the DR share a link with the RR. Introducing a DHCPv6 relay agent would require some additional mechanism to install the correct routing information on a router that shares a link with the RR. Installing the routes would involve some protocol outside DHCPv6 if the DHCPv6 relay agent is not implemented on a router. >>Other updates to the HA data structures required as a side effect of >> prefix delegation are specified by the particular network mobility >> protocol. For example, in the case of "Basic Network Mobility Support" >> [8], the HA would add an entry in its binding cache registering the >> delegated prefix to the MR to which the prefix was delegated. > >I don't think that any proposed solution would involve triggering >additions of BC entries as a result of PD operations. Adding entries in >the BC is exclusively a result of Binding messaging, in my understanding. OK >On another hand, and trying an implementation-independent formulation, >one would say that forwarding information would be updated on the HA as >a result of assigning a prefix to a MR. And along the same lines, the >same happens at MR: when MR receives a prefix it necessarily adds a >route to its routing table. Agreed - and this routing information update issue is the basis for the requirement that the DHCPv6 server be in the DR that shares a link with the RR. >Please correct me where I'm wrong with the above. > >Other: > >I was wondering about the necessity to explain what happens when there >is a FR (fixed router, moves together with MR, sits below MR) inside the >mobile network, and that needs to have its own prefix, supposedly a >sub-prefix of the prefix assigned by HA to MR. Does the MR (acting as a >RR requesting router) have the power to become a DR and delegate >sub-prefixes to FR? > >Or, maybe FR will be itself a RR and request a prefix from the HA >(acting as a DR)? There is no restriction against a device having an RR implementation on its upstream interface and a DR implementation on the downstream interfaces, and no restriction against the RR sharing delegated prefixes with the DR for sub-delegation. We haven't written down an explicit explanation of the details... >Thanks for providing the draft for discussion, > >Alex >GBU You're welcome, and thanks for the comments... - Ralph From exim@www1.ietf.org Wed Jul 2 10:21:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23062 for ; Wed, 2 Jul 2003 10:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTt-0004KC-6Q for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 10:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62EL9Ge016623 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 10:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTt-0004K2-2V for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 10:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23022 for ; Wed, 2 Jul 2003 10:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiTq-0000Lu-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 10:21:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XiTq-0000Lr-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 10:21:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTl-0004J2-T5; Wed, 02 Jul 2003 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiTL-0004If-TX for nemo@optimus.ietf.org; Wed, 02 Jul 2003 10:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22973 for ; Wed, 2 Jul 2003 10:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiTJ-0000Kq-00 for nemo@ietf.org; Wed, 02 Jul 2003 10:20:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19XiTI-0000KP-00 for nemo@ietf.org; Wed, 02 Jul 2003 10:20:33 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62EK0fq005480; Wed, 2 Jul 2003 10:20:00 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ39450; Wed, 2 Jul 2003 10:19:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 10:19:56 -0400 To: Alexandru Petrescu From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Cc: nemo@ietf.org In-Reply-To: <3F02D6E1.5020701@motorola.com> References: <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> <4.3.2.7.2.20030701122946.00ba6940@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 02:58 PM 7/2/2003 +0200, Alexandru Petrescu wrote: >Ralph Droms wrote: >>Following up on our conversation a couple of months ago about using >>DHCPv6 PD for prefix delegation to mobile routers, I've published "DHCPv6 >>Prefix Delegation for NEMO" . This >>draft describes the use of >> DHCPv6 to meet my understanding of the requirements for prefix >> delegation to mobile routers. Comments welcome... > >I'm happy this draft exists and is up for comments. I think that the way >it suggests behaviour of PD between MR and HA is very good for the >simplest mobile network configurations. > >>The requirements for basic network mobility support [8] include the >>ability of the MR to receive delegated prefixes that can then be assigned >>to links in the mobile network. DHCPv6PD can be used to meet this >>requirement for prefix delegation. > >Just a short note to mention that the requirements draft is not [8] but >[7] and [7] does not impose that HA MUST be able to delegate prefixes. >But I also think that HA delegating prefixes is a good feature that >would help with dynamic assignment of prefixes. OK ... the definition of HA in section 2 of "Basic Network Mobility Support" [8] states: "HA MUST be able to delegate a prefix to a MR by any delegation protocols." By "requirements for basic network mobility support", I was referring to this requirement from . >>The DHCPv6PD DR function MUST be implemented in the HA for the MR. The >>use of a DHCPv6 relay agent is not defined for DHCPv6PD. [DR delegating >>router: the router that acts as a DHCP server, and is responding to the >>prefix request.] > >So I understand HA for Mobile Routers must be a DHCPv6 Server. But in >the case of Mobile Hosts, the HA can also be a DHCPv6 Relay only, so it >would be nice if HA for Mobile Routers also could act as a Relay only. >Or otherwise the HA for Mobile Hosts be a Server. At present, DHCPv6 prefix delegation requires that the DR share a link with the RR. Introducing a DHCPv6 relay agent would require some additional mechanism to install the correct routing information on a router that shares a link with the RR. Installing the routes would involve some protocol outside DHCPv6 if the DHCPv6 relay agent is not implemented on a router. >>Other updates to the HA data structures required as a side effect of >> prefix delegation are specified by the particular network mobility >> protocol. For example, in the case of "Basic Network Mobility Support" >> [8], the HA would add an entry in its binding cache registering the >> delegated prefix to the MR to which the prefix was delegated. > >I don't think that any proposed solution would involve triggering >additions of BC entries as a result of PD operations. Adding entries in >the BC is exclusively a result of Binding messaging, in my understanding. OK >On another hand, and trying an implementation-independent formulation, >one would say that forwarding information would be updated on the HA as >a result of assigning a prefix to a MR. And along the same lines, the >same happens at MR: when MR receives a prefix it necessarily adds a >route to its routing table. Agreed - and this routing information update issue is the basis for the requirement that the DHCPv6 server be in the DR that shares a link with the RR. >Please correct me where I'm wrong with the above. > >Other: > >I was wondering about the necessity to explain what happens when there >is a FR (fixed router, moves together with MR, sits below MR) inside the >mobile network, and that needs to have its own prefix, supposedly a >sub-prefix of the prefix assigned by HA to MR. Does the MR (acting as a >RR requesting router) have the power to become a DR and delegate >sub-prefixes to FR? > >Or, maybe FR will be itself a RR and request a prefix from the HA >(acting as a DR)? There is no restriction against a device having an RR implementation on its upstream interface and a DR implementation on the downstream interfaces, and no restriction against the RR sharing delegated prefixes with the DR for sub-delegation. We haven't written down an explicit explanation of the details... >Thanks for providing the draft for discussion, > >Alex >GBU You're welcome, and thanks for the comments... - Ralph From nemo-admin@ietf.org Wed Jul 2 11:10:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26392 for ; Wed, 2 Jul 2003 11:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjFB-0006k7-9K; Wed, 02 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjF0-0006jZ-6P for nemo@optimus.ietf.org; Wed, 02 Jul 2003 11:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26376 for ; Wed, 2 Jul 2003 11:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjEx-0001xU-00 for nemo@ietf.org; Wed, 02 Jul 2003 11:09:47 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19XjEw-0001wf-00 for nemo@ietf.org; Wed, 02 Jul 2003 11:09:46 -0400 Received: from JONGKN03 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h62F73YC001898; Thu, 3 Jul 2003 00:07:03 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Date: Thu, 3 Jul 2003 00:09:35 +0900 Message-ID: <020b01c340ab$f34fbba0$dbf02e93@JONGKN03> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020C_01C340F7.633763A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] The question about NEMO basic support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_020C_01C340F7.633763A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Vijay, I have a question for prefix table described in the draft. In case that prefix table is not pre-configured in HA, MR should use explicit or combined binding mode. Right? Let's assume that MR and HA can run dynamic routing protocol and prefix table is not pre-configured. If MR try to do implicit binding, by the draft, MR cannot set up the bi-directional tunnel with its HA because HA will send BACK with '143' status code(Mobile Network Prefix Information information unavailable) for the requested BU. I think HA should allow the implicit BU from MR that runs dynamic routing protocol because the draft says that prefix table is an optional data structure from the terminology description of section 2. Or, the draft should say prefix table MUST be maintained by HA. It looks like unclear to me. Could you explain that for me? Best Regards, /Jongkeun ------=_NextPart_000_020C_01C340F7.633763A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Vijay,

 

I have a question for prefix table described = in the draft.

In case that prefix table is not = pre-configured in HA, MR should use explicit or combined binding mode. = Right?

Let’s assume that MR and HA can run = dynamic routing protocol and prefix table is not = pre-configured.

If MR try to do implicit binding, by the = draft, MR cannot set up the bi-directional tunnel with its HA because HA will send = BACK with ‘143’ status code(Mobile Network Prefix Information = information unavailable) for the requested BU.

I think HA should allow the implicit BU from = MR that runs dynamic routing protocol because the draft says that prefix table = is an optional data structure from the terminology description of section 2. Or, the = draft should say prefix table MUST be maintained by HA.

 

It looks like unclear to me. Could you = explain that for me?

 

Best Regards,

/Jongkeun

------=_NextPart_000_020C_01C340F7.633763A0-- From exim@www1.ietf.org Wed Jul 2 11:10:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26407 for ; Wed, 2 Jul 2003 11:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjFL-0006l2-Ro for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 11:10:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FABQG025971 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 11:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjFL-0006ko-OI for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26385 for ; Wed, 2 Jul 2003 11:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjFJ-0001y6-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 11:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XjFI-0001y3-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 11:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjFB-0006k7-9K; Wed, 02 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjF0-0006jZ-6P for nemo@optimus.ietf.org; Wed, 02 Jul 2003 11:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26376 for ; Wed, 2 Jul 2003 11:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjEx-0001xU-00 for nemo@ietf.org; Wed, 02 Jul 2003 11:09:47 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19XjEw-0001wf-00 for nemo@ietf.org; Wed, 02 Jul 2003 11:09:46 -0400 Received: from JONGKN03 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h62F73YC001898; Thu, 3 Jul 2003 00:07:03 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Date: Thu, 3 Jul 2003 00:09:35 +0900 Message-ID: <020b01c340ab$f34fbba0$dbf02e93@JONGKN03> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020C_01C340F7.633763A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] The question about NEMO basic support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_020C_01C340F7.633763A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Vijay, I have a question for prefix table described in the draft. In case that prefix table is not pre-configured in HA, MR should use explicit or combined binding mode. Right? Let's assume that MR and HA can run dynamic routing protocol and prefix table is not pre-configured. If MR try to do implicit binding, by the draft, MR cannot set up the bi-directional tunnel with its HA because HA will send BACK with '143' status code(Mobile Network Prefix Information information unavailable) for the requested BU. I think HA should allow the implicit BU from MR that runs dynamic routing protocol because the draft says that prefix table is an optional data structure from the terminology description of section 2. Or, the draft should say prefix table MUST be maintained by HA. It looks like unclear to me. Could you explain that for me? Best Regards, /Jongkeun ------=_NextPart_000_020C_01C340F7.633763A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Vijay,

 

I have a question for prefix table described = in the draft.

In case that prefix table is not = pre-configured in HA, MR should use explicit or combined binding mode. = Right?

Let’s assume that MR and HA can run = dynamic routing protocol and prefix table is not = pre-configured.

If MR try to do implicit binding, by the = draft, MR cannot set up the bi-directional tunnel with its HA because HA will send = BACK with ‘143’ status code(Mobile Network Prefix Information = information unavailable) for the requested BU.

I think HA should allow the implicit BU from = MR that runs dynamic routing protocol because the draft says that prefix table = is an optional data structure from the terminology description of section 2. Or, the = draft should say prefix table MUST be maintained by HA.

 

It looks like unclear to me. Could you = explain that for me?

 

Best Regards,

/Jongkeun

------=_NextPart_000_020C_01C340F7.633763A0-- From nemo-admin@ietf.org Wed Jul 2 11:46:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27747 for ; Wed, 2 Jul 2003 11:46:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjo4-0008I2-8f; Wed, 02 Jul 2003 11:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQXP-00029T-Jz for nemo@optimus.ietf.org; Tue, 01 Jul 2003 15:12:09 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07519 for ; Tue, 1 Jul 2003 13:26:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16123; Tue, 1 Jul 2003 09:56:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h61GuVc01948; Tue, 1 Jul 2003 09:56:31 -0700 X-mProtect: <200307011656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNMA9vG; Tue, 01 Jul 2003 09:56:29 PDT Message-ID: <3F01BD3E.E0E4F99F@iprg.nokia.com> Date: Tue, 01 Jul 2003 09:56:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Subject: Re: [nemo] Vienna Agenda References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Hello Thierry and T.J., > > I'll like to request a slot for discussion on multi-homing issues in the > Vienna Meeting. > > One more thing, I understand the basic solution will be the most > important agenda item. not really. we dont really have a lot of unresolved issues with respect to the basic support. the draft is out. we dont want a slot describing the solution in the draft. people can just read the draft. if there are significant issues raised (before the IETF meeting) then it might make sense discussing the issues. otherwise it doesnt need a slot. > Julien is actually finishing a multihoming > evaluation of the basic solution. So I don't know if its okay for me to > talk about that within the slot in Vienna. We have missed the I-D > publish deadline, but will make it available for public viewing via a > URL. it would be good to nail down what exactly NEMO is supposed to support with respect to mutlihoming at this IETF. I have seen too many multihoming scenarios, some of which are not practical at all (IMHO). Vijay From exim@www1.ietf.org Wed Jul 2 11:46:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27789 for ; Wed, 2 Jul 2003 11:46:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjoJ-00009y-Qj for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 11:46:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FkJcG000608 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 11:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjoJ-00009b-3B for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:46:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27621 for ; Wed, 2 Jul 2003 11:46:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjoI-0002ak-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 11:46:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XjoH-0002aV-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 11:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjo4-0008I2-8f; Wed, 02 Jul 2003 11:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQXP-00029T-Jz for nemo@optimus.ietf.org; Tue, 01 Jul 2003 15:12:09 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07519 for ; Tue, 1 Jul 2003 13:26:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16123; Tue, 1 Jul 2003 09:56:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h61GuVc01948; Tue, 1 Jul 2003 09:56:31 -0700 X-mProtect: <200307011656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNMA9vG; Tue, 01 Jul 2003 09:56:29 PDT Message-ID: <3F01BD3E.E0E4F99F@iprg.nokia.com> Date: Tue, 01 Jul 2003 09:56:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Subject: Re: [nemo] Vienna Agenda References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Hello Thierry and T.J., > > I'll like to request a slot for discussion on multi-homing issues in the > Vienna Meeting. > > One more thing, I understand the basic solution will be the most > important agenda item. not really. we dont really have a lot of unresolved issues with respect to the basic support. the draft is out. we dont want a slot describing the solution in the draft. people can just read the draft. if there are significant issues raised (before the IETF meeting) then it might make sense discussing the issues. otherwise it doesnt need a slot. > Julien is actually finishing a multihoming > evaluation of the basic solution. So I don't know if its okay for me to > talk about that within the slot in Vienna. We have missed the I-D > publish deadline, but will make it available for public viewing via a > URL. it would be good to nail down what exactly NEMO is supposed to support with respect to mutlihoming at this IETF. I have seen too many multihoming scenarios, some of which are not practical at all (IMHO). Vijay From nemo-admin@ietf.org Wed Jul 2 13:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01457 for ; Wed, 2 Jul 2003 13:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkxd-0007B5-Tj; Wed, 02 Jul 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkxC-000755-Bc for nemo@optimus.ietf.org; Wed, 02 Jul 2003 12:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01326 for ; Wed, 2 Jul 2003 12:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkxA-00040w-00 for nemo@ietf.org; Wed, 02 Jul 2003 12:59:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Xkx9-00040G-00 for nemo@ietf.org; Wed, 02 Jul 2003 12:59:32 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA27475; Wed, 2 Jul 2003 09:58:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62Gwqd22759; Wed, 2 Jul 2003 09:58:52 -0700 X-mProtect: <200307021658> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZKqsJT; Wed, 02 Jul 2003 09:58:50 PDT Message-ID: <3F030F4B.7B630D77@iprg.nokia.com> Date: Wed, 02 Jul 2003 09:58:51 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org References: <020b01c340ab$f34fbba0$dbf02e93@JONGKN03> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: The question about NEMO basic support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Hello Vijay, > > > > I have a question for prefix table described in the draft. > > In case that prefix table is not pre-configured in HA, MR should use explicit or combined binding mode. Right? right. > > Let's assume that MR and HA can run dynamic routing protocol and prefix table is not pre-configured. when the MR and HA run a dynamic routing protocol there is no need to include an prefix information in the Binding Update. infact the HA should not try to determine the prefix from the Binding Update. the routing protocol updates will carry the prefix information. do you think we need an explicit flag in the Binding Update for this? Vijay > > If MR try to do implicit binding, by the draft, MR cannot set up the bi-directional tunnel with its HA because HA will send BACK with `143' status > code(Mobile Network Prefix Information information unavailable) for the requested BU. > > I think HA should allow the implicit BU from MR that runs dynamic routing protocol because the draft says that prefix table is an optional data structure > from the terminology description of section 2. Or, the draft should say prefix table MUST be maintained by HA. > > > > It looks like unclear to me. Could you explain that for me? > > > > Best Regards, > > /Jongkeun From exim@www1.ietf.org Wed Jul 2 13:00:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01473 for ; Wed, 2 Jul 2003 13:00:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkxg-0007Ec-Tc for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 13:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62H04rS027810 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 13:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkxg-0007ET-P3 for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01402 for ; Wed, 2 Jul 2003 13:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xkxf-00041X-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xkxe-00041T-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkxd-0007B5-Tj; Wed, 02 Jul 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkxC-000755-Bc for nemo@optimus.ietf.org; Wed, 02 Jul 2003 12:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01326 for ; Wed, 2 Jul 2003 12:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkxA-00040w-00 for nemo@ietf.org; Wed, 02 Jul 2003 12:59:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Xkx9-00040G-00 for nemo@ietf.org; Wed, 02 Jul 2003 12:59:32 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA27475; Wed, 2 Jul 2003 09:58:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62Gwqd22759; Wed, 2 Jul 2003 09:58:52 -0700 X-mProtect: <200307021658> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZKqsJT; Wed, 02 Jul 2003 09:58:50 PDT Message-ID: <3F030F4B.7B630D77@iprg.nokia.com> Date: Wed, 02 Jul 2003 09:58:51 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org References: <020b01c340ab$f34fbba0$dbf02e93@JONGKN03> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: The question about NEMO basic support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Hello Vijay, > > > > I have a question for prefix table described in the draft. > > In case that prefix table is not pre-configured in HA, MR should use explicit or combined binding mode. Right? right. > > Let's assume that MR and HA can run dynamic routing protocol and prefix table is not pre-configured. when the MR and HA run a dynamic routing protocol there is no need to include an prefix information in the Binding Update. infact the HA should not try to determine the prefix from the Binding Update. the routing protocol updates will carry the prefix information. do you think we need an explicit flag in the Binding Update for this? Vijay > > If MR try to do implicit binding, by the draft, MR cannot set up the bi-directional tunnel with its HA because HA will send BACK with `143' status > code(Mobile Network Prefix Information information unavailable) for the requested BU. > > I think HA should allow the implicit BU from MR that runs dynamic routing protocol because the draft says that prefix table is an optional data structure > from the terminology description of section 2. Or, the draft should say prefix table MUST be maintained by HA. > > > > It looks like unclear to me. Could you explain that for me? > > > > Best Regards, > > /Jongkeun From nemo-admin@ietf.org Wed Jul 2 13:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03591 for ; Wed, 2 Jul 2003 13:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlXR-0001cH-4M; Wed, 02 Jul 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlWj-0001bY-1O for nemo@optimus.ietf.org; Wed, 02 Jul 2003 13:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03521 for ; Wed, 2 Jul 2003 13:36:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlWh-0004lm-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:36:15 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19XlWg-0004lb-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:36:14 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D9CB26BA13 for ; Wed, 2 Jul 2003 13:35:43 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h62HZhuW007828; Wed, 2 Jul 2003 13:35:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h62HZeYM017814; Wed, 2 Jul 2003 13:35:41 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 02 Jul 2003 13:35:35 -0400 To: "T.J. Kniveton" From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Very nice work on the Basic Support. Sorry, I cannot make it out to Vienna, but I should be at the next meeting. Also, I have a draft completed on issues related to mobile-ip and routing protocols when using encryption devices. I could not get it in before closeout of Internet Drafts. However I will as soon as IETF opens for new submissions. Here are a few questions and some minor corrections: 1) Question regarding section 8. Support for Dynamic Routing Protocols "In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] through the bi-directional tunnel." I believe the hop limit is usually set to 1 for routing protocols. Encapsulation will decrement by 1. Do we need to state anything here regarding the need to not decrement the Hop Limit field here or is this obvious? ( I am wary of this as it is definitely an issue with encryption devices.) 1.1) Has anyone given some though to policy base routing over tunnels that are coming up and going down? The aeronautics community still has this on their wish list. 2) Many places in the document is state "MUST not." Should those be changed to "MUST NOT"? Typographic and Spelling Mistakes ========================= Page 17. home link. At this point, Mobile Router MAY try try to obtain and own a prefix by the same means that it initially got attributed the Invalid Prefix in question. Alternatively, Mobile Router MAY send Binding Updates in another mode (e.g. implicit mode) to a Home Agent on the same home link. MAY try try >>> MAY try The bi-directional tunnel between Mobile Router and Home Agent allows packets to flow in both directions between these entities, while the Mobile Router is connected to a Visisted Link. Visisted Link. >>> Visited Link Page 18 A Mobile Router MAY use the received Router Advertisements on the interface connected to the home link, but only for logging and administrative purposes. Only when that interface is connected to a A Mobile Router MAY use the received Router Advertisements on the interface connected to the home link, but only for logging and administrative purposes. Only when that interface is connected to a visisted link, visisted link >>> visited link Page 26 8. Support for Dynamic Routing Protocols In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run a intra-doamin routing intra-doamin >>> intra-domain Will Ivancic From exim@www1.ietf.org Wed Jul 2 13:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03607 for ; Wed, 2 Jul 2003 13:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlXT-0001du-7F for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 13:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Hb3gQ006308 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 13:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlXT-0001df-3E for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:37:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03551 for ; Wed, 2 Jul 2003 13:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlXR-0004mJ-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:37:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XlXQ-0004mG-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlXR-0001cH-4M; Wed, 02 Jul 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlWj-0001bY-1O for nemo@optimus.ietf.org; Wed, 02 Jul 2003 13:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03521 for ; Wed, 2 Jul 2003 13:36:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlWh-0004lm-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:36:15 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19XlWg-0004lb-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:36:14 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D9CB26BA13 for ; Wed, 2 Jul 2003 13:35:43 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h62HZhuW007828; Wed, 2 Jul 2003 13:35:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h62HZeYM017814; Wed, 2 Jul 2003 13:35:41 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 02 Jul 2003 13:35:35 -0400 To: "T.J. Kniveton" From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Very nice work on the Basic Support. Sorry, I cannot make it out to Vienna, but I should be at the next meeting. Also, I have a draft completed on issues related to mobile-ip and routing protocols when using encryption devices. I could not get it in before closeout of Internet Drafts. However I will as soon as IETF opens for new submissions. Here are a few questions and some minor corrections: 1) Question regarding section 8. Support for Dynamic Routing Protocols "In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] through the bi-directional tunnel." I believe the hop limit is usually set to 1 for routing protocols. Encapsulation will decrement by 1. Do we need to state anything here regarding the need to not decrement the Hop Limit field here or is this obvious? ( I am wary of this as it is definitely an issue with encryption devices.) 1.1) Has anyone given some though to policy base routing over tunnels that are coming up and going down? The aeronautics community still has this on their wish list. 2) Many places in the document is state "MUST not." Should those be changed to "MUST NOT"? Typographic and Spelling Mistakes ========================= Page 17. home link. At this point, Mobile Router MAY try try to obtain and own a prefix by the same means that it initially got attributed the Invalid Prefix in question. Alternatively, Mobile Router MAY send Binding Updates in another mode (e.g. implicit mode) to a Home Agent on the same home link. MAY try try >>> MAY try The bi-directional tunnel between Mobile Router and Home Agent allows packets to flow in both directions between these entities, while the Mobile Router is connected to a Visisted Link. Visisted Link. >>> Visited Link Page 18 A Mobile Router MAY use the received Router Advertisements on the interface connected to the home link, but only for logging and administrative purposes. Only when that interface is connected to a A Mobile Router MAY use the received Router Advertisements on the interface connected to the home link, but only for logging and administrative purposes. Only when that interface is connected to a visisted link, visisted link >>> visited link Page 26 8. Support for Dynamic Routing Protocols In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run a intra-doamin routing intra-doamin >>> intra-domain Will Ivancic From nemo-admin@ietf.org Wed Jul 2 13:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04203 for ; Wed, 2 Jul 2003 13:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlqn-0002Tn-KC; Wed, 02 Jul 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlqI-0002QE-Og for nemo@optimus.ietf.org; Wed, 02 Jul 2003 13:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04134 for ; Wed, 2 Jul 2003 13:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlqG-00050Q-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:56:28 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19XlqF-0004za-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:56:28 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E2F0F689FB for ; Wed, 2 Jul 2003 13:55:57 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h62HtuuW014113; Wed, 2 Jul 2003 13:55:57 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h62HtpYM029681; Wed, 2 Jul 2003 13:55:52 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 02 Jul 2003 13:55:46 -0400 To: vijayd@IPRG.nokia.com From: William D Ivancic Subject: Re: [nemo] Vienna Agenda Cc: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" In-Reply-To: <3F01BD3E.E0E4F99F@iprg.nokia.com> References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Vijay >it would be good to nail down what exactly NEMO is supposed >to support with respect to mutlihoming at this IETF. I have >seen too many multihoming scenarios, some of which are not >practical at all (IMHO). I work with mobile networks daily using Cisco's IPv4 implementation. The multihoming we utilize is one router with multiple "roaming" interfaces connected to various links. Some of those links may have foreign agents and others may use collocated-care-of-address (CC0A). For example I have one mobile router that has an 802.11 interface (foreign agent); one satellite link using static CCOA and one G2.5 general packet radio service (GPRS) link using dynamic CCOA over PPP. The mobile router is configured to choose links in the following order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links may be active and register as available, only one link can be used at a time. Although some may wish (or at least think they wish) to use multiple links or all links (as with the aeronautical community) the practicality of this is questionable. The following are real measured numbers for some services we have used. Link Practical Data Rate RTT Delay Cost =========================================================================== WiFi >1.0 Mbps 100 msec Free after infrastructure or approximately equal to GPRS GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month Unlimited Volume Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute !!!! Will Ivancic From exim@www1.ietf.org Wed Jul 2 13:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04218 for ; Wed, 2 Jul 2003 13:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlqq-0002Uk-Tq for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 13:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Hv4Ph009589 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 13:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlqq-0002Ua-OQ for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04179 for ; Wed, 2 Jul 2003 13:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xlqo-00050v-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:57:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xlqn-00050s-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 13:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlqn-0002Tn-KC; Wed, 02 Jul 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlqI-0002QE-Og for nemo@optimus.ietf.org; Wed, 02 Jul 2003 13:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04134 for ; Wed, 2 Jul 2003 13:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlqG-00050Q-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:56:28 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19XlqF-0004za-00 for nemo@ietf.org; Wed, 02 Jul 2003 13:56:28 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E2F0F689FB for ; Wed, 2 Jul 2003 13:55:57 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h62HtuuW014113; Wed, 2 Jul 2003 13:55:57 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h62HtpYM029681; Wed, 2 Jul 2003 13:55:52 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 02 Jul 2003 13:55:46 -0400 To: vijayd@IPRG.nokia.com From: William D Ivancic Subject: Re: [nemo] Vienna Agenda Cc: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" In-Reply-To: <3F01BD3E.E0E4F99F@iprg.nokia.com> References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Vijay >it would be good to nail down what exactly NEMO is supposed >to support with respect to mutlihoming at this IETF. I have >seen too many multihoming scenarios, some of which are not >practical at all (IMHO). I work with mobile networks daily using Cisco's IPv4 implementation. The multihoming we utilize is one router with multiple "roaming" interfaces connected to various links. Some of those links may have foreign agents and others may use collocated-care-of-address (CC0A). For example I have one mobile router that has an 802.11 interface (foreign agent); one satellite link using static CCOA and one G2.5 general packet radio service (GPRS) link using dynamic CCOA over PPP. The mobile router is configured to choose links in the following order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links may be active and register as available, only one link can be used at a time. Although some may wish (or at least think they wish) to use multiple links or all links (as with the aeronautical community) the practicality of this is questionable. The following are real measured numbers for some services we have used. Link Practical Data Rate RTT Delay Cost =========================================================================== WiFi >1.0 Mbps 100 msec Free after infrastructure or approximately equal to GPRS GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month Unlimited Volume Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute !!!! Will Ivancic From nemo-admin@ietf.org Wed Jul 2 14:09:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04626 for ; Wed, 2 Jul 2003 14:09:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2Q-0003Ec-0S; Wed, 02 Jul 2003 14:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2L-0003EJ-Fi for nemo@optimus.ietf.org; Wed, 02 Jul 2003 14:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04574 for ; Wed, 2 Jul 2003 14:08:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xm2J-0005Au-00 for nemo@ietf.org; Wed, 02 Jul 2003 14:08:55 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Xm2H-0005A3-00 for nemo@ietf.org; Wed, 02 Jul 2003 14:08:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA01446; Wed, 2 Jul 2003 11:08:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62I88s11075; Wed, 2 Jul 2003 11:08:08 -0700 X-mProtect: <200307021808> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJgtxHc; Wed, 02 Jul 2003 11:08:06 PDT Message-ID: <3F031F86.10B8B46B@iprg.nokia.com> Date: Wed, 02 Jul 2003 11:08:06 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William D Ivancic wrote: > > Very nice work on the Basic Support. > > Sorry, I cannot make it out to Vienna, but I should be at the next > meeting. Also, I have a draft completed on issues related to mobile-ip > and routing protocols when using encryption devices. I could not get it in > before closeout of Internet Drafts. However I will as soon as IETF opens > for new submissions. > > Here are a few questions and some minor corrections: > > 1) Question regarding section 8. Support for Dynamic Routing Protocols > "In the solution described so far, forwarding to the Mobile Network at the > Home Agent is set up when the Home Agent receives a Binding Update from the > Mobile Router. An alternative to this is for the Home Agent and the Mobile > Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] > through the bi-directional tunnel." > > I believe the hop limit is usually set to 1 for routing > protocols. Encapsulation will decrement by 1. Do we need to state > anything here regarding the need to not decrement the Hop Limit field here > or is this obvious? ( I am wary of this as it is definitely an issue with > encryption devices.) the way I see it is, both the HA and MR run a routing protocol through the bi-directional tunnel. this tunnel is treated as a singe hop link. both MR and HA use link local addresses for routing protocol messages inside the tunnel. these messages are processed at each end and are not forwarded onto the other links. forwarding packets with link local address raises a lot of issues and also makes the HA implementation difficult. > > 1.1) Has anyone given some though to policy base routing over tunnels that > are coming up and going down? The aeronautics community still has this on > their wish list. I am not sure I read any previous mails on this. can you tell me more? > > 2) Many places in the document is state "MUST not." Should those be > changed to "MUST NOT"? fixed > > Typographic and Spelling Mistakes > ========================= > Page 17. > home link. At this point, Mobile Router MAY try try to obtain and own a > prefix by the same means that it initially got attributed the Invalid > Prefix in question. Alternatively, Mobile Router MAY send Binding Updates > in another mode (e.g. implicit mode) to a Home Agent on the same home link. > > MAY try try >>> MAY try > > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities, while the Mobile > Router is connected to a Visisted Link. > > Visisted Link. >>> Visited Link > > Page 18 > > A Mobile Router MAY use the received Router Advertisements on the interface > connected to the home link, but only for logging and administrative > purposes. Only when that interface is connected to a A Mobile Router MAY > use the received Router Advertisements on the interface connected to the > home link, but only for logging and administrative purposes. Only when that > interface is connected to a visisted link, > > visisted link >>> visited link > > Page 26 > 8. Support for Dynamic Routing Protocols In the solution described so far, > forwarding to the Mobile Network at the Home Agent is set up when the Home > Agent receives a Binding Update from the Mobile Router. An alternative to > this is for the Home Agent and the Mobile Router to run a intra-doamin routing > > intra-doamin >>> intra-domain thanks. Vijay From exim@www1.ietf.org Wed Jul 2 14:09:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04641 for ; Wed, 2 Jul 2003 14:09:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2a-0003Fh-FC for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 14:09:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62I9C7S012497 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 14:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2a-0003FU-Bc for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 14:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04588 for ; Wed, 2 Jul 2003 14:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xm2Y-0005BJ-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 14:09:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xm2X-0005BG-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 14:09:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2Q-0003Ec-0S; Wed, 02 Jul 2003 14:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xm2L-0003EJ-Fi for nemo@optimus.ietf.org; Wed, 02 Jul 2003 14:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04574 for ; Wed, 2 Jul 2003 14:08:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xm2J-0005Au-00 for nemo@ietf.org; Wed, 02 Jul 2003 14:08:55 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Xm2H-0005A3-00 for nemo@ietf.org; Wed, 02 Jul 2003 14:08:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA01446; Wed, 2 Jul 2003 11:08:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h62I88s11075; Wed, 2 Jul 2003 11:08:08 -0700 X-mProtect: <200307021808> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJgtxHc; Wed, 02 Jul 2003 11:08:06 PDT Message-ID: <3F031F86.10B8B46B@iprg.nokia.com> Date: Wed, 02 Jul 2003 11:08:06 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William D Ivancic wrote: > > Very nice work on the Basic Support. > > Sorry, I cannot make it out to Vienna, but I should be at the next > meeting. Also, I have a draft completed on issues related to mobile-ip > and routing protocols when using encryption devices. I could not get it in > before closeout of Internet Drafts. However I will as soon as IETF opens > for new submissions. > > Here are a few questions and some minor corrections: > > 1) Question regarding section 8. Support for Dynamic Routing Protocols > "In the solution described so far, forwarding to the Mobile Network at the > Home Agent is set up when the Home Agent receives a Binding Update from the > Mobile Router. An alternative to this is for the Home Agent and the Mobile > Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] > through the bi-directional tunnel." > > I believe the hop limit is usually set to 1 for routing > protocols. Encapsulation will decrement by 1. Do we need to state > anything here regarding the need to not decrement the Hop Limit field here > or is this obvious? ( I am wary of this as it is definitely an issue with > encryption devices.) the way I see it is, both the HA and MR run a routing protocol through the bi-directional tunnel. this tunnel is treated as a singe hop link. both MR and HA use link local addresses for routing protocol messages inside the tunnel. these messages are processed at each end and are not forwarded onto the other links. forwarding packets with link local address raises a lot of issues and also makes the HA implementation difficult. > > 1.1) Has anyone given some though to policy base routing over tunnels that > are coming up and going down? The aeronautics community still has this on > their wish list. I am not sure I read any previous mails on this. can you tell me more? > > 2) Many places in the document is state "MUST not." Should those be > changed to "MUST NOT"? fixed > > Typographic and Spelling Mistakes > ========================= > Page 17. > home link. At this point, Mobile Router MAY try try to obtain and own a > prefix by the same means that it initially got attributed the Invalid > Prefix in question. Alternatively, Mobile Router MAY send Binding Updates > in another mode (e.g. implicit mode) to a Home Agent on the same home link. > > MAY try try >>> MAY try > > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities, while the Mobile > Router is connected to a Visisted Link. > > Visisted Link. >>> Visited Link > > Page 18 > > A Mobile Router MAY use the received Router Advertisements on the interface > connected to the home link, but only for logging and administrative > purposes. Only when that interface is connected to a A Mobile Router MAY > use the received Router Advertisements on the interface connected to the > home link, but only for logging and administrative purposes. Only when that > interface is connected to a visisted link, > > visisted link >>> visited link > > Page 26 > 8. Support for Dynamic Routing Protocols In the solution described so far, > forwarding to the Mobile Network at the Home Agent is set up when the Home > Agent receives a Binding Update from the Mobile Router. An alternative to > this is for the Home Agent and the Mobile Router to run a intra-doamin routing > > intra-doamin >>> intra-domain thanks. Vijay From nemo-admin@ietf.org Wed Jul 2 20:18:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04579 for ; Wed, 2 Jul 2003 20:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrnV-0005QE-KV; Wed, 02 Jul 2003 20:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xrmc-0005Oy-DG for nemo@optimus.ietf.org; Wed, 02 Jul 2003 20:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04374 for ; Wed, 2 Jul 2003 20:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xrma-0006ew-00 for nemo@ietf.org; Wed, 02 Jul 2003 20:17:04 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19XrmZ-0006et-00 for nemo@ietf.org; Wed, 02 Jul 2003 20:17:03 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h630H1nD022089; Wed, 2 Jul 2003 17:17:01 -0700 (MST) Received: from motorola.com ([163.14.20.13]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h62NDbrN027938; Wed, 2 Jul 2003 18:13:44 -0500 Message-ID: <3F0391F6.6080405@motorola.com> Date: Thu, 03 Jul 2003 04:16:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William D Ivancic CC: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: experiments (was: Vienna Agenda) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William D Ivancic wrote: > Vijay > > >> it would be good to nail down what exactly NEMO is supposed to >> support with respect to mutlihoming at this IETF. I have seen too >> many multihoming scenarios, some of which are not practical at all >> (IMHO). > > > I work with mobile networks daily using Cisco's IPv4 implementation. > The multihoming we utilize is one router with multiple "roaming" > interfaces connected to various links. Some of those links may have > foreign agents and others may use collocated-care-of-address (CC0A). > For example I have one mobile router that has an 802.11 interface > (foreign agent); one satellite link using static CCOA and one G2.5 > general packet radio service (GPRS) link using dynamic CCOA over PPP. > The mobile router is configured to choose links in the following > order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although > all links may be active and register as available, only one link can > be used at a time. Although some may wish (or at least think they > wish) to use multiple links or all links (as with the aeronautical > community) the practicality of this is questionable. Thanks for the description, I'm happy to see these kinds of experiments happen. Just to show similarity, we call a "roaming" interface a "mobile" interface. We started with the same kind of idea for a mobile router prototype that has several mobile interfaces connected to various access systems (but behaviour was so difficult to maintain that we preferred to isolate ppp connections on a "FrontBox"). For example, when a GPRS mobile interface is used, and the mobile router enters a tunnel (a real tunnel like under a river) then that PPP connection goes down, the corresponding interface disappears, routing entries disappear. When the mobile router exits that tunnel, re-establishing the PPP connection involved relaunching many other things. So we considered designing "FrontBoxes" that would isolate this behaviour from Mobile IPv6 software: A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base Station. It also has a WLAN interface w1 on which it sends IPv6 RAs towards MR. If the PPP connection goes down, this can be repaired locally withouth MR noticing it. A WLAN FrontBox has two WLAN interfaces, one of them attaching to a hotspot WLAN AP, and the other is named w2. (A third _potential_ DVB FrontBox would use a terestrial DVB link as well as a return path on another GPRS phone, such as to still provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the MR.) Each FrontBox uses private IPv4 to connect to GPRS or to hotspots respectively. They also dynamically maintain IPv6-in-UDP/v4 tunnels towards a special machine in the home network that has connectivity to both IPv4 and IPv6 Internets. Each FB provides IPv6-only bidirectional connectivity to MR, each sending different RA's with unique prefixes. A Mobile Router has only one WLAN "mobile" interface that switches attachment between w1 and w2, as well as another WLAN interface towards the mobile network link. The Mobile Router and the nodes in the mobile network exclusively run IPv6 with network mobility based on Mobile IPv6 (no IPv4). Mobile Router switches attachment by means of a visual interface (GUI), with manual buttons. When I see the hotspot access point approaching I push the "WLAN" button; when I see it in the rear view mirror I push "GPRS". Of course, better can be done to automate this with some preferences, as your experiments report. In this way, all access technologies are separated (read deterministic and controllable), from the Mobile IPv6 behaviour. > The following are real measured numbers for some services we have > used. > > Link Practical Data Rate RTT Delay Cost > =========================================================================== > WiFi >1.0 Mbps 100 msec Free after > infrastructure or approximately equal to GPRS > > GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month > Unlimited Volume > > Satellite ~ 40 kbps 1 - 2 seconds $1.00 per > minute !!!! Confirms most of my expectations with respect to GPRS rates/delays/dollar_cost. I'm suprised though to see "satellite" being 40kb/s (I was thinking it would be much less(?). Does the satellite link have a sort of return path? Could I imagine acquiring sattelite link somehow somewhere to make a FrontBox with it? In our experiments, the data rates as shown by vic between LFN and a CN placed in the home network varies between 11-45Kb/s (when GPRS) and about 60kb/s (when WLAN). Ping delays over GPRS are little over 1s. The direct communication between WLAN FrontBox and hotspot AP is standard 11mb/s. All relevant delays and latencies largely depend on the higly variable number of many hops between MR and HA as well as between CN and HA and CN and MR. Billing was not taken into consideration since the billing scheme of the access providers were themselves a moving ground (WLAN hotspots were free but business model changing as we speak, including targetting a "mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes transferred, not the time length, not flat; to complicate things further some GPRS operators make pay more if the given IPv4 address is publicly routable non-NAT'ed, and less if NAT'ed). Ask me for more information, or the operators themselves. There was not any form of multi-homing in our experiments, even if several access systems were indeed used, or some other times in the laboratory several Home Agents were used. Only one connection was used at a time, and I don't see exactly how a "one-size-fits-all" means to reasonably use simultaneously these three access systems can be conceived. And yes, I would very much appreciate if clarifications are sought at the live meeting with respect to multi-homing requirements and the practical scenarios in relation to network mobility. Looking forward... Alex GBU From exim@www1.ietf.org Wed Jul 2 20:18:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04602 for ; Wed, 2 Jul 2003 20:18:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xrng-0005RV-Kc for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 20:18:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h630ICk8020917 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 20:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xrng-0005RI-G7 for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 20:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04527 for ; Wed, 2 Jul 2003 20:18:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xrne-0006i0-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 20:18:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xrnd-0006hx-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 20:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrnV-0005QE-KV; Wed, 02 Jul 2003 20:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xrmc-0005Oy-DG for nemo@optimus.ietf.org; Wed, 02 Jul 2003 20:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04374 for ; Wed, 2 Jul 2003 20:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xrma-0006ew-00 for nemo@ietf.org; Wed, 02 Jul 2003 20:17:04 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19XrmZ-0006et-00 for nemo@ietf.org; Wed, 02 Jul 2003 20:17:03 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h630H1nD022089; Wed, 2 Jul 2003 17:17:01 -0700 (MST) Received: from motorola.com ([163.14.20.13]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h62NDbrN027938; Wed, 2 Jul 2003 18:13:44 -0500 Message-ID: <3F0391F6.6080405@motorola.com> Date: Thu, 03 Jul 2003 04:16:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William D Ivancic CC: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: experiments (was: Vienna Agenda) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William D Ivancic wrote: > Vijay > > >> it would be good to nail down what exactly NEMO is supposed to >> support with respect to mutlihoming at this IETF. I have seen too >> many multihoming scenarios, some of which are not practical at all >> (IMHO). > > > I work with mobile networks daily using Cisco's IPv4 implementation. > The multihoming we utilize is one router with multiple "roaming" > interfaces connected to various links. Some of those links may have > foreign agents and others may use collocated-care-of-address (CC0A). > For example I have one mobile router that has an 802.11 interface > (foreign agent); one satellite link using static CCOA and one G2.5 > general packet radio service (GPRS) link using dynamic CCOA over PPP. > The mobile router is configured to choose links in the following > order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although > all links may be active and register as available, only one link can > be used at a time. Although some may wish (or at least think they > wish) to use multiple links or all links (as with the aeronautical > community) the practicality of this is questionable. Thanks for the description, I'm happy to see these kinds of experiments happen. Just to show similarity, we call a "roaming" interface a "mobile" interface. We started with the same kind of idea for a mobile router prototype that has several mobile interfaces connected to various access systems (but behaviour was so difficult to maintain that we preferred to isolate ppp connections on a "FrontBox"). For example, when a GPRS mobile interface is used, and the mobile router enters a tunnel (a real tunnel like under a river) then that PPP connection goes down, the corresponding interface disappears, routing entries disappear. When the mobile router exits that tunnel, re-establishing the PPP connection involved relaunching many other things. So we considered designing "FrontBoxes" that would isolate this behaviour from Mobile IPv6 software: A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base Station. It also has a WLAN interface w1 on which it sends IPv6 RAs towards MR. If the PPP connection goes down, this can be repaired locally withouth MR noticing it. A WLAN FrontBox has two WLAN interfaces, one of them attaching to a hotspot WLAN AP, and the other is named w2. (A third _potential_ DVB FrontBox would use a terestrial DVB link as well as a return path on another GPRS phone, such as to still provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the MR.) Each FrontBox uses private IPv4 to connect to GPRS or to hotspots respectively. They also dynamically maintain IPv6-in-UDP/v4 tunnels towards a special machine in the home network that has connectivity to both IPv4 and IPv6 Internets. Each FB provides IPv6-only bidirectional connectivity to MR, each sending different RA's with unique prefixes. A Mobile Router has only one WLAN "mobile" interface that switches attachment between w1 and w2, as well as another WLAN interface towards the mobile network link. The Mobile Router and the nodes in the mobile network exclusively run IPv6 with network mobility based on Mobile IPv6 (no IPv4). Mobile Router switches attachment by means of a visual interface (GUI), with manual buttons. When I see the hotspot access point approaching I push the "WLAN" button; when I see it in the rear view mirror I push "GPRS". Of course, better can be done to automate this with some preferences, as your experiments report. In this way, all access technologies are separated (read deterministic and controllable), from the Mobile IPv6 behaviour. > The following are real measured numbers for some services we have > used. > > Link Practical Data Rate RTT Delay Cost > =========================================================================== > WiFi >1.0 Mbps 100 msec Free after > infrastructure or approximately equal to GPRS > > GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month > Unlimited Volume > > Satellite ~ 40 kbps 1 - 2 seconds $1.00 per > minute !!!! Confirms most of my expectations with respect to GPRS rates/delays/dollar_cost. I'm suprised though to see "satellite" being 40kb/s (I was thinking it would be much less(?). Does the satellite link have a sort of return path? Could I imagine acquiring sattelite link somehow somewhere to make a FrontBox with it? In our experiments, the data rates as shown by vic between LFN and a CN placed in the home network varies between 11-45Kb/s (when GPRS) and about 60kb/s (when WLAN). Ping delays over GPRS are little over 1s. The direct communication between WLAN FrontBox and hotspot AP is standard 11mb/s. All relevant delays and latencies largely depend on the higly variable number of many hops between MR and HA as well as between CN and HA and CN and MR. Billing was not taken into consideration since the billing scheme of the access providers were themselves a moving ground (WLAN hotspots were free but business model changing as we speak, including targetting a "mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes transferred, not the time length, not flat; to complicate things further some GPRS operators make pay more if the given IPv4 address is publicly routable non-NAT'ed, and less if NAT'ed). Ask me for more information, or the operators themselves. There was not any form of multi-homing in our experiments, even if several access systems were indeed used, or some other times in the laboratory several Home Agents were used. Only one connection was used at a time, and I don't see exactly how a "one-size-fits-all" means to reasonably use simultaneously these three access systems can be conceived. And yes, I would very much appreciate if clarifications are sought at the live meeting with respect to multi-homing requirements and the practical scenarios in relation to network mobility. Looking forward... Alex GBU From nemo-admin@ietf.org Wed Jul 2 21:34:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09639 for ; Wed, 2 Jul 2003 21:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsz3-0000S3-IH; Wed, 02 Jul 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsyi-0000Rs-Qg for nemo@optimus.ietf.org; Wed, 02 Jul 2003 21:33:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09615 for ; Wed, 2 Jul 2003 21:33:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xsyg-0000uK-00 for nemo@ietf.org; Wed, 02 Jul 2003 21:33:38 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19Xsyf-0000uG-00 for nemo@ietf.org; Wed, 02 Jul 2003 21:33:37 -0400 Received: from JONGKN03 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h631UuYC011246; Thu, 3 Jul 2003 10:30:56 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: [nemo] Re: The question about NEMO basic support Date: Thu, 3 Jul 2003 10:33:28 +0900 Message-ID: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-reply-to: <3F030F4B.7B630D77@iprg.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > I have a question for prefix table described in the draft. > > > > In case that prefix table is not pre-configured in HA, MR should use > explicit or combined binding mode. Right? > > right. > > > > > Let's assume that MR and HA can run dynamic routing protocol and prefix > table is not pre-configured. > > when the MR and HA run a dynamic routing protocol there is > no need to include an prefix information in the Binding > Update. infact the HA should not try to determine the > prefix from the Binding Update. the routing protocol updates > will carry the prefix information. do you think we need an > explicit flag in the Binding Update for this? > Yes, I thought an explicit flag is required for HA to properly handle this situation. /Jongkeun > > Vijay > > > > > If MR try to do implicit binding, by the draft, MR cannot set up the bi- > directional tunnel with its HA because HA will send BACK with `143' status > > code(Mobile Network Prefix Information information unavailable) for the > requested BU. > > > > I think HA should allow the implicit BU from MR that runs dynamic > routing protocol because the draft says that prefix table is an optional > data structure > > from the terminology description of section 2. Or, the draft should say > prefix table MUST be maintained by HA. > > > > > > > > It looks like unclear to me. Could you explain that for me? > > > > > > > > Best Regards, > > > > /Jongkeun From exim@www1.ietf.org Wed Jul 2 21:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09654 for ; Wed, 2 Jul 2003 21:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsz7-0000Sz-4f for nemo-archive@odin.ietf.org; Wed, 02 Jul 2003 21:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h631Y5b8001787 for nemo-archive@odin.ietf.org; Wed, 2 Jul 2003 21:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsz7-0000Sk-0h for nemo-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 21:34:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09628 for ; Wed, 2 Jul 2003 21:34:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xsz4-0000uj-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 21:34:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xsz3-0000ug-00 for nemo-web-archive@ietf.org; Wed, 02 Jul 2003 21:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsz3-0000S3-IH; Wed, 02 Jul 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xsyi-0000Rs-Qg for nemo@optimus.ietf.org; Wed, 02 Jul 2003 21:33:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09615 for ; Wed, 2 Jul 2003 21:33:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xsyg-0000uK-00 for nemo@ietf.org; Wed, 02 Jul 2003 21:33:38 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19Xsyf-0000uG-00 for nemo@ietf.org; Wed, 02 Jul 2003 21:33:37 -0400 Received: from JONGKN03 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h631UuYC011246; Thu, 3 Jul 2003 10:30:56 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: [nemo] Re: The question about NEMO basic support Date: Thu, 3 Jul 2003 10:33:28 +0900 Message-ID: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-reply-to: <3F030F4B.7B630D77@iprg.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I have a question for prefix table described in the draft. > > > > In case that prefix table is not pre-configured in HA, MR should use > explicit or combined binding mode. Right? > > right. > > > > > Let's assume that MR and HA can run dynamic routing protocol and prefix > table is not pre-configured. > > when the MR and HA run a dynamic routing protocol there is > no need to include an prefix information in the Binding > Update. infact the HA should not try to determine the > prefix from the Binding Update. the routing protocol updates > will carry the prefix information. do you think we need an > explicit flag in the Binding Update for this? > Yes, I thought an explicit flag is required for HA to properly handle this situation. /Jongkeun > > Vijay > > > > > If MR try to do implicit binding, by the draft, MR cannot set up the bi- > directional tunnel with its HA because HA will send BACK with `143' status > > code(Mobile Network Prefix Information information unavailable) for the > requested BU. > > > > I think HA should allow the implicit BU from MR that runs dynamic > routing protocol because the draft says that prefix table is an optional > data structure > > from the terminology description of section 2. Or, the draft should say > prefix table MUST be maintained by HA. > > > > > > > > It looks like unclear to me. Could you explain that for me? > > > > > > > > Best Regards, > > > > /Jongkeun From nemo-admin@ietf.org Thu Jul 3 01:44:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16456 for ; Thu, 3 Jul 2003 01:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xwsz-0006gY-Cu; Thu, 03 Jul 2003 01:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xws7-0006gB-7X for nemo@optimus.ietf.org; Thu, 03 Jul 2003 01:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16416 for ; Thu, 3 Jul 2003 01:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xws4-00038w-00 for nemo@ietf.org; Thu, 03 Jul 2003 01:43:04 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Xws3-00038t-00 for nemo@ietf.org; Thu, 03 Jul 2003 01:43:03 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h635xIW36113; Thu, 3 Jul 2003 14:59:18 +0900 (KST) (envelope-from eun) Date: Thu, 3 Jul 2003 14:59:18 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Message-ID: <20030703145918.A35770@mmlab.snu.ac.kr> References: <20030702185301.A24813@mmlab.snu.ac.kr> <3F02B21E.6040102@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F02B21E.6040102@motorola.com>; from alexandru.petrescu@motorola.com on Wed, Jul 02, 2003 at 12:21:18PM +0200 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Thank you for your kind reply. Please see inlines. > > And I have another question on the implementation of nested mobile > > networks. For example, let's think about following topology. > > > > Internet | AR | Parent MR | Child MR > > > > In the figure, Parent MR may autoconfigure its CoA after it listens > > RA of AR. Then, Child MR may autoconfigure its CoA after it listens > > RA of Parent MR. After that, if Parent MR listens Child MR's RA, > > Parent MR configures new CoA according to Child MR's RA ? > > In this particular configuration, I do not think that Parent MR > configures a CoA based on the Child MR RA. There are two reasons for that. > > One is that according to the stateless autoconfiguration mechanisms a > router will not autoconfigure an address on an interface based on > received RA's. Parent MR is a router, so. Then, how MR's egress interface configures its CoA when it moves into a foreign link ? Doesn't it need RA from foreign link ? > > The other is that Child MR is, in fact, visiting the network of Parent > MR; when a MR is visiting, it acts as a host on its egress interface, > not as a router. Thus it will not send RA's on its egress interface if > it is not at home, so Parent MR does not get RA's from Child MR. I wonder if parent MR's egress interrface listen the RA of child MR's ingress interface. (Child MR's ingress interface may broadcast its RA for its VMNs.) And how can we distinguish egress interface from ingress interface physically ? > There is also a widely acknolwedged problem of "disconnected" operation > that was mentioned very early. > > Have you encountered some similar problems? Could you breifly explain about "disconnected" operation ? Regards, Eun Kyoung From exim@www1.ietf.org Thu Jul 3 01:44:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16471 for ; Thu, 3 Jul 2003 01:44:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xwt3-0006hX-Ct for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 01:44:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h635i5wm025755 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 01:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xwt3-0006hK-9Y for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 01:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16449 for ; Thu, 3 Jul 2003 01:44:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xwt0-0003Ak-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 01:44:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xwsz-0003Ah-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 01:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xwsz-0006gY-Cu; Thu, 03 Jul 2003 01:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xws7-0006gB-7X for nemo@optimus.ietf.org; Thu, 03 Jul 2003 01:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16416 for ; Thu, 3 Jul 2003 01:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xws4-00038w-00 for nemo@ietf.org; Thu, 03 Jul 2003 01:43:04 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 19Xws3-00038t-00 for nemo@ietf.org; Thu, 03 Jul 2003 01:43:03 -0400 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h635xIW36113; Thu, 3 Jul 2003 14:59:18 +0900 (KST) (envelope-from eun) Date: Thu, 3 Jul 2003 14:59:18 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Message-ID: <20030703145918.A35770@mmlab.snu.ac.kr> References: <20030702185301.A24813@mmlab.snu.ac.kr> <3F02B21E.6040102@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F02B21E.6040102@motorola.com>; from alexandru.petrescu@motorola.com on Wed, Jul 02, 2003 at 12:21:18PM +0200 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Thank you for your kind reply. Please see inlines. > > And I have another question on the implementation of nested mobile > > networks. For example, let's think about following topology. > > > > Internet | AR | Parent MR | Child MR > > > > In the figure, Parent MR may autoconfigure its CoA after it listens > > RA of AR. Then, Child MR may autoconfigure its CoA after it listens > > RA of Parent MR. After that, if Parent MR listens Child MR's RA, > > Parent MR configures new CoA according to Child MR's RA ? > > In this particular configuration, I do not think that Parent MR > configures a CoA based on the Child MR RA. There are two reasons for that. > > One is that according to the stateless autoconfiguration mechanisms a > router will not autoconfigure an address on an interface based on > received RA's. Parent MR is a router, so. Then, how MR's egress interface configures its CoA when it moves into a foreign link ? Doesn't it need RA from foreign link ? > > The other is that Child MR is, in fact, visiting the network of Parent > MR; when a MR is visiting, it acts as a host on its egress interface, > not as a router. Thus it will not send RA's on its egress interface if > it is not at home, so Parent MR does not get RA's from Child MR. I wonder if parent MR's egress interrface listen the RA of child MR's ingress interface. (Child MR's ingress interface may broadcast its RA for its VMNs.) And how can we distinguish egress interface from ingress interface physically ? > There is also a widely acknolwedged problem of "disconnected" operation > that was mentioned very early. > > Have you encountered some similar problems? Could you breifly explain about "disconnected" operation ? Regards, Eun Kyoung From nemo-admin@ietf.org Thu Jul 3 03:53:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01626 for ; Thu, 3 Jul 2003 03:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xyto-00033C-Qw; Thu, 03 Jul 2003 03:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XytO-00032r-Eu for nemo@optimus.ietf.org; Thu, 03 Jul 2003 03:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01585 for ; Thu, 3 Jul 2003 03:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XytL-00041a-00 for nemo@ietf.org; Thu, 03 Jul 2003 03:52:31 -0400 Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi) by ietf-mx with esmtp (Exim 4.12) id 19XytK-00041X-00 for nemo@ietf.org; Thu, 03 Jul 2003 03:52:30 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA22433 for ; Thu, 3 Jul 2003 10:52:30 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma022424; Thu, 3 Jul 03 10:52:09 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (Postfix) with ESMTP id BC25318C1A8; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h637q1F5016136; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Received: from localhost (lpetande@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h637q1rd016133; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST) From: Henrik Petander To: Alexandru Petrescu Cc: Ralph Droms , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt In-Reply-To: <3F02D6E1.5020701@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , On Wed, 2 Jul 2003, Alexandru Petrescu wrote: > Ralph Droms wrote: > > Following up on our conversation a couple of months ago about using > > DHCPv6 PD for prefix delegation to mobile routers, I've published > > "DHCPv6 Prefix Delegation for NEMO" > > . This draft describes the use of > > DHCPv6 to meet my understanding of the requirements for prefix > > delegation to mobile routers. Comments welcome... > > I'm happy this draft exists and is up for comments. I think that the way > it suggests behaviour of PD between MR and HA is very good for the > simplest mobile network configurations. Yes, this seems like an easy way to allow a mobile node to become a mobile router e.g. when user attaches a PDA to her mobile phone. > > > Other updates to the HA data structures required as a side effect of > > prefix delegation are specified by the particular network mobility > > protocol. For example, in the case of "Basic Network Mobility > > Support" [8], the HA would add an entry in its binding cache > > registering the delegated prefix to the MR to which the prefix was > > delegated. > > I don't think that any proposed solution would involve triggering > additions of BC entries as a result of PD operations. Adding entries in > the BC is exclusively a result of Binding messaging, in my understanding. I guess the prefix should be added to the prefix table instead. Then the HA could authenticate MR as being authorized to send BUs for the delegated prefix and MR could also send BUs without including explicit prefix information. Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From exim@www1.ietf.org Thu Jul 3 03:53:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01644 for ; Thu, 3 Jul 2003 03:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xytt-00034A-V9 for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 03:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h637r5Sw011786 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 03:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xytt-000341-M2 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 03:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01595 for ; Thu, 3 Jul 2003 03:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xytr-00041u-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 03:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xytq-00041r-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 03:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xyto-00033C-Qw; Thu, 03 Jul 2003 03:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XytO-00032r-Eu for nemo@optimus.ietf.org; Thu, 03 Jul 2003 03:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01585 for ; Thu, 3 Jul 2003 03:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XytL-00041a-00 for nemo@ietf.org; Thu, 03 Jul 2003 03:52:31 -0400 Received: from tml.hut.fi ([130.233.44.1] helo=tml-gw.tml.hut.fi) by ietf-mx with esmtp (Exim 4.12) id 19XytK-00041X-00 for nemo@ietf.org; Thu, 03 Jul 2003 03:52:30 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA22433 for ; Thu, 3 Jul 2003 10:52:30 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma022424; Thu, 3 Jul 03 10:52:09 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (Postfix) with ESMTP id BC25318C1A8; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id h637q1F5016136; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Received: from localhost (lpetande@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id h637q1rd016133; Thu, 3 Jul 2003 10:52:01 +0300 (EEST) Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST) From: Henrik Petander To: Alexandru Petrescu Cc: Ralph Droms , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt In-Reply-To: <3F02D6E1.5020701@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , On Wed, 2 Jul 2003, Alexandru Petrescu wrote: > Ralph Droms wrote: > > Following up on our conversation a couple of months ago about using > > DHCPv6 PD for prefix delegation to mobile routers, I've published > > "DHCPv6 Prefix Delegation for NEMO" > > . This draft describes the use of > > DHCPv6 to meet my understanding of the requirements for prefix > > delegation to mobile routers. Comments welcome... > > I'm happy this draft exists and is up for comments. I think that the way > it suggests behaviour of PD between MR and HA is very good for the > simplest mobile network configurations. Yes, this seems like an easy way to allow a mobile node to become a mobile router e.g. when user attaches a PDA to her mobile phone. > > > Other updates to the HA data structures required as a side effect of > > prefix delegation are specified by the particular network mobility > > protocol. For example, in the case of "Basic Network Mobility > > Support" [8], the HA would add an entry in its binding cache > > registering the delegated prefix to the MR to which the prefix was > > delegated. > > I don't think that any proposed solution would involve triggering > additions of BC entries as a result of PD operations. Adding entries in > the BC is exclusively a result of Binding messaging, in my understanding. I guess the prefix should be added to the prefix table instead. Then the HA could authenticate MR as being authorized to send BUs for the delegated prefix and MR could also send BUs without including explicit prefix information. Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From nemo-admin@ietf.org Thu Jul 3 05:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03545 for ; Thu, 3 Jul 2003 05:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0Nl-0005Ko-1C; Thu, 03 Jul 2003 05:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xzkk-0004Xr-VK for nemo@optimus.ietf.org; Thu, 03 Jul 2003 04:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02629 for ; Thu, 3 Jul 2003 04:47:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xzki-0004Jp-00 for nemo@ietf.org; Thu, 03 Jul 2003 04:47:40 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19Xzkh-0004Jh-00 for nemo@ietf.org; Thu, 03 Jul 2003 04:47:39 -0400 Received: from stonehenge.ac.upc.es (stonehenge.ac.upc.es [147.83.32.6]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h638l944009497 for ; Thu, 3 Jul 2003 10:47:09 +0200 (MET DST) From: Conferencia ew2004 Received: (from ew2004@localhost) by stonehenge.ac.upc.es (8.12.8/8.12.8) id h638l9nB009307 for nemo@ietf.org; Thu, 3 Jul 2003 10:47:09 +0200 Message-Id: <200307030847.h638l9nB009307@stonehenge.ac.upc.es> To: nemo@ietf.org Date: Thu, 3 Jul 2003 10:47:09 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Subject: [nemo] nemo-request@ietf.org Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , From exim@www1.ietf.org Thu Jul 3 05:28:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03563 for ; Thu, 3 Jul 2003 05:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0Ns-0005Lk-15 for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 05:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h639S8vG020558 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 05:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0Nr-0005LV-UM for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 05:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03536 for ; Thu, 3 Jul 2003 05:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0No-0004Z1-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 05:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y0No-0004Yy-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 05:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0Nl-0005Ko-1C; Thu, 03 Jul 2003 05:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xzkk-0004Xr-VK for nemo@optimus.ietf.org; Thu, 03 Jul 2003 04:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02629 for ; Thu, 3 Jul 2003 04:47:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xzki-0004Jp-00 for nemo@ietf.org; Thu, 03 Jul 2003 04:47:40 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19Xzkh-0004Jh-00 for nemo@ietf.org; Thu, 03 Jul 2003 04:47:39 -0400 Received: from stonehenge.ac.upc.es (stonehenge.ac.upc.es [147.83.32.6]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h638l944009497 for ; Thu, 3 Jul 2003 10:47:09 +0200 (MET DST) From: Conferencia ew2004 Received: (from ew2004@localhost) by stonehenge.ac.upc.es (8.12.8/8.12.8) id h638l9nB009307 for nemo@ietf.org; Thu, 3 Jul 2003 10:47:09 +0200 Message-Id: <200307030847.h638l9nB009307@stonehenge.ac.upc.es> To: nemo@ietf.org Date: Thu, 3 Jul 2003 10:47:09 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Subject: [nemo] nemo-request@ietf.org Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , From nemo-admin@ietf.org Thu Jul 3 05:42:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03973 for ; Thu, 3 Jul 2003 05:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0bJ-0005p7-82; Thu, 03 Jul 2003 05:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0an-0005op-Fx for nemo@optimus.ietf.org; Thu, 03 Jul 2003 05:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03955 for ; Thu, 3 Jul 2003 05:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0ak-0004gS-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:41:26 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Y0aj-0004gO-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:41:25 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h639fQhA028498; Thu, 3 Jul 2003 02:41:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h639fMSR009669; Thu, 3 Jul 2003 04:41:23 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 07C1D2EC86; Thu, 3 Jul 2003 11:41:22 +0200 (CEST) Message-ID: <3F03FA41.5090407@motorola.com> Date: Thu, 03 Jul 2003 11:41:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] References: <20030702185301.A24813@mmlab.snu.ac.kr> <3F02B21E.6040102@motorola.com> <20030703145918.A35770@mmlab.snu.ac.kr> In-Reply-To: <20030703145918.A35770@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eun Kyoung Paik wrote: > Thank you for your kind reply. Please see inlines. > >>> And I have another question on the implementation of nested >>> mobile networks. For example, let's think about following >>> topology. >>> >>> Internet | AR | Parent MR | Child MR >>> >>> In the figure, Parent MR may autoconfigure its CoA after it >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after >>> it listens RA of Parent MR. After that, if Parent MR listens >>> Child MR's RA, Parent MR configures new CoA according to Child >>> MR's RA ? >> >> In this particular configuration, I do not think that Parent MR >> configures a CoA based on the Child MR RA. There are two reasons >> for that. >> >> One is that according to the stateless autoconfiguration mechanisms >> a router will not autoconfigure an address on an interface based >> on received RA's. Parent MR is a router, so. > > Then, how MR's egress interface configures its CoA when it moves into > a foreign link ? Doesn't it need RA from foreign link ? Yes, exactly, it does need one. That's why the egress interface of a MR will act as if it were belonging to a host (not a router) when visiting a foreign network. >> The other is that Child MR is, in fact, visiting the network of >> Parent MR; when a MR is visiting, it acts as a host on its egress >> interface, not as a router. Thus it will not send RA's on its >> egress interface if it is not at home, so Parent MR does not get >> RA's from Child MR. > > > I wonder if parent MR's egress interrface listen the RA of child MR's > ingress interface. A picture would help. My picture is that Parent MR uses its egress to connect to AR and ingress to connect to Child MR. Child MR uses its egress to connect to Parent and its ingress to connect to its mobile link. In general, I think the MR's _ingress_ interface will listen for RA's but will not use it to autoconfigure addresses. The MR's _egress_ interface, when in a foreign link, will listen to RA's from AR and will autoconfigure CoA. Since the Child MR is acting like the parent MR, and child's egress interface does not send RA (because it acts as a host on that interface) then parent will not see any RA's coming from child MR. > (Child MR's ingress interface may broadcast its RA for its VMNs.) Yes, Child MR's ingress interface MUST broadcast RA (but not the egress). Right? > And how can we distinguish egress interface from ingress interface > physically ? That's a good question and in one implementation that is a "knob", that is like a turning button, like a kernel variable that says which interface is "egress". > Could you breifly explain about "disconnected" operation ? Ok, maybe "disconnected operation" is my name for it, but the issue was mentioned under other names, where two nested mobile networks can't talk to each other if their respective HA's are not available. Many discussions in the archives. Many pros and cons of this being or not being a problem. Alex GBU From exim@www1.ietf.org Thu Jul 3 05:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03988 for ; Thu, 3 Jul 2003 05:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0bL-0005qA-Md for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 05:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h639g3r7022440 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 05:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0bL-0005pr-Fs for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 05:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03961 for ; Thu, 3 Jul 2003 05:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0bI-0004gb-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 05:42:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y0bH-0004gY-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 05:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0bJ-0005p7-82; Thu, 03 Jul 2003 05:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0an-0005op-Fx for nemo@optimus.ietf.org; Thu, 03 Jul 2003 05:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03955 for ; Thu, 3 Jul 2003 05:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0ak-0004gS-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:41:26 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Y0aj-0004gO-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:41:25 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h639fQhA028498; Thu, 3 Jul 2003 02:41:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h639fMSR009669; Thu, 3 Jul 2003 04:41:23 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 07C1D2EC86; Thu, 3 Jul 2003 11:41:22 +0200 (CEST) Message-ID: <3F03FA41.5090407@motorola.com> Date: Thu, 03 Jul 2003 11:41:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] References: <20030702185301.A24813@mmlab.snu.ac.kr> <3F02B21E.6040102@motorola.com> <20030703145918.A35770@mmlab.snu.ac.kr> In-Reply-To: <20030703145918.A35770@mmlab.snu.ac.kr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eun Kyoung Paik wrote: > Thank you for your kind reply. Please see inlines. > >>> And I have another question on the implementation of nested >>> mobile networks. For example, let's think about following >>> topology. >>> >>> Internet | AR | Parent MR | Child MR >>> >>> In the figure, Parent MR may autoconfigure its CoA after it >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after >>> it listens RA of Parent MR. After that, if Parent MR listens >>> Child MR's RA, Parent MR configures new CoA according to Child >>> MR's RA ? >> >> In this particular configuration, I do not think that Parent MR >> configures a CoA based on the Child MR RA. There are two reasons >> for that. >> >> One is that according to the stateless autoconfiguration mechanisms >> a router will not autoconfigure an address on an interface based >> on received RA's. Parent MR is a router, so. > > Then, how MR's egress interface configures its CoA when it moves into > a foreign link ? Doesn't it need RA from foreign link ? Yes, exactly, it does need one. That's why the egress interface of a MR will act as if it were belonging to a host (not a router) when visiting a foreign network. >> The other is that Child MR is, in fact, visiting the network of >> Parent MR; when a MR is visiting, it acts as a host on its egress >> interface, not as a router. Thus it will not send RA's on its >> egress interface if it is not at home, so Parent MR does not get >> RA's from Child MR. > > > I wonder if parent MR's egress interrface listen the RA of child MR's > ingress interface. A picture would help. My picture is that Parent MR uses its egress to connect to AR and ingress to connect to Child MR. Child MR uses its egress to connect to Parent and its ingress to connect to its mobile link. In general, I think the MR's _ingress_ interface will listen for RA's but will not use it to autoconfigure addresses. The MR's _egress_ interface, when in a foreign link, will listen to RA's from AR and will autoconfigure CoA. Since the Child MR is acting like the parent MR, and child's egress interface does not send RA (because it acts as a host on that interface) then parent will not see any RA's coming from child MR. > (Child MR's ingress interface may broadcast its RA for its VMNs.) Yes, Child MR's ingress interface MUST broadcast RA (but not the egress). Right? > And how can we distinguish egress interface from ingress interface > physically ? That's a good question and in one implementation that is a "knob", that is like a turning button, like a kernel variable that says which interface is "egress". > Could you breifly explain about "disconnected" operation ? Ok, maybe "disconnected operation" is my name for it, but the issue was mentioned under other names, where two nested mobile networks can't talk to each other if their respective HA's are not available. Many discussions in the archives. Many pros and cons of this being or not being a problem. Alex GBU From nemo-admin@ietf.org Thu Jul 3 08:33:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08544 for ; Thu, 3 Jul 2003 08:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3Gn-0001xo-FO; Thu, 03 Jul 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3GL-0001xR-4n for nemo@optimus.ietf.org; Thu, 03 Jul 2003 08:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08520 for ; Thu, 3 Jul 2003 08:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3GJ-0005qS-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:32:31 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19Y3GI-0005qP-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:32:31 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h63CVb1J000474; Thu, 3 Jul 2003 06:31:37 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h63CVYQ11489; Thu, 3 Jul 2003 14:31:35 +0200 (MEST) Date: Thu, 3 Jul 2003 14:19:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt To: Ralph Droms Cc: nemo@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Ralph, Thanks for writing up the draft. I noticed a typo in the last paragraph in section 3.1 ("and are may be forwarded") but more importantly I think it is unfortunate to use the term "forwarded" in that context; the packets in question are "sent" or "originated" by the HA thus they are not forwarded on the tunnel. I think making this clearer would help given that there has been some questions on the mailing list on this topic in the past. Erik From exim@www1.ietf.org Thu Jul 3 08:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08559 for ; Thu, 3 Jul 2003 08:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3Gq-0001yk-SR for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 08:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63CX4eW007600 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 08:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3Gq-0001yV-K1 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 08:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08529 for ; Thu, 3 Jul 2003 08:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3Gp-0005qf-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 08:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y3Go-0005qc-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 08:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3Gn-0001xo-FO; Thu, 03 Jul 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3GL-0001xR-4n for nemo@optimus.ietf.org; Thu, 03 Jul 2003 08:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08520 for ; Thu, 3 Jul 2003 08:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3GJ-0005qS-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:32:31 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19Y3GI-0005qP-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:32:31 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h63CVb1J000474; Thu, 3 Jul 2003 06:31:37 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h63CVYQ11489; Thu, 3 Jul 2003 14:31:35 +0200 (MEST) Date: Thu, 3 Jul 2003 14:19:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt To: Ralph Droms Cc: nemo@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Ralph, Thanks for writing up the draft. I noticed a typo in the last paragraph in section 3.1 ("and are may be forwarded") but more importantly I think it is unfortunate to use the term "forwarded" in that context; the packets in question are "sent" or "originated" by the HA thus they are not forwarded on the tunnel. I think making this clearer would help given that there has been some questions on the mailing list on this topic in the past. Erik From nemo-admin@ietf.org Thu Jul 3 08:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09070 for ; Thu, 3 Jul 2003 08:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WG-0002cY-Rv; Thu, 03 Jul 2003 08:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WA-0002cD-LR for nemo@optimus.ietf.org; Thu, 03 Jul 2003 08:48:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09049 for ; Thu, 3 Jul 2003 08:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3W9-0005z1-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:48:53 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Y3W8-0005yf-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:48:52 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h63CmKfq029590; Thu, 3 Jul 2003 08:48:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-313.cisco.com [10.82.225.57]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAK08117; Thu, 3 Jul 2003 08:48:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20030703084422.03f88a30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 08:48:10 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Cc: nemo@ietf.org In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Erik, In a private communication, I received a recommendation that section 10.4.4 of draft-ietf-mobileip-ipv6-23.txt might be a more relevant reference to cite in section 3.1: 10.4.4 Stateful Address Autoconfiguration This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [29] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node which sends DHCPv6 messages to the home agent without this support will not receive a response. If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows. Rewriting 3.1 to read, in essence: "Do what it says in section 10.4.4 of the mobile IPv6 specification" would clarify the issue. - Ralph At 02:19 PM 7/3/2003 +0200, Erik Nordmark wrote: >Ralph, > >Thanks for writing up the draft. > >I noticed a typo in the last paragraph in section 3.1 ("and are may be >forwarded") but more importantly I think it is unfortunate to use the >term "forwarded" in that context; the packets in question are "sent" >or "originated" by the HA thus they are not forwarded on the tunnel. >I think making this clearer would help given that there has been >some questions on the mailing list on this topic in the past. > > Erik From exim@www1.ietf.org Thu Jul 3 08:49:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09085 for ; Thu, 3 Jul 2003 08:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WJ-0002dU-9Q for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 08:49:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Cn3NQ010126 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 08:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WJ-0002dF-5n for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 08:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09054 for ; Thu, 3 Jul 2003 08:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3WH-0005z7-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 08:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y3WH-0005z4-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 08:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WG-0002cY-Rv; Thu, 03 Jul 2003 08:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3WA-0002cD-LR for nemo@optimus.ietf.org; Thu, 03 Jul 2003 08:48:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09049 for ; Thu, 3 Jul 2003 08:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3W9-0005z1-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:48:53 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Y3W8-0005yf-00 for nemo@ietf.org; Thu, 03 Jul 2003 08:48:52 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h63CmKfq029590; Thu, 3 Jul 2003 08:48:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-313.cisco.com [10.82.225.57]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAK08117; Thu, 3 Jul 2003 08:48:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20030703084422.03f88a30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 08:48:10 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Cc: nemo@ietf.org In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20030702093919.048d2f08@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Erik, In a private communication, I received a recommendation that section 10.4.4 of draft-ietf-mobileip-ipv6-23.txt might be a more relevant reference to cite in section 3.1: 10.4.4 Stateful Address Autoconfiguration This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [29] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node which sends DHCPv6 messages to the home agent without this support will not receive a response. If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows. Rewriting 3.1 to read, in essence: "Do what it says in section 10.4.4 of the mobile IPv6 specification" would clarify the issue. - Ralph At 02:19 PM 7/3/2003 +0200, Erik Nordmark wrote: >Ralph, > >Thanks for writing up the draft. > >I noticed a typo in the last paragraph in section 3.1 ("and are may be >forwarded") but more importantly I think it is unfortunate to use the >term "forwarded" in that context; the packets in question are "sent" >or "originated" by the HA thus they are not forwarded on the tunnel. >I think making this clearer would help given that there has been >some questions on the mailing list on this topic in the past. > > Erik From nemo-admin@ietf.org Thu Jul 3 09:29:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10072 for ; Thu, 3 Jul 2003 09:29:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y48z-0003xV-0u; Thu, 03 Jul 2003 09:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y48J-0003x0-1M for nemo@optimus.ietf.org; Thu, 03 Jul 2003 09:28:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10036 for ; Thu, 3 Jul 2003 09:28:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y48H-0006Ep-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:28:17 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19Y48G-0006Eh-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:28:16 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 94BDC6BA98 for ; Thu, 3 Jul 2003 09:27:46 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h63DRfWD018751; Thu, 3 Jul 2003 09:27:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp139.grc.nasa.gov [139.88.245.139]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h63DRYYM003827; Thu, 3 Jul 2003 09:27:36 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030703085416.017ad308@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Jul 2003 09:27:26 -0400 To: Alexandru Petrescu From: William D Ivancic Subject: Re: [nemo] Re: experiments (was: Vienna Agenda) Cc: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu In-Reply-To: <3F0391F6.6080405@motorola.com> References: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >>The following are real measured numbers for some services we have used. >>Link Practical Data Rate RTT Delay Cost >=========================================================================== >>WiFi >1.0 Mbps 100 msec Free after >>infrastructure or approximately equal to GPRS >>GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month >> Unlimited Volume >>Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute !!!! > >Confirms most of my expectations with respect to GPRS >rates/delays/dollar_cost. I'm suprised though to see "satellite" being >40kb/s (I was thinking it would be much less(?). Does the satellite >link have a sort of return path? Could I imagine acquiring sattelite >link somehow somewhere to make a FrontBox with it? > We have used two systems to date, both Globalstar. One is an MCM-8 communication system and the other an MDSS-16. Both The MCM-8 is eight 7 kbps channels multiplexed and provides bandwidth-on-demand from Globalstar and Sea Tel. This is a client/server based system and require that the first call originate from the mobile unit. If one is willing to pay, one can keep a single (or all) channel(s) up thereby keeping a VPN circuit up and allowing for remote users to initiate communications. A single channel currently cost a minumum of $0.12 per minute. Things get expensive FAST with satellites We also have used an MDSS-16 from Qualcomm which multiplexes up to 16 channels. Currently, the MDSS-16 is not commerically available. Currently it is full on bi-directional. Thus, one is paying rough $2.00 per minute for approximately 110 kbps throughput. The system was designed for aeronautical Internet applications. I understand some people have also multiplexed Iridium channels together. My understanding is that Iridium data channels are 2.4 kbps. Globalstar's are 9.6 kbps but really the usable data is approximately 7 kpbs. The advantage of both Globalstar and Iriduim is that they are low-earth-orbiting (LEO) satellites and the ground antenna systems are omni-direcectional. That means, there is no need to track the satellite. Systems like INMARSAT swift 64 require tracking for a mobile (on-the-move) vehicle. This is somewhat difficult for aircraft and boats, and is extremely difficult for land-mobile due to the rapid change in direction (90 degree turns, bouncing, off-road , etc...). The surprising thing to me regarding the LEO satellites was the extremely long delay of up to 2 or even 4 seconds. I believe this is primarily due to the multiplexing of long thin pipes and buffering to accommodate reordering and remultiplexing. In "theory", LEOs should have very short delays probably in the 100 msec range. >Billing was not taken into consideration since the billing scheme of the >access providers were themselves a moving ground (WLAN hotspots were >free but business model changing as we speak, including targetting a >"mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes >transferred, not the time length, not flat; to complicate things further >some GPRS operators make pay more if the given IPv4 address is publicly >routable non-NAT'ed, and less if NAT'ed). Ask me for more information, >or the operators themselves. In my opinion, f one is using Satellites or G3 or WiFi, the services providers are going to have to realize that they need to bill as flat rate, not per packet. If they do not bill flat rate, they will not realize nearly the market they could. Do any of you pay per packet for Internet service be it Cable Modem, Dial-Up or DSL? Why do the providers need to bill at flat-rate? Corporations need to budget. You cannot determine how many packets will be sent day-to-day, nor is it practical for a user to monitor and police their traffic (amount of traffic). Also, NATs are NOT my friend. They only cause pain and misery. NATs also make true peer-to-peer communications difficult, if not impossible. Unfortunately, there is little one can do today. Will From exim@www1.ietf.org Thu Jul 3 09:29:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10091 for ; Thu, 3 Jul 2003 09:29:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y49L-000412-87 for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 09:29:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63DTN5f015435 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 09:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y49K-00040s-Pr for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 09:29:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10066 for ; Thu, 3 Jul 2003 09:29:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y49J-0006FL-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 09:29:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y49I-0006FI-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 09:29:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y48z-0003xV-0u; Thu, 03 Jul 2003 09:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y48J-0003x0-1M for nemo@optimus.ietf.org; Thu, 03 Jul 2003 09:28:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10036 for ; Thu, 3 Jul 2003 09:28:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y48H-0006Ep-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:28:17 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19Y48G-0006Eh-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:28:16 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 94BDC6BA98 for ; Thu, 3 Jul 2003 09:27:46 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h63DRfWD018751; Thu, 3 Jul 2003 09:27:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp139.grc.nasa.gov [139.88.245.139]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h63DRYYM003827; Thu, 3 Jul 2003 09:27:36 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030703085416.017ad308@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Jul 2003 09:27:26 -0400 To: Alexandru Petrescu From: William D Ivancic Subject: Re: [nemo] Re: experiments (was: Vienna Agenda) Cc: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu In-Reply-To: <3F0391F6.6080405@motorola.com> References: <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >>The following are real measured numbers for some services we have used. >>Link Practical Data Rate RTT Delay Cost >=========================================================================== >>WiFi >1.0 Mbps 100 msec Free after >>infrastructure or approximately equal to GPRS >>GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month >> Unlimited Volume >>Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute !!!! > >Confirms most of my expectations with respect to GPRS >rates/delays/dollar_cost. I'm suprised though to see "satellite" being >40kb/s (I was thinking it would be much less(?). Does the satellite >link have a sort of return path? Could I imagine acquiring sattelite >link somehow somewhere to make a FrontBox with it? > We have used two systems to date, both Globalstar. One is an MCM-8 communication system and the other an MDSS-16. Both The MCM-8 is eight 7 kbps channels multiplexed and provides bandwidth-on-demand from Globalstar and Sea Tel. This is a client/server based system and require that the first call originate from the mobile unit. If one is willing to pay, one can keep a single (or all) channel(s) up thereby keeping a VPN circuit up and allowing for remote users to initiate communications. A single channel currently cost a minumum of $0.12 per minute. Things get expensive FAST with satellites We also have used an MDSS-16 from Qualcomm which multiplexes up to 16 channels. Currently, the MDSS-16 is not commerically available. Currently it is full on bi-directional. Thus, one is paying rough $2.00 per minute for approximately 110 kbps throughput. The system was designed for aeronautical Internet applications. I understand some people have also multiplexed Iridium channels together. My understanding is that Iridium data channels are 2.4 kbps. Globalstar's are 9.6 kbps but really the usable data is approximately 7 kpbs. The advantage of both Globalstar and Iriduim is that they are low-earth-orbiting (LEO) satellites and the ground antenna systems are omni-direcectional. That means, there is no need to track the satellite. Systems like INMARSAT swift 64 require tracking for a mobile (on-the-move) vehicle. This is somewhat difficult for aircraft and boats, and is extremely difficult for land-mobile due to the rapid change in direction (90 degree turns, bouncing, off-road , etc...). The surprising thing to me regarding the LEO satellites was the extremely long delay of up to 2 or even 4 seconds. I believe this is primarily due to the multiplexing of long thin pipes and buffering to accommodate reordering and remultiplexing. In "theory", LEOs should have very short delays probably in the 100 msec range. >Billing was not taken into consideration since the billing scheme of the >access providers were themselves a moving ground (WLAN hotspots were >free but business model changing as we speak, including targetting a >"mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes >transferred, not the time length, not flat; to complicate things further >some GPRS operators make pay more if the given IPv4 address is publicly >routable non-NAT'ed, and less if NAT'ed). Ask me for more information, >or the operators themselves. In my opinion, f one is using Satellites or G3 or WiFi, the services providers are going to have to realize that they need to bill as flat rate, not per packet. If they do not bill flat rate, they will not realize nearly the market they could. Do any of you pay per packet for Internet service be it Cable Modem, Dial-Up or DSL? Why do the providers need to bill at flat-rate? Corporations need to budget. You cannot determine how many packets will be sent day-to-day, nor is it practical for a user to monitor and police their traffic (amount of traffic). Also, NATs are NOT my friend. They only cause pain and misery. NATs also make true peer-to-peer communications difficult, if not impossible. Unfortunately, there is little one can do today. Will From nemo-admin@ietf.org Thu Jul 3 09:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10251 for ; Thu, 3 Jul 2003 09:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Bs-00045h-Pj; Thu, 03 Jul 2003 09:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Br-00045G-Sa for nemo@optimus.ietf.org; Thu, 03 Jul 2003 09:31:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10213 for ; Thu, 3 Jul 2003 09:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4Bq-0006HF-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:31:58 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Y4Bp-0006HC-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:31:57 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h63DVuhA006719; Thu, 3 Jul 2003 06:31:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h63CT0rN019795; Thu, 3 Jul 2003 07:29:02 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D3F982EC86; Thu, 3 Jul 2003 15:31:50 +0200 (CEST) Message-ID: <3F043046.6020401@motorola.com> Date: Thu, 03 Jul 2003 15:31:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Charbon Cc: IETF NEMO WG , Chan-Wah Ng , Koshiro Mitsuya , Thierry Ernst Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> In-Reply-To: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Julien Charbon wrote: > Hello all, > > We have written an Internet-Draft on the evaluation of Multi-homing > support by NEMO Basic solution. Thanks for the draft, useful analysis. Good to see that most multi-homing aspects can be featured by base spec. I have some remarks from the start. The document defines "Policy" and "Load Sharing" in a very loose way (at least when compared to the specific specification of e.g. deriving a Home Address from the MNP). So maybe a more concrete definition of Load Sharing is needed. > Load-sharing: This is achieved when the traffic load is distributed > among different connections between the mobile network and the > Internet. YEs, this is possible with the current base spec, I think. > As long as the protocol uses all active connections simultaneously, > Load-sharing will have been deemed achieved. What is "simultaneously" more exactly? In the setting I use, both access systems are up and active simultaneously. If I switch the MR very quickly between one access system to another then I can give the impression of simultaneous connections. Would this qualify as "simultaneous"? And I will not ask what is the "Policy" problem more exactly :-) > 2.3 Solution behavior > > o Against Load-Sharing: > > 1. Doesn't specify the simultaneous use of several bi-directional > tunnels but doesn't prevent it. Ok. > 2. Doesn't specify the binding of multiple CoAs against the same MNP > but doesn't prevent it. Ok. > 3. Doesn't provides a method to identify each CoA but doesn't > prevent it: Ok. > Here an explanation of one of possibility of this management: > > As long as there is no specific field for a CoA ID, the solution have > to use a field present in current Prefix-BU definition. Probably yes, in case that explicit, or explicit combined modes are used. And implicit mode? > The only common field is each type of Prefix-BU - Implicit, Explicit > and Explicit combined - is the Home Address Option in the Destination > Option Header [Section 6.3 Home Address Option] [13]. Yes, exactly, only the Home Address is common. > Thus a NEMO implementation can create a Home Address for each egress > interface. And when a CoA on an egress interface change, use in > Prefix-BU the corresponding Home Address in the Home Address Option. > An example to make clear this behavior: > > HA Routing Table & Binding Cache before: > > > +===============+=================+=========================+ | Home > Address | Care-of Address | MN Prefix/Prefix Length | > +===============+=================+=========================+ | HoA-1 > | CoA-1 | MNP-1/Length-1 | | HoA-2 | CoA-2 | > MNP-1/Length-1 | > +===============+=================+=========================+ I think the base spec tries to say that the prefix is neither in the RT nor in the BC, but in the Prefix Table. No? > Here HoA-x is the Home Address corresponding to the egress interface > x on which is assigned CoA-x. Now the HA receives a Prefix-BU > because CoA-1 has changed to CoA-New. > > The Prefix-BU: > > > +===============+=================+=========================+ | Home > Address | Care-of Address | MN Prefix/Prefix Length | > +===============+=================+=========================+ | HoA-1 > | CoA-New | MNP-1/Length-1 | > +===============+=================+=========================+ Yes, if Prefix-BU (explicit or explicit-combined modes). No, if implicit mode; in implicit mode there is neither prefix nor prefix len in the BU. > And an example of creation of Home Address according to egress > interface can be: > > Egress Interface 1 -> EUI-64-1 -> Home Address for this interface: > MNP:EUI-64-1 > > Egress Interface 2 -> EUI-64-2 -> Home Address for this interface: > MNP:EUI-64-2 Would the scheme work if EUI-64 addresses are not used? For example, in many configurations manual addresses are assigned to interfaces (not with EUI-64). By your analysis, and for my clarification, is this method somehow suggesting that the basic solution as is does not support "load sharing multi-homing" because the Home Address assigned of the egress interface of the Mobile Router is not derived from MNP? And following this reasoning, is the proposed method trying to suggest that, for a basic solution to support multi-homing load sharing, it must absolutely necessarily have Home Addresses on the egress interface of the MR derived from the MNP? Should I also deduce that, if implicit mode is used, then there is not even the smallest chance to have multi-homing load sharing? I hope I didn't interpret the analysis wrong. > Maybe the solution should specify this behavior because it is very > specific to NEMO. > > o Against dynamic Load-sharing and Policy: > > The solution didn't specify anything about a kind of preference/ > policy field, but maybe an NEMO implementation can use some part of > the reserved field in the MNP Option [Section 4.3. Mobile Network > Prefix Option] [1] or in a sub-option. Sometimes I don't think there's need for more bits in the BU to specify preferences. On another hand, if there is indeed a need for new bits to specify preferences then I think the same need for preferences related to a CoA are valid for Mobile Hosts too, not only Mobile Routers, no? What do you think? > o Multiple CoAs for the same MNP: > > The proposed solution doesn't have to specify anything one this > subject, just to support it. But a paragraph on this purpose can be > helpful for implementation's developers. Yes, maybe somewhere it should say that it is possible to have several Care-of Addresses for the same MNP. But I think it is easily understandable that this is possible since the tables pictured in the draft-charbon clearly show some entries in some tables that associate same MNP to different CoA's. Alex GBU From exim@www1.ietf.org Thu Jul 3 09:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10266 for ; Thu, 3 Jul 2003 09:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Bu-00046j-95 for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 09:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63DW24w015785 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 09:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Bu-00046W-56 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 09:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10230 for ; Thu, 3 Jul 2003 09:31:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4Bs-0006HP-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 09:32:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y4Br-0006HM-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 09:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Bs-00045h-Pj; Thu, 03 Jul 2003 09:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4Br-00045G-Sa for nemo@optimus.ietf.org; Thu, 03 Jul 2003 09:31:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10213 for ; Thu, 3 Jul 2003 09:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4Bq-0006HF-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:31:58 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19Y4Bp-0006HC-00 for nemo@ietf.org; Thu, 03 Jul 2003 09:31:57 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h63DVuhA006719; Thu, 3 Jul 2003 06:31:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h63CT0rN019795; Thu, 3 Jul 2003 07:29:02 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D3F982EC86; Thu, 3 Jul 2003 15:31:50 +0200 (CEST) Message-ID: <3F043046.6020401@motorola.com> Date: Thu, 03 Jul 2003 15:31:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Charbon Cc: IETF NEMO WG , Chan-Wah Ng , Koshiro Mitsuya , Thierry Ernst Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> In-Reply-To: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julien Charbon wrote: > Hello all, > > We have written an Internet-Draft on the evaluation of Multi-homing > support by NEMO Basic solution. Thanks for the draft, useful analysis. Good to see that most multi-homing aspects can be featured by base spec. I have some remarks from the start. The document defines "Policy" and "Load Sharing" in a very loose way (at least when compared to the specific specification of e.g. deriving a Home Address from the MNP). So maybe a more concrete definition of Load Sharing is needed. > Load-sharing: This is achieved when the traffic load is distributed > among different connections between the mobile network and the > Internet. YEs, this is possible with the current base spec, I think. > As long as the protocol uses all active connections simultaneously, > Load-sharing will have been deemed achieved. What is "simultaneously" more exactly? In the setting I use, both access systems are up and active simultaneously. If I switch the MR very quickly between one access system to another then I can give the impression of simultaneous connections. Would this qualify as "simultaneous"? And I will not ask what is the "Policy" problem more exactly :-) > 2.3 Solution behavior > > o Against Load-Sharing: > > 1. Doesn't specify the simultaneous use of several bi-directional > tunnels but doesn't prevent it. Ok. > 2. Doesn't specify the binding of multiple CoAs against the same MNP > but doesn't prevent it. Ok. > 3. Doesn't provides a method to identify each CoA but doesn't > prevent it: Ok. > Here an explanation of one of possibility of this management: > > As long as there is no specific field for a CoA ID, the solution have > to use a field present in current Prefix-BU definition. Probably yes, in case that explicit, or explicit combined modes are used. And implicit mode? > The only common field is each type of Prefix-BU - Implicit, Explicit > and Explicit combined - is the Home Address Option in the Destination > Option Header [Section 6.3 Home Address Option] [13]. Yes, exactly, only the Home Address is common. > Thus a NEMO implementation can create a Home Address for each egress > interface. And when a CoA on an egress interface change, use in > Prefix-BU the corresponding Home Address in the Home Address Option. > An example to make clear this behavior: > > HA Routing Table & Binding Cache before: > > > +===============+=================+=========================+ | Home > Address | Care-of Address | MN Prefix/Prefix Length | > +===============+=================+=========================+ | HoA-1 > | CoA-1 | MNP-1/Length-1 | | HoA-2 | CoA-2 | > MNP-1/Length-1 | > +===============+=================+=========================+ I think the base spec tries to say that the prefix is neither in the RT nor in the BC, but in the Prefix Table. No? > Here HoA-x is the Home Address corresponding to the egress interface > x on which is assigned CoA-x. Now the HA receives a Prefix-BU > because CoA-1 has changed to CoA-New. > > The Prefix-BU: > > > +===============+=================+=========================+ | Home > Address | Care-of Address | MN Prefix/Prefix Length | > +===============+=================+=========================+ | HoA-1 > | CoA-New | MNP-1/Length-1 | > +===============+=================+=========================+ Yes, if Prefix-BU (explicit or explicit-combined modes). No, if implicit mode; in implicit mode there is neither prefix nor prefix len in the BU. > And an example of creation of Home Address according to egress > interface can be: > > Egress Interface 1 -> EUI-64-1 -> Home Address for this interface: > MNP:EUI-64-1 > > Egress Interface 2 -> EUI-64-2 -> Home Address for this interface: > MNP:EUI-64-2 Would the scheme work if EUI-64 addresses are not used? For example, in many configurations manual addresses are assigned to interfaces (not with EUI-64). By your analysis, and for my clarification, is this method somehow suggesting that the basic solution as is does not support "load sharing multi-homing" because the Home Address assigned of the egress interface of the Mobile Router is not derived from MNP? And following this reasoning, is the proposed method trying to suggest that, for a basic solution to support multi-homing load sharing, it must absolutely necessarily have Home Addresses on the egress interface of the MR derived from the MNP? Should I also deduce that, if implicit mode is used, then there is not even the smallest chance to have multi-homing load sharing? I hope I didn't interpret the analysis wrong. > Maybe the solution should specify this behavior because it is very > specific to NEMO. > > o Against dynamic Load-sharing and Policy: > > The solution didn't specify anything about a kind of preference/ > policy field, but maybe an NEMO implementation can use some part of > the reserved field in the MNP Option [Section 4.3. Mobile Network > Prefix Option] [1] or in a sub-option. Sometimes I don't think there's need for more bits in the BU to specify preferences. On another hand, if there is indeed a need for new bits to specify preferences then I think the same need for preferences related to a CoA are valid for Mobile Hosts too, not only Mobile Routers, no? What do you think? > o Multiple CoAs for the same MNP: > > The proposed solution doesn't have to specify anything one this > subject, just to support it. But a paragraph on this purpose can be > helpful for implementation's developers. Yes, maybe somewhere it should say that it is possible to have several Care-of Addresses for the same MNP. But I think it is easily understandable that this is possible since the tables pictured in the draft-charbon clearly show some entries in some tables that associate same MNP to different CoA's. Alex GBU From nemo-admin@ietf.org Thu Jul 3 10:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13202 for ; Thu, 3 Jul 2003 10:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y50D-0005nh-NF; Thu, 03 Jul 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4zW-0005nM-22 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 10:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13193 for ; Thu, 3 Jul 2003 10:23:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4zT-00073q-00 for nemo@ietf.org; Thu, 03 Jul 2003 10:23:15 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19Y4zT-00073B-00 for nemo@ietf.org; Thu, 03 Jul 2003 10:23:15 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7812468971 for ; Thu, 3 Jul 2003 10:22:44 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h63EMhWD008042; Thu, 3 Jul 2003 10:22:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp139.grc.nasa.gov [139.88.245.139]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h63EMfYM002555; Thu, 3 Jul 2003 10:22:42 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030703093248.01828d00@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Jul 2003 10:22:34 -0400 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: "T.J. Kniveton" , nemo@ietf.org In-Reply-To: <3F031F86.10B8B46B@iprg.nokia.com> References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > 1) Question regarding section 8. Support for Dynamic Routing Protocols > > "In the solution described so far, forwarding to the Mobile Network at the > > Home Agent is set up when the Home Agent receives a Binding Update from the > > Mobile Router. An alternative to this is for the Home Agent and the Mobile > > Router to run a intra-domain routing protocol like RIPng [6] and OSPF [7] > > through the bi-directional tunnel." > > > > > 1.1) Has anyone given some though to policy base routing over tunnels that > > are coming up and going down? The aeronautics community still has this on > > their wish list. > >I am not sure I read any previous mails on this. can you tell >me more? Hello Vijay, let me try and give the aeronautic example. The aero community (FAA, ICAO and other multinational political organizations) has an air/ground link called VDL (VHF Data Link) which comes in four flavors. This link is robust and used throughout the world. Ten years in the future, the aero community hopes to get everybody to use packetized communication at roughly 8 kbps per link shared among a number of users. Current requirement ALL COMMAND and CONTROL is required to use VDL links or INMARSAT. (IMHO a very poor and foolish requirement, but this community is used to circuit-base communication system, not networks and packet-based communications nor open systems. Two specific things that the aero community has written as requirements is Load Sharing and Policy Based Routing. If I have two 8 kbps links available, I would like to load share (assume these links are already paid for and free to the user - poor assumption, but one that is used). OK, so maybe it makes some sense to load share between the two 8 kbps links. Now let's add two more satellite links: INMARSAT swift 64 (64 kbps) and Connexion by Boeing (4 Mbps on, 100s of kbps off). Does load sharing make sense here? Why not use the Connexion link as the entertainment services are already paying for the link. Command and Control will not even be noticed and can be give highest priority. Remember, if I load share the Swift 64, I have to pay that bill and it is quite high. Pay per packet or per connect time. Try budgeting that. >>>> Regarding multi-homing, I believe in the vast majority of the cases, one would rather pick the best link and not load share because of cost. Now, if I already had flat-rate billing and a GRPS and CDMA service paid for and both links active, I may wish to load share. <<<<< Given these same four links, Policy states I must send command and control over VDL or INMARSAT. Thus the policy based routing requirement. Now, when I fly over the oceans, I loose VDL so policy says route via INMARSAT if available. If VDL is active route through VDL. Never route Command and Control through Connexion. So, interfaces and tunnels are coming up and down on the mobile unit. How does one write policy? Better yet, they also would like to write policy on the ground that directs traffic to take particular routes through the ground network. Not to easy if everything resides in tunnels - of course we haven't even considered secure tunnels to hide things. Now let me add some more reality to the mess. (This is my current understanding as explained to me by various pilots. I am open to correction.) Commercial aircraft today generally only have one active VDL circuit that is performing packetized communication. The other is used for voice. They are not combined (i.e. VOIP). Because the satellite time costs so much, the INMARSAT system generally is not powered on unless the VDL link is lost. So in reality, only one link is active. The question I keep raising to this community is why policy-based routing and load sharing when in reality only one link is active. I also suspect that I could obtain much higher QoS if I used the Connexion link ( or similar) for command and control when available and could sufficiently secure those messages with today's technologies. IMHO, What is really needed is some type of quality of service requirement such that command and control is highest priority. Will From exim@www1.ietf.org Thu Jul 3 10:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13217 for ; Thu, 3 Jul 2003 10:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y50H-0005oh-St for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 10:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63EO5gX022356 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 10:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y50H-0005oV-NU for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:24:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13198 for ; Thu, 3 Jul 2003 10:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y50F-00074M-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 10:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y50F-00074J-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 10:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y50D-0005nh-NF; Thu, 03 Jul 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4zW-0005nM-22 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 10:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13193 for ; Thu, 3 Jul 2003 10:23:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y4zT-00073q-00 for nemo@ietf.org; Thu, 03 Jul 2003 10:23:15 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19Y4zT-00073B-00 for nemo@ietf.org; Thu, 03 Jul 2003 10:23:15 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7812468971 for ; Thu, 3 Jul 2003 10:22:44 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h63EMhWD008042; Thu, 3 Jul 2003 10:22:43 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp139.grc.nasa.gov [139.88.245.139]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h63EMfYM002555; Thu, 3 Jul 2003 10:22:42 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030703093248.01828d00@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Jul 2003 10:22:34 -0400 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: "T.J. Kniveton" , nemo@ietf.org In-Reply-To: <3F031F86.10B8B46B@iprg.nokia.com> References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > 1) Question regarding section 8. Support for Dynamic Routing Protocols > > "In the solution described so far, forwarding to the Mobile Network at the > > Home Agent is set up when the Home Agent receives a Binding Update from the > > Mobile Router. An alternative to this is for the Home Agent and the Mobile > > Router to run a intra-domain routing protocol like RIPng [6] and OSPF [7] > > through the bi-directional tunnel." > > > > > 1.1) Has anyone given some though to policy base routing over tunnels that > > are coming up and going down? The aeronautics community still has this on > > their wish list. > >I am not sure I read any previous mails on this. can you tell >me more? Hello Vijay, let me try and give the aeronautic example. The aero community (FAA, ICAO and other multinational political organizations) has an air/ground link called VDL (VHF Data Link) which comes in four flavors. This link is robust and used throughout the world. Ten years in the future, the aero community hopes to get everybody to use packetized communication at roughly 8 kbps per link shared among a number of users. Current requirement ALL COMMAND and CONTROL is required to use VDL links or INMARSAT. (IMHO a very poor and foolish requirement, but this community is used to circuit-base communication system, not networks and packet-based communications nor open systems. Two specific things that the aero community has written as requirements is Load Sharing and Policy Based Routing. If I have two 8 kbps links available, I would like to load share (assume these links are already paid for and free to the user - poor assumption, but one that is used). OK, so maybe it makes some sense to load share between the two 8 kbps links. Now let's add two more satellite links: INMARSAT swift 64 (64 kbps) and Connexion by Boeing (4 Mbps on, 100s of kbps off). Does load sharing make sense here? Why not use the Connexion link as the entertainment services are already paying for the link. Command and Control will not even be noticed and can be give highest priority. Remember, if I load share the Swift 64, I have to pay that bill and it is quite high. Pay per packet or per connect time. Try budgeting that. >>>> Regarding multi-homing, I believe in the vast majority of the cases, one would rather pick the best link and not load share because of cost. Now, if I already had flat-rate billing and a GRPS and CDMA service paid for and both links active, I may wish to load share. <<<<< Given these same four links, Policy states I must send command and control over VDL or INMARSAT. Thus the policy based routing requirement. Now, when I fly over the oceans, I loose VDL so policy says route via INMARSAT if available. If VDL is active route through VDL. Never route Command and Control through Connexion. So, interfaces and tunnels are coming up and down on the mobile unit. How does one write policy? Better yet, they also would like to write policy on the ground that directs traffic to take particular routes through the ground network. Not to easy if everything resides in tunnels - of course we haven't even considered secure tunnels to hide things. Now let me add some more reality to the mess. (This is my current understanding as explained to me by various pilots. I am open to correction.) Commercial aircraft today generally only have one active VDL circuit that is performing packetized communication. The other is used for voice. They are not combined (i.e. VOIP). Because the satellite time costs so much, the INMARSAT system generally is not powered on unless the VDL link is lost. So in reality, only one link is active. The question I keep raising to this community is why policy-based routing and load sharing when in reality only one link is active. I also suspect that I could obtain much higher QoS if I used the Connexion link ( or similar) for command and control when available and could sufficiently secure those messages with today's technologies. IMHO, What is really needed is some type of quality of service requirement such that command and control is highest priority. Will From nemo-admin@ietf.org Thu Jul 3 13:00:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24656 for ; Thu, 3 Jul 2003 13:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7RB-00081R-JU; Thu, 03 Jul 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7QU-00080g-J3 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 12:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24606 for ; Thu, 3 Jul 2003 12:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7QS-0003D0-00 for nemo@ietf.org; Thu, 03 Jul 2003 12:59:16 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19Y7QS-0003Cx-00 for nemo@ietf.org; Thu, 03 Jul 2003 12:59:16 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h63GxFnD012195 for ; Thu, 3 Jul 2003 09:59:15 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h63FuLrN008461 for ; Thu, 3 Jul 2003 10:56:22 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AB0AE2EC86 for ; Thu, 3 Jul 2003 18:59:11 +0200 (CEST) Message-ID: <3F0460DF.1040603@motorola.com> Date: Thu, 03 Jul 2003 18:59:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-leekj-nemo-ro-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Chairs stop me if RO discussions not in context now] Hello to authors of draft-leekj-nemo-ro-pd-00.txt. I've read the draft, thanks for providing it. I understand that the method offers optimal paths between MN's inside the mobile network and CN outside the mobile network. Figure 1 shows an LFN, that is supposedly fixed. Is the draft providing optimal routes between LFN and CN too (or only between MN and CN)? LFN normally does not perform itself Mobile IPv6, right? I don't understand why there is a need for a new ND option? Couldn't the usual RA be used by MR to put the delegated prefix in, and advertise towards MN? What happens when there are several fixed routers in the mobile network and a MN would visit deep below one of those FR's? Normally RA's stay on a link, so the RA with the delegated prefix coming from up will only be seen in the first upper link, not below. Or maybe that is outside the scope of the draft? Alex GBU From exim@www1.ietf.org Thu Jul 3 13:00:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24672 for ; Thu, 3 Jul 2003 13:00:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7RQ-00082U-Cr for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 13:00:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63H0GqW030902 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 13:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7RQ-00082L-5W for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 13:00:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24645 for ; Thu, 3 Jul 2003 13:00:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7RO-0003DZ-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:00:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y7RN-0003DV-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:00:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7RB-00081R-JU; Thu, 03 Jul 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7QU-00080g-J3 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 12:59:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24606 for ; Thu, 3 Jul 2003 12:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7QS-0003D0-00 for nemo@ietf.org; Thu, 03 Jul 2003 12:59:16 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19Y7QS-0003Cx-00 for nemo@ietf.org; Thu, 03 Jul 2003 12:59:16 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h63GxFnD012195 for ; Thu, 3 Jul 2003 09:59:15 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h63FuLrN008461 for ; Thu, 3 Jul 2003 10:56:22 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AB0AE2EC86 for ; Thu, 3 Jul 2003 18:59:11 +0200 (CEST) Message-ID: <3F0460DF.1040603@motorola.com> Date: Thu, 03 Jul 2003 18:59:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-leekj-nemo-ro-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Chairs stop me if RO discussions not in context now] Hello to authors of draft-leekj-nemo-ro-pd-00.txt. I've read the draft, thanks for providing it. I understand that the method offers optimal paths between MN's inside the mobile network and CN outside the mobile network. Figure 1 shows an LFN, that is supposedly fixed. Is the draft providing optimal routes between LFN and CN too (or only between MN and CN)? LFN normally does not perform itself Mobile IPv6, right? I don't understand why there is a need for a new ND option? Couldn't the usual RA be used by MR to put the delegated prefix in, and advertise towards MN? What happens when there are several fixed routers in the mobile network and a MN would visit deep below one of those FR's? Normally RA's stay on a link, so the RA with the delegated prefix coming from up will only be seen in the first upper link, not below. Or maybe that is outside the scope of the draft? Alex GBU From nemo-admin@ietf.org Thu Jul 3 13:08:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25069 for ; Thu, 3 Jul 2003 13:08:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Yv-000050-U0; Thu, 03 Jul 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7YF-0008Ku-73 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 13:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25026 for ; Thu, 3 Jul 2003 13:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7YD-0003Ou-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:07:17 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19Y7YC-0003Or-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:07:16 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h63H7Flj001179 for ; Thu, 3 Jul 2003 10:07:15 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h63G6l7q016790 for ; Thu, 3 Jul 2003 11:06:48 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3D1492EC86 for ; Thu, 3 Jul 2003 19:07:14 +0200 (CEST) Message-ID: <3F0462C1.7050804@motorola.com> Date: Thu, 03 Jul 2003 19:07:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-hkang-nemo-ro-tlmr-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Again, Chairs stop me if discussion out of context now] Hello to authors of draft-hkang-nemo-ro-tlmr-00.txt I've read the draft, thanks for providing it. May I ask two questions. I was wondering whether you totally agree with the idea of propagating (relaying) information received in one RA from one interface to another RA on another interface. Also I was wondering whether you're aware of the old HMIPv6 similar proposal, where the TLMR is named MAP and RA's are also propagated through a set of fixed routers (they belong to the fixed infrastructure, not to the mobile network). Also I was wondering whether you've tried to unfold a RO scenario where MR acts as a MH and does RO with the HA (as if it were a CN) of the MH that visits under it. Also wondering whether you've tried to unfold an RO scenario where MR automatically does RO with LFN's CN, on behalf of LFN, such as no new messages are defined between LFN and MR. Thanks for any information, Alex GBU From exim@www1.ietf.org Thu Jul 3 13:08:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25084 for ; Thu, 3 Jul 2003 13:08:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Yy-00006u-AF for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 13:08:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63H84b4000418 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 13:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Yy-00006W-4q for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 13:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25052 for ; Thu, 3 Jul 2003 13:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7Yw-0003PR-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y7Yv-0003PO-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7Yv-000050-U0; Thu, 03 Jul 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7YF-0008Ku-73 for nemo@optimus.ietf.org; Thu, 03 Jul 2003 13:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25026 for ; Thu, 3 Jul 2003 13:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7YD-0003Ou-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:07:17 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19Y7YC-0003Or-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:07:16 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h63H7Flj001179 for ; Thu, 3 Jul 2003 10:07:15 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h63G6l7q016790 for ; Thu, 3 Jul 2003 11:06:48 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3D1492EC86 for ; Thu, 3 Jul 2003 19:07:14 +0200 (CEST) Message-ID: <3F0462C1.7050804@motorola.com> Date: Thu, 03 Jul 2003 19:07:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-hkang-nemo-ro-tlmr-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Again, Chairs stop me if discussion out of context now] Hello to authors of draft-hkang-nemo-ro-tlmr-00.txt I've read the draft, thanks for providing it. May I ask two questions. I was wondering whether you totally agree with the idea of propagating (relaying) information received in one RA from one interface to another RA on another interface. Also I was wondering whether you're aware of the old HMIPv6 similar proposal, where the TLMR is named MAP and RA's are also propagated through a set of fixed routers (they belong to the fixed infrastructure, not to the mobile network). Also I was wondering whether you've tried to unfold a RO scenario where MR acts as a MH and does RO with the HA (as if it were a CN) of the MH that visits under it. Also wondering whether you've tried to unfold an RO scenario where MR automatically does RO with LFN's CN, on behalf of LFN, such as no new messages are defined between LFN and MR. Thanks for any information, Alex GBU From nemo-admin@ietf.org Thu Jul 3 13:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26564 for ; Thu, 3 Jul 2003 13:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7sG-0000Zo-Q8; Thu, 03 Jul 2003 13:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7rW-0000Z8-KH for nemo@optimus.ietf.org; Thu, 03 Jul 2003 13:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26479 for ; Thu, 3 Jul 2003 13:27:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7rU-00046b-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:27:12 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19Y7rR-00046W-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:27:09 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h63HR8nD000807 for ; Thu, 3 Jul 2003 10:27:08 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h63HR51n029078 for ; Thu, 3 Jul 2003 12:27:06 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 16C002EC86 for ; Thu, 3 Jul 2003 19:27:05 +0200 (CEST) Message-ID: <3F046768.2040403@motorola.com> Date: Thu, 03 Jul 2003 19:27:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-jung-nemo-threat-analysis-00 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello to authors of draft-jung-nemo-threat-analysis-00.txt. Thanks for this beginning of threat analysis. As you think, I also think it is important for this group's agenda. But I hope there are many things that could be refined in the draft. For example, most of the threats stay too generic and sometimes don't capture the essence of all the discussions that happened on the list. Some of the threats are not specifically related to the way the base spec works, but are more related to generic security threats. All eavesdropping/monitoring/traffic analysis applies. Some threats specifically say that IPsec might help there, others don't say anything; e.g. it's excellent to have text that says IPsec helps with MiTM between MR and HA, so it would also be fine to have saying IPsec helps with e.g. 3.2. messages between MR and HA. > All the data packets between MR and HA have to go through the > bi-directional tunnel. This tunnel should be secured by IPsec. But > some of the routing information that may not go through this tunnel > should be secured. I don't think there is any routing information that won't go through that secured tunnel, isn't it? > The location of MR or MNN inside the subnet may be the privacy of the > client, so the location information while network is in motion > should be secured. Attacker can analyze the header information MR-CoA > in the tunneled data packet and identify the location of the MR. > Since all the data packets between MNN and CN are also tunneled using > MR-CoA as new source address, the location of the MNN can also be > disclosed. Location privacy risks have been largely discussed on the list and there are some conclusions. For example, if the IPsec MR-HA tunnel is made of steel then nobody can look inside, so attacker can't make an association between the HoA (invisible) and the visible CoA. But maybe this section can be further detailed to say more precisely who is the attacker and what is the sensitive information (e.g. attacker can not be CN because all communication goes through HA; also the sensitive information is the HoA, not the CoA, because the CoA must always be in clear). Also there was relevant discussion on the list about other security risks more pertinent to NEMO, like for example when the MR belongs to an admin domain and the HA to another domain (IIRC). Thanks again for the draft, Alex GBU From exim@www1.ietf.org Thu Jul 3 13:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26581 for ; Thu, 3 Jul 2003 13:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7sM-0000al-Ub for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 13:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63HS6Vt002269 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 13:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7sM-0000aW-R6 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 13:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26532 for ; Thu, 3 Jul 2003 13:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7sK-00047t-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y7sK-00047q-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 13:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7sG-0000Zo-Q8; Thu, 03 Jul 2003 13:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y7rW-0000Z8-KH for nemo@optimus.ietf.org; Thu, 03 Jul 2003 13:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26479 for ; Thu, 3 Jul 2003 13:27:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y7rU-00046b-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:27:12 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19Y7rR-00046W-00 for nemo@ietf.org; Thu, 03 Jul 2003 13:27:09 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h63HR8nD000807 for ; Thu, 3 Jul 2003 10:27:08 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h63HR51n029078 for ; Thu, 3 Jul 2003 12:27:06 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 16C002EC86 for ; Thu, 3 Jul 2003 19:27:05 +0200 (CEST) Message-ID: <3F046768.2040403@motorola.com> Date: Thu, 03 Jul 2003 19:27:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-jung-nemo-threat-analysis-00 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello to authors of draft-jung-nemo-threat-analysis-00.txt. Thanks for this beginning of threat analysis. As you think, I also think it is important for this group's agenda. But I hope there are many things that could be refined in the draft. For example, most of the threats stay too generic and sometimes don't capture the essence of all the discussions that happened on the list. Some of the threats are not specifically related to the way the base spec works, but are more related to generic security threats. All eavesdropping/monitoring/traffic analysis applies. Some threats specifically say that IPsec might help there, others don't say anything; e.g. it's excellent to have text that says IPsec helps with MiTM between MR and HA, so it would also be fine to have saying IPsec helps with e.g. 3.2. messages between MR and HA. > All the data packets between MR and HA have to go through the > bi-directional tunnel. This tunnel should be secured by IPsec. But > some of the routing information that may not go through this tunnel > should be secured. I don't think there is any routing information that won't go through that secured tunnel, isn't it? > The location of MR or MNN inside the subnet may be the privacy of the > client, so the location information while network is in motion > should be secured. Attacker can analyze the header information MR-CoA > in the tunneled data packet and identify the location of the MR. > Since all the data packets between MNN and CN are also tunneled using > MR-CoA as new source address, the location of the MNN can also be > disclosed. Location privacy risks have been largely discussed on the list and there are some conclusions. For example, if the IPsec MR-HA tunnel is made of steel then nobody can look inside, so attacker can't make an association between the HoA (invisible) and the visible CoA. But maybe this section can be further detailed to say more precisely who is the attacker and what is the sensitive information (e.g. attacker can not be CN because all communication goes through HA; also the sensitive information is the HoA, not the CoA, because the CoA must always be in clear). Also there was relevant discussion on the list about other security risks more pertinent to NEMO, like for example when the MR belongs to an admin domain and the HA to another domain (IIRC). Thanks again for the draft, Alex GBU From nemo-admin@ietf.org Thu Jul 3 17:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07934 for ; Thu, 3 Jul 2003 17:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBnA-0003b7-Vp; Thu, 03 Jul 2003 17:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBml-0003ar-2R for nemo@optimus.ietf.org; Thu, 03 Jul 2003 17:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07917 for ; Thu, 3 Jul 2003 17:38:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBmi-000454-00 for nemo@ietf.org; Thu, 03 Jul 2003 17:38:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19YBmg-00044i-00 for nemo@ietf.org; Thu, 03 Jul 2003 17:38:30 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA29092; Thu, 3 Jul 2003 14:37:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h63LbrG10742; Thu, 3 Jul 2003 14:37:53 -0700 X-mProtect: <200307032137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8U2hea; Thu, 03 Jul 2003 14:37:52 PDT Message-ID: <3F04A230.C3588A3A@iprg.nokia.com> Date: Thu, 03 Jul 2003 14:37:52 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Subject: Re: [nemo] Vienna Agenda References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William D Ivancic wrote: > > The mobile router is configured > to choose links in the following order of > preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links may > be active and register as available, only one link can be used at a > time. Although some may wish (or at least think they wish) to use multiple > links or all links (as with the aeronautical community) the practicality of > this is questionable. this is where I think we need to spend some time. nail down the scenarios first. see if the NEMO basic support solution supports these scenarios. if not, make changes to the basic support so that it doesnt prevent any particular multi-homing scenarios. the exact details can be specified in a separate draft. Vijay From exim@www1.ietf.org Thu Jul 3 17:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07950 for ; Thu, 3 Jul 2003 17:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBnF-0003cA-RV for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 17:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Ld52r013888 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 17:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBnF-0003bv-MA for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 17:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07921 for ; Thu, 3 Jul 2003 17:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBnD-00045O-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 17:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YBnC-00045L-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 17:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBnA-0003b7-Vp; Thu, 03 Jul 2003 17:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBml-0003ar-2R for nemo@optimus.ietf.org; Thu, 03 Jul 2003 17:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07917 for ; Thu, 3 Jul 2003 17:38:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBmi-000454-00 for nemo@ietf.org; Thu, 03 Jul 2003 17:38:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19YBmg-00044i-00 for nemo@ietf.org; Thu, 03 Jul 2003 17:38:30 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA29092; Thu, 3 Jul 2003 14:37:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h63LbrG10742; Thu, 3 Jul 2003 14:37:53 -0700 X-mProtect: <200307032137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8U2hea; Thu, 03 Jul 2003 14:37:52 PDT Message-ID: <3F04A230.C3588A3A@iprg.nokia.com> Date: Thu, 03 Jul 2003 14:37:52 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Subject: Re: [nemo] Vienna Agenda References: <20030602175601.162cf872.ernst@sfc.wide.ad.jp> <1057036320.1483.11.camel@beethoven> <5.1.1.5.2.20030702133735.092f33b0@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William D Ivancic wrote: > > The mobile router is configured > to choose links in the following order of > preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links may > be active and register as available, only one link can be used at a > time. Although some may wish (or at least think they wish) to use multiple > links or all links (as with the aeronautical community) the practicality of > this is questionable. this is where I think we need to spend some time. nail down the scenarios first. see if the NEMO basic support solution supports these scenarios. if not, make changes to the basic support so that it doesnt prevent any particular multi-homing scenarios. the exact details can be specified in a separate draft. Vijay From nemo-admin@ietf.org Thu Jul 3 18:05:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08938 for ; Thu, 3 Jul 2003 18:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCCL-0004EH-BC; Thu, 03 Jul 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCBi-0004Da-8P for nemo@optimus.ietf.org; Thu, 03 Jul 2003 18:04:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08774 for ; Thu, 3 Jul 2003 18:04:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YCBf-0004wK-00 for nemo@ietf.org; Thu, 03 Jul 2003 18:04:19 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19YCBe-0004sV-00 for nemo@ietf.org; Thu, 03 Jul 2003 18:04:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA00214; Thu, 3 Jul 2003 15:03:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h63M3gv07806; Thu, 3 Jul 2003 15:03:42 -0700 X-mProtect: <200307032203> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Kyajd; Thu, 03 Jul 2003 15:03:40 PDT Message-ID: <3F04A83D.B0526AF5@iprg.nokia.com> Date: Thu, 03 Jul 2003 15:03:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org, ernst@sfc.wide.ad.jp Subject: Policy base MR operation (was Re: [nemo] Design Team draft for NEMO Basic Solution) References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> <5.1.1.5.2.20030703093248.01828d00@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William D Ivancic wrote: > Given these same four links, Policy states I must send command and control > over VDL or INMARSAT. Thus the policy based routing requirement. Now, > when I fly over the oceans, I loose VDL so policy says route via INMARSAT > if available. If VDL is active route through VDL. Never route Command and > Control through Connexion. So, interfaces and tunnels are coming up and > down on the mobile unit. How does one write policy? Better yet, they > also would like to write policy on the ground that directs traffic to take > particular routes through the ground network. Not to easy if everything > resides in tunnels - of course we haven't even considered secure tunnels to > hide things. I got it. there are two problems here 1. there are multiple intefaces available, and the MR should pick the best available interface. IMO, this is not necessarily a NEMO problem. you need something like a "roaming manager" (there are many synonyms for this), which figures out which interface is up and decides which interface should be used and when. as far as the NEMO protocol is concerned, it needs an uplink to the visited network, through which the MR can reach its Home Agent. I think there is nothing to standardize here. the "roaming manager" would be implementation specific. 2. in your experiment, you said you were required to send control traffic through a VDL or INMARSAT link and data traffic through a Connexion link. isnt this again implementation specific? the forwarding code on the MR has to figure out the outgoing interface based on the message contents. do you see a need to standardize something here? do we need an API between the NEMO module and the "roaming manager"? a list of requirements in the form of an internet draft would be nice. then we can figure out what exactly needs to be specified. > Now let me add some more reality to the mess. (This is my current > understanding as explained to me by various pilots. I am open to > correction.) Commercial aircraft today generally only have one active VDL > circuit that is performing packetized communication. The other is used for > voice. They are not combined (i.e. VOIP). Because the satellite time > costs so much, the INMARSAT system generally is not powered on unless the > VDL link is lost. So in reality, only one link is active. The question > I keep raising to this community is why policy-based routing and load > sharing when in reality only one link is active. I also suspect that I > could obtain much higher QoS if I used the Connexion link ( or > similar) for command and control when available and could sufficiently > secure those messages with today's technologies. IMHO, What is really > needed is some type of quality of service requirement such that command and > control is highest priority. I agree with you here. Vijay From exim@www1.ietf.org Thu Jul 3 18:05:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08953 for ; Thu, 3 Jul 2003 18:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCCQ-0004FH-6h for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 18:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63M56lq016319 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 18:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCCQ-0004F8-28 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 18:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08883 for ; Thu, 3 Jul 2003 18:05:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YCCN-00057x-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 18:05:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YCCM-00057u-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 18:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCCL-0004EH-BC; Thu, 03 Jul 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCBi-0004Da-8P for nemo@optimus.ietf.org; Thu, 03 Jul 2003 18:04:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08774 for ; Thu, 3 Jul 2003 18:04:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YCBf-0004wK-00 for nemo@ietf.org; Thu, 03 Jul 2003 18:04:19 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19YCBe-0004sV-00 for nemo@ietf.org; Thu, 03 Jul 2003 18:04:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA00214; Thu, 3 Jul 2003 15:03:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h63M3gv07806; Thu, 3 Jul 2003 15:03:42 -0700 X-mProtect: <200307032203> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Kyajd; Thu, 03 Jul 2003 15:03:40 PDT Message-ID: <3F04A83D.B0526AF5@iprg.nokia.com> Date: Thu, 03 Jul 2003 15:03:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org, ernst@sfc.wide.ad.jp Subject: Policy base MR operation (was Re: [nemo] Design Team draft for NEMO Basic Solution) References: <5.1.1.5.2.20030702132346.09370cc8@popserve.grc.nasa.gov> <5.1.1.5.2.20030703093248.01828d00@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William D Ivancic wrote: > Given these same four links, Policy states I must send command and control > over VDL or INMARSAT. Thus the policy based routing requirement. Now, > when I fly over the oceans, I loose VDL so policy says route via INMARSAT > if available. If VDL is active route through VDL. Never route Command and > Control through Connexion. So, interfaces and tunnels are coming up and > down on the mobile unit. How does one write policy? Better yet, they > also would like to write policy on the ground that directs traffic to take > particular routes through the ground network. Not to easy if everything > resides in tunnels - of course we haven't even considered secure tunnels to > hide things. I got it. there are two problems here 1. there are multiple intefaces available, and the MR should pick the best available interface. IMO, this is not necessarily a NEMO problem. you need something like a "roaming manager" (there are many synonyms for this), which figures out which interface is up and decides which interface should be used and when. as far as the NEMO protocol is concerned, it needs an uplink to the visited network, through which the MR can reach its Home Agent. I think there is nothing to standardize here. the "roaming manager" would be implementation specific. 2. in your experiment, you said you were required to send control traffic through a VDL or INMARSAT link and data traffic through a Connexion link. isnt this again implementation specific? the forwarding code on the MR has to figure out the outgoing interface based on the message contents. do you see a need to standardize something here? do we need an API between the NEMO module and the "roaming manager"? a list of requirements in the form of an internet draft would be nice. then we can figure out what exactly needs to be specified. > Now let me add some more reality to the mess. (This is my current > understanding as explained to me by various pilots. I am open to > correction.) Commercial aircraft today generally only have one active VDL > circuit that is performing packetized communication. The other is used for > voice. They are not combined (i.e. VOIP). Because the satellite time > costs so much, the INMARSAT system generally is not powered on unless the > VDL link is lost. So in reality, only one link is active. The question > I keep raising to this community is why policy-based routing and load > sharing when in reality only one link is active. I also suspect that I > could obtain much higher QoS if I used the Connexion link ( or > similar) for command and control when available and could sufficiently > secure those messages with today's technologies. IMHO, What is really > needed is some type of quality of service requirement such that command and > control is highest priority. I agree with you here. Vijay From mailman-admin@ietf.org Thu Jul 3 18:31:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12520 for ; Thu, 3 Jul 2003 18:31:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCbs-00022l-TU for nemo-archive@lists.ietf.org; Thu, 03 Jul 2003 18:31:24 -0400 Date: Thu, 03 Jul 2003 18:31:24 -0400 Message-ID: <20030703223124.4508.8387.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-admin@ietf.org Thu Jul 3 19:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21535 for ; Thu, 3 Jul 2003 19:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDKz-000829-Ae; Thu, 03 Jul 2003 19:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0dl-0005wL-Uz for nemo@optimus.ietf.org; Thu, 03 Jul 2003 05:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04064 for ; Thu, 3 Jul 2003 05:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0di-0004iH-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:44:30 -0400 Received: from newton.aot.cs.tu-berlin.de ([130.149.154.80]) by ietf-mx with esmtp (Exim 4.12) id 19Y0dg-0004hd-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:44:29 -0400 Received: from birke.dai-lab.de (birke [130.149.154.85]) by newton.aot.cs.tu-berlin.de (8.11.6/8.11.2) with ESMTP id h639huD11648 for ; Thu, 3 Jul 2003 11:43:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jul 2003 11:43:53 +0200 Message-ID: Thread-Topic: Nemo digest, Vol 1 #38 - 10 msgs Thread-Index: AcNBR4Y3kgGSpHoWTOOBWSFXNPU3UwAAA6/A From: =?iso-8859-1?Q?Ingo_R=FCbe?= To: Content-Transfer-Encoding: quoted-printable Subject: [nemo] AW: Nemo digest, Vol 1 #38 - 10 msgs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In 5 minuten=20 -ingo -----Urspr=FCngliche Nachricht----- Von: nemo-request@ietf.org [mailto:nemo-request@ietf.org]=20 Gesendet: Donnerstag, 3. Juli 2003 11:42 An: nemo@ietf.org Betreff: Nemo digest, Vol 1 #38 - 10 msgs Send Nemo mailing list submissions to nemo@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/nemo or, via email, send a message with subject or body 'help' to nemo-request@ietf.org You can reach the person managing the list at nemo-admin@ietf.org When replying, please edit your Subject line so it is more specific than = "Re: Contents of Nemo digest..." Today's Topics: 1. Re: The question about NEMO basic support (Vijay Devarapalli) 2. Re: Design Team draft for NEMO Basic Solution (William D Ivancic) 3. Re: Vienna Agenda (William D Ivancic) 4. Re: Design Team draft for NEMO Basic Solution (Vijay Devarapalli) 5. Re: experiments (was: Vienna Agenda) (Alexandru Petrescu) 6. RE: Re: The question about NEMO basic support (Jongkeun Na) 7. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] (Eun = Kyoung Paik) 8. Re: Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt = (Henrik Petander) 9. nemo-request@ietf.org (Conferencia ew2004) 10. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] = (Alexandru Petrescu) --__--__-- Message: 1 Date: Wed, 02 Jul 2003 09:58:51 -0700 From: Vijay Devarapalli To: Jongkeun Na CC: nemo@ietf.org Subject: [nemo] Re: The question about NEMO basic support >=20 > Hello Vijay, >=20 > =20 >=20 > I have a question for prefix table described in the draft. >=20 > In case that prefix table is not pre-configured in HA, MR should use=20 > explicit or combined binding mode. Right? right.=20 >=20 > Let's assume that MR and HA can run dynamic routing protocol and=20 > prefix table is not pre-configured. when the MR and HA run a dynamic routing protocol there is no need to include an prefix information in the Binding Update. infact the HA should not try to determine the=20 prefix from the Binding Update. the routing protocol updates will carry = the prefix information. do you think we need an explicit flag in the = Binding Update for this?=20 Vijay >=20 > If MR try to do implicit binding, by the draft, MR cannot set up the=20 > bi-directional tunnel with its HA because HA will send BACK with `143' = > status code(Mobile Network Prefix Information information unavailable) = > for the requested BU. >=20 > I think HA should allow the implicit BU from MR that runs dynamic=20 > routing protocol because the draft says that prefix table is an=20 > optional data structure from the terminology description of section 2. = > Or, the draft should say prefix table MUST be maintained by HA. >=20 > =20 >=20 > It looks like unclear to me. Could you explain that for me? >=20 > =20 >=20 > Best Regards, >=20 > /Jongkeun --__--__-- Message: 2 Date: Wed, 02 Jul 2003 13:35:35 -0400 To: "T.J. Kniveton" From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: Very nice work on the Basic Support. Sorry, I cannot make it out to Vienna, but I should be at the next=20 meeting. Also, I have a draft completed on issues related to = mobile-ip=20 and routing protocols when using encryption devices. I could not get it = in=20 before closeout of Internet Drafts. However I will as soon as IETF = opens=20 for new submissions. Here are a few questions and some minor corrections: 1) Question regarding section 8. Support for Dynamic Routing Protocols = "In the solution described so far, forwarding to the Mobile Network at = the=20 Home Agent is set up when the Home Agent receives a Binding Update from = the=20 Mobile Router. An alternative to this is for the Home Agent and the = Mobile=20 Router to run a intra-doamin routing protocol like RIPng [6] and OSPF = [7]=20 through the bi-directional tunnel." I believe the hop limit is usually set to 1 for routing=20 protocols. Encapsulation will decrement by 1. Do we need to state=20 anything here regarding the need to not decrement the Hop Limit field = here=20 or is this obvious? ( I am wary of this as it is definitely an issue = with=20 encryption devices.) 1.1) Has anyone given some though to policy base routing over tunnels = that=20 are coming up and going down? The aeronautics community still has this = on=20 their wish list. 2) Many places in the document is state "MUST not." Should those be=20 changed to "MUST NOT"? Typographic and Spelling Mistakes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Page 17. home link. At this point, Mobile Router MAY try try to obtain and own a=20 prefix by the same means that it initially got attributed the Invalid=20 Prefix in question. Alternatively, Mobile Router MAY send Binding = Updates=20 in another mode (e.g. implicit mode) to a Home Agent on the same home = link. MAY try try >>> MAY try The bi-directional tunnel between Mobile Router and Home Agent allows=20 packets to flow in both directions between these entities, while the = Mobile=20 Router is connected to a Visisted Link. Visisted Link. >>> Visited Link Page 18 A Mobile Router MAY use the received Router Advertisements on the = interface=20 connected to the home link, but only for logging and administrative=20 purposes. Only when that interface is connected to a A Mobile Router MAY = use the received Router Advertisements on the interface connected to the = home link, but only for logging and administrative purposes. Only when = that=20 interface is connected to a visisted link, visisted link >>> visited link Page 26 8. Support for Dynamic Routing Protocols In the solution described so = far,=20 forwarding to the Mobile Network at the Home Agent is set up when the = Home=20 Agent receives a Binding Update from the Mobile Router. An alternative = to=20 this is for the Home Agent and the Mobile Router to run a intra-doamin = routing intra-doamin >>> intra-domain Will Ivancic --__--__-- Message: 3 Date: Wed, 02 Jul 2003 13:55:46 -0400 To: vijayd@IPRG.nokia.com From: William D Ivancic Subject: Re: [nemo] Vienna Agenda Cc: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Vijay >it would be good to nail down what exactly NEMO is supposed >to support with respect to mutlihoming at this IETF. I have seen too=20 >many multihoming scenarios, some of which are not practical at all=20 >(IMHO). I work with mobile networks daily using Cisco's IPv4 implementation. = The=20 multihoming we utilize is one router with multiple "roaming" interfaces=20 connected to various links. Some of those links may have foreign agents = and others may use collocated-care-of-address (CC0A). For example I = have=20 one mobile router that has an 802.11 interface (foreign agent); one=20 satellite link using static CCOA and one G2.5 general packet radio = service=20 (GPRS) link using dynamic CCOA over PPP. The mobile router is = configured=20 to choose links in the following order of=20 preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links = may=20 be active and register as available, only one link can be used at a=20 time. Although some may wish (or at least think they wish) to use = multiple=20 links or all links (as with the aeronautical community) the practicality = of=20 this is questionable. The following are real measured numbers for some services we have used. Link Practical Data=20 Rate RTT Delay Cost =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= WiFi >1.0 Mbps 100 msec Free after=20 infrastructure or approximately equal to GPRS GPRS ~30 kbps 300 - 1000 msec $30 - $70 per=20 month Unlimited Volume Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute = !!!! Will Ivancic --__--__-- Message: 4 Date: Wed, 02 Jul 2003 11:08:06 -0700 From: Vijay Devarapalli To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution William D Ivancic wrote: >=20 > Very nice work on the Basic Support. >=20 > Sorry, I cannot make it out to Vienna, but I should be at the next > meeting. Also, I have a draft completed on issues related to = mobile-ip > and routing protocols when using encryption devices. I could not get=20 > it in before closeout of Internet Drafts. However I will as soon as=20 > IETF opens for new submissions. >=20 > Here are a few questions and some minor corrections: >=20 > 1) Question regarding section 8. Support for Dynamic Routing=20 > Protocols "In the solution described so far, forwarding to the Mobile=20 > Network at the Home Agent is set up when the Home Agent receives a=20 > Binding Update from the Mobile Router. An alternative to this is for=20 > the Home Agent and the Mobile Router to run a intra-doamin routing=20 > protocol like RIPng [6] and OSPF [7] through the bi-directional=20 > tunnel." >=20 > I believe the hop limit is usually set to 1 for routing > protocols. Encapsulation will decrement by 1. Do we need to state > anything here regarding the need to not decrement the Hop Limit field=20 > here or is this obvious? ( I am wary of this as it is definitely an=20 > issue with encryption devices.) the way I see it is, both the HA and MR run a routing protocol through = the bi-directional tunnel. this tunnel is treated as=20 a singe hop link. both MR and HA use link local addresses for routing = protocol messages inside the tunnel. these messages are processed at = each end and are not forwarded onto the other links. forwarding packets with link local address raises a lot of=20 issues and also makes the HA implementation difficult. >=20 > 1.1) Has anyone given some though to policy base routing over tunnels = that > are coming up and going down? The aeronautics community still has = this on > their wish list. I am not sure I read any previous mails on this. can you tell me more? >=20 > 2) Many places in the document is state "MUST not." Should those = be > changed to "MUST NOT"? fixed >=20 > Typographic and Spelling Mistakes > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Page 17. > home link. At this point, Mobile Router MAY try try to obtain and own=20 > a prefix by the same means that it initially got attributed the=20 > Invalid Prefix in question. Alternatively, Mobile Router MAY send=20 > Binding Updates in another mode (e.g. implicit mode) to a Home Agent=20 > on the same home link. >=20 > MAY try try >>> MAY try >=20 > The bi-directional tunnel between Mobile Router and Home Agent allows=20 > packets to flow in both directions between these entities, while the=20 > Mobile Router is connected to a Visisted Link. >=20 > Visisted Link. >>> Visited Link >=20 > Page 18 >=20 > A Mobile Router MAY use the received Router Advertisements on the=20 > interface connected to the home link, but only for logging and=20 > administrative purposes. Only when that interface is connected to a A=20 > Mobile Router MAY use the received Router Advertisements on the=20 > interface connected to the home link, but only for logging and=20 > administrative purposes. Only when that interface is connected to a=20 > visisted link, >=20 > visisted link >>> visited link >=20 > Page 26 > 8. Support for Dynamic Routing Protocols In the solution described so=20 > far, forwarding to the Mobile Network at the Home Agent is set up when = > the Home Agent receives a Binding Update from the Mobile Router. An=20 > alternative to this is for the Home Agent and the Mobile Router to run = > a intra-doamin routing >=20 > intra-doamin >>> intra-domain thanks. Vijay --__--__-- Message: 5 Date: Thu, 03 Jul 2003 04:16:22 +0200 From: Alexandru Petrescu To: William D Ivancic CC: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG = , "T.J. Kniveton" , Alexandru Petrescu Subject: [nemo] Re: experiments (was: Vienna Agenda) William D Ivancic wrote: > Vijay >=20 >=20 >> it would be good to nail down what exactly NEMO is supposed to >> support with respect to mutlihoming at this IETF. I have seen too=20 >> many multihoming scenarios, some of which are not practical at all=20 >> (IMHO). >=20 >=20 > I work with mobile networks daily using Cisco's IPv4 implementation. > The multihoming we utilize is one router with multiple "roaming"=20 > interfaces connected to various links. Some of those links may have=20 > foreign agents and others may use collocated-care-of-address (CC0A).=20 > For example I have one mobile router that has an 802.11 interface=20 > (foreign agent); one satellite link using static CCOA and one G2.5=20 > general packet radio service (GPRS) link using dynamic CCOA over PPP. > The mobile router is configured to choose links in the following=20 > order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although > all links may be active and register as available, only one link can > be used at a time. Although some may wish (or at least think they=20 > wish) to use multiple links or all links (as with the aeronautical=20 > community) the practicality of this is questionable. Thanks for the description, I'm happy to see these kinds of experiments = happen. Just to show similarity, we call a "roaming" interface a = "mobile" interface. We started with the same kind of idea for a mobile router prototype that = has several mobile interfaces connected to various access systems (but = behaviour was so difficult to maintain that we preferred to isolate ppp = connections on a "FrontBox"). For example, when a GPRS mobile interface = is used, and the mobile router enters a tunnel (a real tunnel like under = a river) then that PPP connection goes down, the corresponding interface = disappears, routing entries disappear. When the mobile router exits = that tunnel, re-establishing the PPP connection involved relaunching = many other things. So we considered designing "FrontBoxes" that would = isolate this behaviour from Mobile IPv6 software: A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base = Station. It also has a WLAN interface w1 on which it sends IPv6 RAs = towards MR. If the PPP connection goes down, this can be repaired = locally withouth MR noticing it. A WLAN FrontBox has two WLAN = interfaces, one of them attaching to a hotspot WLAN AP, and the other is = named w2. (A third _potential_ DVB FrontBox would use a terestrial DVB = link as well as a return path on another GPRS phone, such as to still = provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the = MR.) Each FrontBox uses private IPv4 to connect to GPRS or to hotspots = respectively. They also dynamically maintain IPv6-in-UDP/v4 tunnels = towards a special machine in the home network that has connectivity to = both IPv4 and IPv6 Internets. Each FB provides IPv6-only bidirectional = connectivity to MR, each sending different RA's with unique prefixes. A Mobile Router has only one WLAN "mobile" interface that switches = attachment between w1 and w2, as well as another WLAN interface towards = the mobile network link. The Mobile Router and the nodes in the mobile = network exclusively run IPv6 with network mobility based on Mobile IPv6 = (no IPv4). Mobile Router switches attachment by means of a visual = interface (GUI), with manual buttons. When I see the hotspot access = point approaching I push the "WLAN" button; when I see it in the rear = view mirror I push "GPRS". Of course, better can be done to automate = this with some preferences, as your experiments report. In this way, all access technologies are separated (read deterministic = and controllable), from the Mobile IPv6 behaviour. > The following are real measured numbers for some services we have > used. >=20 > Link Practical Data Rate RTT Delay Cost >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > WiFi >1.0 Mbps 100 msec Free after=20 > infrastructure or approximately equal to GPRS >=20 > GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month > Unlimited Volume >=20 > Satellite ~ 40 kbps 1 - 2 seconds $1.00 per=20 > minute !!!! Confirms most of my expectations with respect to GPRS = rates/delays/dollar_cost. I'm suprised though to see "satellite" being = 40kb/s (I was thinking it would be much less(?). Does the satellite = link have a sort of return path? Could I imagine acquiring sattelite = link somehow somewhere to make a FrontBox with it? In our experiments, the data rates as shown by vic between LFN and a CN = placed in the home network varies between 11-45Kb/s (when GPRS) and = about 60kb/s (when WLAN). Ping delays over GPRS are little over 1s. The = direct communication between WLAN FrontBox and hotspot AP is standard = 11mb/s. All relevant delays and latencies largely depend on the higly = variable number of many hops between MR and HA as well as between CN and = HA and CN and MR. Billing was not taken into consideration since the billing scheme of the = access providers were themselves a moving ground (WLAN hotspots were = free but business model changing as we speak, including targetting a = "mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes = transferred, not the time length, not flat; to complicate things further = some GPRS operators make pay more if the given IPv4 address is publicly = routable non-NAT'ed, and less if NAT'ed). Ask me for more information, = or the operators themselves. There was not any form of multi-homing in our experiments, even if = several access systems were indeed used, or some other times in the = laboratory several Home Agents were used. Only one connection was used = at a time, and I don't see exactly how a "one-size-fits-all" means to = reasonably use simultaneously these three access systems can be = conceived. And yes, I would very much appreciate if clarifications are sought at = the live meeting with respect to multi-homing requirements and the = practical scenarios in relation to network mobility. Looking forward... Alex GBU --__--__-- Message: 6 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: [nemo] Re: The question about NEMO basic support Date: Thu, 3 Jul 2003 10:33:28 +0900 > > I have a question for prefix table described in the draft. > > > > In case that prefix table is not pre-configured in HA, MR should use > explicit or combined binding mode. Right? >=20 > right. >=20 > > > > Let's assume that MR and HA can run dynamic routing protocol and prefix > table is not pre-configured. >=20 > when the MR and HA run a dynamic routing protocol there is > no need to include an prefix information in the Binding Update. infact = > the HA should not try to determine the prefix from the Binding Update. = > the routing protocol updates will carry the prefix information. do you = > think we need an explicit flag in the Binding Update for this? >=20 Yes, I thought an explicit flag is required for HA to properly handle = this situation. /Jongkeun >=20 > Vijay >=20 > > > > If MR try to do implicit binding, by the draft, MR cannot set up the bi- > directional tunnel with its HA because HA will send BACK with `143' status > > code(Mobile Network Prefix Information information unavailable) for the > requested BU. > > > > I think HA should allow the implicit BU from MR that runs dynamic > routing protocol because the draft says that prefix table is an optional > data structure > > from the terminology description of section 2. Or, the draft should say > prefix table MUST be maintained by HA. > > > > > > > > It looks like unclear to me. Could you explain that for me? > > > > > > > > Best Regards, > > > > /Jongkeun --__--__-- Message: 7 Date: Thu, 3 Jul 2003 14:59:18 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D = ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Thank you for your kind reply. Please see inlines.=20 > > And I have another question on the implementation of nested mobile > > networks. For example, let's think about following topology. > >=20 > > Internet | AR | Parent MR | Child MR > >=20 > > In the figure, Parent MR may autoconfigure its CoA after it listens > > RA of AR. Then, Child MR may autoconfigure its CoA after it listens=20 > > RA of Parent MR. After that, if Parent MR listens Child MR's RA,=20 > > Parent MR configures new CoA according to Child MR's RA ? >=20 > In this particular configuration, I do not think that Parent MR=20 > configures a CoA based on the Child MR RA. There are two reasons for=20 > that. >=20 > One is that according to the stateless autoconfiguration mechanisms a=20 > router will not autoconfigure an address on an interface based on=20 > received RA's. Parent MR is a router, so. Then, how MR's egress interface configures its CoA=20 when it moves into a foreign link ? Doesn't it need RA from foreign link ? =20 >=20 > The other is that Child MR is, in fact, visiting the network of Parent > MR; when a MR is visiting, it acts as a host on its egress interface,=20 > not as a router. Thus it will not send RA's on its egress interface=20 > if it is not at home, so Parent MR does not get RA's from Child MR. I wonder if parent MR's egress interrface listen the RA of child MR's = ingress interface. (Child MR's ingress interface may broadcast its RA = for its VMNs.) And how can we distinguish egress interface from ingress interface = physically ? > There is also a widely acknolwedged problem of "disconnected"=20 > operation that was mentioned very early. >=20 > Have you encountered some similar problems? =20 Could you breifly explain about "disconnected" operation ? Regards, Eun Kyoung --__--__-- Message: 8 Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST) From: Henrik Petander To: Alexandru Petrescu Cc: Ralph Droms , Subject: Re: [nemo] Re: I-D = ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt On Wed, 2 Jul 2003, Alexandru Petrescu wrote: > Ralph Droms wrote: > > Following up on our conversation a couple of months ago about using=20 > > DHCPv6 PD for prefix delegation to mobile routers, I've published=20 > > "DHCPv6 Prefix Delegation for NEMO"=20 > > . This draft describes the use=20 > > of DHCPv6 to meet my understanding of the requirements for prefix=20 > > delegation to mobile routers. Comments welcome... > > I'm happy this draft exists and is up for comments. I think that the=20 > way it suggests behaviour of PD between MR and HA is very good for the = > simplest mobile network configurations. Yes, this seems like an easy way to allow a mobile node to become a = mobile router e.g. when user attaches a PDA to her mobile phone. > > > Other updates to the HA data structures required as a side effect of = =20 > > prefix delegation are specified by the particular network mobility=20 > > protocol. For example, in the case of "Basic Network Mobility=20 > > Support" [8], the HA would add an entry in its binding cache=20 > > registering the delegated prefix to the MR to which the prefix was=20 > > delegated. > > I don't think that any proposed solution would involve triggering=20 > additions of BC entries as a result of PD operations. Adding entries=20 > in the BC is exclusively a result of Binding messaging, in my=20 > understanding. I guess the prefix should be added to the prefix table instead. Then the = HA could authenticate MR as being authorized to send BUs for the = delegated prefix and MR could also send BUs without including explicit = prefix information. Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- --__--__-- Message: 9 From: Conferencia ew2004 To: nemo@ietf.org Date: Thu, 3 Jul 2003 10:47:09 +0200 (MEST) Subject: [nemo] nemo-request@ietf.org --__--__-- Message: 10 Date: Thu, 03 Jul 2003 11:41:21 +0200 From: Alexandru Petrescu To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D = ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Eun Kyoung Paik wrote: > Thank you for your kind reply. Please see inlines. >=20 >>> And I have another question on the implementation of nested >>> mobile networks. For example, let's think about following=20 >>> topology. >>>=20 >>> Internet | AR | Parent MR | Child MR >>>=20 >>> In the figure, Parent MR may autoconfigure its CoA after it >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after=20 >>> it listens RA of Parent MR. After that, if Parent MR listens=20 >>> Child MR's RA, Parent MR configures new CoA according to Child=20 >>> MR's RA ? >>=20 >> In this particular configuration, I do not think that Parent MR >> configures a CoA based on the Child MR RA. There are two reasons=20 >> for that. >>=20 >> One is that according to the stateless autoconfiguration mechanisms =20 >> a router will not autoconfigure an address on an interface based on=20 >> received RA's. Parent MR is a router, so. >=20 > Then, how MR's egress interface configures its CoA when it moves into = > a foreign link ? Doesn't it need RA from foreign link ? Yes, exactly, it does need one. That's why the egress interface of a MR = will act as if it were belonging to a host (not a router) when visiting = a foreign network. >> The other is that Child MR is, in fact, visiting the network of >> Parent MR; when a MR is visiting, it acts as a host on its egress=20 >> interface, not as a router. Thus it will not send RA's on its=20 >> egress interface if it is not at home, so Parent MR does not get=20 >> RA's from Child MR. >=20 >=20 > I wonder if parent MR's egress interrface listen the RA of child MR's = > ingress interface. A picture would help. My picture is that Parent MR uses its egress to = connect to AR and ingress to connect to Child MR. Child MR uses its = egress to connect to Parent and its ingress to connect to its mobile = link. In general, I think the MR's _ingress_ interface will listen for RA's = but will not use it to autoconfigure addresses. The MR's _egress_ = interface, when in a foreign link, will listen to RA's from AR and will = autoconfigure CoA. Since the Child MR is acting like the parent MR, and child's egress = interface does not send RA (because it acts as a host on that interface) = then parent will not see any RA's coming from child MR. > (Child MR's ingress interface may broadcast its RA for its VMNs.) Yes, Child MR's ingress interface MUST broadcast RA (but not the = egress). Right? > And how can we distinguish egress interface from ingress interface > physically ? That's a good question and in one implementation that is a "knob", that = is like a turning button, like a kernel variable that says which = interface is "egress". > Could you breifly explain about "disconnected" operation ? Ok, maybe "disconnected operation" is my name for it, but the issue was = mentioned under other names, where two nested mobile networks can't talk = to each other if their respective HA's are not available. Many = discussions in the archives. Many pros and cons of this being or not = being a problem. Alex GBU --__--__-- _______________________________________________ Nemo mailing list Nemo@ietf.org https://www1.ietf.org/mailman/listinfo/nemo End of Nemo Digest From exim@www1.ietf.org Thu Jul 3 19:24:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22454 for ; Thu, 3 Jul 2003 19:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQL-0008UV-If for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 19:23:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NNX8S032635 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 19:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQL-0008UI-Eq for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:23:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21942 for ; Thu, 3 Jul 2003 19:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDL4-0003bT-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 19:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YDL3-0003bQ-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 19:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDKz-000829-Ae; Thu, 03 Jul 2003 19:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0dl-0005wL-Uz for nemo@optimus.ietf.org; Thu, 03 Jul 2003 05:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04064 for ; Thu, 3 Jul 2003 05:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0di-0004iH-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:44:30 -0400 Received: from newton.aot.cs.tu-berlin.de ([130.149.154.80]) by ietf-mx with esmtp (Exim 4.12) id 19Y0dg-0004hd-00 for nemo@ietf.org; Thu, 03 Jul 2003 05:44:29 -0400 Received: from birke.dai-lab.de (birke [130.149.154.85]) by newton.aot.cs.tu-berlin.de (8.11.6/8.11.2) with ESMTP id h639huD11648 for ; Thu, 3 Jul 2003 11:43:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jul 2003 11:43:53 +0200 Message-ID: Thread-Topic: Nemo digest, Vol 1 #38 - 10 msgs Thread-Index: AcNBR4Y3kgGSpHoWTOOBWSFXNPU3UwAAA6/A From: =?iso-8859-1?Q?Ingo_R=FCbe?= To: Content-Transfer-Encoding: quoted-printable Subject: [nemo] AW: Nemo digest, Vol 1 #38 - 10 msgs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In 5 minuten=20 -ingo -----Urspr=FCngliche Nachricht----- Von: nemo-request@ietf.org [mailto:nemo-request@ietf.org]=20 Gesendet: Donnerstag, 3. Juli 2003 11:42 An: nemo@ietf.org Betreff: Nemo digest, Vol 1 #38 - 10 msgs Send Nemo mailing list submissions to nemo@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/nemo or, via email, send a message with subject or body 'help' to nemo-request@ietf.org You can reach the person managing the list at nemo-admin@ietf.org When replying, please edit your Subject line so it is more specific than = "Re: Contents of Nemo digest..." Today's Topics: 1. Re: The question about NEMO basic support (Vijay Devarapalli) 2. Re: Design Team draft for NEMO Basic Solution (William D Ivancic) 3. Re: Vienna Agenda (William D Ivancic) 4. Re: Design Team draft for NEMO Basic Solution (Vijay Devarapalli) 5. Re: experiments (was: Vienna Agenda) (Alexandru Petrescu) 6. RE: Re: The question about NEMO basic support (Jongkeun Na) 7. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] (Eun = Kyoung Paik) 8. Re: Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt = (Henrik Petander) 9. nemo-request@ietf.org (Conferencia ew2004) 10. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] = (Alexandru Petrescu) --__--__-- Message: 1 Date: Wed, 02 Jul 2003 09:58:51 -0700 From: Vijay Devarapalli To: Jongkeun Na CC: nemo@ietf.org Subject: [nemo] Re: The question about NEMO basic support >=20 > Hello Vijay, >=20 > =20 >=20 > I have a question for prefix table described in the draft. >=20 > In case that prefix table is not pre-configured in HA, MR should use=20 > explicit or combined binding mode. Right? right.=20 >=20 > Let's assume that MR and HA can run dynamic routing protocol and=20 > prefix table is not pre-configured. when the MR and HA run a dynamic routing protocol there is no need to include an prefix information in the Binding Update. infact the HA should not try to determine the=20 prefix from the Binding Update. the routing protocol updates will carry = the prefix information. do you think we need an explicit flag in the = Binding Update for this?=20 Vijay >=20 > If MR try to do implicit binding, by the draft, MR cannot set up the=20 > bi-directional tunnel with its HA because HA will send BACK with `143' = > status code(Mobile Network Prefix Information information unavailable) = > for the requested BU. >=20 > I think HA should allow the implicit BU from MR that runs dynamic=20 > routing protocol because the draft says that prefix table is an=20 > optional data structure from the terminology description of section 2. = > Or, the draft should say prefix table MUST be maintained by HA. >=20 > =20 >=20 > It looks like unclear to me. Could you explain that for me? >=20 > =20 >=20 > Best Regards, >=20 > /Jongkeun --__--__-- Message: 2 Date: Wed, 02 Jul 2003 13:35:35 -0400 To: "T.J. Kniveton" From: William D Ivancic Subject: Re: [nemo] Design Team draft for NEMO Basic Solution Cc: Very nice work on the Basic Support. Sorry, I cannot make it out to Vienna, but I should be at the next=20 meeting. Also, I have a draft completed on issues related to = mobile-ip=20 and routing protocols when using encryption devices. I could not get it = in=20 before closeout of Internet Drafts. However I will as soon as IETF = opens=20 for new submissions. Here are a few questions and some minor corrections: 1) Question regarding section 8. Support for Dynamic Routing Protocols = "In the solution described so far, forwarding to the Mobile Network at = the=20 Home Agent is set up when the Home Agent receives a Binding Update from = the=20 Mobile Router. An alternative to this is for the Home Agent and the = Mobile=20 Router to run a intra-doamin routing protocol like RIPng [6] and OSPF = [7]=20 through the bi-directional tunnel." I believe the hop limit is usually set to 1 for routing=20 protocols. Encapsulation will decrement by 1. Do we need to state=20 anything here regarding the need to not decrement the Hop Limit field = here=20 or is this obvious? ( I am wary of this as it is definitely an issue = with=20 encryption devices.) 1.1) Has anyone given some though to policy base routing over tunnels = that=20 are coming up and going down? The aeronautics community still has this = on=20 their wish list. 2) Many places in the document is state "MUST not." Should those be=20 changed to "MUST NOT"? Typographic and Spelling Mistakes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Page 17. home link. At this point, Mobile Router MAY try try to obtain and own a=20 prefix by the same means that it initially got attributed the Invalid=20 Prefix in question. Alternatively, Mobile Router MAY send Binding = Updates=20 in another mode (e.g. implicit mode) to a Home Agent on the same home = link. MAY try try >>> MAY try The bi-directional tunnel between Mobile Router and Home Agent allows=20 packets to flow in both directions between these entities, while the = Mobile=20 Router is connected to a Visisted Link. Visisted Link. >>> Visited Link Page 18 A Mobile Router MAY use the received Router Advertisements on the = interface=20 connected to the home link, but only for logging and administrative=20 purposes. Only when that interface is connected to a A Mobile Router MAY = use the received Router Advertisements on the interface connected to the = home link, but only for logging and administrative purposes. Only when = that=20 interface is connected to a visisted link, visisted link >>> visited link Page 26 8. Support for Dynamic Routing Protocols In the solution described so = far,=20 forwarding to the Mobile Network at the Home Agent is set up when the = Home=20 Agent receives a Binding Update from the Mobile Router. An alternative = to=20 this is for the Home Agent and the Mobile Router to run a intra-doamin = routing intra-doamin >>> intra-domain Will Ivancic --__--__-- Message: 3 Date: Wed, 02 Jul 2003 13:55:46 -0400 To: vijayd@IPRG.nokia.com From: William D Ivancic Subject: Re: [nemo] Vienna Agenda Cc: Chan-Wah Ng , Thierry Ernst , IETF NEMO WG , "T.J. Kniveton" Vijay >it would be good to nail down what exactly NEMO is supposed >to support with respect to mutlihoming at this IETF. I have seen too=20 >many multihoming scenarios, some of which are not practical at all=20 >(IMHO). I work with mobile networks daily using Cisco's IPv4 implementation. = The=20 multihoming we utilize is one router with multiple "roaming" interfaces=20 connected to various links. Some of those links may have foreign agents = and others may use collocated-care-of-address (CC0A). For example I = have=20 one mobile router that has an 802.11 interface (foreign agent); one=20 satellite link using static CCOA and one G2.5 general packet radio = service=20 (GPRS) link using dynamic CCOA over PPP. The mobile router is = configured=20 to choose links in the following order of=20 preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although all links = may=20 be active and register as available, only one link can be used at a=20 time. Although some may wish (or at least think they wish) to use = multiple=20 links or all links (as with the aeronautical community) the practicality = of=20 this is questionable. The following are real measured numbers for some services we have used. Link Practical Data=20 Rate RTT Delay Cost =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= WiFi >1.0 Mbps 100 msec Free after=20 infrastructure or approximately equal to GPRS GPRS ~30 kbps 300 - 1000 msec $30 - $70 per=20 month Unlimited Volume Satellite ~ 40 kbps 1 - 2 seconds $1.00 per minute = !!!! Will Ivancic --__--__-- Message: 4 Date: Wed, 02 Jul 2003 11:08:06 -0700 From: Vijay Devarapalli To: William D Ivancic CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Design Team draft for NEMO Basic Solution William D Ivancic wrote: >=20 > Very nice work on the Basic Support. >=20 > Sorry, I cannot make it out to Vienna, but I should be at the next > meeting. Also, I have a draft completed on issues related to = mobile-ip > and routing protocols when using encryption devices. I could not get=20 > it in before closeout of Internet Drafts. However I will as soon as=20 > IETF opens for new submissions. >=20 > Here are a few questions and some minor corrections: >=20 > 1) Question regarding section 8. Support for Dynamic Routing=20 > Protocols "In the solution described so far, forwarding to the Mobile=20 > Network at the Home Agent is set up when the Home Agent receives a=20 > Binding Update from the Mobile Router. An alternative to this is for=20 > the Home Agent and the Mobile Router to run a intra-doamin routing=20 > protocol like RIPng [6] and OSPF [7] through the bi-directional=20 > tunnel." >=20 > I believe the hop limit is usually set to 1 for routing > protocols. Encapsulation will decrement by 1. Do we need to state > anything here regarding the need to not decrement the Hop Limit field=20 > here or is this obvious? ( I am wary of this as it is definitely an=20 > issue with encryption devices.) the way I see it is, both the HA and MR run a routing protocol through = the bi-directional tunnel. this tunnel is treated as=20 a singe hop link. both MR and HA use link local addresses for routing = protocol messages inside the tunnel. these messages are processed at = each end and are not forwarded onto the other links. forwarding packets with link local address raises a lot of=20 issues and also makes the HA implementation difficult. >=20 > 1.1) Has anyone given some though to policy base routing over tunnels = that > are coming up and going down? The aeronautics community still has = this on > their wish list. I am not sure I read any previous mails on this. can you tell me more? >=20 > 2) Many places in the document is state "MUST not." Should those = be > changed to "MUST NOT"? fixed >=20 > Typographic and Spelling Mistakes > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Page 17. > home link. At this point, Mobile Router MAY try try to obtain and own=20 > a prefix by the same means that it initially got attributed the=20 > Invalid Prefix in question. Alternatively, Mobile Router MAY send=20 > Binding Updates in another mode (e.g. implicit mode) to a Home Agent=20 > on the same home link. >=20 > MAY try try >>> MAY try >=20 > The bi-directional tunnel between Mobile Router and Home Agent allows=20 > packets to flow in both directions between these entities, while the=20 > Mobile Router is connected to a Visisted Link. >=20 > Visisted Link. >>> Visited Link >=20 > Page 18 >=20 > A Mobile Router MAY use the received Router Advertisements on the=20 > interface connected to the home link, but only for logging and=20 > administrative purposes. Only when that interface is connected to a A=20 > Mobile Router MAY use the received Router Advertisements on the=20 > interface connected to the home link, but only for logging and=20 > administrative purposes. Only when that interface is connected to a=20 > visisted link, >=20 > visisted link >>> visited link >=20 > Page 26 > 8. Support for Dynamic Routing Protocols In the solution described so=20 > far, forwarding to the Mobile Network at the Home Agent is set up when = > the Home Agent receives a Binding Update from the Mobile Router. An=20 > alternative to this is for the Home Agent and the Mobile Router to run = > a intra-doamin routing >=20 > intra-doamin >>> intra-domain thanks. Vijay --__--__-- Message: 5 Date: Thu, 03 Jul 2003 04:16:22 +0200 From: Alexandru Petrescu To: William D Ivancic CC: vijayd@IPRG.nokia.com, Chan-Wah Ng , Thierry Ernst , IETF NEMO WG = , "T.J. Kniveton" , Alexandru Petrescu Subject: [nemo] Re: experiments (was: Vienna Agenda) William D Ivancic wrote: > Vijay >=20 >=20 >> it would be good to nail down what exactly NEMO is supposed to >> support with respect to mutlihoming at this IETF. I have seen too=20 >> many multihoming scenarios, some of which are not practical at all=20 >> (IMHO). >=20 >=20 > I work with mobile networks daily using Cisco's IPv4 implementation. > The multihoming we utilize is one router with multiple "roaming"=20 > interfaces connected to various links. Some of those links may have=20 > foreign agents and others may use collocated-care-of-address (CC0A).=20 > For example I have one mobile router that has an 802.11 interface=20 > (foreign agent); one satellite link using static CCOA and one G2.5=20 > general packet radio service (GPRS) link using dynamic CCOA over PPP. > The mobile router is configured to choose links in the following=20 > order of preference: 1st WiFi, 2nd GPRS, 3rd Satellite. Although > all links may be active and register as available, only one link can > be used at a time. Although some may wish (or at least think they=20 > wish) to use multiple links or all links (as with the aeronautical=20 > community) the practicality of this is questionable. Thanks for the description, I'm happy to see these kinds of experiments = happen. Just to show similarity, we call a "roaming" interface a = "mobile" interface. We started with the same kind of idea for a mobile router prototype that = has several mobile interfaces connected to various access systems (but = behaviour was so difficult to maintain that we preferred to isolate ppp = connections on a "FrontBox"). For example, when a GPRS mobile interface = is used, and the mobile router enters a tunnel (a real tunnel like under = a river) then that PPP connection goes down, the corresponding interface = disappears, routing entries disappear. When the mobile router exits = that tunnel, re-establishing the PPP connection involved relaunching = many other things. So we considered designing "FrontBoxes" that would = isolate this behaviour from Mobile IPv6 software: A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base = Station. It also has a WLAN interface w1 on which it sends IPv6 RAs = towards MR. If the PPP connection goes down, this can be repaired = locally withouth MR noticing it. A WLAN FrontBox has two WLAN = interfaces, one of them attaching to a hotspot WLAN AP, and the other is = named w2. (A third _potential_ DVB FrontBox would use a terestrial DVB = link as well as a return path on another GPRS phone, such as to still = provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the = MR.) Each FrontBox uses private IPv4 to connect to GPRS or to hotspots = respectively. They also dynamically maintain IPv6-in-UDP/v4 tunnels = towards a special machine in the home network that has connectivity to = both IPv4 and IPv6 Internets. Each FB provides IPv6-only bidirectional = connectivity to MR, each sending different RA's with unique prefixes. A Mobile Router has only one WLAN "mobile" interface that switches = attachment between w1 and w2, as well as another WLAN interface towards = the mobile network link. The Mobile Router and the nodes in the mobile = network exclusively run IPv6 with network mobility based on Mobile IPv6 = (no IPv4). Mobile Router switches attachment by means of a visual = interface (GUI), with manual buttons. When I see the hotspot access = point approaching I push the "WLAN" button; when I see it in the rear = view mirror I push "GPRS". Of course, better can be done to automate = this with some preferences, as your experiments report. In this way, all access technologies are separated (read deterministic = and controllable), from the Mobile IPv6 behaviour. > The following are real measured numbers for some services we have > used. >=20 > Link Practical Data Rate RTT Delay Cost >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > WiFi >1.0 Mbps 100 msec Free after=20 > infrastructure or approximately equal to GPRS >=20 > GPRS ~30 kbps 300 - 1000 msec $30 - $70 per month > Unlimited Volume >=20 > Satellite ~ 40 kbps 1 - 2 seconds $1.00 per=20 > minute !!!! Confirms most of my expectations with respect to GPRS = rates/delays/dollar_cost. I'm suprised though to see "satellite" being = 40kb/s (I was thinking it would be much less(?). Does the satellite = link have a sort of return path? Could I imagine acquiring sattelite = link somehow somewhere to make a FrontBox with it? In our experiments, the data rates as shown by vic between LFN and a CN = placed in the home network varies between 11-45Kb/s (when GPRS) and = about 60kb/s (when WLAN). Ping delays over GPRS are little over 1s. The = direct communication between WLAN FrontBox and hotspot AP is standard = 11mb/s. All relevant delays and latencies largely depend on the higly = variable number of many hops between MR and HA as well as between CN and = HA and CN and MR. Billing was not taken into consideration since the billing scheme of the = access providers were themselves a moving ground (WLAN hotspots were = free but business model changing as we speak, including targetting a = "mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes = transferred, not the time length, not flat; to complicate things further = some GPRS operators make pay more if the given IPv4 address is publicly = routable non-NAT'ed, and less if NAT'ed). Ask me for more information, = or the operators themselves. There was not any form of multi-homing in our experiments, even if = several access systems were indeed used, or some other times in the = laboratory several Home Agents were used. Only one connection was used = at a time, and I don't see exactly how a "one-size-fits-all" means to = reasonably use simultaneously these three access systems can be = conceived. And yes, I would very much appreciate if clarifications are sought at = the live meeting with respect to multi-homing requirements and the = practical scenarios in relation to network mobility. Looking forward... Alex GBU --__--__-- Message: 6 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: [nemo] Re: The question about NEMO basic support Date: Thu, 3 Jul 2003 10:33:28 +0900 > > I have a question for prefix table described in the draft. > > > > In case that prefix table is not pre-configured in HA, MR should use > explicit or combined binding mode. Right? >=20 > right. >=20 > > > > Let's assume that MR and HA can run dynamic routing protocol and prefix > table is not pre-configured. >=20 > when the MR and HA run a dynamic routing protocol there is > no need to include an prefix information in the Binding Update. infact = > the HA should not try to determine the prefix from the Binding Update. = > the routing protocol updates will carry the prefix information. do you = > think we need an explicit flag in the Binding Update for this? >=20 Yes, I thought an explicit flag is required for HA to properly handle = this situation. /Jongkeun >=20 > Vijay >=20 > > > > If MR try to do implicit binding, by the draft, MR cannot set up the bi- > directional tunnel with its HA because HA will send BACK with `143' status > > code(Mobile Network Prefix Information information unavailable) for the > requested BU. > > > > I think HA should allow the implicit BU from MR that runs dynamic > routing protocol because the draft says that prefix table is an optional > data structure > > from the terminology description of section 2. Or, the draft should say > prefix table MUST be maintained by HA. > > > > > > > > It looks like unclear to me. Could you explain that for me? > > > > > > > > Best Regards, > > > > /Jongkeun --__--__-- Message: 7 Date: Thu, 3 Jul 2003 14:59:18 +0900 From: Eun Kyoung Paik To: Alexandru Petrescu Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D = ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Thank you for your kind reply. Please see inlines.=20 > > And I have another question on the implementation of nested mobile > > networks. For example, let's think about following topology. > >=20 > > Internet | AR | Parent MR | Child MR > >=20 > > In the figure, Parent MR may autoconfigure its CoA after it listens > > RA of AR. Then, Child MR may autoconfigure its CoA after it listens=20 > > RA of Parent MR. After that, if Parent MR listens Child MR's RA,=20 > > Parent MR configures new CoA according to Child MR's RA ? >=20 > In this particular configuration, I do not think that Parent MR=20 > configures a CoA based on the Child MR RA. There are two reasons for=20 > that. >=20 > One is that according to the stateless autoconfiguration mechanisms a=20 > router will not autoconfigure an address on an interface based on=20 > received RA's. Parent MR is a router, so. Then, how MR's egress interface configures its CoA=20 when it moves into a foreign link ? Doesn't it need RA from foreign link ? =20 >=20 > The other is that Child MR is, in fact, visiting the network of Parent > MR; when a MR is visiting, it acts as a host on its egress interface,=20 > not as a router. Thus it will not send RA's on its egress interface=20 > if it is not at home, so Parent MR does not get RA's from Child MR. I wonder if parent MR's egress interrface listen the RA of child MR's = ingress interface. (Child MR's ingress interface may broadcast its RA = for its VMNs.) And how can we distinguish egress interface from ingress interface = physically ? > There is also a widely acknolwedged problem of "disconnected"=20 > operation that was mentioned very early. >=20 > Have you encountered some similar problems? =20 Could you breifly explain about "disconnected" operation ? Regards, Eun Kyoung --__--__-- Message: 8 Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST) From: Henrik Petander To: Alexandru Petrescu Cc: Ralph Droms , Subject: Re: [nemo] Re: I-D = ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt On Wed, 2 Jul 2003, Alexandru Petrescu wrote: > Ralph Droms wrote: > > Following up on our conversation a couple of months ago about using=20 > > DHCPv6 PD for prefix delegation to mobile routers, I've published=20 > > "DHCPv6 Prefix Delegation for NEMO"=20 > > . This draft describes the use=20 > > of DHCPv6 to meet my understanding of the requirements for prefix=20 > > delegation to mobile routers. Comments welcome... > > I'm happy this draft exists and is up for comments. I think that the=20 > way it suggests behaviour of PD between MR and HA is very good for the = > simplest mobile network configurations. Yes, this seems like an easy way to allow a mobile node to become a = mobile router e.g. when user attaches a PDA to her mobile phone. > > > Other updates to the HA data structures required as a side effect of = =20 > > prefix delegation are specified by the particular network mobility=20 > > protocol. For example, in the case of "Basic Network Mobility=20 > > Support" [8], the HA would add an entry in its binding cache=20 > > registering the delegated prefix to the MR to which the prefix was=20 > > delegated. > > I don't think that any proposed solution would involve triggering=20 > additions of BC entries as a result of PD operations. Adding entries=20 > in the BC is exclusively a result of Binding messaging, in my=20 > understanding. I guess the prefix should be added to the prefix table instead. Then the = HA could authenticate MR as being authorized to send BUs for the = delegated prefix and MR could also send BUs without including explicit = prefix information. Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- --__--__-- Message: 9 From: Conferencia ew2004 To: nemo@ietf.org Date: Thu, 3 Jul 2003 10:47:09 +0200 (MEST) Subject: [nemo] nemo-request@ietf.org --__--__-- Message: 10 Date: Thu, 03 Jul 2003 11:41:21 +0200 From: Alexandru Petrescu To: Eun Kyoung Paik Cc: nemo@ietf.org, hscho@mmlab.snu.ac.kr Subject: Re: [nemo] I-D = ACTION:draft-lach-nemo-experiments-overdrive-00.txt] Eun Kyoung Paik wrote: > Thank you for your kind reply. Please see inlines. >=20 >>> And I have another question on the implementation of nested >>> mobile networks. For example, let's think about following=20 >>> topology. >>>=20 >>> Internet | AR | Parent MR | Child MR >>>=20 >>> In the figure, Parent MR may autoconfigure its CoA after it >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after=20 >>> it listens RA of Parent MR. After that, if Parent MR listens=20 >>> Child MR's RA, Parent MR configures new CoA according to Child=20 >>> MR's RA ? >>=20 >> In this particular configuration, I do not think that Parent MR >> configures a CoA based on the Child MR RA. There are two reasons=20 >> for that. >>=20 >> One is that according to the stateless autoconfiguration mechanisms =20 >> a router will not autoconfigure an address on an interface based on=20 >> received RA's. Parent MR is a router, so. >=20 > Then, how MR's egress interface configures its CoA when it moves into = > a foreign link ? Doesn't it need RA from foreign link ? Yes, exactly, it does need one. That's why the egress interface of a MR = will act as if it were belonging to a host (not a router) when visiting = a foreign network. >> The other is that Child MR is, in fact, visiting the network of >> Parent MR; when a MR is visiting, it acts as a host on its egress=20 >> interface, not as a router. Thus it will not send RA's on its=20 >> egress interface if it is not at home, so Parent MR does not get=20 >> RA's from Child MR. >=20 >=20 > I wonder if parent MR's egress interrface listen the RA of child MR's = > ingress interface. A picture would help. My picture is that Parent MR uses its egress to = connect to AR and ingress to connect to Child MR. Child MR uses its = egress to connect to Parent and its ingress to connect to its mobile = link. In general, I think the MR's _ingress_ interface will listen for RA's = but will not use it to autoconfigure addresses. The MR's _egress_ = interface, when in a foreign link, will listen to RA's from AR and will = autoconfigure CoA. Since the Child MR is acting like the parent MR, and child's egress = interface does not send RA (because it acts as a host on that interface) = then parent will not see any RA's coming from child MR. > (Child MR's ingress interface may broadcast its RA for its VMNs.) Yes, Child MR's ingress interface MUST broadcast RA (but not the = egress). Right? > And how can we distinguish egress interface from ingress interface > physically ? That's a good question and in one implementation that is a "knob", that = is like a turning button, like a kernel variable that says which = interface is "egress". > Could you breifly explain about "disconnected" operation ? Ok, maybe "disconnected operation" is my name for it, but the issue was = mentioned under other names, where two nested mobile networks can't talk = to each other if their respective HA's are not available. Many = discussions in the archives. Many pros and cons of this being or not = being a problem. Alex GBU --__--__-- _______________________________________________ Nemo mailing list Nemo@ietf.org https://www1.ietf.org/mailman/listinfo/nemo End of Nemo Digest From exim@www1.ietf.org Thu Jul 3 19:46:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26949 for ; Thu, 3 Jul 2003 19:46:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDmS-0002Zl-Dy for nemo-archive@odin.ietf.org; Thu, 03 Jul 2003 19:46:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NkOse009891 for nemo-archive@odin.ietf.org; Thu, 3 Jul 2003 19:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDkO-0002Bz-J9 for nemo-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 19:44:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25161 for ; Thu, 3 Jul 2003 19:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YD3w-0000Ls-00 for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 19:00:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YCru-0006wV-0E for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 18:47:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCfo-0008Oi-Ii for nemo-web-archive@ietf.org; Thu, 03 Jul 2003 18:35:28 -0400 Date: Thu, 03 Jul 2003 18:35:28 -0400 Message-ID: <20030703223528.4508.84319.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From nemo-admin@ietf.org Fri Jul 4 02:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18370 for ; Fri, 4 Jul 2003 02:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKTG-00029R-LW; Fri, 04 Jul 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKT3-00028a-DM for nemo@optimus.ietf.org; Fri, 04 Jul 2003 02:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18340 for ; Fri, 4 Jul 2003 02:54:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YKSz-0002n8-00 for nemo@ietf.org; Fri, 04 Jul 2003 02:54:45 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19YKSy-0002lm-00 for nemo@ietf.org; Fri, 04 Jul 2003 02:54:44 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <3GJLXK7P>; Fri, 4 Jul 2003 02:54:11 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BBA4@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , William D Ivancic Cc: "T.J. Kniveton" , nemo@ietf.org, ernst@sfc.wide.ad.jp Subject: RE: Policy base MR operation (was Re: [nemo] Design Team draft fo r NEMO Basic Solution) Date: Fri, 4 Jul 2003 02:54:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > 1. there are multiple intefaces available, and the MR > should pick the best available interface. IMO, this > is not necessarily a NEMO problem. you need something > like a "roaming manager" (there are many synonyms for > this), which figures out which interface is up and > decides which interface should be used and when. as > far as the NEMO protocol is concerned, it needs an > uplink to the visited network, through which the MR > can reach its Home Agent. I think there is nothing to > standardize here. the "roaming manager" would be > implementation specific. > > 2. in your experiment, you said you were required to send > control traffic through a VDL or INMARSAT link and data > traffic through a Connexion link. isnt this again > implementation specific? the forwarding code on the > MR has to figure out the outgoing interface based on the > message contents. do you see a need to standardize > something here? do we need an API between the NEMO > module and the "roaming manager"? => There would be a protocol to standardise if the MR has a different CoA on each interface. We've attempted this in : http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-03.txt for mobile nodes and the same can be used by MRs. I don't think any of this is NEMO specific though. Hesham > > a list of requirements in the form of an internet draft > would be nice. then we can figure out what exactly needs > to be specified. > > > Now let me add some more reality to the mess. (This is my current > > understanding as explained to me by various pilots. I am open to > > correction.) Commercial aircraft today generally only > have one active VDL > > circuit that is performing packetized communication. The > other is used for > > voice. They are not combined (i.e. VOIP). Because the > satellite time > > costs so much, the INMARSAT system generally is not > powered on unless the > > VDL link is lost. So in reality, only one link is > active. The question > > I keep raising to this community is why policy-based > routing and load > > sharing when in reality only one link is active. I also > suspect that I > > could obtain much higher QoS if I used the Connexion link ( or > > similar) for command and control when available and could > sufficiently > > secure those messages with today's technologies. IMHO, > What is really > > needed is some type of quality of service requirement such > that command and > > control is highest priority. > > I agree with you here. > > Vijay > From exim@www1.ietf.org Fri Jul 4 02:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18385 for ; Fri, 4 Jul 2003 02:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKTJ-0002BP-Jz for nemo-archive@odin.ietf.org; Fri, 04 Jul 2003 02:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h646t5s2008390 for nemo-archive@odin.ietf.org; Fri, 4 Jul 2003 02:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKTJ-0002BF-DD for nemo-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 02:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAB18357 for ; Fri, 4 Jul 2003 02:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YKTF-0002nY-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 02:55:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YKTF-0002nV-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 02:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKTG-00029R-LW; Fri, 04 Jul 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YKT3-00028a-DM for nemo@optimus.ietf.org; Fri, 04 Jul 2003 02:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18340 for ; Fri, 4 Jul 2003 02:54:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YKSz-0002n8-00 for nemo@ietf.org; Fri, 04 Jul 2003 02:54:45 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19YKSy-0002lm-00 for nemo@ietf.org; Fri, 04 Jul 2003 02:54:44 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <3GJLXK7P>; Fri, 4 Jul 2003 02:54:11 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BBA4@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , William D Ivancic Cc: "T.J. Kniveton" , nemo@ietf.org, ernst@sfc.wide.ad.jp Subject: RE: Policy base MR operation (was Re: [nemo] Design Team draft fo r NEMO Basic Solution) Date: Fri, 4 Jul 2003 02:54:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > 1. there are multiple intefaces available, and the MR > should pick the best available interface. IMO, this > is not necessarily a NEMO problem. you need something > like a "roaming manager" (there are many synonyms for > this), which figures out which interface is up and > decides which interface should be used and when. as > far as the NEMO protocol is concerned, it needs an > uplink to the visited network, through which the MR > can reach its Home Agent. I think there is nothing to > standardize here. the "roaming manager" would be > implementation specific. > > 2. in your experiment, you said you were required to send > control traffic through a VDL or INMARSAT link and data > traffic through a Connexion link. isnt this again > implementation specific? the forwarding code on the > MR has to figure out the outgoing interface based on the > message contents. do you see a need to standardize > something here? do we need an API between the NEMO > module and the "roaming manager"? => There would be a protocol to standardise if the MR has a different CoA on each interface. We've attempted this in : http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-03.txt for mobile nodes and the same can be used by MRs. I don't think any of this is NEMO specific though. Hesham > > a list of requirements in the form of an internet draft > would be nice. then we can figure out what exactly needs > to be specified. > > > Now let me add some more reality to the mess. (This is my current > > understanding as explained to me by various pilots. I am open to > > correction.) Commercial aircraft today generally only > have one active VDL > > circuit that is performing packetized communication. The > other is used for > > voice. They are not combined (i.e. VOIP). Because the > satellite time > > costs so much, the INMARSAT system generally is not > powered on unless the > > VDL link is lost. So in reality, only one link is > active. The question > > I keep raising to this community is why policy-based > routing and load > > sharing when in reality only one link is active. I also > suspect that I > > could obtain much higher QoS if I used the Connexion link ( or > > similar) for command and control when available and could > sufficiently > > secure those messages with today's technologies. IMHO, > What is really > > needed is some type of quality of service requirement such > that command and > > control is highest priority. > > I agree with you here. > > Vijay > From nemo-admin@ietf.org Fri Jul 4 04:31:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20325 for ; Fri, 4 Jul 2003 04:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLy9-00006v-SG; Fri, 04 Jul 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLxV-000060-Hc for nemo@optimus.ietf.org; Fri, 04 Jul 2003 04:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20288 for ; Fri, 4 Jul 2003 04:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YLxS-0003OK-00 for nemo@ietf.org; Fri, 04 Jul 2003 04:30:18 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19YLxR-0003O3-00 for nemo@ietf.org; Fri, 04 Jul 2003 04:30:18 -0400 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h648Tk44011448 for ; Fri, 4 Jul 2003 10:29:47 +0200 (MET DST) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id h648TkdX024878 for nemo@ietf.org; Fri, 4 Jul 2003 10:29:46 +0200 (MET DST) Date: Fri, 4 Jul 2003 10:29:46 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030704082946.GA24873@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roura.ac.upc.es id h648Tk44011448 Content-Transfer-Encoding: quoted-printable Subject: [nemo] European Wireless'04 CFP reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Colleague, We would like to draw your attention to the "5th European Wireless Conference" Barcelona, Spain, February 2004. We would appreciate your assistance in distributing this call for papers to your colleagues. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. ------------------------------------------------------------------------- EW2004 The 5th European Wireless Conference Mobile and Wireless Systems beyond 3G http://www.ac.upc.es/EW2004=20 February 24-27, 2004 Technical University of Catalonia (UPC) - Barcelona, Spain CONFERENCE SCOPE In order to be able to be connected anywhere and at anytime a seamless ac= cess to the various access technologies is needed providing the adequate QoS t= o=20 diverse applications.=20 The 5th European Wireless Conference focuses on technologies, protocols,=20 services and applications that will enable a full seamless and nomadic us= er=20 access to new classes of person to person, device to device and device=20 to person applications. TOPICS Technical papers describing original, previously unpublished research are= solicited.=20 Specific topics of interest include, but are not limited to, the followin= g: * Adaptive Antennas * Base Station Technology * Indoor Channel Modeling( Wave Propagation and Measurements * Integration of Radio Localization Systems into Wireless User Terminals * Integration of Terrestrial and Satellite Networks * Interference Mitigation and Management Techniques * Power and Interference Control * Power Management for small terminals * Protocols for Air Interfaces and Networks * Short Range Communication Systems * Signal Processing Techniques for Communications * Analysis( Simulation and Measurements of Mobile and Wireless Systems * High Altitude Platforms and Satellites * Internetworking between Different Access Technologies * Mobile Agents * Mobile and Wireless Applications * Mobility Management * Multiple Access Schemes * Positioning=20 * QoS in Mobile and Wireless Networks * Routing in Ad hoc Networks * Security and robustness in wireless networks * Sensor Network Planning and Deployment * Wireless Ad hoc Networks * Wireless LANs PAPER SUBMISSION INSTRUCTIONS Papers for the conference should be written in English and with a limit o= f 12 double=20 spaced pages. All paper submissions will be handled electronically, following the instr= uctions at: http://www.ac.upc.es/EW2004 All papers will be reviewed by the program committee members. Accepted papers will be published in the conference proceedings.=20 IMPORTANT DATES Full papers due: September 10th 2003 Notification of Acceptance: November 14th 2003 Camera Ready due: December 12th 2003 GENERAL CHAIR:=20 Olga Casals, (Technical University of Catalonia, UPC, Spain) Jorge Garcia-Vidal (Technical University of Catalonia, UPC, Spain) STEERING COMMITTEE CHAIR:=20 Bernhard Walke (Aachen University of Technology, Germany) TECHNICAL PROGRAM CO-CHAIRS: Miguel A. Lagunas (CTTC, Spain) Ioannis Stavrakakis (University of Athens, Greece) TUTORIAL CHAIR: Jorge Garc=EDa-Vidal (UPC, Spain) LOCAL ARRANGEMENTS CO-CHAIRS: Carles Ant=F3n (CTTC, Spain) Jose M. Barcel=F3 (UPC, Spain) Lloren=E7 Cerd=E0 (UPC, Spain) TECHNICAL PROGRAM COMMITTEE: R. Agust=ED (UPC, Spain) I. Akyildiz (Georgia Ins. of Technology, USA) E. Altman (INRIA, France) A. Art=E9s (Univ. Carlos III, Spain) S. Benedetto (Politecnico de Torino, Italy) C. Blondia (Univ. of Antwerp, Belgium) E. Bonek (TU of Viena, Austria) A. Campbell (Columbia University, USA) V. Casares (UPV, Spain) E. Casilari (Univ. de Malaga, Spain) L. Castedo (Univ. de La Coru=F1a, Spain) M. Conti (IIT/CNR, Italy) L. Correia (IST, Portugal) L. Cuthbert (Univ. of London, UK) J. Dunlop (Univ. of Strathclyde, UK) S. Giordano (EPFL, Switzerland) H. Kawashima (Tokio Univ. of Agriculture & Technology, Japan) U. K=F6rner (Univ. of Lund, Sweden) P. Kuehn (Univ. of Stuttgart, Germany) L. Lenzini (Univ. of Pisa, Italy) J. M. Paez Borrallo (UPM, Spain) J. Paradells (UPC, Spain) C. Rosenberg (Purdue University, USA) H. St=FCttgen (NEC, Germany) A. Svensson (Chalmers, Sweden) R. Tafazolli (Univ. of Surrey, UK) Y. Takahashi (Kyoto University, Japan) L. Tassiulas (Univ. of Maryland, USA) S. Tohme (ENST, France) P. Tran-Gia (Univ. of W=FCrzburg, Germany) M. Uylat (Univ. of Waterloo, Canada) A. Valko (Ericsson, Sweden) A. Vilavaara (Nokia Research Center, Finland) A. Wolisz (Univ. of Berlin, Germany) J. Zander (KTH Stockholm, Sweden) M. Zukerman (Univ. of Melbourne, Australia) EW2004 CONTACT e-mail: ew2004@ac.upc.es FINANCE CHAIR Volker Schanz, VDE/ITG, Germany CONFERENCE SECRETARIAT VDE-Conference Department Stresemannallee 1560596 Frankfurt-Main Germany Phone: +49-69-6308-202 Fax: +49-69-97315213 e-mail: vde-conferences@vde.com URL: www.vde.com=20 From exim@www1.ietf.org Fri Jul 4 04:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20340 for ; Fri, 4 Jul 2003 04:31:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLyG-000080-D7 for nemo-archive@odin.ietf.org; Fri, 04 Jul 2003 04:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h648V8KE000492 for nemo-archive@odin.ietf.org; Fri, 4 Jul 2003 04:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLyF-00007r-Vh for nemo-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 04:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20309 for ; Fri, 4 Jul 2003 04:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YLyD-0003Oi-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 04:31:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YLyC-0003Of-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 04:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLy9-00006v-SG; Fri, 04 Jul 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YLxV-000060-Hc for nemo@optimus.ietf.org; Fri, 04 Jul 2003 04:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20288 for ; Fri, 4 Jul 2003 04:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YLxS-0003OK-00 for nemo@ietf.org; Fri, 04 Jul 2003 04:30:18 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19YLxR-0003O3-00 for nemo@ietf.org; Fri, 04 Jul 2003 04:30:18 -0400 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h648Tk44011448 for ; Fri, 4 Jul 2003 10:29:47 +0200 (MET DST) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id h648TkdX024878 for nemo@ietf.org; Fri, 4 Jul 2003 10:29:46 +0200 (MET DST) Date: Fri, 4 Jul 2003 10:29:46 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030704082946.GA24873@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roura.ac.upc.es id h648Tk44011448 Content-Transfer-Encoding: quoted-printable Subject: [nemo] European Wireless'04 CFP reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Colleague, We would like to draw your attention to the "5th European Wireless Conference" Barcelona, Spain, February 2004. We would appreciate your assistance in distributing this call for papers to your colleagues. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. ------------------------------------------------------------------------- EW2004 The 5th European Wireless Conference Mobile and Wireless Systems beyond 3G http://www.ac.upc.es/EW2004=20 February 24-27, 2004 Technical University of Catalonia (UPC) - Barcelona, Spain CONFERENCE SCOPE In order to be able to be connected anywhere and at anytime a seamless ac= cess to the various access technologies is needed providing the adequate QoS t= o=20 diverse applications.=20 The 5th European Wireless Conference focuses on technologies, protocols,=20 services and applications that will enable a full seamless and nomadic us= er=20 access to new classes of person to person, device to device and device=20 to person applications. TOPICS Technical papers describing original, previously unpublished research are= solicited.=20 Specific topics of interest include, but are not limited to, the followin= g: * Adaptive Antennas * Base Station Technology * Indoor Channel Modeling( Wave Propagation and Measurements * Integration of Radio Localization Systems into Wireless User Terminals * Integration of Terrestrial and Satellite Networks * Interference Mitigation and Management Techniques * Power and Interference Control * Power Management for small terminals * Protocols for Air Interfaces and Networks * Short Range Communication Systems * Signal Processing Techniques for Communications * Analysis( Simulation and Measurements of Mobile and Wireless Systems * High Altitude Platforms and Satellites * Internetworking between Different Access Technologies * Mobile Agents * Mobile and Wireless Applications * Mobility Management * Multiple Access Schemes * Positioning=20 * QoS in Mobile and Wireless Networks * Routing in Ad hoc Networks * Security and robustness in wireless networks * Sensor Network Planning and Deployment * Wireless Ad hoc Networks * Wireless LANs PAPER SUBMISSION INSTRUCTIONS Papers for the conference should be written in English and with a limit o= f 12 double=20 spaced pages. All paper submissions will be handled electronically, following the instr= uctions at: http://www.ac.upc.es/EW2004 All papers will be reviewed by the program committee members. Accepted papers will be published in the conference proceedings.=20 IMPORTANT DATES Full papers due: September 10th 2003 Notification of Acceptance: November 14th 2003 Camera Ready due: December 12th 2003 GENERAL CHAIR:=20 Olga Casals, (Technical University of Catalonia, UPC, Spain) Jorge Garcia-Vidal (Technical University of Catalonia, UPC, Spain) STEERING COMMITTEE CHAIR:=20 Bernhard Walke (Aachen University of Technology, Germany) TECHNICAL PROGRAM CO-CHAIRS: Miguel A. Lagunas (CTTC, Spain) Ioannis Stavrakakis (University of Athens, Greece) TUTORIAL CHAIR: Jorge Garc=EDa-Vidal (UPC, Spain) LOCAL ARRANGEMENTS CO-CHAIRS: Carles Ant=F3n (CTTC, Spain) Jose M. Barcel=F3 (UPC, Spain) Lloren=E7 Cerd=E0 (UPC, Spain) TECHNICAL PROGRAM COMMITTEE: R. Agust=ED (UPC, Spain) I. Akyildiz (Georgia Ins. of Technology, USA) E. Altman (INRIA, France) A. Art=E9s (Univ. Carlos III, Spain) S. Benedetto (Politecnico de Torino, Italy) C. Blondia (Univ. of Antwerp, Belgium) E. Bonek (TU of Viena, Austria) A. Campbell (Columbia University, USA) V. Casares (UPV, Spain) E. Casilari (Univ. de Malaga, Spain) L. Castedo (Univ. de La Coru=F1a, Spain) M. Conti (IIT/CNR, Italy) L. Correia (IST, Portugal) L. Cuthbert (Univ. of London, UK) J. Dunlop (Univ. of Strathclyde, UK) S. Giordano (EPFL, Switzerland) H. Kawashima (Tokio Univ. of Agriculture & Technology, Japan) U. K=F6rner (Univ. of Lund, Sweden) P. Kuehn (Univ. of Stuttgart, Germany) L. Lenzini (Univ. of Pisa, Italy) J. M. Paez Borrallo (UPM, Spain) J. Paradells (UPC, Spain) C. Rosenberg (Purdue University, USA) H. St=FCttgen (NEC, Germany) A. Svensson (Chalmers, Sweden) R. Tafazolli (Univ. of Surrey, UK) Y. Takahashi (Kyoto University, Japan) L. Tassiulas (Univ. of Maryland, USA) S. Tohme (ENST, France) P. Tran-Gia (Univ. of W=FCrzburg, Germany) M. Uylat (Univ. of Waterloo, Canada) A. Valko (Ericsson, Sweden) A. Vilavaara (Nokia Research Center, Finland) A. Wolisz (Univ. of Berlin, Germany) J. Zander (KTH Stockholm, Sweden) M. Zukerman (Univ. of Melbourne, Australia) EW2004 CONTACT e-mail: ew2004@ac.upc.es FINANCE CHAIR Volker Schanz, VDE/ITG, Germany CONFERENCE SECRETARIAT VDE-Conference Department Stresemannallee 1560596 Frankfurt-Main Germany Phone: +49-69-6308-202 Fax: +49-69-97315213 e-mail: vde-conferences@vde.com URL: www.vde.com=20 From nemo-admin@ietf.org Fri Jul 4 20:49:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13978 for ; Fri, 4 Jul 2003 20:49:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbEb-0000ZX-Dk; Fri, 04 Jul 2003 20:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbDp-0000ZA-KX for nemo@optimus.ietf.org; Fri, 04 Jul 2003 20:48:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13963 for ; Fri, 4 Jul 2003 20:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YbDn-0004gf-00 for nemo@ietf.org; Fri, 04 Jul 2003 20:48:11 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 19YbDm-0004gH-00 for nemo@ietf.org; Fri, 04 Jul 2003 20:48:10 -0400 Received: from kjlee (leekj3.etri.re.kr [129.254.112.172]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h6510o918261; Sat, 5 Jul 2003 10:00:51 +0900 (KST) Message-ID: <004901c3428f$066dedd0$ac70fe81@kjlee> From: "KyeongJin Lee" To: "Alexandru Petrescu" , References: <3F0460DF.1040603@motorola.com> Subject: Re: [nemo] Comments on draft-leekj-nemo-ro-pd-00.txt Date: Sat, 5 Jul 2003 09:47:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24uDQoNCj4gW0NoYWlycyBzdG9wIG1l IGlmIFJPIGRpc2N1c3Npb25zIG5vdCBpbiBjb250ZXh0IG5vd10NCj4gDQo+IEhlbGxvIHRvIGF1 dGhvcnMgb2YgZHJhZnQtbGVla2otbmVtby1yby1wZC0wMC50eHQuDQo+IA0KPiBJJ3ZlIHJlYWQg dGhlIGRyYWZ0LCB0aGFua3MgZm9yIHByb3ZpZGluZyBpdC4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0 aGF0IHRoZSBtZXRob2Qgb2ZmZXJzIG9wdGltYWwgcGF0aHMgYmV0d2VlbiBNTidzIGluc2lkZQ0K PiB0aGUgbW9iaWxlIG5ldHdvcmsgYW5kIENOIG91dHNpZGUgdGhlIG1vYmlsZSBuZXR3b3JrLiAg RmlndXJlIDEgc2hvd3MgYW4NCj4gTEZOLCB0aGF0IGlzIHN1cHBvc2VkbHkgZml4ZWQuICBJcyB0 aGUgZHJhZnQgcHJvdmlkaW5nIG9wdGltYWwgcm91dGVzDQo+IGJldHdlZW4gTEZOIGFuZCBDTiB0 b28gKG9yIG9ubHkgYmV0d2VlbiBNTiBhbmQgQ04pPyAgTEZOIG5vcm1hbGx5IGRvZXMNCj4gbm90 IHBlcmZvcm0gaXRzZWxmIE1vYmlsZSBJUHY2LCByaWdodD8NCg0KT3VyIGRyYWZ0IHByb3Bvc2Vz IFJPIGJldHdlZW4gTU4gYW5kIENOLg0KVGhlIGZpZ3VyZSAxIHNob3dzIGFuIGV4YW1wbGUgb2Yg bW9iaWxlIG5ldHdvcmsgYW5kIHRoZSBMRk4gaXMganVzdCBhbiBleGFtcGxlIG9mIE1OTnMuDQpB cyB5b3Ugc2FpZCwgYSBmaXhlZCBub2RlIGRvZXMgbm90IHBlcmZvcm0gTW9iaWxlIElQdjYsIA0K TEZOIGFuZCBDTiBjb21tdW5pY2F0ZSBlYWNoIG90aGVyIGJ5IHVzaW5nIGJpLWRpcmVjdGlvbmFs IHR1bm5lbCBiZXR3ZWVuIE1SIGFuZCBNUidzIEhBLg0KDQoNCj4gSSBkb24ndCB1bmRlcnN0YW5k IHdoeSB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgbmV3IE5EIG9wdGlvbj8gIENvdWxkbid0DQo+IHRo ZSB1c3VhbCBSQSBiZSB1c2VkIGJ5IE1SIHRvIHB1dCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbiwg YW5kIGFkdmVydGlzZQ0KPiB0b3dhcmRzIE1OPw0KDQpNTiBtdXN0IGRpc3Rpbmd1aXNoIGJldHdl ZW4gb24tbGluayBwcmVmaXggYW5kIGRlbGVnYXRlZCBwcmVmaXguIA0KRm9yIHRoZSBkaXN0aW5j dGlvbiwgd2UgY2FuIHVzZSBuZXcgb3B0aW9uIG9yIG5ldyBmbGFnLg0KSW4gb3VyIGFub3RoZXIg ZHJhZnQsDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1u ZW1vLXJvLW5kcHJveHktMDAudHh0DQpkZWZpbmVzIGp1c3QgYSBmbGFnIGZvciBSTyBpbiB0aGUg cHJlZml4IGluZm9ybWF0aW9uIG9wdGlvbiBvZiBSQSAuDQoNCj4gV2hhdCBoYXBwZW5zIHdoZW4g dGhlcmUgYXJlIHNldmVyYWwgZml4ZWQgcm91dGVycyBpbiB0aGUgbW9iaWxlIG5ldHdvcmsNCj4g YW5kIGEgTU4gd291bGQgdmlzaXQgZGVlcCBiZWxvdyBvbmUgb2YgdGhvc2UgRlIncz8gIE5vcm1h bGx5IFJBJ3Mgc3RheQ0KPiBvbiBhIGxpbmssIHNvIHRoZSBSQSB3aXRoIHRoZSBkZWxlZ2F0ZWQg cHJlZml4IGNvbWluZyBmcm9tIHVwIHdpbGwgb25seQ0KPiBiZSBzZWVuIGluIHRoZSBmaXJzdCB1 cHBlciBsaW5rLCBub3QgYmVsb3cuICBPciBtYXliZSB0aGF0IGlzIG91dHNpZGUNCj4gdGhlIHNj b3BlIG9mIHRoZSBkcmFmdD8NCg0KSW4gb3VyIGRyYWZ0LCBpdCBpcyBvdXQgb2Ygc2NvcGUuDQoN Cg0KPiANCj4gQWxleA0KPiBHQlUNCj4gDQo+IA0KPiA= From exim@www1.ietf.org Fri Jul 4 20:49:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13993 for ; Fri, 4 Jul 2003 20:49:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbEi-0000aX-Cf for nemo-archive@odin.ietf.org; Fri, 04 Jul 2003 20:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h650n8tv002255 for nemo-archive@odin.ietf.org; Fri, 4 Jul 2003 20:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbEi-0000aI-8l for nemo-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 20:49:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13975 for ; Fri, 4 Jul 2003 20:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YbEg-0004hN-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 20:49:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YbEf-0004hJ-00 for nemo-web-archive@ietf.org; Fri, 04 Jul 2003 20:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbEb-0000ZX-Dk; Fri, 04 Jul 2003 20:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YbDp-0000ZA-KX for nemo@optimus.ietf.org; Fri, 04 Jul 2003 20:48:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13963 for ; Fri, 4 Jul 2003 20:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YbDn-0004gf-00 for nemo@ietf.org; Fri, 04 Jul 2003 20:48:11 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 19YbDm-0004gH-00 for nemo@ietf.org; Fri, 04 Jul 2003 20:48:10 -0400 Received: from kjlee (leekj3.etri.re.kr [129.254.112.172]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h6510o918261; Sat, 5 Jul 2003 10:00:51 +0900 (KST) Message-ID: <004901c3428f$066dedd0$ac70fe81@kjlee> From: "KyeongJin Lee" To: "Alexandru Petrescu" , References: <3F0460DF.1040603@motorola.com> Subject: Re: [nemo] Comments on draft-leekj-nemo-ro-pd-00.txt Date: Sat, 5 Jul 2003 09:47:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24uDQoNCj4gW0NoYWlycyBzdG9wIG1l IGlmIFJPIGRpc2N1c3Npb25zIG5vdCBpbiBjb250ZXh0IG5vd10NCj4gDQo+IEhlbGxvIHRvIGF1 dGhvcnMgb2YgZHJhZnQtbGVla2otbmVtby1yby1wZC0wMC50eHQuDQo+IA0KPiBJJ3ZlIHJlYWQg dGhlIGRyYWZ0LCB0aGFua3MgZm9yIHByb3ZpZGluZyBpdC4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0 aGF0IHRoZSBtZXRob2Qgb2ZmZXJzIG9wdGltYWwgcGF0aHMgYmV0d2VlbiBNTidzIGluc2lkZQ0K PiB0aGUgbW9iaWxlIG5ldHdvcmsgYW5kIENOIG91dHNpZGUgdGhlIG1vYmlsZSBuZXR3b3JrLiAg RmlndXJlIDEgc2hvd3MgYW4NCj4gTEZOLCB0aGF0IGlzIHN1cHBvc2VkbHkgZml4ZWQuICBJcyB0 aGUgZHJhZnQgcHJvdmlkaW5nIG9wdGltYWwgcm91dGVzDQo+IGJldHdlZW4gTEZOIGFuZCBDTiB0 b28gKG9yIG9ubHkgYmV0d2VlbiBNTiBhbmQgQ04pPyAgTEZOIG5vcm1hbGx5IGRvZXMNCj4gbm90 IHBlcmZvcm0gaXRzZWxmIE1vYmlsZSBJUHY2LCByaWdodD8NCg0KT3VyIGRyYWZ0IHByb3Bvc2Vz IFJPIGJldHdlZW4gTU4gYW5kIENOLg0KVGhlIGZpZ3VyZSAxIHNob3dzIGFuIGV4YW1wbGUgb2Yg bW9iaWxlIG5ldHdvcmsgYW5kIHRoZSBMRk4gaXMganVzdCBhbiBleGFtcGxlIG9mIE1OTnMuDQpB cyB5b3Ugc2FpZCwgYSBmaXhlZCBub2RlIGRvZXMgbm90IHBlcmZvcm0gTW9iaWxlIElQdjYsIA0K TEZOIGFuZCBDTiBjb21tdW5pY2F0ZSBlYWNoIG90aGVyIGJ5IHVzaW5nIGJpLWRpcmVjdGlvbmFs IHR1bm5lbCBiZXR3ZWVuIE1SIGFuZCBNUidzIEhBLg0KDQoNCj4gSSBkb24ndCB1bmRlcnN0YW5k IHdoeSB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgbmV3IE5EIG9wdGlvbj8gIENvdWxkbid0DQo+IHRo ZSB1c3VhbCBSQSBiZSB1c2VkIGJ5IE1SIHRvIHB1dCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbiwg YW5kIGFkdmVydGlzZQ0KPiB0b3dhcmRzIE1OPw0KDQpNTiBtdXN0IGRpc3Rpbmd1aXNoIGJldHdl ZW4gb24tbGluayBwcmVmaXggYW5kIGRlbGVnYXRlZCBwcmVmaXguIA0KRm9yIHRoZSBkaXN0aW5j dGlvbiwgd2UgY2FuIHVzZSBuZXcgb3B0aW9uIG9yIG5ldyBmbGFnLg0KSW4gb3VyIGFub3RoZXIg ZHJhZnQsDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1u ZW1vLXJvLW5kcHJveHktMDAudHh0DQpkZWZpbmVzIGp1c3QgYSBmbGFnIGZvciBSTyBpbiB0aGUg cHJlZml4IGluZm9ybWF0aW9uIG9wdGlvbiBvZiBSQSAuDQoNCj4gV2hhdCBoYXBwZW5zIHdoZW4g dGhlcmUgYXJlIHNldmVyYWwgZml4ZWQgcm91dGVycyBpbiB0aGUgbW9iaWxlIG5ldHdvcmsNCj4g YW5kIGEgTU4gd291bGQgdmlzaXQgZGVlcCBiZWxvdyBvbmUgb2YgdGhvc2UgRlIncz8gIE5vcm1h bGx5IFJBJ3Mgc3RheQ0KPiBvbiBhIGxpbmssIHNvIHRoZSBSQSB3aXRoIHRoZSBkZWxlZ2F0ZWQg cHJlZml4IGNvbWluZyBmcm9tIHVwIHdpbGwgb25seQ0KPiBiZSBzZWVuIGluIHRoZSBmaXJzdCB1 cHBlciBsaW5rLCBub3QgYmVsb3cuICBPciBtYXliZSB0aGF0IGlzIG91dHNpZGUNCj4gdGhlIHNj b3BlIG9mIHRoZSBkcmFmdD8NCg0KSW4gb3VyIGRyYWZ0LCBpdCBpcyBvdXQgb2Ygc2NvcGUuDQoN Cg0KPiANCj4gQWxleA0KPiBHQlUNCj4gDQo+IA0KPiA= From nemo-admin@ietf.org Mon Jul 7 10:06:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25804 for ; Mon, 7 Jul 2003 10:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcz-0002Mc-2m; Mon, 07 Jul 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWck-0002KH-DK for nemo@optimus.ietf.org; Mon, 07 Jul 2003 10:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25588 for ; Mon, 7 Jul 2003 10:05:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWci-0004W5-00 for nemo@ietf.org; Mon, 07 Jul 2003 10:05:44 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19ZWcg-0004Vi-00 for nemo@ietf.org; Mon, 07 Jul 2003 10:05:42 -0400 Received: from localhost (unknown [203.178.138.13]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id BC9365D013; Mon, 7 Jul 2003 23:03:59 +0900 (JST) Date: Mon, 7 Jul 2003 23:03:58 +0900 From: Julien Charbon To: nemo@ietf.org Cc: Alexandru Petrescu Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> In-Reply-To: <3F043046.6020401@motorola.com> References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bonjour Alexandru, Hello all, Alexandru Petrescu wrote: > Julien Charbon wrote: > > Hello all, > > > > We have written an Internet-Draft on the evaluation of Multi-homing > > support by NEMO Basic solution. > > Thanks for the draft, useful analysis. Good to see that most > multi-homing aspects can be featured by base spec. Thanks for appreciations, and yes, you work fine to permit the Basic solution to not prevent Multihoming support; pretty good proposition I think. > I have some remarks from the start. The document defines "Policy" and > "Load Sharing" in a very loose way (at least when compared to the > specific specification of e.g. deriving a Home Address from the MNP). > So maybe a more concrete definition of Load Sharing is needed. > > > Load-sharing: This is achieved when the traffic load is distributed > > among different connections between the mobile network and the > > Internet. > > YEs, this is possible with the current base spec, I think. > > > As long as the protocol uses all active connections simultaneously, > > Load-sharing will have been deemed achieved. > > What is "simultaneously" more exactly? In the setting I use, both > access systems are up and active simultaneously. If I switch the MR > very quickly between one access system to another then I can give the > impression of simultaneous connections. Would this qualify as > "simultaneous"? The "Simultaneous" term goal mark difference with Fault-Tolerance / Redundancy benefits where just one interface is used at the same time. Take some concrete deployment cases to show this difference and because multihoming in NEMO need several concretes scenarios [1]: o You have three interfaces on a MR in a car: For Egress Interfaces: Type [Max Bandwidth] - One 802.11b Wi-Fi [11Mb/s] - One GPRS [160Kb/s] For Ingress Interface: - One 802.11b Wi-Fi [11Mb/s] And you want to keep the connectivity with Internet with the best interface according to possibilities provided in location where you are, thus rules should be: 1. Choose Wi-fi, if not 2. Choose GPRS, if not 3. Sorry. Thus for keeping connectivity you realize some vertical handover between Wi-Fi and GPRS, and MIP6 being a solution to solve this problem, NEMO have to do nothing more than the Basic Solution to support this case. This case is an illustration of Fault-Tolerance benefit. o Now take a MR inside the bus Tokio - Kyoto: For Egress Interface: - Three GPRS interfaces. [480Kb/s][Together] For Ingress Interface: - One 802.11b Wi-Fi [11Mb/s] Here the main interest is to provide a "correct" connection to all people inside bus all the time, and because of this bus run forward country side, only GPRS is usable during all this trip. Thus you multiply the GPRS connections to provide a better bandwidth. So if you have ten people which use the Internet Connection a the same time, theoretically, each person can get a 6kB/s connection which is not so bad. Here NEMO have to permit several binding for the same prefix to the same CoAs. This part is currently OK. And now because the bus make a long way, it have to change of GPRS provider - for example from NTT East to NTT West - to keep connectivity and thus MR get new CoAs and update its bindings. Here the NEMO Basic solution have to provide a mechanism to identify each CoA - as described in the draft-charbon-multihoming-evaluation-00. This is an example of Load-sharing because you /use/ simultaneously several egress interfaces. o Conclusion: So why there is no formal definition for Load-sharing, because /use/ is not an accurate term. Anyway if I take inspiration from Cisco's definitions [2][3]: Load-sharing: [in NEMO] Load-sharing is concept that allow some Nodes [MNNs, MRs, HAs - depending on the case] to distribute the outgoing and incoming traffic among multiple paths. But I do'nt know if it is much more sharp. And sorry if my remark seems like a teacher ones. :) [1] http://www1.ietf.org/mail-archive/working-groups/nemo/current/msg00154.html [The last comment from Vijay] And you can find more deployment scenarios in: [http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt] [Section 3. Deployment Scenarios] [2] http://www.cisco.com/warp/public/459/40.html#intro [3] http://www.cisco.com/warp/public/105/46.html#intro > And I will not ask what is the "Policy" problem more exactly :-) Yes, you are right, and here I can bring more precisions: o Load-sharing: [None accurate definition] ... and mechanisms which make the distribution need only informations from the network traffic itself. For example: o Per-packet distribution. o Per-connection distribution. o Split TCP and UDP traffic. o Load-balancing based network load statistics. o Policy: [Same as Load-sharing] ... but mechanisms which make the policy distribution need informations which are not provided by the network traffic itself. Thus theses informations have to be transported by NEMO protocol in addition of current protocol information. For example, distribution depending on: o Cost of connection. o Class of user registration. o Age of captain. IMHO it is the main difference between Load-sharing and Policy benefit. > > 2.3 Solution behavior > > > > o Against Load-Sharing: > > > > 1. Doesn't specify the simultaneous use of several bi-directional > > tunnels but doesn't prevent it. > > Ok. > > > 2. Doesn't specify the binding of multiple CoAs against the same MNP > > but doesn't prevent it. > > Ok. > > > 3. Doesn't provides a method to identify each CoA but doesn't > > prevent it: > > Ok. Fine. ;) > > Here an explanation of one of possibility of this management: > > > > As long as there is no specific field for a CoA ID, the solution have > > to use a field present in current Prefix-BU definition. > > Probably yes, in case that explicit, or explicit combined modes are > used. And implicit mode? Well, read far below [A]. But the important point for this mechanism is the association between HoA and Egress-Interface to update the good CoA not association between HoA and MNP in Prefix-BU. > > The only common field is each type of Prefix-BU - Implicit, Explicit > > and Explicit combined - is the Home Address Option in the Destination > > Option Header [Section 6.3 Home Address Option] [13]. > > Yes, exactly, only the Home Address is common. > > > Thus a NEMO implementation can create a Home Address for each egress > > interface. And when a CoA on an egress interface change, use in > > Prefix-BU the corresponding Home Address in the Home Address Option. > > An example to make clear this behavior: > > > > HA Routing Table & Binding Cache before: > > > > +===============+=================+=========================+ > > | Home Address | Care-of Address | MN Prefix/Prefix Length | > > +===============+=================+=========================+ > > | HoA-1 | CoA-1 | MNP-1/Length-1 | > > | HoA-2 | CoA-2 | MNP-1/Length-1 | > > +===============+=================+=========================+ > > I think the base spec tries to say that the prefix is neither in the > RT nor in the BC, but in the Prefix Table. No? Hum, we took this example: ,----[ draft-ietf-nemo-basic-support-00.txt ] | 6.5. Forwarding Packets | | [...] | | 1. The Home Agent maintains a route to the Mobile Network Prefix | with the next hop set to the Mobile Router's Home Address. When | the Home Agent tries to forward the packet to the next hop, it | finds a binding cache entry for the home address. Then the Home | Agent extracts the Mobile Router's Care-of address and tunnels | the packet to the Care-of address. `---- So above it is a logical view, the exploded corresponding view is: Routing Table +=========================+===============+ | MN Prefix/Prefix Length | Next Hop | +=========================+===============+ | MN-Prefix-1/Length-1 | HoA-1 | | MN-Prefix-1/Length-1 | HoA-2 | +=========================+===============+ Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-1 | | HoA-2 | CoA-2 | +===============+=================+ But maybe it's too confuse. I will think about this representation. > > Here HoA-x is the Home Address corresponding to the egress interface > > x on which is assigned CoA-x. Now the HA receives a Prefix-BU > > because CoA-1 has changed to CoA-New. > > > > The Prefix-BU: > > > > > > +===============+=================+=========================+ > > | Home Address | Care-of Address | MN Prefix/Prefix Length | > > +===============+=================+=========================+ > > | HoA-1 | CoA-New | MNP-1/Length-1 | > > +===============+=================+=========================+ > > Yes, if Prefix-BU (explicit or explicit-combined modes). No, if > implicit mode; in implicit mode there is neither prefix nor prefix len > in the BU. Yes, but read below [A] and think about association between HoA and Egress-Interface first. > > And an example of creation of Home Address according to egress > > interface can be: > > > > Egress Interface 1 -> EUI-64-1 -> Home Address for this interface: > > MNP:EUI-64-1 > > > > Egress Interface 2 -> EUI-64-2 -> Home Address for this interface: > > MNP:EUI-64-2 > > Would the scheme work if EUI-64 addresses are not used? For example, > in many configurations manual addresses are assigned to interfaces > (not with EUI-64). Yes, that's why is just an example. :) Anyway from each kind of link which support all features of Ipv6, we can create a EUI-64 [3], and if the administrator of this MR want to support Load-sharing, the fact that he have to configure his MR specially for this benefit is not so strange. It's the same in many Load-sharing configurations [4][5]. If you want automatic or easy-to-install Load-sharing, yes here is a problem but I prefer paid the administrator more [because I'm administrator too ;)]. [3] http://www.zvon.org/tmRFC/RFC3513/Output/chapter6.html [4] http://www.cisco.com/warp/public/459/40.html#2 [5] http://www.cisco.com/warp/public/459/40.html#2a > By your analysis, and for my clarification, is this method somehow > suggesting that the basic solution as is does not support "load > sharing multi-homing" because the Home Address assigned of the egress > interface of the Mobile Router is not derived from MNP? And following > this reasoning, is the proposed method trying to suggest that, for a > basic solution to support multi-homing load sharing, it must > absolutely necessarily have Home Addresses on the egress interface of > the MR derived from the MNP? Nope: ... Home Addresses of the MR derived from Egress-Interface. ^ ^ ^ Read just below [A]. And it's just an example because writing: ,---- | 3. Doesn't provides a method to identify each CoA but doesn't | prevent it: `---- is not enough for a validation. The main goal of this example is to prove this affirmation. But it carry some other problems like: o If you had a interface to your MR, you have to declare an additional HoA to the administrator of the corresponding HA(s). It can be boring. [Thanks to Ryuji for this comment] o Break the assumption "One HoA <-> One Mobile Network with One Mobile Network" which maybe some people have in mind. But I do'nt see all consequences of that. But with the current NEMO Basic Solution, it's the only example that I see. > Should I also deduce that, if implicit mode is used, then there is not > even the smallest chance to have multi-homing load sharing? [A] I'm not agree with this point because in my understanding in each mode - Implicit, Explicit, Explicit combined - the association between HoA and an Egress Interface is keep. Thus the NEMO implementation is always able to found the CoA to update according to a HoA inside a Prefix-BU. Prof by illustration: o Pre-requirement: There is a mechanisms which provide this bijective association: HoA-x <-> Egress-Interface-x For example: [already-know] Egress-Interface-x <-> EUI-64-x <-> Home Address associated: MNP:EUI-64-x Let's start: o Routing Table & Binding cache before: Routing Table +=========================+===============+ | MN Prefix/Prefix Length | Next Hop | +=========================+===============+ | MN-Prefix-1/Length-1 | HoA-1 | | MN-Prefix-1/Length-1 | HoA-2 | +=========================+===============+ Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-1 | | HoA-2 | CoA-2 | +===============+=================+ o Sending Prefix-BU Implicit: The Prefix-BU: +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-New | +===============+=================+ Explicit: +===============+=================+=========================+ | Home Address | Care-of Address | MN Prefix/Prefix Length | +===============+=================+=========================+ | HoA-1 | CoA-New | MNP-1/Length-1 | +===============+=================+=========================+ Explicit combined: +===============+=================+===============+ | Home Address | Care-of Address | Prefix Length | +===============+=================+===============+ | HoA-1 | CoA-New | Length-1 | +===============+=================+===============+ o Binding cache after, in any mode: Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-New | | HoA-2 | CoA-2 | +===============+=================+ Thus the good CoA has been updated because identified by appropriate HoA. > I hope I didn't interpret the analysis wrong. I hope I answer to your question too. > > Maybe the solution should specify this behavior because it is very > > specific to NEMO. > > > > o Against dynamic Load-sharing and Policy: > > > > The solution didn't specify anything about a kind of preference/ > > policy field, but maybe an NEMO implementation can use some part of > > the reserved field in the MNP Option [Section 4.3. Mobile Network > > Prefix Option] [1] or in a sub-option. > > Sometimes I don't think there's need for more bits in the BU to > specify preferences. On another hand, if there is indeed a need for > new bits to specify preferences then I think the same need for > preferences related to a CoA are valid for Mobile Hosts too, not only > Mobile Routers, no? What do you think? Yes, you are right, this proposition is a good one, I will seek for a kind of Policy Information sub-option in MIP6 WG. > > o Multiple CoAs for the same MNP: > > > > The proposed solution doesn't have to specify anything one this > > subject, just to support it. But a paragraph on this purpose can be > > helpful for implementation's developers. > > Yes, maybe somewhere it should say that it is possible to have several > Care-of Addresses for the same MNP. But I think it is easily > understandable that this is possible since the tables pictured in the > draft-charbon clearly show some entries in some tables that associate > same MNP to different CoA's. Yes this part is clear in the draft, It's my fault I would say: o Multiple CoAs for the same MNP & CoA Identification: The CoA Identification is a little bit more difficult to understand, with just the current Basic draft, IMHO. And I want to say that this idea to associate Egress Interface with HoA come firstly from Pascal Thubert. Thus thanks to him for this interesting idea. Thanks you Alexandru for theses constructive comments. Best regards. -- Julien From exim@www1.ietf.org Mon Jul 7 10:06:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25821 for ; Mon, 7 Jul 2003 10:06:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWdJ-0002Rh-7c for nemo-archive@odin.ietf.org; Mon, 07 Jul 2003 10:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67E6Lve009401 for nemo-archive@odin.ietf.org; Mon, 7 Jul 2003 10:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWdJ-0002RY-2Z for nemo-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 10:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25700 for ; Mon, 7 Jul 2003 10:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWdH-0004X1-00 for nemo-web-archive@ietf.org; Mon, 07 Jul 2003 10:06:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZWdG-0004Wx-00 for nemo-web-archive@ietf.org; Mon, 07 Jul 2003 10:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcz-0002Mc-2m; Mon, 07 Jul 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWck-0002KH-DK for nemo@optimus.ietf.org; Mon, 07 Jul 2003 10:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25588 for ; Mon, 7 Jul 2003 10:05:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWci-0004W5-00 for nemo@ietf.org; Mon, 07 Jul 2003 10:05:44 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19ZWcg-0004Vi-00 for nemo@ietf.org; Mon, 07 Jul 2003 10:05:42 -0400 Received: from localhost (unknown [203.178.138.13]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id BC9365D013; Mon, 7 Jul 2003 23:03:59 +0900 (JST) Date: Mon, 7 Jul 2003 23:03:58 +0900 From: Julien Charbon To: nemo@ietf.org Cc: Alexandru Petrescu Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> In-Reply-To: <3F043046.6020401@motorola.com> References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bonjour Alexandru, Hello all, Alexandru Petrescu wrote: > Julien Charbon wrote: > > Hello all, > > > > We have written an Internet-Draft on the evaluation of Multi-homing > > support by NEMO Basic solution. > > Thanks for the draft, useful analysis. Good to see that most > multi-homing aspects can be featured by base spec. Thanks for appreciations, and yes, you work fine to permit the Basic solution to not prevent Multihoming support; pretty good proposition I think. > I have some remarks from the start. The document defines "Policy" and > "Load Sharing" in a very loose way (at least when compared to the > specific specification of e.g. deriving a Home Address from the MNP). > So maybe a more concrete definition of Load Sharing is needed. > > > Load-sharing: This is achieved when the traffic load is distributed > > among different connections between the mobile network and the > > Internet. > > YEs, this is possible with the current base spec, I think. > > > As long as the protocol uses all active connections simultaneously, > > Load-sharing will have been deemed achieved. > > What is "simultaneously" more exactly? In the setting I use, both > access systems are up and active simultaneously. If I switch the MR > very quickly between one access system to another then I can give the > impression of simultaneous connections. Would this qualify as > "simultaneous"? The "Simultaneous" term goal mark difference with Fault-Tolerance / Redundancy benefits where just one interface is used at the same time. Take some concrete deployment cases to show this difference and because multihoming in NEMO need several concretes scenarios [1]: o You have three interfaces on a MR in a car: For Egress Interfaces: Type [Max Bandwidth] - One 802.11b Wi-Fi [11Mb/s] - One GPRS [160Kb/s] For Ingress Interface: - One 802.11b Wi-Fi [11Mb/s] And you want to keep the connectivity with Internet with the best interface according to possibilities provided in location where you are, thus rules should be: 1. Choose Wi-fi, if not 2. Choose GPRS, if not 3. Sorry. Thus for keeping connectivity you realize some vertical handover between Wi-Fi and GPRS, and MIP6 being a solution to solve this problem, NEMO have to do nothing more than the Basic Solution to support this case. This case is an illustration of Fault-Tolerance benefit. o Now take a MR inside the bus Tokio - Kyoto: For Egress Interface: - Three GPRS interfaces. [480Kb/s][Together] For Ingress Interface: - One 802.11b Wi-Fi [11Mb/s] Here the main interest is to provide a "correct" connection to all people inside bus all the time, and because of this bus run forward country side, only GPRS is usable during all this trip. Thus you multiply the GPRS connections to provide a better bandwidth. So if you have ten people which use the Internet Connection a the same time, theoretically, each person can get a 6kB/s connection which is not so bad. Here NEMO have to permit several binding for the same prefix to the same CoAs. This part is currently OK. And now because the bus make a long way, it have to change of GPRS provider - for example from NTT East to NTT West - to keep connectivity and thus MR get new CoAs and update its bindings. Here the NEMO Basic solution have to provide a mechanism to identify each CoA - as described in the draft-charbon-multihoming-evaluation-00. This is an example of Load-sharing because you /use/ simultaneously several egress interfaces. o Conclusion: So why there is no formal definition for Load-sharing, because /use/ is not an accurate term. Anyway if I take inspiration from Cisco's definitions [2][3]: Load-sharing: [in NEMO] Load-sharing is concept that allow some Nodes [MNNs, MRs, HAs - depending on the case] to distribute the outgoing and incoming traffic among multiple paths. But I do'nt know if it is much more sharp. And sorry if my remark seems like a teacher ones. :) [1] http://www1.ietf.org/mail-archive/working-groups/nemo/current/msg00154.html [The last comment from Vijay] And you can find more deployment scenarios in: [http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt] [Section 3. Deployment Scenarios] [2] http://www.cisco.com/warp/public/459/40.html#intro [3] http://www.cisco.com/warp/public/105/46.html#intro > And I will not ask what is the "Policy" problem more exactly :-) Yes, you are right, and here I can bring more precisions: o Load-sharing: [None accurate definition] ... and mechanisms which make the distribution need only informations from the network traffic itself. For example: o Per-packet distribution. o Per-connection distribution. o Split TCP and UDP traffic. o Load-balancing based network load statistics. o Policy: [Same as Load-sharing] ... but mechanisms which make the policy distribution need informations which are not provided by the network traffic itself. Thus theses informations have to be transported by NEMO protocol in addition of current protocol information. For example, distribution depending on: o Cost of connection. o Class of user registration. o Age of captain. IMHO it is the main difference between Load-sharing and Policy benefit. > > 2.3 Solution behavior > > > > o Against Load-Sharing: > > > > 1. Doesn't specify the simultaneous use of several bi-directional > > tunnels but doesn't prevent it. > > Ok. > > > 2. Doesn't specify the binding of multiple CoAs against the same MNP > > but doesn't prevent it. > > Ok. > > > 3. Doesn't provides a method to identify each CoA but doesn't > > prevent it: > > Ok. Fine. ;) > > Here an explanation of one of possibility of this management: > > > > As long as there is no specific field for a CoA ID, the solution have > > to use a field present in current Prefix-BU definition. > > Probably yes, in case that explicit, or explicit combined modes are > used. And implicit mode? Well, read far below [A]. But the important point for this mechanism is the association between HoA and Egress-Interface to update the good CoA not association between HoA and MNP in Prefix-BU. > > The only common field is each type of Prefix-BU - Implicit, Explicit > > and Explicit combined - is the Home Address Option in the Destination > > Option Header [Section 6.3 Home Address Option] [13]. > > Yes, exactly, only the Home Address is common. > > > Thus a NEMO implementation can create a Home Address for each egress > > interface. And when a CoA on an egress interface change, use in > > Prefix-BU the corresponding Home Address in the Home Address Option. > > An example to make clear this behavior: > > > > HA Routing Table & Binding Cache before: > > > > +===============+=================+=========================+ > > | Home Address | Care-of Address | MN Prefix/Prefix Length | > > +===============+=================+=========================+ > > | HoA-1 | CoA-1 | MNP-1/Length-1 | > > | HoA-2 | CoA-2 | MNP-1/Length-1 | > > +===============+=================+=========================+ > > I think the base spec tries to say that the prefix is neither in the > RT nor in the BC, but in the Prefix Table. No? Hum, we took this example: ,----[ draft-ietf-nemo-basic-support-00.txt ] | 6.5. Forwarding Packets | | [...] | | 1. The Home Agent maintains a route to the Mobile Network Prefix | with the next hop set to the Mobile Router's Home Address. When | the Home Agent tries to forward the packet to the next hop, it | finds a binding cache entry for the home address. Then the Home | Agent extracts the Mobile Router's Care-of address and tunnels | the packet to the Care-of address. `---- So above it is a logical view, the exploded corresponding view is: Routing Table +=========================+===============+ | MN Prefix/Prefix Length | Next Hop | +=========================+===============+ | MN-Prefix-1/Length-1 | HoA-1 | | MN-Prefix-1/Length-1 | HoA-2 | +=========================+===============+ Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-1 | | HoA-2 | CoA-2 | +===============+=================+ But maybe it's too confuse. I will think about this representation. > > Here HoA-x is the Home Address corresponding to the egress interface > > x on which is assigned CoA-x. Now the HA receives a Prefix-BU > > because CoA-1 has changed to CoA-New. > > > > The Prefix-BU: > > > > > > +===============+=================+=========================+ > > | Home Address | Care-of Address | MN Prefix/Prefix Length | > > +===============+=================+=========================+ > > | HoA-1 | CoA-New | MNP-1/Length-1 | > > +===============+=================+=========================+ > > Yes, if Prefix-BU (explicit or explicit-combined modes). No, if > implicit mode; in implicit mode there is neither prefix nor prefix len > in the BU. Yes, but read below [A] and think about association between HoA and Egress-Interface first. > > And an example of creation of Home Address according to egress > > interface can be: > > > > Egress Interface 1 -> EUI-64-1 -> Home Address for this interface: > > MNP:EUI-64-1 > > > > Egress Interface 2 -> EUI-64-2 -> Home Address for this interface: > > MNP:EUI-64-2 > > Would the scheme work if EUI-64 addresses are not used? For example, > in many configurations manual addresses are assigned to interfaces > (not with EUI-64). Yes, that's why is just an example. :) Anyway from each kind of link which support all features of Ipv6, we can create a EUI-64 [3], and if the administrator of this MR want to support Load-sharing, the fact that he have to configure his MR specially for this benefit is not so strange. It's the same in many Load-sharing configurations [4][5]. If you want automatic or easy-to-install Load-sharing, yes here is a problem but I prefer paid the administrator more [because I'm administrator too ;)]. [3] http://www.zvon.org/tmRFC/RFC3513/Output/chapter6.html [4] http://www.cisco.com/warp/public/459/40.html#2 [5] http://www.cisco.com/warp/public/459/40.html#2a > By your analysis, and for my clarification, is this method somehow > suggesting that the basic solution as is does not support "load > sharing multi-homing" because the Home Address assigned of the egress > interface of the Mobile Router is not derived from MNP? And following > this reasoning, is the proposed method trying to suggest that, for a > basic solution to support multi-homing load sharing, it must > absolutely necessarily have Home Addresses on the egress interface of > the MR derived from the MNP? Nope: ... Home Addresses of the MR derived from Egress-Interface. ^ ^ ^ Read just below [A]. And it's just an example because writing: ,---- | 3. Doesn't provides a method to identify each CoA but doesn't | prevent it: `---- is not enough for a validation. The main goal of this example is to prove this affirmation. But it carry some other problems like: o If you had a interface to your MR, you have to declare an additional HoA to the administrator of the corresponding HA(s). It can be boring. [Thanks to Ryuji for this comment] o Break the assumption "One HoA <-> One Mobile Network with One Mobile Network" which maybe some people have in mind. But I do'nt see all consequences of that. But with the current NEMO Basic Solution, it's the only example that I see. > Should I also deduce that, if implicit mode is used, then there is not > even the smallest chance to have multi-homing load sharing? [A] I'm not agree with this point because in my understanding in each mode - Implicit, Explicit, Explicit combined - the association between HoA and an Egress Interface is keep. Thus the NEMO implementation is always able to found the CoA to update according to a HoA inside a Prefix-BU. Prof by illustration: o Pre-requirement: There is a mechanisms which provide this bijective association: HoA-x <-> Egress-Interface-x For example: [already-know] Egress-Interface-x <-> EUI-64-x <-> Home Address associated: MNP:EUI-64-x Let's start: o Routing Table & Binding cache before: Routing Table +=========================+===============+ | MN Prefix/Prefix Length | Next Hop | +=========================+===============+ | MN-Prefix-1/Length-1 | HoA-1 | | MN-Prefix-1/Length-1 | HoA-2 | +=========================+===============+ Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-1 | | HoA-2 | CoA-2 | +===============+=================+ o Sending Prefix-BU Implicit: The Prefix-BU: +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-New | +===============+=================+ Explicit: +===============+=================+=========================+ | Home Address | Care-of Address | MN Prefix/Prefix Length | +===============+=================+=========================+ | HoA-1 | CoA-New | MNP-1/Length-1 | +===============+=================+=========================+ Explicit combined: +===============+=================+===============+ | Home Address | Care-of Address | Prefix Length | +===============+=================+===============+ | HoA-1 | CoA-New | Length-1 | +===============+=================+===============+ o Binding cache after, in any mode: Binding Cache +===============+=================+ | Home Address | Care-of Address | +===============+=================+ | HoA-1 | CoA-New | | HoA-2 | CoA-2 | +===============+=================+ Thus the good CoA has been updated because identified by appropriate HoA. > I hope I didn't interpret the analysis wrong. I hope I answer to your question too. > > Maybe the solution should specify this behavior because it is very > > specific to NEMO. > > > > o Against dynamic Load-sharing and Policy: > > > > The solution didn't specify anything about a kind of preference/ > > policy field, but maybe an NEMO implementation can use some part of > > the reserved field in the MNP Option [Section 4.3. Mobile Network > > Prefix Option] [1] or in a sub-option. > > Sometimes I don't think there's need for more bits in the BU to > specify preferences. On another hand, if there is indeed a need for > new bits to specify preferences then I think the same need for > preferences related to a CoA are valid for Mobile Hosts too, not only > Mobile Routers, no? What do you think? Yes, you are right, this proposition is a good one, I will seek for a kind of Policy Information sub-option in MIP6 WG. > > o Multiple CoAs for the same MNP: > > > > The proposed solution doesn't have to specify anything one this > > subject, just to support it. But a paragraph on this purpose can be > > helpful for implementation's developers. > > Yes, maybe somewhere it should say that it is possible to have several > Care-of Addresses for the same MNP. But I think it is easily > understandable that this is possible since the tables pictured in the > draft-charbon clearly show some entries in some tables that associate > same MNP to different CoA's. Yes this part is clear in the draft, It's my fault I would say: o Multiple CoAs for the same MNP & CoA Identification: The CoA Identification is a little bit more difficult to understand, with just the current Basic draft, IMHO. And I want to say that this idea to associate Egress Interface with HoA come firstly from Pascal Thubert. Thus thanks to him for this interesting idea. Thanks you Alexandru for theses constructive comments. Best regards. -- Julien From nemo-admin@ietf.org Mon Jul 7 16:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14300 for ; Mon, 7 Jul 2003 16:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcoE-0003te-20; Mon, 07 Jul 2003 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zco7-0003rz-6h for nemo@optimus.ietf.org; Mon, 07 Jul 2003 16:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14264 for ; Mon, 7 Jul 2003 16:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zco5-0002Sf-00 for nemo@ietf.org; Mon, 07 Jul 2003 16:41:53 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Zco4-0002SU-00 for nemo@ietf.org; Mon, 07 Jul 2003 16:41:52 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25613 for ; Mon, 7 Jul 2003 13:41:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h67KfKq14755 for ; Mon, 7 Jul 2003 13:41:20 -0700 X-mProtect: <200307072041> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdL1CFgV; Mon, 07 Jul 2003 13:41:18 PDT Message-ID: <3F09DAEE.9C0B56E8@kniveton.com> Date: Mon, 07 Jul 2003 13:41:18 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IPR update on base draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There were some questions about the Nokia IPR in the basic NEMO support draft, so as I mentioned, I spoke with our patent attorneys. They have submitted to the IETF licensing terms that grant free license for open source implementations. Here is a link to the statement: http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt FYI, Cisco has also submitted an IPR statement on this draft, which can be found here: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From exim@www1.ietf.org Mon Jul 7 16:42:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14330 for ; Mon, 7 Jul 2003 16:42:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcoI-0003yB-OB for nemo-archive@odin.ietf.org; Mon, 07 Jul 2003 16:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Kg68b015253 for nemo-archive@odin.ietf.org; Mon, 7 Jul 2003 16:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcoI-0003xw-Ig for nemo-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 16:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14279 for ; Mon, 7 Jul 2003 16:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcoG-0002T4-00 for nemo-web-archive@ietf.org; Mon, 07 Jul 2003 16:42:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZcoG-0002T1-00 for nemo-web-archive@ietf.org; Mon, 07 Jul 2003 16:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcoE-0003te-20; Mon, 07 Jul 2003 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zco7-0003rz-6h for nemo@optimus.ietf.org; Mon, 07 Jul 2003 16:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14264 for ; Mon, 7 Jul 2003 16:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zco5-0002Sf-00 for nemo@ietf.org; Mon, 07 Jul 2003 16:41:53 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19Zco4-0002SU-00 for nemo@ietf.org; Mon, 07 Jul 2003 16:41:52 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25613 for ; Mon, 7 Jul 2003 13:41:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h67KfKq14755 for ; Mon, 7 Jul 2003 13:41:20 -0700 X-mProtect: <200307072041> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdL1CFgV; Mon, 07 Jul 2003 13:41:18 PDT Message-ID: <3F09DAEE.9C0B56E8@kniveton.com> Date: Mon, 07 Jul 2003 13:41:18 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IPR update on base draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There were some questions about the Nokia IPR in the basic NEMO support draft, so as I mentioned, I spoke with our patent attorneys. They have submitted to the IETF licensing terms that grant free license for open source implementations. Here is a link to the statement: http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt FYI, Cisco has also submitted an IPR statement on this draft, which can be found here: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From nemo-admin@ietf.org Tue Jul 8 05:05:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15114 for ; Tue, 8 Jul 2003 05:05:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoPF-0006I0-Rf; Tue, 08 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoOy-0006Gg-9v for nemo@optimus.ietf.org; Tue, 08 Jul 2003 05:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15082 for ; Tue, 8 Jul 2003 05:04:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoOv-00000z-00 for nemo@ietf.org; Tue, 08 Jul 2003 05:04:41 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZoOu-00000u-00 for nemo@ietf.org; Tue, 08 Jul 2003 05:04:40 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KY0Z0HGCVK9BARTB@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 8 Jul 2003 19:03:41 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2962812C009; Tue, 08 Jul 2003 19:03:41 +1000 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 1378A12C008; Tue, 08 Jul 2003 19:03:41 +1000 (EST) Date: Tue, 08 Jul 2003 19:03:41 +1000 From: Gregory Daley Subject: Re: [nemo] IPR update on base draft To: "T.J. Kniveton" Cc: nemo@ietf.org Message-id: <2d7d00e2d82bd9.2d82bd92d7d00e@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi TJ, ----- Original Message ----- From: "T.J. Kniveton" Date: Tuesday, July 8, 2003 6:41 am Subject: [nemo] IPR update on base draft > There were some questions about the Nokia IPR in the basic NEMO > support draft, > so as I mentioned, I spoke with our patent attorneys. They have > submitted to > the IETF licensing terms that grant free license for open source > implementations. Here is a link to the statement: > > http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic- > support.txt At the risk of looking like an open-source weenie, I'd like to thank (yourself and) Nokia of for clarifying the position of NEMO with respect to the GPL (which I know causes difficulties). > FYI, Cisco has also submitted an IPR statement on this draft, which > can be > found here: > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic- > support.txt I'm less happy with Cisco's statement since it still precludes development and distribution of Linux (Kernel-based) implementations. Greg From exim@www1.ietf.org Tue Jul 8 05:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15129 for ; Tue, 8 Jul 2003 05:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoPN-0006Is-NY for nemo-archive@odin.ietf.org; Tue, 08 Jul 2003 05:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68959XI024229 for nemo-archive@odin.ietf.org; Tue, 8 Jul 2003 05:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoPN-0006Ii-Io for nemo-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 05:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15104 for ; Tue, 8 Jul 2003 05:05:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoPK-00001R-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 05:05:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZoPK-00001O-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 05:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoPF-0006I0-Rf; Tue, 08 Jul 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoOy-0006Gg-9v for nemo@optimus.ietf.org; Tue, 08 Jul 2003 05:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15082 for ; Tue, 8 Jul 2003 05:04:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoOv-00000z-00 for nemo@ietf.org; Tue, 08 Jul 2003 05:04:41 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZoOu-00000u-00 for nemo@ietf.org; Tue, 08 Jul 2003 05:04:40 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KY0Z0HGCVK9BARTB@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 8 Jul 2003 19:03:41 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2962812C009; Tue, 08 Jul 2003 19:03:41 +1000 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 1378A12C008; Tue, 08 Jul 2003 19:03:41 +1000 (EST) Date: Tue, 08 Jul 2003 19:03:41 +1000 From: Gregory Daley Subject: Re: [nemo] IPR update on base draft To: "T.J. Kniveton" Cc: nemo@ietf.org Message-id: <2d7d00e2d82bd9.2d82bd92d7d00e@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi TJ, ----- Original Message ----- From: "T.J. Kniveton" Date: Tuesday, July 8, 2003 6:41 am Subject: [nemo] IPR update on base draft > There were some questions about the Nokia IPR in the basic NEMO > support draft, > so as I mentioned, I spoke with our patent attorneys. They have > submitted to > the IETF licensing terms that grant free license for open source > implementations. Here is a link to the statement: > > http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic- > support.txt At the risk of looking like an open-source weenie, I'd like to thank (yourself and) Nokia of for clarifying the position of NEMO with respect to the GPL (which I know causes difficulties). > FYI, Cisco has also submitted an IPR statement on this draft, which > can be > found here: > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic- > support.txt I'm less happy with Cisco's statement since it still precludes development and distribution of Linux (Kernel-based) implementations. Greg From nemo-admin@ietf.org Tue Jul 8 23:25:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20303 for ; Tue, 8 Jul 2003 23:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zl-0005uR-G0; Tue, 08 Jul 2003 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Yw-0005tQ-MD for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20265 for ; Tue, 8 Jul 2003 23:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yu-00037p-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:08 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yt-00037X-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:07 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id EB7CC5D0F0 for ; Wed, 9 Jul 2003 12:23:35 +0900 (JST) Date: Wed, 9 Jul 2003 00:37:00 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) Message-Id: <20030709003700.6c4fd86f.ernst@sfc.wide.ad.jp> In-Reply-To: <3EFBC4D5.2090703@eng.monash.edu.au> References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> <3EFBC4D5.2090703@eng.monash.edu.au> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, About multicast, see below my personal opinion. It may diverge from Vijay. > >>Do you think that we need to handle multicast > >>issues for hosts on the NEMO in the base draft? > > > > > > I dont think so. I think more work needs to be done > > on this and is best handled through a separate > > specification. > > Good. That's what I was checking. To be more precise: a separate specification, but under NEMO Basic Support. Back to requirement R17, we must make sure multicast is functioning for NEMO Basic, which means, in principle, multicast signaling would be able to fly across the bi-directional tunnel MR <-> HA. > >>and then see if we need a document > >>on multicast routing or multicast-ro. > >> > >>Maybe we just need to add a line regarding multicast > >>routing protocols on the MR to section 8? > > > > > > for this you would need both the Home Agent and the > > Mobile Router to run a multicast routing protocol. I > > am not sure if we should talk about it in the basic > > support draft.... > > OK. We'll let people read between the lines when it > says "dynamic routing protocol". One of the reason I was supporting "dynamic routing protocol" for basic was precisely to allow multicast signaling. But, of course, now we need to examine if NEMO Basic Support as is prevents or not the proper operation of multicast. > I've been having a think about this issue too, and > may get a short draft out after the meeting. An analysis of the issues NEMO Basic Support may cause to multicast is more than welcome. The soonest the better, because we might be able to fix draft NEMO basic support based on this analysis before it is in IESG hands. Thierry From exim@www1.ietf.org Tue Jul 8 23:25:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20331 for ; Tue, 8 Jul 2003 23:25:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zz-0005w4-PN for nemo-archive@odin.ietf.org; Tue, 08 Jul 2003 23:25:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h693PFLV022810 for nemo-archive@odin.ietf.org; Tue, 8 Jul 2003 23:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zz-0005vp-J5 for nemo-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 23:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20290 for ; Tue, 8 Jul 2003 23:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Zx-000385-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:25:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a5Zx-00037z-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zl-0005uH-1B; Tue, 08 Jul 2003 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Yw-0005tL-JN for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20264 for ; Tue, 8 Jul 2003 23:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yu-00037s-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:08 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yt-00037W-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:07 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 9D7B35D098 for ; Wed, 9 Jul 2003 12:23:35 +0900 (JST) Date: Wed, 9 Jul 2003 00:21:29 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-Id: <20030709002129.205b4e2b.ernst@sfc.wide.ad.jp> In-Reply-To: <20030624130406.A8802@mmlab.snu.ac.kr> References: <20030624130406.A8802@mmlab.snu.ac.kr> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Another way to do it is for the MR to simply response with an ICMP > > re-direct message when it looses its egress link. > > > > The first way, the lost of egress link is transparent to MNNs. The > > second way, the MR inform MNNs that it has lost a route, and force MNNs > > to re-direct their packets to other MRs. > > The first way is included in what I called "communication between MRs". > They listen each other MR's RA and set up tunnel. > (If you think the term "communication" is not appropriate for this, i.e. just exchange > signaling for tunnel set-up, we may paraphrase it.) > > The second way does not seem to provide mobility transparency to MNNs. > So, it is not recommandable, IMHO. Hi, I'm a few weeks behind, processing my NEMO emails. Response to Eun Kyoung's email dated June 24th: Well, egress interface selection has nothing to do with mobility management, thus nor eitheir with network mobility transparency. But, of course, it would be desirable to achieve multihoming for MNNs without requiring changes to their protocol stack. Thierry. From nemo-admin@ietf.org Tue Jul 8 23:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20709 for ; Tue, 8 Jul 2003 23:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t7-0007oU-He; Tue, 08 Jul 2003 23:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t1-0007oD-BM for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20649 for ; Tue, 8 Jul 2003 23:44:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5sz-0003Dg-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:44:53 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5sy-0003DX-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:44:52 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id E9B495D098 for ; Wed, 9 Jul 2003 12:44:22 +0900 (JST) Date: Wed, 9 Jul 2003 12:42:08 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? Message-Id: <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> In-Reply-To: <001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> References: <3EFFE02B.2020401@eng.monash.edu.au> <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> <20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp> <001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Souhwan, > > > We have been working on the threat analysis for NEMO, and we submitted a draft. > > > You can find my draft on the following location. > > > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt > > > > > > Our approach is to build a generic threat model and to consider all possible threats from the scratch, which means that the threats are based on the assumption that no security mechanisms are available for NEMO yet. This may not be true with the new draft of NEMO basic protocol. > > > In fact, our work was done before the new draft is announced. > > > > > > Anyway, we keep working on updating our draft while analyzing the feasibility of those threats assuming the security mechanisms available in the draft of basic NEMO protocol. > > > > > > Any comments to our draft will be helpful for us to update the draft. Very interesting document, I was waiting for a contribution on this subject for a long time. This is a good starting document. I find your model very useful to list security threats. Probably there will be more to add. For instance, is there anything to case about in the nested case ? May I ask you if you already had time to analyse the specific security threats faced by the implementation of draft-ietf-nemo-basic as it is written today ? Is this in your plans to add this in your draft ? What about draft-ietf-nemo-basic 's ability to prevent such threats ? For instance, in section 3.1, when you speak about man-in-the-middle. I doubt the BU message defined in draft-ietf-nemo-basic can be compromised since the MR is authenticated by the HA (but, sure, without the authentication, the threat would arise). On the other hand, some threats may not be prevented by the current draft-ietf-nemo-basic draft, so it would need fixes. qWhat about the authorization to perform the operation (e.g. sending a BU for a prefix of a specified lenght) ? In summary, I can see your draft a 1st step of a 3-step complete analysis: - what are the potential threats - where NEMO basic support fails to prevent such threats - how to fix NEMO basic support Misc comments and questions about your draft: - FA: you meant to say AR. Note that AR doesn't assign CoA for MRs. 3.1: - interrupted: intercepted 3.2 - In this section, I think you don't explain enough what security mechanisms are needed to prevent what specific threat. - Also, I think you go further than where we NEMO is expected to go for basic, particularly when you mention the HA-CN portion of the path. 4. - MR is part of the mobile network, as MNN. - what's the difference between FN and MNN ? - FA: AR ? - MR-A: this terminology is peculiar to draft-wakikawa-nemo-basic - how a MR can be compromised ? 5. - I think you can dropp that section ... Thanks for the draft, Thierry From exim@www1.ietf.org Tue Jul 8 23:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20724 for ; Tue, 8 Jul 2003 23:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t9-0007pP-9V for nemo-archive@odin.ietf.org; Tue, 08 Jul 2003 23:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h693j3aJ030087 for nemo-archive@odin.ietf.org; Tue, 8 Jul 2003 23:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t9-0007pC-5S for nemo-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 23:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20653 for ; Tue, 8 Jul 2003 23:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5t7-0003Dm-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a5t6-0003Dj-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:45:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t7-0007oU-He; Tue, 08 Jul 2003 23:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5t1-0007oD-BM for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20649 for ; Tue, 8 Jul 2003 23:44:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5sz-0003Dg-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:44:53 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5sy-0003DX-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:44:52 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id E9B495D098 for ; Wed, 9 Jul 2003 12:44:22 +0900 (JST) Date: Wed, 9 Jul 2003 12:42:08 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? Message-Id: <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> In-Reply-To: <001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> References: <3EFFE02B.2020401@eng.monash.edu.au> <000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ> <20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp> <001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Souhwan, > > > We have been working on the threat analysis for NEMO, and we submitted a draft. > > > You can find my draft on the following location. > > > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt > > > > > > Our approach is to build a generic threat model and to consider all possible threats from the scratch, which means that the threats are based on the assumption that no security mechanisms are available for NEMO yet. This may not be true with the new draft of NEMO basic protocol. > > > In fact, our work was done before the new draft is announced. > > > > > > Anyway, we keep working on updating our draft while analyzing the feasibility of those threats assuming the security mechanisms available in the draft of basic NEMO protocol. > > > > > > Any comments to our draft will be helpful for us to update the draft. Very interesting document, I was waiting for a contribution on this subject for a long time. This is a good starting document. I find your model very useful to list security threats. Probably there will be more to add. For instance, is there anything to case about in the nested case ? May I ask you if you already had time to analyse the specific security threats faced by the implementation of draft-ietf-nemo-basic as it is written today ? Is this in your plans to add this in your draft ? What about draft-ietf-nemo-basic 's ability to prevent such threats ? For instance, in section 3.1, when you speak about man-in-the-middle. I doubt the BU message defined in draft-ietf-nemo-basic can be compromised since the MR is authenticated by the HA (but, sure, without the authentication, the threat would arise). On the other hand, some threats may not be prevented by the current draft-ietf-nemo-basic draft, so it would need fixes. qWhat about the authorization to perform the operation (e.g. sending a BU for a prefix of a specified lenght) ? In summary, I can see your draft a 1st step of a 3-step complete analysis: - what are the potential threats - where NEMO basic support fails to prevent such threats - how to fix NEMO basic support Misc comments and questions about your draft: - FA: you meant to say AR. Note that AR doesn't assign CoA for MRs. 3.1: - interrupted: intercepted 3.2 - In this section, I think you don't explain enough what security mechanisms are needed to prevent what specific threat. - Also, I think you go further than where we NEMO is expected to go for basic, particularly when you mention the HA-CN portion of the path. 4. - MR is part of the mobile network, as MNN. - what's the difference between FN and MNN ? - FA: AR ? - MR-A: this terminology is peculiar to draft-wakikawa-nemo-basic - how a MR can be compromised ? 5. - I think you can dropp that section ... Thanks for the draft, Thierry From nemo-admin@ietf.org Wed Jul 9 00:10:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20302 for ; Tue, 8 Jul 2003 23:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zl-0005uH-1B; Tue, 08 Jul 2003 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Yw-0005tL-JN for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20264 for ; Tue, 8 Jul 2003 23:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yu-00037s-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:08 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yt-00037W-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:07 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 9D7B35D098 for ; Wed, 9 Jul 2003 12:23:35 +0900 (JST) Date: Wed, 9 Jul 2003 00:21:29 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] draft-ng-nemo-multihoming-issues-01.txt Message-Id: <20030709002129.205b4e2b.ernst@sfc.wide.ad.jp> In-Reply-To: <20030624130406.A8802@mmlab.snu.ac.kr> References: <20030624130406.A8802@mmlab.snu.ac.kr> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Another way to do it is for the MR to simply response with an ICMP > > re-direct message when it looses its egress link. > > > > The first way, the lost of egress link is transparent to MNNs. The > > second way, the MR inform MNNs that it has lost a route, and force MNNs > > to re-direct their packets to other MRs. > > The first way is included in what I called "communication between MRs". > They listen each other MR's RA and set up tunnel. > (If you think the term "communication" is not appropriate for this, i.e. just exchange > signaling for tunnel set-up, we may paraphrase it.) > > The second way does not seem to provide mobility transparency to MNNs. > So, it is not recommandable, IMHO. Hi, I'm a few weeks behind, processing my NEMO emails. Response to Eun Kyoung's email dated June 24th: Well, egress interface selection has nothing to do with mobility management, thus nor eitheir with network mobility transparency. But, of course, it would be desirable to achieve multihoming for MNNs without requiring changes to their protocol stack. Thierry. From exim@www1.ietf.org Wed Jul 9 00:10:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20333 for ; Tue, 8 Jul 2003 23:25:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5a0-0005wK-1t for nemo-archive@odin.ietf.org; Tue, 08 Jul 2003 23:25:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h693PG98022826 for nemo-archive@odin.ietf.org; Tue, 8 Jul 2003 23:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zz-0005w5-Uh for nemo-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 23:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20293 for ; Tue, 8 Jul 2003 23:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Zy-000388-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:25:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a5Zx-000380-00 for nemo-web-archive@ietf.org; Tue, 08 Jul 2003 23:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Zl-0005uR-G0; Tue, 08 Jul 2003 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5Yw-0005tQ-MD for nemo@optimus.ietf.org; Tue, 08 Jul 2003 23:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20265 for ; Tue, 8 Jul 2003 23:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yu-00037p-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:08 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19a5Yt-00037X-00 for nemo@ietf.org; Tue, 08 Jul 2003 23:24:07 -0400 Received: from localhost.nautilus6.org (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id EB7CC5D0F0 for ; Wed, 9 Jul 2003 12:23:35 +0900 (JST) Date: Wed, 9 Jul 2003 00:37:00 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) Message-Id: <20030709003700.6c4fd86f.ernst@sfc.wide.ad.jp> In-Reply-To: <3EFBC4D5.2090703@eng.monash.edu.au> References: <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> <3EFBC4D5.2090703@eng.monash.edu.au> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, About multicast, see below my personal opinion. It may diverge from Vijay. > >>Do you think that we need to handle multicast > >>issues for hosts on the NEMO in the base draft? > > > > > > I dont think so. I think more work needs to be done > > on this and is best handled through a separate > > specification. > > Good. That's what I was checking. To be more precise: a separate specification, but under NEMO Basic Support. Back to requirement R17, we must make sure multicast is functioning for NEMO Basic, which means, in principle, multicast signaling would be able to fly across the bi-directional tunnel MR <-> HA. > >>and then see if we need a document > >>on multicast routing or multicast-ro. > >> > >>Maybe we just need to add a line regarding multicast > >>routing protocols on the MR to section 8? > > > > > > for this you would need both the Home Agent and the > > Mobile Router to run a multicast routing protocol. I > > am not sure if we should talk about it in the basic > > support draft.... > > OK. We'll let people read between the lines when it > says "dynamic routing protocol". One of the reason I was supporting "dynamic routing protocol" for basic was precisely to allow multicast signaling. But, of course, now we need to examine if NEMO Basic Support as is prevents or not the proper operation of multicast. > I've been having a think about this issue too, and > may get a short draft out after the meeting. An analysis of the issues NEMO Basic Support may cause to multicast is more than welcome. The soonest the better, because we might be able to fix draft NEMO basic support based on this analysis before it is in IESG hands. Thierry From nemo-admin@ietf.org Wed Jul 9 11:14:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04762 for ; Wed, 9 Jul 2003 11:14:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd1-0000z0-Fg; Wed, 09 Jul 2003 11:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aDxO-0002dt-24 for nemo@optimus.ietf.org; Wed, 09 Jul 2003 08:21:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28684 for ; Wed, 9 Jul 2003 08:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aDxM-0006JO-00 for nemo@ietf.org; Wed, 09 Jul 2003 08:21:56 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19aDxM-0006JL-00 for nemo@ietf.org; Wed, 09 Jul 2003 08:21:56 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8C58A6BA76 for ; Wed, 9 Jul 2003 08:21:24 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h69CLJWD014927; Wed, 9 Jul 2003 08:21:19 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h69CLHYM000779; Wed, 9 Jul 2003 08:21:18 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030709081552.01f26830@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 09 Jul 2003 08:20:47 -0400 To: Thierry Ernst From: William D Ivancic Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) Cc: nemo@ietf.org In-Reply-To: <20030709003700.6c4fd86f.ernst@sfc.wide.ad.jp> References: <3EFBC4D5.2090703@eng.monash.edu.au> <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> <3EFBC4D5.2090703@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , We have run multicast over bidirectional tunnels using IPv4. I suspect (but cannot yet confirm) that multicast would operate similarly over IPv6 bidirectional tunnels. Also, the HA makes an excellent rendezvous point - ideal for multicasting. Sorry, but I don't think we have written anything up yet on this. Will > > > OK. We'll let people read been the lines when it > > says "dynamic routing protocol". > >One of the reason I was supporting "dynamic routing protocol" for basic >was precisely to allow multicast signaling. But, of course, now we need >to examine if NEMO Basic Support as is prevents or not the proper >operation of multicast. > > >Thierry From exim@www1.ietf.org Wed Jul 9 11:14:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04898 for ; Wed, 9 Jul 2003 11:14:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdZ-0001ZG-Dc for nemo-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDfER006020 for nemo-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdW-0001Wx-Uv for nemo-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04321 for ; Wed, 9 Jul 2003 11:13:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aGdV-0007Jd-00 for nemo-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aGdV-0007J2-00 for nemo-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd1-0000z0-Fg; Wed, 09 Jul 2003 11:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aDxO-0002dt-24 for nemo@optimus.ietf.org; Wed, 09 Jul 2003 08:21:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28684 for ; Wed, 9 Jul 2003 08:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aDxM-0006JO-00 for nemo@ietf.org; Wed, 09 Jul 2003 08:21:56 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19aDxM-0006JL-00 for nemo@ietf.org; Wed, 09 Jul 2003 08:21:56 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8C58A6BA76 for ; Wed, 9 Jul 2003 08:21:24 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h69CLJWD014927; Wed, 9 Jul 2003 08:21:19 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp136.grc.nasa.gov [139.88.245.136]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h69CLHYM000779; Wed, 9 Jul 2003 08:21:18 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030709081552.01f26830@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 09 Jul 2003 08:20:47 -0400 To: Thierry Ernst From: William D Ivancic Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) Cc: nemo@ietf.org In-Reply-To: <20030709003700.6c4fd86f.ernst@sfc.wide.ad.jp> References: <3EFBC4D5.2090703@eng.monash.edu.au> <3EFB6968.C3D4CD4F@iprg.nokia.com> <3EFB8341.60904@eng.monash.edu.au> <3EFB9523.7FEDB155@iprg.nokia.com> <3EFBC4D5.2090703@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , We have run multicast over bidirectional tunnels using IPv4. I suspect (but cannot yet confirm) that multicast would operate similarly over IPv6 bidirectional tunnels. Also, the HA makes an excellent rendezvous point - ideal for multicasting. Sorry, but I don't think we have written anything up yet on this. Will > > > OK. We'll let people read been the lines when it > > says "dynamic routing protocol". > >One of the reason I was supporting "dynamic routing protocol" for basic >was precisely to allow multicast signaling. But, of course, now we need >to examine if NEMO Basic Support as is prevents or not the proper >operation of multicast. > > >Thierry From nemo-admin@ietf.org Wed Jul 9 12:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08004 for ; Wed, 9 Jul 2003 12:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY2-00011L-BP; Wed, 09 Jul 2003 12:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHXs-00010N-K9 for nemo@optimus.ietf.org; Wed, 09 Jul 2003 12:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07982 for ; Wed, 9 Jul 2003 12:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHXr-0000ED-00 for nemo@ietf.org; Wed, 09 Jul 2003 12:11:51 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19aHXq-0000E9-00 for nemo@ietf.org; Wed, 09 Jul 2003 12:11:50 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KY2S9AVY5O9C5ZSH@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 10 Jul 2003 02:11:33 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5FB9112C005; Thu, 10 Jul 2003 02:11:33 +1000 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 4673012C004; Thu, 10 Jul 2003 02:11:33 +1000 (EST) Date: Thu, 10 Jul 2003 02:11:33 +1000 From: Gregory Daley Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: William D Ivancic Cc: Thierry Ernst , nemo@ietf.org Message-id: <2e2a4b02e2bd18.2e2bd182e2a4b0@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Will, It's nice to know that things work as they should. I'm also pretty sure IPv6 will work as well. Greg ----- Original Message ----- From: William D Ivancic Date: Wednesday, July 9, 2003 10:20 pm Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) > We have run multicast over bidirectional tunnels using IPv4. I > suspect > (but cannot yet confirm) that multicast would operate similarly > over IPv6 > bidirectional tunnels. Also, the HA makes an excellent > rendezvous point > - ideal for multicasting. Sorry, but I don't think we have > written > anything up yet on this. > > Will > > > > > > OK. We'll let people read been the lines when it > > > says "dynamic routing protocol". > > > >One of the reason I was supporting "dynamic routing protocol" for > basic>was precisely to allow multicast signaling. But, of course, > now we need > >to examine if NEMO Basic Support as is prevents or not the proper > >operation of multicast. > > > > > >Thierry > > > From exim@www1.ietf.org Wed Jul 9 12:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08019 for ; Wed, 9 Jul 2003 12:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY3-00012T-J4 for nemo-archive@odin.ietf.org; Wed, 09 Jul 2003 12:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69GC3j6003989 for nemo-archive@odin.ietf.org; Wed, 9 Jul 2003 12:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY3-00012G-FY for nemo-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 12:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07991 for ; Wed, 9 Jul 2003 12:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHY2-0000EW-00 for nemo-web-archive@ietf.org; Wed, 09 Jul 2003 12:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aHY1-0000ET-00 for nemo-web-archive@ietf.org; Wed, 09 Jul 2003 12:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY2-00011L-BP; Wed, 09 Jul 2003 12:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHXs-00010N-K9 for nemo@optimus.ietf.org; Wed, 09 Jul 2003 12:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07982 for ; Wed, 9 Jul 2003 12:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHXr-0000ED-00 for nemo@ietf.org; Wed, 09 Jul 2003 12:11:51 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 19aHXq-0000E9-00 for nemo@ietf.org; Wed, 09 Jul 2003 12:11:50 -0400 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KY2S9AVY5O9C5ZSH@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 10 Jul 2003 02:11:33 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5FB9112C005; Thu, 10 Jul 2003 02:11:33 +1000 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 4673012C004; Thu, 10 Jul 2003 02:11:33 +1000 (EST) Date: Thu, 10 Jul 2003 02:11:33 +1000 From: Gregory Daley Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) To: William D Ivancic Cc: Thierry Ernst , nemo@ietf.org Message-id: <2e2a4b02e2bd18.2e2bd182e2a4b0@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Will, It's nice to know that things work as they should. I'm also pretty sure IPv6 will work as well. Greg ----- Original Message ----- From: William D Ivancic Date: Wednesday, July 9, 2003 10:20 pm Subject: Re: Need for text on issue 4? (Re: [nemo] Basic Support Issue List) > We have run multicast over bidirectional tunnels using IPv4. I > suspect > (but cannot yet confirm) that multicast would operate similarly > over IPv6 > bidirectional tunnels. Also, the HA makes an excellent > rendezvous point > - ideal for multicasting. Sorry, but I don't think we have > written > anything up yet on this. > > Will > > > > > > OK. We'll let people read been the lines when it > > > says "dynamic routing protocol". > > > >One of the reason I was supporting "dynamic routing protocol" for > basic>was precisely to allow multicast signaling. But, of course, > now we need > >to examine if NEMO Basic Support as is prevents or not the proper > >operation of multicast. > > > > > >Thierry > > > From nemo-admin@ietf.org Thu Jul 10 03:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20878 for ; Thu, 10 Jul 2003 03:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjj-0006CJ-1r; Thu, 10 Jul 2003 03:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjW-0006Bt-9o for nemo@optimus.ietf.org; Thu, 10 Jul 2003 03:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20844 for ; Thu, 10 Jul 2003 03:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVjU-00007x-00 for nemo@ietf.org; Thu, 10 Jul 2003 03:20:48 -0400 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19aVjT-00007i-00 for nemo@ietf.org; Thu, 10 Jul 2003 03:20:47 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHS00I01SDTFD@mailout2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:17 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHS00C9VSDSYF@mailout2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:17 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHS006ZOSDS6P@mmp2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:16 +0900 (KST) Date: Thu, 10 Jul 2003 16:20:32 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <000301c346b3$bfa72b40$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] test mail Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT sorry Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics From exim@www1.ietf.org Thu Jul 10 03:21:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20896 for ; Thu, 10 Jul 2003 03:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjo-0006Dh-Nn for nemo-archive@odin.ietf.org; Thu, 10 Jul 2003 03:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A7L8uA023903 for nemo-archive@odin.ietf.org; Thu, 10 Jul 2003 03:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjo-0006DS-Ec for nemo-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 03:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20875 for ; Thu, 10 Jul 2003 03:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVjm-00008N-00 for nemo-web-archive@ietf.org; Thu, 10 Jul 2003 03:21:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aVjl-00008J-00 for nemo-web-archive@ietf.org; Thu, 10 Jul 2003 03:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjj-0006CJ-1r; Thu, 10 Jul 2003 03:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVjW-0006Bt-9o for nemo@optimus.ietf.org; Thu, 10 Jul 2003 03:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20844 for ; Thu, 10 Jul 2003 03:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVjU-00007x-00 for nemo@ietf.org; Thu, 10 Jul 2003 03:20:48 -0400 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19aVjT-00007i-00 for nemo@ietf.org; Thu, 10 Jul 2003 03:20:47 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHS00I01SDTFD@mailout2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:17 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHS00C9VSDSYF@mailout2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:17 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHS006ZOSDS6P@mmp2.samsung.com> for nemo@ietf.org; Thu, 10 Jul 2003 16:20:16 +0900 (KST) Date: Thu, 10 Jul 2003 16:20:32 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <000301c346b3$bfa72b40$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] test mail Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT sorry Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics From nemo-admin@ietf.org Thu Jul 10 19:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26850 for ; Thu, 10 Jul 2003 19:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akxF-0003l0-Pa; Thu, 10 Jul 2003 19:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akwI-0003he-O8 for nemo@optimus.ietf.org; Thu, 10 Jul 2003 19:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26835 for ; Thu, 10 Jul 2003 19:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19akwG-0000Qr-00 for nemo@ietf.org; Thu, 10 Jul 2003 19:35:00 -0400 Received: from [203.254.224.24] (helo=realname) by ietf-mx with esmtp (Exim 4.12) id 19akwF-0000Qe-00 for nemo@ietf.org; Thu, 10 Jul 2003 19:35:00 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHU00A051GWB4@mailout1.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:08 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHU00C3G1GTN7@mailout1.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:05 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHU00A8D1GSTX@mmp2.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:05 +0900 (KST) Date: Fri, 11 Jul 2003 08:34:19 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <000601c3473b$c9151330$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Dear all Above subject is being discussed at IPv6 forum by WiFi team. For this mechanism, I submitted a draft, and I would like to listen some comment and feedback from nemo WG. Abstract : In this draft, we describe a new mobility framework to extend 802.11 [WLAN] to seamlessly manage roaming into GPRS access network, whenever the mobile node is out of range from any 802.11 domain. http://www.ietf.org/internet-drafts/draft-park-mobileip-wifi-handover-00 .txt Please let me know your view on this with feedback and comment... Regards Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics From exim@www1.ietf.org Thu Jul 10 19:36:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26865 for ; Thu, 10 Jul 2003 19:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akxK-0003lx-Pz for nemo-archive@odin.ietf.org; Thu, 10 Jul 2003 19:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ANa6Pf014495 for nemo-archive@odin.ietf.org; Thu, 10 Jul 2003 19:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akxK-0003li-HD for nemo-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 19:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26843 for ; Thu, 10 Jul 2003 19:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19akxI-0000R3-00 for nemo-web-archive@ietf.org; Thu, 10 Jul 2003 19:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19akxI-0000R0-00 for nemo-web-archive@ietf.org; Thu, 10 Jul 2003 19:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akxF-0003l0-Pa; Thu, 10 Jul 2003 19:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19akwI-0003he-O8 for nemo@optimus.ietf.org; Thu, 10 Jul 2003 19:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26835 for ; Thu, 10 Jul 2003 19:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19akwG-0000Qr-00 for nemo@ietf.org; Thu, 10 Jul 2003 19:35:00 -0400 Received: from [203.254.224.24] (helo=realname) by ietf-mx with esmtp (Exim 4.12) id 19akwF-0000Qe-00 for nemo@ietf.org; Thu, 10 Jul 2003 19:35:00 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHU00A051GWB4@mailout1.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:08 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHU00C3G1GTN7@mailout1.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:05 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHU00A8D1GSTX@mmp2.samsung.com> for nemo@ietf.org; Fri, 11 Jul 2003 08:34:05 +0900 (KST) Date: Fri, 11 Jul 2003 08:34:19 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <000601c3473b$c9151330$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear all Above subject is being discussed at IPv6 forum by WiFi team. For this mechanism, I submitted a draft, and I would like to listen some comment and feedback from nemo WG. Abstract : In this draft, we describe a new mobility framework to extend 802.11 [WLAN] to seamlessly manage roaming into GPRS access network, whenever the mobile node is out of range from any 802.11 domain. http://www.ietf.org/internet-drafts/draft-park-mobileip-wifi-handover-00 .txt Please let me know your view on this with feedback and comment... Regards Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics From nemo-admin@ietf.org Fri Jul 11 02:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17039 for ; Fri, 11 Jul 2003 02:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arBO-0000Np-7i; Fri, 11 Jul 2003 02:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arAu-0000LC-D3 for nemo@optimus.ietf.org; Fri, 11 Jul 2003 02:14:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16940 for ; Fri, 11 Jul 2003 02:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19arAq-0002bD-00 for nemo@ietf.org; Fri, 11 Jul 2003 02:14:28 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19arAq-0002b2-00 for nemo@ietf.org; Fri, 11 Jul 2003 02:14:28 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA28592; Thu, 10 Jul 2003 23:13:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6B6DrG12763; Thu, 10 Jul 2003 23:13:53 -0700 X-mProtect: <200307110613> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.254, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT6nZyl; Thu, 10 Jul 2003 23:13:52 PDT Message-ID: <3F0E559F.8000006@iprg.nokia.com> Date: Thu, 10 Jul 2003 23:13:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org Subject: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) References: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> In-Reply-To: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Jongkeun, please take a look at further discussion on this thread at http://people.nokia.net/vijayd/nemo/issue6.txt. the DT members feel that this a matter of config at the Home Agent, and there is no need for explicit indication in the Binding Update. I also would like to avoid introducing additional bits in the Binding Update. and I can add the following to Section 8. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, it is necessary that the Home Agent does not create routes to the Mobile network when the Binding Update from the Mobile Router is received. Any routes to the Mobile Network are created through routing protocol updates. let me know what you think about this. Vijay Jongkeun Na wrote: >>>I have a question for prefix table described in the draft. >>> >>>In case that prefix table is not pre-configured in HA, MR should use >> >>explicit or combined binding mode. Right? >> >>right. >> >> >>>Let's assume that MR and HA can run dynamic routing protocol and > > prefix > >>table is not pre-configured. >> >>when the MR and HA run a dynamic routing protocol there is >>no need to include an prefix information in the Binding >>Update. infact the HA should not try to determine the >>prefix from the Binding Update. the routing protocol updates >>will carry the prefix information. do you think we need an >>explicit flag in the Binding Update for this? >> > > > Yes, I thought an explicit flag is required for HA to properly handle > this situation. > > /Jongkeun > >>Vijay >> >> >>>If MR try to do implicit binding, by the draft, MR cannot set up the > > bi- > >>directional tunnel with its HA because HA will send BACK with `143' > > status > >>>code(Mobile Network Prefix Information information unavailable) for > > the > >>requested BU. >> >>>I think HA should allow the implicit BU from MR that runs dynamic >> >>routing protocol because the draft says that prefix table is an > > optional > >>data structure >> >>>from the terminology description of section 2. Or, the draft should > > say > >>prefix table MUST be maintained by HA. >> >>> >>> >>>It looks like unclear to me. Could you explain that for me? >>> >>> >>> >>>Best Regards, >>> >>>/Jongkeun > > From exim@www1.ietf.org Fri Jul 11 02:15:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17059 for ; Fri, 11 Jul 2003 02:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arBW-0000Pm-Sq for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 02:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B6FABb001591 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 02:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arBU-0000PS-UQ for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 02:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16994 for ; Fri, 11 Jul 2003 02:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19arBR-0002bP-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 02:15:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19arBR-0002bM-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 02:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arBO-0000Np-7i; Fri, 11 Jul 2003 02:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19arAu-0000LC-D3 for nemo@optimus.ietf.org; Fri, 11 Jul 2003 02:14:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16940 for ; Fri, 11 Jul 2003 02:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19arAq-0002bD-00 for nemo@ietf.org; Fri, 11 Jul 2003 02:14:28 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19arAq-0002b2-00 for nemo@ietf.org; Fri, 11 Jul 2003 02:14:28 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA28592; Thu, 10 Jul 2003 23:13:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6B6DrG12763; Thu, 10 Jul 2003 23:13:53 -0700 X-mProtect: <200307110613> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.254, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT6nZyl; Thu, 10 Jul 2003 23:13:52 PDT Message-ID: <3F0E559F.8000006@iprg.nokia.com> Date: Thu, 10 Jul 2003 23:13:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org Subject: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) References: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> In-Reply-To: <020d01c34103$1a80ecb0$dbf02e93@JONGKN03> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Jongkeun, please take a look at further discussion on this thread at http://people.nokia.net/vijayd/nemo/issue6.txt. the DT members feel that this a matter of config at the Home Agent, and there is no need for explicit indication in the Binding Update. I also would like to avoid introducing additional bits in the Binding Update. and I can add the following to Section 8. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, it is necessary that the Home Agent does not create routes to the Mobile network when the Binding Update from the Mobile Router is received. Any routes to the Mobile Network are created through routing protocol updates. let me know what you think about this. Vijay Jongkeun Na wrote: >>>I have a question for prefix table described in the draft. >>> >>>In case that prefix table is not pre-configured in HA, MR should use >> >>explicit or combined binding mode. Right? >> >>right. >> >> >>>Let's assume that MR and HA can run dynamic routing protocol and > > prefix > >>table is not pre-configured. >> >>when the MR and HA run a dynamic routing protocol there is >>no need to include an prefix information in the Binding >>Update. infact the HA should not try to determine the >>prefix from the Binding Update. the routing protocol updates >>will carry the prefix information. do you think we need an >>explicit flag in the Binding Update for this? >> > > > Yes, I thought an explicit flag is required for HA to properly handle > this situation. > > /Jongkeun > >>Vijay >> >> >>>If MR try to do implicit binding, by the draft, MR cannot set up the > > bi- > >>directional tunnel with its HA because HA will send BACK with `143' > > status > >>>code(Mobile Network Prefix Information information unavailable) for > > the > >>requested BU. >> >>>I think HA should allow the implicit BU from MR that runs dynamic >> >>routing protocol because the draft says that prefix table is an > > optional > >>data structure >> >>>from the terminology description of section 2. Or, the draft should > > say > >>prefix table MUST be maintained by HA. >> >>> >>> >>>It looks like unclear to me. Could you explain that for me? >>> >>> >>> >>>Best Regards, >>> >>>/Jongkeun > > From nemo-admin@ietf.org Fri Jul 11 04:30:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20746 for ; Fri, 11 Jul 2003 04:30:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atI3-00034s-Jn; Fri, 11 Jul 2003 04:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atHL-0002yQ-HK for nemo@optimus.ietf.org; Fri, 11 Jul 2003 04:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20688 for ; Fri, 11 Jul 2003 04:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atHI-0003Uu-00 for nemo@ietf.org; Fri, 11 Jul 2003 04:29:16 -0400 Received: from fwin.ssu.ac.kr ([203.253.30.8]) by ietf-mx with smtp (Exim 4.12) id 19atHH-0003Uf-00 for nemo@ietf.org; Fri, 11 Jul 2003 04:29:15 -0400 Received: from SOUHWANSENSQ ([203.253.0.12]) by mail.ssu.ac.kr (8.8.8/8.8.8) with SMTP id RAA07277; Fri, 11 Jul 2003 17:21:53 +0900 (KST) Message-ID: <017d01c34786$6e4262a0$cd10fea9@SOUHWANSENSQ> From: "Souhwan Jung" To: "Thierry Ernst" , References: <3EFFE02B.2020401@eng.monash.edu.au><000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ><20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp><001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> Subject: Re: [nemo] Security considerations for NEMO? Date: Fri, 11 Jul 2003 17:28:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RGVhciBUaGllcnJ5LA0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLg0KDQo+IFZlcnkg aW50ZXJlc3RpbmcgZG9jdW1lbnQsIEkgd2FzIHdhaXRpbmcgZm9yIGEgY29udHJpYnV0aW9uIG9u IHRoaXMNCj4gc3ViamVjdCBmb3IgYSBsb25nIHRpbWUuIFRoaXMgaXMgYSBnb29kIHN0YXJ0aW5n IGRvY3VtZW50LiBJIGZpbmQgeW91cg0KPiBtb2RlbCB2ZXJ5IHVzZWZ1bCB0byBsaXN0IHNlY3Vy aXR5IHRocmVhdHMuIFByb2JhYmx5IHRoZXJlIHdpbGwgYmUgbW9yZQ0KPiB0byBhZGQuIEZvciBp bnN0YW5jZSwgaXMgdGhlcmUgYW55dGhpbmcgdG8gY2FzZSBhYm91dCBpbiB0aGUgbmVzdGVkIGNh c2UNCj4gPw0KDQpUaGFua3MuDQpZZXMuIFRoZXJlIG1pZ2h0IGJlIHNvbWUgbW9yZSBpc3N1ZXMg dG8gdGhpbmsgYWJvdXQgIGluY2x1ZGluZyBuZXN0ZWQgY2FzZXMgYW5kIG11bHRpaG9taW5nIGNh c2VzLg0KV2Ugd2lsbCBrZWVwIHdvcmtpbmcgb24gdGhlIGlzc3Vlcy4NCg0KPiBNYXkgSSBhc2sg eW91IGlmIHlvdSBhbHJlYWR5IGhhZCB0aW1lIHRvIGFuYWx5c2UgdGhlIHNwZWNpZmljIHNlY3Vy aXR5DQo+IHRocmVhdHMgZmFjZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uIG9mIGRyYWZ0LWlldGYt bmVtby1iYXNpYyBhcyBpdCBpcw0KPiB3cml0dGVuIHRvZGF5ID8gSXMgdGhpcyBpbiB5b3VyIHBs YW5zIHRvIGFkZCB0aGlzIGluIHlvdXIgZHJhZnQgPyBXaGF0DQo+IGFib3V0IGRyYWZ0LWlldGYt bmVtby1iYXNpYyAncyBhYmlsaXR5IHRvIHByZXZlbnQgc3VjaCB0aHJlYXRzID8gDQoNClRocmVh dHMgYmFzZWQgb24gYmFzaWMgbmVtbyBwcm90b2NvbCBhcmUgdGhlIHdvcmsgdGhhdCB3ZSBoYXZl IHRvIGRvIG5leHQuDQpXZSB3aWxsIHJlZmluZSBvdXIgZHJhZnQgdG8gZGVzY3JpYmUgc3BlY2lm aWMgdGhyZWF0cyBhZ2FpbnN0IHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIG9mIHRoZSBiYXNpYyBu ZW1vIHByb3RvY29sLg0KDQo+IEZvciBpbnN0YW5jZSwgaW4gc2VjdGlvbiAzLjEsIHdoZW4geW91 IHNwZWFrIGFib3V0IG1hbi1pbi10aGUtbWlkZGxlLiBJDQo+IGRvdWJ0IHRoZSBCVSBtZXNzYWdl IGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1uZW1vLWJhc2ljIGNhbiBiZSBjb21wcm9taXNlZA0KPiBz aW5jZSB0aGUgTVIgaXMgYXV0aGVudGljYXRlZCBieSB0aGUgSEEgKGJ1dCwgc3VyZSwgd2l0aG91 dCB0aGUNCj4gYXV0aGVudGljYXRpb24sIHRoZSB0aHJlYXQgd291bGQgYXJpc2UpLiBPbiB0aGUg b3RoZXIgaGFuZCwgc29tZSB0aHJlYXRzDQo+IG1heSBub3QgYmUgcHJldmVudGVkIGJ5IHRoZSBj dXJyZW50IGRyYWZ0LWlldGYtbmVtby1iYXNpYyBkcmFmdCwgc28gaXQNCj4gd291bGQgbmVlZCBm aXhlcy4gcVdoYXQgYWJvdXQgdGhlIGF1dGhvcml6YXRpb24gdG8gcGVyZm9ybSB0aGUgb3BlcmF0 aW9uDQo+IChlLmcuIHNlbmRpbmcgYSBCVSBmb3IgYSBwcmVmaXggb2YgYSBzcGVjaWZpZWQgbGVu Z2h0KSA/DQoNCkRvIHlvdSBtZWFuIHRvIGFkZCBhdXRob3JpemF0aW9uIG9wZXJhdGlvbiB0byB0 aGUgYmFzaWMgbmVtbyBwcm90b2NvbCwgc28gZXZlcnkgY2xpZW50IG5lZWQgdG8gZ2V0IHRoZSBh dXRocml6YXRpb24gZnJvbSBIQSBiZWZvcmUgaXQgc2VuZHMgQlUgdG8gSEE/IFBsZWFzZSBleHBs YWluIG1vcmUgZGV0YWlscy4NCiANCj4gSW4gc3VtbWFyeSwgSSBjYW4gc2VlIHlvdXIgZHJhZnQg YSAxc3Qgc3RlcCBvZiBhIDMtc3RlcCBjb21wbGV0ZSBhbmFseXNpczoNCj4gLSB3aGF0IGFyZSB0 aGUgcG90ZW50aWFsIHRocmVhdHMNCj4gLSB3aGVyZSBORU1PIGJhc2ljIHN1cHBvcnQgZmFpbHMg dG8gcHJldmVudCBzdWNoIHRocmVhdHMNCj4gLSBob3cgdG8gZml4IE5FTU8gYmFzaWMgc3VwcG9y dA0KIA0KIFRoYXQncyByaWdodC4gV2UgbmVlZCB0byBrZWVwIHVwZGF0aW5nIGl0IGJhc2VkIG9u IHRoZSBkaXNjdXNzaW9ucyBhbmQgY29tbWVudHMgZnJvbSBORU1PIE1MLg0KDQo+IE1pc2MgY29t bWVudHMgYW5kIHF1ZXN0aW9ucyBhYm91dCB5b3VyIGRyYWZ0Og0KDQpXZSB3aWxsIGZpeCBzb21l IHRlcm1pbm9sb2dpZXMgYW5kIHR5cG9zLg0KDQpSZWdhcmRzLA0KDQpTb3Vod2FuDQo= From exim@www1.ietf.org Fri Jul 11 04:30:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20764 for ; Fri, 11 Jul 2003 04:30:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atIE-000373-TF for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 04:30:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B8UE9O011966 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 04:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atID-00035l-6O for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 04:30:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20732 for ; Fri, 11 Jul 2003 04:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atIA-0003W1-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 04:30:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19atI9-0003Vx-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 04:30:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atI3-00034s-Jn; Fri, 11 Jul 2003 04:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atHL-0002yQ-HK for nemo@optimus.ietf.org; Fri, 11 Jul 2003 04:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20688 for ; Fri, 11 Jul 2003 04:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atHI-0003Uu-00 for nemo@ietf.org; Fri, 11 Jul 2003 04:29:16 -0400 Received: from fwin.ssu.ac.kr ([203.253.30.8]) by ietf-mx with smtp (Exim 4.12) id 19atHH-0003Uf-00 for nemo@ietf.org; Fri, 11 Jul 2003 04:29:15 -0400 Received: from SOUHWANSENSQ ([203.253.0.12]) by mail.ssu.ac.kr (8.8.8/8.8.8) with SMTP id RAA07277; Fri, 11 Jul 2003 17:21:53 +0900 (KST) Message-ID: <017d01c34786$6e4262a0$cd10fea9@SOUHWANSENSQ> From: "Souhwan Jung" To: "Thierry Ernst" , References: <3EFFE02B.2020401@eng.monash.edu.au><000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ><20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp><001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> Subject: Re: [nemo] Security considerations for NEMO? Date: Fri, 11 Jul 2003 17:28:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBUaGllcnJ5LA0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLg0KDQo+IFZlcnkg aW50ZXJlc3RpbmcgZG9jdW1lbnQsIEkgd2FzIHdhaXRpbmcgZm9yIGEgY29udHJpYnV0aW9uIG9u IHRoaXMNCj4gc3ViamVjdCBmb3IgYSBsb25nIHRpbWUuIFRoaXMgaXMgYSBnb29kIHN0YXJ0aW5n IGRvY3VtZW50LiBJIGZpbmQgeW91cg0KPiBtb2RlbCB2ZXJ5IHVzZWZ1bCB0byBsaXN0IHNlY3Vy aXR5IHRocmVhdHMuIFByb2JhYmx5IHRoZXJlIHdpbGwgYmUgbW9yZQ0KPiB0byBhZGQuIEZvciBp bnN0YW5jZSwgaXMgdGhlcmUgYW55dGhpbmcgdG8gY2FzZSBhYm91dCBpbiB0aGUgbmVzdGVkIGNh c2UNCj4gPw0KDQpUaGFua3MuDQpZZXMuIFRoZXJlIG1pZ2h0IGJlIHNvbWUgbW9yZSBpc3N1ZXMg dG8gdGhpbmsgYWJvdXQgIGluY2x1ZGluZyBuZXN0ZWQgY2FzZXMgYW5kIG11bHRpaG9taW5nIGNh c2VzLg0KV2Ugd2lsbCBrZWVwIHdvcmtpbmcgb24gdGhlIGlzc3Vlcy4NCg0KPiBNYXkgSSBhc2sg eW91IGlmIHlvdSBhbHJlYWR5IGhhZCB0aW1lIHRvIGFuYWx5c2UgdGhlIHNwZWNpZmljIHNlY3Vy aXR5DQo+IHRocmVhdHMgZmFjZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uIG9mIGRyYWZ0LWlldGYt bmVtby1iYXNpYyBhcyBpdCBpcw0KPiB3cml0dGVuIHRvZGF5ID8gSXMgdGhpcyBpbiB5b3VyIHBs YW5zIHRvIGFkZCB0aGlzIGluIHlvdXIgZHJhZnQgPyBXaGF0DQo+IGFib3V0IGRyYWZ0LWlldGYt bmVtby1iYXNpYyAncyBhYmlsaXR5IHRvIHByZXZlbnQgc3VjaCB0aHJlYXRzID8gDQoNClRocmVh dHMgYmFzZWQgb24gYmFzaWMgbmVtbyBwcm90b2NvbCBhcmUgdGhlIHdvcmsgdGhhdCB3ZSBoYXZl IHRvIGRvIG5leHQuDQpXZSB3aWxsIHJlZmluZSBvdXIgZHJhZnQgdG8gZGVzY3JpYmUgc3BlY2lm aWMgdGhyZWF0cyBhZ2FpbnN0IHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIG9mIHRoZSBiYXNpYyBu ZW1vIHByb3RvY29sLg0KDQo+IEZvciBpbnN0YW5jZSwgaW4gc2VjdGlvbiAzLjEsIHdoZW4geW91 IHNwZWFrIGFib3V0IG1hbi1pbi10aGUtbWlkZGxlLiBJDQo+IGRvdWJ0IHRoZSBCVSBtZXNzYWdl IGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1uZW1vLWJhc2ljIGNhbiBiZSBjb21wcm9taXNlZA0KPiBz aW5jZSB0aGUgTVIgaXMgYXV0aGVudGljYXRlZCBieSB0aGUgSEEgKGJ1dCwgc3VyZSwgd2l0aG91 dCB0aGUNCj4gYXV0aGVudGljYXRpb24sIHRoZSB0aHJlYXQgd291bGQgYXJpc2UpLiBPbiB0aGUg b3RoZXIgaGFuZCwgc29tZSB0aHJlYXRzDQo+IG1heSBub3QgYmUgcHJldmVudGVkIGJ5IHRoZSBj dXJyZW50IGRyYWZ0LWlldGYtbmVtby1iYXNpYyBkcmFmdCwgc28gaXQNCj4gd291bGQgbmVlZCBm aXhlcy4gcVdoYXQgYWJvdXQgdGhlIGF1dGhvcml6YXRpb24gdG8gcGVyZm9ybSB0aGUgb3BlcmF0 aW9uDQo+IChlLmcuIHNlbmRpbmcgYSBCVSBmb3IgYSBwcmVmaXggb2YgYSBzcGVjaWZpZWQgbGVu Z2h0KSA/DQoNCkRvIHlvdSBtZWFuIHRvIGFkZCBhdXRob3JpemF0aW9uIG9wZXJhdGlvbiB0byB0 aGUgYmFzaWMgbmVtbyBwcm90b2NvbCwgc28gZXZlcnkgY2xpZW50IG5lZWQgdG8gZ2V0IHRoZSBh dXRocml6YXRpb24gZnJvbSBIQSBiZWZvcmUgaXQgc2VuZHMgQlUgdG8gSEE/IFBsZWFzZSBleHBs YWluIG1vcmUgZGV0YWlscy4NCiANCj4gSW4gc3VtbWFyeSwgSSBjYW4gc2VlIHlvdXIgZHJhZnQg YSAxc3Qgc3RlcCBvZiBhIDMtc3RlcCBjb21wbGV0ZSBhbmFseXNpczoNCj4gLSB3aGF0IGFyZSB0 aGUgcG90ZW50aWFsIHRocmVhdHMNCj4gLSB3aGVyZSBORU1PIGJhc2ljIHN1cHBvcnQgZmFpbHMg dG8gcHJldmVudCBzdWNoIHRocmVhdHMNCj4gLSBob3cgdG8gZml4IE5FTU8gYmFzaWMgc3VwcG9y dA0KIA0KIFRoYXQncyByaWdodC4gV2UgbmVlZCB0byBrZWVwIHVwZGF0aW5nIGl0IGJhc2VkIG9u IHRoZSBkaXNjdXNzaW9ucyBhbmQgY29tbWVudHMgZnJvbSBORU1PIE1MLg0KDQo+IE1pc2MgY29t bWVudHMgYW5kIHF1ZXN0aW9ucyBhYm91dCB5b3VyIGRyYWZ0Og0KDQpXZSB3aWxsIGZpeCBzb21l IHRlcm1pbm9sb2dpZXMgYW5kIHR5cG9zLg0KDQpSZWdhcmRzLA0KDQpTb3Vod2FuDQo= From nemo-admin@ietf.org Fri Jul 11 11:22:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03315 for ; Fri, 11 Jul 2003 11:22:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azij-0002M9-Or; Fri, 11 Jul 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azhp-0002EW-Qe for nemo@optimus.ietf.org; Fri, 11 Jul 2003 11:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03264 for ; Fri, 11 Jul 2003 11:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azhp-0006Qc-00 for nemo@ietf.org; Fri, 11 Jul 2003 11:21:05 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19azho-0006QT-00 for nemo@ietf.org; Fri, 11 Jul 2003 11:21:04 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6BFIXYC021905; Sat, 12 Jul 2003 00:18:33 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Date: Sat, 12 Jul 2003 00:20:54 +0900 Message-ID: <001501c347c0$056da2f0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3F0E559F.8000006@iprg.nokia.com> Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, > > hi Jongkeun, > > please take a look at further discussion on this thread > at http://people.nokia.net/vijayd/nemo/issue6.txt. In case of using implicit mode BU, HA checks its prefix table whether there is any entry having MNP mapped from MR's HoA. The last paragraph of section 6.6 says as follows: "The Home Agent sets the status code in the Binding Acknowledgement to '143' (Mobile Network Prefix information unavailable) in order to indicate the Mobile Router that the received Home Address in the Binding Update does not match any prefix entry in the pre-configured prefix table. This is used in the Implicit case where the Mobile Router does not include any prefix information in the Binding Update." The above statement is not perfect in describing the case of running dynamic routing protocol. My point is that there is no need to refer the prefix table by HA when HA know that HA and MR use the dynamic routing protocol because the prefix information will be set in HA's routing table via dynamic routing update. So, there is need to distinguish between one implicit mode BU depending on the prefix table configuration and the other implicit mode BU depending on routing table for the check of MNP availability by HA. > the DT members feel that this a matter of config at the > Home Agent, and there is no need for explicit indication > in the Binding Update. I also would like to avoid > introducing additional bits in the Binding Update. > > and I can add the following to Section 8. > > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, it is necessary that the > Home Agent does not create routes to the Mobile network > when the Binding Update from the Mobile Router is received. > Any routes to the Mobile Network are created through routing > protocol updates. Good, better than no there. > let me know what you think about this. > Yes, HA can distinguish both implicit modes if it can know automatically through IGP routing interaction/configuration at home that MR run routing protocol and still will run routing daemon while away, or if the administrator configures one entry of the prefix table with new field(Ryuji's comment) that indicates MNP will be set by routing update. First is not clear but second is properly good. I totally agree with the use of new field in prefix table in just this case. But, IMHO, I think that HA needs to know MR is running dynamic routing protocol at the moment of each BU if NEMO basic protocol actively supports dynamic routing between MR and HA so that HA can properly or easily handle the prefix management. Anyway, at this time, it looks like insignificant in NEMO basic support. Thanks. /Jongkeun > Vijay > > Jongkeun Na wrote: > >>>I have a question for prefix table described in the draft. > >>> > >>>In case that prefix table is not pre-configured in HA, MR should use > >> > >>explicit or combined binding mode. Right? > >> > >>right. > >> > >> > >>>Let's assume that MR and HA can run dynamic routing protocol and > > > > prefix > > > >>table is not pre-configured. > >> > >>when the MR and HA run a dynamic routing protocol there is > >>no need to include an prefix information in the Binding > >>Update. infact the HA should not try to determine the > >>prefix from the Binding Update. the routing protocol updates > >>will carry the prefix information. do you think we need an > >>explicit flag in the Binding Update for this? > >> > > > > > > Yes, I thought an explicit flag is required for HA to properly handle > > this situation. > > > > /Jongkeun > > > >>Vijay > >> > >> > >>>If MR try to do implicit binding, by the draft, MR cannot set up the > > > > bi- > > > >>directional tunnel with its HA because HA will send BACK with `143' > > > > status > > > >>>code(Mobile Network Prefix Information information unavailable) for > > > > the > > > >>requested BU. > >> > >>>I think HA should allow the implicit BU from MR that runs dynamic > >> > >>routing protocol because the draft says that prefix table is an > > > > optional > > > >>data structure > >> > >>>from the terminology description of section 2. Or, the draft should > > > > say > > > >>prefix table MUST be maintained by HA. > >> > >>> > >>> > >>>It looks like unclear to me. Could you explain that for me? > >>> > >>> > >>> > >>>Best Regards, > >>> > >>>/Jongkeun > > > > From exim@www1.ietf.org Fri Jul 11 11:22:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03330 for ; Fri, 11 Jul 2003 11:22:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aziv-0002OA-Fj for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 11:22:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BFMDY0009178 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 11:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aziu-0002Nx-VP for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 11:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03300 for ; Fri, 11 Jul 2003 11:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aziu-0006R1-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 11:22:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19azit-0006Qy-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 11:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azij-0002M9-Or; Fri, 11 Jul 2003 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azhp-0002EW-Qe for nemo@optimus.ietf.org; Fri, 11 Jul 2003 11:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03264 for ; Fri, 11 Jul 2003 11:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azhp-0006Qc-00 for nemo@ietf.org; Fri, 11 Jul 2003 11:21:05 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19azho-0006QT-00 for nemo@ietf.org; Fri, 11 Jul 2003 11:21:04 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6BFIXYC021905; Sat, 12 Jul 2003 00:18:33 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" Cc: Subject: RE: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Date: Sat, 12 Jul 2003 00:20:54 +0900 Message-ID: <001501c347c0$056da2f0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3F0E559F.8000006@iprg.nokia.com> Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, > > hi Jongkeun, > > please take a look at further discussion on this thread > at http://people.nokia.net/vijayd/nemo/issue6.txt. In case of using implicit mode BU, HA checks its prefix table whether there is any entry having MNP mapped from MR's HoA. The last paragraph of section 6.6 says as follows: "The Home Agent sets the status code in the Binding Acknowledgement to '143' (Mobile Network Prefix information unavailable) in order to indicate the Mobile Router that the received Home Address in the Binding Update does not match any prefix entry in the pre-configured prefix table. This is used in the Implicit case where the Mobile Router does not include any prefix information in the Binding Update." The above statement is not perfect in describing the case of running dynamic routing protocol. My point is that there is no need to refer the prefix table by HA when HA know that HA and MR use the dynamic routing protocol because the prefix information will be set in HA's routing table via dynamic routing update. So, there is need to distinguish between one implicit mode BU depending on the prefix table configuration and the other implicit mode BU depending on routing table for the check of MNP availability by HA. > the DT members feel that this a matter of config at the > Home Agent, and there is no need for explicit indication > in the Binding Update. I also would like to avoid > introducing additional bits in the Binding Update. > > and I can add the following to Section 8. > > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, it is necessary that the > Home Agent does not create routes to the Mobile network > when the Binding Update from the Mobile Router is received. > Any routes to the Mobile Network are created through routing > protocol updates. Good, better than no there. > let me know what you think about this. > Yes, HA can distinguish both implicit modes if it can know automatically through IGP routing interaction/configuration at home that MR run routing protocol and still will run routing daemon while away, or if the administrator configures one entry of the prefix table with new field(Ryuji's comment) that indicates MNP will be set by routing update. First is not clear but second is properly good. I totally agree with the use of new field in prefix table in just this case. But, IMHO, I think that HA needs to know MR is running dynamic routing protocol at the moment of each BU if NEMO basic protocol actively supports dynamic routing between MR and HA so that HA can properly or easily handle the prefix management. Anyway, at this time, it looks like insignificant in NEMO basic support. Thanks. /Jongkeun > Vijay > > Jongkeun Na wrote: > >>>I have a question for prefix table described in the draft. > >>> > >>>In case that prefix table is not pre-configured in HA, MR should use > >> > >>explicit or combined binding mode. Right? > >> > >>right. > >> > >> > >>>Let's assume that MR and HA can run dynamic routing protocol and > > > > prefix > > > >>table is not pre-configured. > >> > >>when the MR and HA run a dynamic routing protocol there is > >>no need to include an prefix information in the Binding > >>Update. infact the HA should not try to determine the > >>prefix from the Binding Update. the routing protocol updates > >>will carry the prefix information. do you think we need an > >>explicit flag in the Binding Update for this? > >> > > > > > > Yes, I thought an explicit flag is required for HA to properly handle > > this situation. > > > > /Jongkeun > > > >>Vijay > >> > >> > >>>If MR try to do implicit binding, by the draft, MR cannot set up the > > > > bi- > > > >>directional tunnel with its HA because HA will send BACK with `143' > > > > status > > > >>>code(Mobile Network Prefix Information information unavailable) for > > > > the > > > >>requested BU. > >> > >>>I think HA should allow the implicit BU from MR that runs dynamic > >> > >>routing protocol because the draft says that prefix table is an > > > > optional > > > >>data structure > >> > >>>from the terminology description of section 2. Or, the draft should > > > > say > > > >>prefix table MUST be maintained by HA. > >> > >>> > >>> > >>>It looks like unclear to me. Could you explain that for me? > >>> > >>> > >>> > >>>Best Regards, > >>> > >>>/Jongkeun > > > > From nemo-admin@ietf.org Fri Jul 11 13:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07433 for ; Fri, 11 Jul 2003 13:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1nR-0004qF-Sd; Fri, 11 Jul 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1nQ-0004py-BS for nemo@optimus.ietf.org; Fri, 11 Jul 2003 13:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07413 for ; Fri, 11 Jul 2003 13:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1nO-0007gB-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:34:58 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b1nN-0007fz-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:34:57 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04860; Fri, 11 Jul 2003 10:34:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BHYNl30397; Fri, 11 Jul 2003 10:34:23 -0700 X-mProtect: <200307111734> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5ETt7b; Fri, 11 Jul 2003 10:34:22 PDT Message-ID: <3F0EF51E.33499E3F@iprg.nokia.com> Date: Fri, 11 Jul 2003 10:34:22 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Souhwan Jung CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? References: <3EFFE02B.2020401@eng.monash.edu.au><000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ><20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp><001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> <017d01c34786$6e4262a0$ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Souhwan Jung wrote: > > Threats based on basic nemo protocol are the work that we have to do next. > We will refine our draft to describe specific threats against the security mechanisms of the basic nemo protocol. good. this will be useful. and when you analyze the threats keep in mind that NEMO signaling is always authenticated. and also please discard those threats which arise from a compromised Access Router. this is not specific to NEMO. Vijay > > > For instance, in section 3.1, when you speak about man-in-the-middle. I > > doubt the BU message defined in draft-ietf-nemo-basic can be compromised > > since the MR is authenticated by the HA (but, sure, without the > > authentication, the threat would arise). On the other hand, some threats > > may not be prevented by the current draft-ietf-nemo-basic draft, so it > > would need fixes. qWhat about the authorization to perform the operation > > (e.g. sending a BU for a prefix of a specified lenght) ? > > Do you mean to add authorization operation to the basic nemo protocol, so every client need to get the authrization from HA before it sends BU to HA? Please explain more details. > > > In summary, I can see your draft a 1st step of a 3-step complete analysis: > > - what are the potential threats > > - where NEMO basic support fails to prevent such threats > > - how to fix NEMO basic support > > That's right. We need to keep updating it based on the discussions and comments from NEMO ML. > > > Misc comments and questions about your draft: > > We will fix some terminologies and typos. > > Regards, > > Souhwan From exim@www1.ietf.org Fri Jul 11 13:35:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07458 for ; Fri, 11 Jul 2003 13:35:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1ns-0004sc-4V for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 13:35:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BHZSkK018757 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 13:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1nr-0004sS-Vo for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 13:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07430 for ; Fri, 11 Jul 2003 13:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1nY-0007gS-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 13:35:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b1nX-0007gP-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 13:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1nR-0004qF-Sd; Fri, 11 Jul 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1nQ-0004py-BS for nemo@optimus.ietf.org; Fri, 11 Jul 2003 13:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07413 for ; Fri, 11 Jul 2003 13:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1nO-0007gB-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:34:58 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b1nN-0007fz-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:34:57 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04860; Fri, 11 Jul 2003 10:34:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BHYNl30397; Fri, 11 Jul 2003 10:34:23 -0700 X-mProtect: <200307111734> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5ETt7b; Fri, 11 Jul 2003 10:34:22 PDT Message-ID: <3F0EF51E.33499E3F@iprg.nokia.com> Date: Fri, 11 Jul 2003 10:34:22 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Souhwan Jung CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Security considerations for NEMO? References: <3EFFE02B.2020401@eng.monash.edu.au><000f01c33f4d$e801f560$a301a8c0@SOUHWANSENSQ><20030701134111.42f8e8fb.ernst@sfc.wide.ad.jp><001c01c33f8b$f5de0c80$4f01a8c0@SOUHWANSENSQ> <20030709124208.2d2230e1.ernst@sfc.wide.ad.jp> <017d01c34786$6e4262a0$ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Souhwan Jung wrote: > > Threats based on basic nemo protocol are the work that we have to do next. > We will refine our draft to describe specific threats against the security mechanisms of the basic nemo protocol. good. this will be useful. and when you analyze the threats keep in mind that NEMO signaling is always authenticated. and also please discard those threats which arise from a compromised Access Router. this is not specific to NEMO. Vijay > > > For instance, in section 3.1, when you speak about man-in-the-middle. I > > doubt the BU message defined in draft-ietf-nemo-basic can be compromised > > since the MR is authenticated by the HA (but, sure, without the > > authentication, the threat would arise). On the other hand, some threats > > may not be prevented by the current draft-ietf-nemo-basic draft, so it > > would need fixes. qWhat about the authorization to perform the operation > > (e.g. sending a BU for a prefix of a specified lenght) ? > > Do you mean to add authorization operation to the basic nemo protocol, so every client need to get the authrization from HA before it sends BU to HA? Please explain more details. > > > In summary, I can see your draft a 1st step of a 3-step complete analysis: > > - what are the potential threats > > - where NEMO basic support fails to prevent such threats > > - how to fix NEMO basic support > > That's right. We need to keep updating it based on the discussions and comments from NEMO ML. > > > Misc comments and questions about your draft: > > We will fix some terminologies and typos. > > Regards, > > Souhwan From nemo-admin@ietf.org Fri Jul 11 13:44:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07756 for ; Fri, 11 Jul 2003 13:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1w8-0005b5-RY; Fri, 11 Jul 2003 13:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1vH-0005Tn-LN for nemo@optimus.ietf.org; Fri, 11 Jul 2003 13:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07715 for ; Fri, 11 Jul 2003 13:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1vD-0007ka-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:43:04 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b1vC-0007kF-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:43:03 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05298; Fri, 11 Jul 2003 10:42:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BHgSm07631; Fri, 11 Jul 2003 10:42:28 -0700 X-mProtect: <200307111742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTrqkri; Fri, 11 Jul 2003 10:42:26 PDT Message-ID: <3F0EF702.5975C06D@iprg.nokia.com> Date: Fri, 11 Jul 2003 10:42:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org Subject: Re: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) References: <001501c347c0$056da2f0$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jongkeun Na wrote: > I totally agree with the use of new field in prefix table in just this > case. But, IMHO, I think that HA needs to know MR is running dynamic > routing protocol at the moment of each BU if NEMO basic protocol > actively supports dynamic routing between MR and HA so that HA can > properly or easily handle the prefix management. Anyway, at this time, > it looks like insignificant in NEMO basic support. Thanks. okay. I will make it more explicit. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. this goes into section 8. Vijay From exim@www1.ietf.org Fri Jul 11 13:44:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07775 for ; Fri, 11 Jul 2003 13:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1wB-0005c3-2D for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 13:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BHi3ZG021569 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 13:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1wA-0005bo-Lf for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 13:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07750 for ; Fri, 11 Jul 2003 13:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1w8-0007lS-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 13:44:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b1w8-0007lP-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 13:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1w8-0005b5-RY; Fri, 11 Jul 2003 13:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1vH-0005Tn-LN for nemo@optimus.ietf.org; Fri, 11 Jul 2003 13:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07715 for ; Fri, 11 Jul 2003 13:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1vD-0007ka-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:43:04 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b1vC-0007kF-00 for nemo@ietf.org; Fri, 11 Jul 2003 13:43:03 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05298; Fri, 11 Jul 2003 10:42:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BHgSm07631; Fri, 11 Jul 2003 10:42:28 -0700 X-mProtect: <200307111742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTrqkri; Fri, 11 Jul 2003 10:42:26 PDT Message-ID: <3F0EF702.5975C06D@iprg.nokia.com> Date: Fri, 11 Jul 2003 10:42:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: nemo@ietf.org Subject: Re: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) References: <001501c347c0$056da2f0$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jongkeun Na wrote: > I totally agree with the use of new field in prefix table in just this > case. But, IMHO, I think that HA needs to know MR is running dynamic > routing protocol at the moment of each BU if NEMO basic protocol > actively supports dynamic routing between MR and HA so that HA can > properly or easily handle the prefix management. Anyway, at this time, > it looks like insignificant in NEMO basic support. Thanks. okay. I will make it more explicit. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. this goes into section 8. Vijay From nemo-admin@ietf.org Fri Jul 11 15:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13733 for ; Fri, 11 Jul 2003 15:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iT-0005Mg-Co; Fri, 11 Jul 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iN-0005LJ-Tx for nemo@optimus.ietf.org; Fri, 11 Jul 2003 15:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13703 for ; Fri, 11 Jul 2003 15:37:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3iM-0001LX-00 for nemo@ietf.org; Fri, 11 Jul 2003 15:37:54 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b3iL-0001Kz-00 for nemo@ietf.org; Fri, 11 Jul 2003 15:37:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA12977; Fri, 11 Jul 2003 12:37:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BJbGf30791; Fri, 11 Jul 2003 12:37:16 -0700 X-mProtect: <200307111937> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzVCUbZ; Fri, 11 Jul 2003 12:37:14 PDT Message-ID: <3F0F11EA.9310C7AD@iprg.nokia.com> Date: Fri, 11 Jul 2003 12:37:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: cwng@psl.com.sg CC: IETF NEMO WG Subject: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > > if the Mobile Router set the R bit to 0 in the Binding > > Update, it means it is going to behave as a mobile host. > > > > > So, does this means that for a static route configuration > > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > > the Home Agent should discard packets sent to the Mobile Network Prefix > > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > > of the Home Agent in this case can be specified? > > > > even in static route configuartion, the HA must > > consult the binding cache for the MR's current CoA. > > if there is no binding cache entry, then the packets > > are sent on link. if there is a binding cache entry > > and the R bit set to 0, the HA must not forward the > > packets. > > > > is this an acceptable solution? > > > Yes, it is. I just thought that this should be reflected in the draft. okay. I am changing the following The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is just behaving as a Mobile Node, and should not forward packets destined for the mobile network to the Mobile Router. to The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is just behaving as a Mobile Node, and MUST NOT forward packets destined for the mobile network to the Mobile Router. MUST NOT should make it clear that if the R flag is set to 0, the HA does not forward packets meant for the mobile network to the mobile router under all circumstances. > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > there be changes to the Binding Cache as well? > > > > yes. you are right. the HA should store the prefixes > > that was sent in the Binding Update. it needs this list > > of prefixes later on to delete all the routes, if the > > binding cache entry expires. I will add some text. > > > OK. here is some text (to be added to Section 6.1) The Home Agent SHOULD store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information is later used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. The Home Agent also stores the status of the Mobile Router Flag 'R' in the Binding Cache entry. > > > > Nothing is mentioned in the operation of Mobile Router about checks on > > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > > verify that the inner packet has a destination address that is within > > > its Mobile Network Prefix? > > > > it should perform all the necessary checks when > > decapsulating and forwarding packets. we will add some > > text. > > > OK here is some text. in section 3. after The Mobile Router decapsulates the packet and forwards it onto the link where the Mobile Network is connected. add The Mobile Router before decapsulating the tunneled packet, has to check if the Source address on the outer IPv6 header is the Home Agent's address. It also has to make sure the destination address on the inner IPv6 header belongs to one of its Mobile Network Prefixes before forwarding the packet to the Mobile Network. Vijay From exim@www1.ietf.org Fri Jul 11 15:38:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13750 for ; Fri, 11 Jul 2003 15:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iY-0005Nv-V9 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 15:38:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJc6ON020693 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 15:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iY-0005Ng-RG for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 15:38:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13712 for ; Fri, 11 Jul 2003 15:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3iX-0001Lt-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 15:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b3iX-0001Lq-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 15:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iT-0005Mg-Co; Fri, 11 Jul 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3iN-0005LJ-Tx for nemo@optimus.ietf.org; Fri, 11 Jul 2003 15:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13703 for ; Fri, 11 Jul 2003 15:37:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3iM-0001LX-00 for nemo@ietf.org; Fri, 11 Jul 2003 15:37:54 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b3iL-0001Kz-00 for nemo@ietf.org; Fri, 11 Jul 2003 15:37:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA12977; Fri, 11 Jul 2003 12:37:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BJbGf30791; Fri, 11 Jul 2003 12:37:16 -0700 X-mProtect: <200307111937> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzVCUbZ; Fri, 11 Jul 2003 12:37:14 PDT Message-ID: <3F0F11EA.9310C7AD@iprg.nokia.com> Date: Fri, 11 Jul 2003 12:37:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: cwng@psl.com.sg CC: IETF NEMO WG Subject: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > > if the Mobile Router set the R bit to 0 in the Binding > > Update, it means it is going to behave as a mobile host. > > > > > So, does this means that for a static route configuration > > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > > the Home Agent should discard packets sent to the Mobile Network Prefix > > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > > of the Home Agent in this case can be specified? > > > > even in static route configuartion, the HA must > > consult the binding cache for the MR's current CoA. > > if there is no binding cache entry, then the packets > > are sent on link. if there is a binding cache entry > > and the R bit set to 0, the HA must not forward the > > packets. > > > > is this an acceptable solution? > > > Yes, it is. I just thought that this should be reflected in the draft. okay. I am changing the following The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is just behaving as a Mobile Node, and should not forward packets destined for the mobile network to the Mobile Router. to The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is just behaving as a Mobile Node, and MUST NOT forward packets destined for the mobile network to the Mobile Router. MUST NOT should make it clear that if the R flag is set to 0, the HA does not forward packets meant for the mobile network to the mobile router under all circumstances. > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > there be changes to the Binding Cache as well? > > > > yes. you are right. the HA should store the prefixes > > that was sent in the Binding Update. it needs this list > > of prefixes later on to delete all the routes, if the > > binding cache entry expires. I will add some text. > > > OK. here is some text (to be added to Section 6.1) The Home Agent SHOULD store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information is later used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. The Home Agent also stores the status of the Mobile Router Flag 'R' in the Binding Cache entry. > > > > Nothing is mentioned in the operation of Mobile Router about checks on > > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > > verify that the inner packet has a destination address that is within > > > its Mobile Network Prefix? > > > > it should perform all the necessary checks when > > decapsulating and forwarding packets. we will add some > > text. > > > OK here is some text. in section 3. after The Mobile Router decapsulates the packet and forwards it onto the link where the Mobile Network is connected. add The Mobile Router before decapsulating the tunneled packet, has to check if the Source address on the outer IPv6 header is the Home Agent's address. It also has to make sure the destination address on the inner IPv6 header belongs to one of its Mobile Network Prefixes before forwarding the packet to the Mobile Network. Vijay From nemo-admin@ietf.org Fri Jul 11 17:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17835 for ; Fri, 11 Jul 2003 17:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Qv-00050z-8L; Fri, 11 Jul 2003 17:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Qg-00050g-2x for nemo@optimus.ietf.org; Fri, 11 Jul 2003 17:27:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17806 for ; Fri, 11 Jul 2003 17:27:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5Qd-0002hV-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:27:43 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b5Qc-0002h8-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:27:42 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19575; Fri, 11 Jul 2003 14:27:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BLR9e07108; Fri, 11 Jul 2003 14:27:09 -0700 X-mProtect: <200307112127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpsCOtc; Fri, 11 Jul 2003 14:27:08 PDT Message-ID: <3F0F2BAC.F7A1A05F@iprg.nokia.com> Date: Fri, 11 Jul 2003 14:27:08 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: julien@sfc.wide.ad.jp CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-charbon-nemo-multihoming-evaluation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit a very good and useful draft. thanks. I have some comments on the draft. fault tolerance and policy as two categories makes a lot of sense. I am not sure about the load sharing support. what exactly do you gain by sharing load between the two egress interfaces (assuming the MR has two egress interfaces)? do you have a concrete example for this? you would always want use the high bandwidth link, right? I strongly disagree with statements like > In this case the MR and the HA MUST use the two bi-directional > tunnels simultaneously. > Thus the NEMO solution MUST manage network traffic > simultaneously through the several connection of a same MR. it might be an attractive feature to have. but it is not a MUST feature to have, IMO. especially when I dont see the need for it. section 2.2 > > A MR is multi-homed when it has simultaneously more than one > active connection to the Internet, [...] and > R12: The solution MUST function for multi-homed MR and > multi-homed mobile networks as defined in [NEMO-TERMS]). > Particularly: > > R12.1: The solution MUST function for multi-MR mobile > networks does not lead you to > > Thus the NEMO solution MUST manage network traffic > simultaneously through the several connection of a same MR. I dont know how you arrived at the above statement. in case (0,1,0) its a mess if the Home Agents belong to different administrative domains. I looked at the reference [11]. towards the end of section 5.1.2 in reference [11], I see some text which says this kind of multi-homining is rare. I think you should also say that this is rare and is out of scope for NEMO. frankly, I think it is not worth solving. in case (1,0,1) and case (1,1,1) what if both prefixes are advertised by both Mobile Routers? is there any difference? for both these cases, you have assumed that each Mobile Router will advertise a different prefix (which is good makes things simpler). but is this a valid assumption? > 10. Conclusions > > In this draft, we explore the level of Multi-homing support available > in the NEMO Basic proposed solution with respect to Multi-homing > requirements, the main goal being: > > "Do not prevent Multi-homing configurations/benefits by the using of > NEMO Basic Support." > > and this goal is mainly respected. good to know that. > However, based on our analysis, > we propose some improvements. arent these improvements best handled by separate specifications? > > o Preference & Priority: > > Theses two informations permit to manage the sharing/the policy of > the Inbound traffic to the Mobile Network through several CoAs > and/or several HAs. > > Theses information could be added to the Prefix-BU, and the > proposed solution specify a field/an sub-option to permit some > implementation to provide this benefit; or specify in the next > release of NEMO protocol. > > o Multiple CoAs for the same MNP: > > The proposed solution doesn't have to specify anything one this > subject, just to support it. But a paragraph on this purpose can > be helpful for implementation's developers. can you suggest some text? it is not clear to me what you are looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt provide a solution for this? Vijay From exim@www1.ietf.org Fri Jul 11 17:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17850 for ; Fri, 11 Jul 2003 17:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5R2-00055L-Jm for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 17:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BLS8la019542 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 17:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5R2-000557-GL for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 17:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17824 for ; Fri, 11 Jul 2003 17:28:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5R0-0002hj-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 17:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b5Qz-0002hg-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 17:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Qv-00050z-8L; Fri, 11 Jul 2003 17:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Qg-00050g-2x for nemo@optimus.ietf.org; Fri, 11 Jul 2003 17:27:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17806 for ; Fri, 11 Jul 2003 17:27:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5Qd-0002hV-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:27:43 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b5Qc-0002h8-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:27:42 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19575; Fri, 11 Jul 2003 14:27:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BLR9e07108; Fri, 11 Jul 2003 14:27:09 -0700 X-mProtect: <200307112127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpsCOtc; Fri, 11 Jul 2003 14:27:08 PDT Message-ID: <3F0F2BAC.F7A1A05F@iprg.nokia.com> Date: Fri, 11 Jul 2003 14:27:08 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: julien@sfc.wide.ad.jp CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-charbon-nemo-multihoming-evaluation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit a very good and useful draft. thanks. I have some comments on the draft. fault tolerance and policy as two categories makes a lot of sense. I am not sure about the load sharing support. what exactly do you gain by sharing load between the two egress interfaces (assuming the MR has two egress interfaces)? do you have a concrete example for this? you would always want use the high bandwidth link, right? I strongly disagree with statements like > In this case the MR and the HA MUST use the two bi-directional > tunnels simultaneously. > Thus the NEMO solution MUST manage network traffic > simultaneously through the several connection of a same MR. it might be an attractive feature to have. but it is not a MUST feature to have, IMO. especially when I dont see the need for it. section 2.2 > > A MR is multi-homed when it has simultaneously more than one > active connection to the Internet, [...] and > R12: The solution MUST function for multi-homed MR and > multi-homed mobile networks as defined in [NEMO-TERMS]). > Particularly: > > R12.1: The solution MUST function for multi-MR mobile > networks does not lead you to > > Thus the NEMO solution MUST manage network traffic > simultaneously through the several connection of a same MR. I dont know how you arrived at the above statement. in case (0,1,0) its a mess if the Home Agents belong to different administrative domains. I looked at the reference [11]. towards the end of section 5.1.2 in reference [11], I see some text which says this kind of multi-homining is rare. I think you should also say that this is rare and is out of scope for NEMO. frankly, I think it is not worth solving. in case (1,0,1) and case (1,1,1) what if both prefixes are advertised by both Mobile Routers? is there any difference? for both these cases, you have assumed that each Mobile Router will advertise a different prefix (which is good makes things simpler). but is this a valid assumption? > 10. Conclusions > > In this draft, we explore the level of Multi-homing support available > in the NEMO Basic proposed solution with respect to Multi-homing > requirements, the main goal being: > > "Do not prevent Multi-homing configurations/benefits by the using of > NEMO Basic Support." > > and this goal is mainly respected. good to know that. > However, based on our analysis, > we propose some improvements. arent these improvements best handled by separate specifications? > > o Preference & Priority: > > Theses two informations permit to manage the sharing/the policy of > the Inbound traffic to the Mobile Network through several CoAs > and/or several HAs. > > Theses information could be added to the Prefix-BU, and the > proposed solution specify a field/an sub-option to permit some > implementation to provide this benefit; or specify in the next > release of NEMO protocol. > > o Multiple CoAs for the same MNP: > > The proposed solution doesn't have to specify anything one this > subject, just to support it. But a paragraph on this purpose can > be helpful for implementation's developers. can you suggest some text? it is not clear to me what you are looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt provide a solution for this? Vijay From nemo-admin@ietf.org Fri Jul 11 17:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18426 for ; Fri, 11 Jul 2003 17:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5ab-0005sC-G8; Fri, 11 Jul 2003 17:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Zc-0005aw-N3 for nemo@optimus.ietf.org; Fri, 11 Jul 2003 17:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18329 for ; Fri, 11 Jul 2003 17:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5Za-0002pM-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:36:58 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b5ZZ-0002pB-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:36:57 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19930; Fri, 11 Jul 2003 14:36:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BLaKN16470; Fri, 11 Jul 2003 14:36:20 -0700 X-mProtect: <200307112136> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2MEiwy; Fri, 11 Jul 2003 14:36:18 PDT Message-ID: <3F0F2DD3.DE75A7D7@iprg.nokia.com> Date: Fri, 11 Jul 2003 14:36:19 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, Alexandru Petrescu Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Julien Charbon wrote: > o Now take a MR inside the bus Tokio - Kyoto: > > For Egress Interface: > > - Three GPRS interfaces. [480Kb/s][Together] > > For Ingress Interface: > > - One 802.11b Wi-Fi [11Mb/s] > > Here the main interest is to provide a "correct" connection to all > people inside bus all the time, and because of this bus run forward > country side, only GPRS is usable during all this trip. Thus you > multiply the GPRS connections to provide a better bandwidth. I guess I found the example I was looking for in my previous mail. :) I hadnt read this mail then. sorry. I have a question here. what do you we need to standardise here? how the Mobile Router distributes the traffic between the three egress interface is implementation dependent. ofcourse you still need the support for registering the same MNP with multiple CoAs. but there is nothing to standardise for the load sharing itself. it is internal to the Mobile Router. Vijay From exim@www1.ietf.org Fri Jul 11 17:38:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18448 for ; Fri, 11 Jul 2003 17:38:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5al-0005wN-Kf for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 17:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BLcBus022829 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 17:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5al-0005w8-Gi for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 17:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18407 for ; Fri, 11 Jul 2003 17:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5af-0002qW-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 17:38:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b5af-0002qT-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 17:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5ab-0005sC-G8; Fri, 11 Jul 2003 17:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b5Zc-0005aw-N3 for nemo@optimus.ietf.org; Fri, 11 Jul 2003 17:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18329 for ; Fri, 11 Jul 2003 17:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b5Za-0002pM-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:36:58 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b5ZZ-0002pB-00 for nemo@ietf.org; Fri, 11 Jul 2003 17:36:57 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19930; Fri, 11 Jul 2003 14:36:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BLaKN16470; Fri, 11 Jul 2003 14:36:20 -0700 X-mProtect: <200307112136> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2MEiwy; Fri, 11 Jul 2003 14:36:18 PDT Message-ID: <3F0F2DD3.DE75A7D7@iprg.nokia.com> Date: Fri, 11 Jul 2003 14:36:19 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, Alexandru Petrescu Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julien Charbon wrote: > o Now take a MR inside the bus Tokio - Kyoto: > > For Egress Interface: > > - Three GPRS interfaces. [480Kb/s][Together] > > For Ingress Interface: > > - One 802.11b Wi-Fi [11Mb/s] > > Here the main interest is to provide a "correct" connection to all > people inside bus all the time, and because of this bus run forward > country side, only GPRS is usable during all this trip. Thus you > multiply the GPRS connections to provide a better bandwidth. I guess I found the example I was looking for in my previous mail. :) I hadnt read this mail then. sorry. I have a question here. what do you we need to standardise here? how the Mobile Router distributes the traffic between the three egress interface is implementation dependent. ofcourse you still need the support for registering the same MNP with multiple CoAs. but there is nothing to standardise for the load sharing itself. it is internal to the Mobile Router. Vijay From nemo-admin@ietf.org Fri Jul 11 19:42:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25020 for ; Fri, 11 Jul 2003 19:42:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Wa-0005Zq-WC; Fri, 11 Jul 2003 19:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Vd-0005XY-PT for nemo@optimus.ietf.org; Fri, 11 Jul 2003 19:41:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24917 for ; Fri, 11 Jul 2003 19:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7Vc-0004uC-00 for nemo@ietf.org; Fri, 11 Jul 2003 19:41:00 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b7Va-0004tg-00 for nemo@ietf.org; Fri, 11 Jul 2003 19:40:59 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03319; Fri, 11 Jul 2003 16:40:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BNeQI07181; Fri, 11 Jul 2003 16:40:26 -0700 X-mProtect: <200307112340> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeFbFRE; Fri, 11 Jul 2003 16:40:24 PDT Message-ID: <3F0F4AE9.FF0628B8@iprg.nokia.com> Date: Fri, 11 Jul 2003 16:40:25 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: julien@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] Comments on draft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > in case (0,1,0) > > its a mess if the Home Agents belong to different > administrative domains. I looked at the reference [11]. > towards the end of section 5.1.2 in reference [11], I > see some text which says this kind of multi-homining > is rare. I think you should also say that this is rare > and is out of scope for NEMO. frankly, I think it is > not worth solving. I want to clarify something. having two Home Agents in different administrative domains is okay if the MR uses separate Mobile Network Prefixes with these two Home Agents. and each prefix should be aggregated under the respective Home Agents. Vijay From exim@www1.ietf.org Fri Jul 11 19:42:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25037 for ; Fri, 11 Jul 2003 19:42:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Wm-0005an-Nr for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 19:42:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BNgCOd021491 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 19:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Wm-0005aY-JH for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 19:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24990 for ; Fri, 11 Jul 2003 19:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7Wk-0004vS-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 19:42:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b7Wk-0004vP-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 19:42:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Wa-0005Zq-WC; Fri, 11 Jul 2003 19:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7Vd-0005XY-PT for nemo@optimus.ietf.org; Fri, 11 Jul 2003 19:41:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24917 for ; Fri, 11 Jul 2003 19:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7Vc-0004uC-00 for nemo@ietf.org; Fri, 11 Jul 2003 19:41:00 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b7Va-0004tg-00 for nemo@ietf.org; Fri, 11 Jul 2003 19:40:59 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03319; Fri, 11 Jul 2003 16:40:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6BNeQI07181; Fri, 11 Jul 2003 16:40:26 -0700 X-mProtect: <200307112340> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeFbFRE; Fri, 11 Jul 2003 16:40:24 PDT Message-ID: <3F0F4AE9.FF0628B8@iprg.nokia.com> Date: Fri, 11 Jul 2003 16:40:25 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: julien@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] Comments on draft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > in case (0,1,0) > > its a mess if the Home Agents belong to different > administrative domains. I looked at the reference [11]. > towards the end of section 5.1.2 in reference [11], I > see some text which says this kind of multi-homining > is rare. I think you should also say that this is rare > and is out of scope for NEMO. frankly, I think it is > not worth solving. I want to clarify something. having two Home Agents in different administrative domains is okay if the MR uses separate Mobile Network Prefixes with these two Home Agents. and each prefix should be aggregated under the respective Home Agents. Vijay From nemo-admin@ietf.org Fri Jul 11 20:40:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27750 for ; Fri, 11 Jul 2003 20:40:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8Qj-0000WD-Vg; Fri, 11 Jul 2003 20:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8QU-0000ST-SO for nemo@optimus.ietf.org; Fri, 11 Jul 2003 20:39:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27710 for ; Fri, 11 Jul 2003 20:39:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b8QS-0005dd-00 for nemo@ietf.org; Fri, 11 Jul 2003 20:39:44 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b8QR-0005dB-00 for nemo@ietf.org; Fri, 11 Jul 2003 20:39:43 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA06155; Fri, 11 Jul 2003 17:38:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6C0cvP25032; Fri, 11 Jul 2003 17:38:57 -0700 X-mProtect: <200307120038> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5nh0Ei; Fri, 11 Jul 2003 17:38:53 PDT Message-ID: <3F0F589E.5C231938@iprg.nokia.com> Date: Fri, 11 Jul 2003 17:38:54 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: cwng@psl.com.sg, julien@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] multi-homing scenarios Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I read draft-ng-nemo-multihoming-issues-01. a very useful draft. I have some comments on some of the scenarios. > 2.2.3 (0,1,0): Single MR, Multiple HAs, Single Prefix > > The (0,1,0) mobile network has only one mobile router advertising a > single subnet prefix. The mobile router, however, associates to > multiple home agents, possibly one home agent per home addresses. No > assumption is made on whether or not the home agents belongs to the > same administrative domain. > > > AR HA2 > _ | > |-|_|-| _ > _____ | |-|_| > _ p _ | |-| > |_|-|<-_ |-|_|-| | > _ |-|_|=| |_____|-| _ > |_|-| | | _ |-|_| > |-|_|-| > | > MNNs MR AR Internet AR HA1 both HA1 and HA2 start advertising reachability for the prefix 'p'. this might be okay if both belong to the same administrative domain. the HA1 and HA2 MUST NOT belong to different administrative domains. I think this restriction is necessary. later in Section 4 you say > The case of multiple home agents at different domains > advertising a route to the same subnet prefix may pose a problem > in the routing infrastructure as a whole. The implications of > this aspect needs further exploration. this is a serious problem and should be avoided. IMO, there is no further exploration needed. :) > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > The (0,1,1) mobile network has only one mobile router. However, the > mobile router advertises more than one subnet prefix, and also > associates to multiple home agents at the same time, possibly one > home agent per home address. No assumptions is made on whether or > not the home agents belongs to the same administrative domain. > > > AR HA2 > _ | > |-|_|-| _ > _____ | |-|_| > _ p1,p2 _ | |-| > |_|-|<-_ |-|_|-| | > _ |-|_|=| |_____|-| _ > |_|-| | | _ |-|_| > |-|_|-| > | > MNNs MR AR Internet AR HA1 if HA1 advertises P1 and HA2 advertises P2, it makes this very simple. so why dont we place such a restriction? we dont lose any functionality with this restriction. > 2.2.5 (1,0,0): Multiple MRs, Single HA, Single Prefix > > The (1,0,0) mobile network has more than one mobile router > advertising global routes. These mobile routers, however, advertise > the same subnet prefix and associate to the same home agent. Since > only one subnet prefix is advertised, the mobile network nodes are > (usually) not multi-homed. > > MR2 > > p > <-_ | > _ |-|_|-| _____ > |_|-| |-| | > _ | | |-| _ > |_|-| _ |-|_____| | _ |-|_| > |-|_|-| |-|_|-| > <- | | > p > > MNNs MR1 Internet AR HA so where does the HA forward packets meant for the prefix 'p'? to MR1 or MR2? if the HA uses the routing table for forwarding packets for P, it clearly cant have two routing entries. > 2.2.6 (1,0,1): Multiple MRs, Single HA, Multiple Prefixes for this why dont we place a restriction that MR1 and MR2 should register P1 and P2, respectively, with the single Home Agent? this would make it simple. > 2.2.7 (1,1,0): Multiple MRs, Multiple HAs, Single Prefix again, I think the HAs MUST belong to the same administrative domain if there is only one Mobile Network Prefix. > From the above analysis, we can identify the following problems > relating to multi-homed mobile network: > > o Multiple care-of-addresses to one home-address: the answer is standardize draft-wakikawa-mobileip-multiplecoa-00.txt > o Multiple prefixes taken care of by a single home-address: what is the issue here? you can send multiple prefixes in the same binding update using the Mobile Network Prefix option in draft-ietf-nemo-basic-support-00.txt. the prefixes can be of different prefix lengths. > o A single home-address registered to multiple home agents: > > * Is this allowed? should be disallowed. > o A single subnet prefix registered to multiple home agents: > > * Is this allowed? only if both Home Agents belong to the same domain. I hope all this gets discussed on Wednesday. :) Vijay From exim@www1.ietf.org Fri Jul 11 20:40:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27765 for ; Fri, 11 Jul 2003 20:40:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8Qp-0000Yy-RP for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 20:40:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6C0e7NC002165 for nemo-archive@odin.ietf.org; Fri, 11 Jul 2003 20:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8Qp-0000Yq-Cn for nemo-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 20:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27733 for ; Fri, 11 Jul 2003 20:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b8Qn-0005dx-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 20:40:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b8Qm-0005du-00 for nemo-web-archive@ietf.org; Fri, 11 Jul 2003 20:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8Qj-0000WD-Vg; Fri, 11 Jul 2003 20:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b8QU-0000ST-SO for nemo@optimus.ietf.org; Fri, 11 Jul 2003 20:39:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27710 for ; Fri, 11 Jul 2003 20:39:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b8QS-0005dd-00 for nemo@ietf.org; Fri, 11 Jul 2003 20:39:44 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19b8QR-0005dB-00 for nemo@ietf.org; Fri, 11 Jul 2003 20:39:43 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA06155; Fri, 11 Jul 2003 17:38:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6C0cvP25032; Fri, 11 Jul 2003 17:38:57 -0700 X-mProtect: <200307120038> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5nh0Ei; Fri, 11 Jul 2003 17:38:53 PDT Message-ID: <3F0F589E.5C231938@iprg.nokia.com> Date: Fri, 11 Jul 2003 17:38:54 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: cwng@psl.com.sg, julien@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] multi-homing scenarios Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I read draft-ng-nemo-multihoming-issues-01. a very useful draft. I have some comments on some of the scenarios. > 2.2.3 (0,1,0): Single MR, Multiple HAs, Single Prefix > > The (0,1,0) mobile network has only one mobile router advertising a > single subnet prefix. The mobile router, however, associates to > multiple home agents, possibly one home agent per home addresses. No > assumption is made on whether or not the home agents belongs to the > same administrative domain. > > > AR HA2 > _ | > |-|_|-| _ > _____ | |-|_| > _ p _ | |-| > |_|-|<-_ |-|_|-| | > _ |-|_|=| |_____|-| _ > |_|-| | | _ |-|_| > |-|_|-| > | > MNNs MR AR Internet AR HA1 both HA1 and HA2 start advertising reachability for the prefix 'p'. this might be okay if both belong to the same administrative domain. the HA1 and HA2 MUST NOT belong to different administrative domains. I think this restriction is necessary. later in Section 4 you say > The case of multiple home agents at different domains > advertising a route to the same subnet prefix may pose a problem > in the routing infrastructure as a whole. The implications of > this aspect needs further exploration. this is a serious problem and should be avoided. IMO, there is no further exploration needed. :) > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > The (0,1,1) mobile network has only one mobile router. However, the > mobile router advertises more than one subnet prefix, and also > associates to multiple home agents at the same time, possibly one > home agent per home address. No assumptions is made on whether or > not the home agents belongs to the same administrative domain. > > > AR HA2 > _ | > |-|_|-| _ > _____ | |-|_| > _ p1,p2 _ | |-| > |_|-|<-_ |-|_|-| | > _ |-|_|=| |_____|-| _ > |_|-| | | _ |-|_| > |-|_|-| > | > MNNs MR AR Internet AR HA1 if HA1 advertises P1 and HA2 advertises P2, it makes this very simple. so why dont we place such a restriction? we dont lose any functionality with this restriction. > 2.2.5 (1,0,0): Multiple MRs, Single HA, Single Prefix > > The (1,0,0) mobile network has more than one mobile router > advertising global routes. These mobile routers, however, advertise > the same subnet prefix and associate to the same home agent. Since > only one subnet prefix is advertised, the mobile network nodes are > (usually) not multi-homed. > > MR2 > > p > <-_ | > _ |-|_|-| _____ > |_|-| |-| | > _ | | |-| _ > |_|-| _ |-|_____| | _ |-|_| > |-|_|-| |-|_|-| > <- | | > p > > MNNs MR1 Internet AR HA so where does the HA forward packets meant for the prefix 'p'? to MR1 or MR2? if the HA uses the routing table for forwarding packets for P, it clearly cant have two routing entries. > 2.2.6 (1,0,1): Multiple MRs, Single HA, Multiple Prefixes for this why dont we place a restriction that MR1 and MR2 should register P1 and P2, respectively, with the single Home Agent? this would make it simple. > 2.2.7 (1,1,0): Multiple MRs, Multiple HAs, Single Prefix again, I think the HAs MUST belong to the same administrative domain if there is only one Mobile Network Prefix. > From the above analysis, we can identify the following problems > relating to multi-homed mobile network: > > o Multiple care-of-addresses to one home-address: the answer is standardize draft-wakikawa-mobileip-multiplecoa-00.txt > o Multiple prefixes taken care of by a single home-address: what is the issue here? you can send multiple prefixes in the same binding update using the Mobile Network Prefix option in draft-ietf-nemo-basic-support-00.txt. the prefixes can be of different prefix lengths. > o A single home-address registered to multiple home agents: > > * Is this allowed? should be disallowed. > o A single subnet prefix registered to multiple home agents: > > * Is this allowed? only if both Home Agents belong to the same domain. I hope all this gets discussed on Wednesday. :) Vijay From nemo-admin@ietf.org Sat Jul 12 20:56:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25056 for ; Sat, 12 Jul 2003 20:56:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV9l-00076u-Ny; Sat, 12 Jul 2003 20:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV8u-00074U-HT for nemo@optimus.ietf.org; Sat, 12 Jul 2003 20:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24978 for ; Sat, 12 Jul 2003 20:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bV8s-0000wI-00 for nemo@ietf.org; Sat, 12 Jul 2003 20:55:06 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19bV8r-0000vh-00 for nemo@ietf.org; Sat, 12 Jul 2003 20:55:05 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA00312; Sat, 12 Jul 2003 17:54:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6D0sXK18935; Sat, 12 Jul 2003 17:54:33 -0700 X-mProtect: <200307130054> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDK8cAL; Sat, 12 Jul 2003 17:54:31 PDT Message-ID: <3F10ADC7.CDB3DE9C@iprg.nokia.com> Date: Sat, 12 Jul 2003 17:54:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rdroms@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Ralph, thanks for the draft. a few comments > Other updates to the HA data structures > required as a side effect of prefix delegation are specified by the > particular network mobility protocol. For example, in the case of > "Basic Network Mobility Support" [8], the HA would add an entry in > its binding cache registering the delegated prefix to the MR to which > the prefix was delegated. something is mixed up here. prefix delegation should work indepedent of the binding cache entries for the mobile routers. in the basic support NEMO draft the Home Agent creates routes to the mobile network when it receives a Binding Update from the mobile router. do you see a need to store the delegated prefix in the binding cache entry? this wont work because, the binding cache entry could expire. the lifetime of the binding cache entry shouldnt be related to the lifetime of the delegated prefix. > Following the DHCPv6 Prefix Delegation specification, HAs and MRs > SHOULD use DHCPv6 authentication as described in section > "Authentication of DHCP messages" of the DHCPv6 specification [6], to > guard against attacks mounted through prefix delegation. I dont follow DCHPv6 work. I looked up the DHCPv6 spec. it says the messages are authenticated using an authentication option, while the actual distribution of keys is declared out of scope. is there any work on distributing keys to the DHCPv6 client, especially if the client never comes home. this could be true in the case of NEMO. the mobile router could be away from home all the time. how does one distribute keys? manual keying? I am not saying manual keying wont work, I just want to understand this better. Vijay From exim@www1.ietf.org Sat Jul 12 20:56:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25077 for ; Sat, 12 Jul 2003 20:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV9t-00077v-PB for nemo-archive@odin.ietf.org; Sat, 12 Jul 2003 20:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6D0u9Vk027389 for nemo-archive@odin.ietf.org; Sat, 12 Jul 2003 20:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV9t-00077g-Lh for nemo-web-archive@optimus.ietf.org; Sat, 12 Jul 2003 20:56:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25033 for ; Sat, 12 Jul 2003 20:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bV9r-0000xX-00 for nemo-web-archive@ietf.org; Sat, 12 Jul 2003 20:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bV9q-0000xT-00 for nemo-web-archive@ietf.org; Sat, 12 Jul 2003 20:56:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV9l-00076u-Ny; Sat, 12 Jul 2003 20:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bV8u-00074U-HT for nemo@optimus.ietf.org; Sat, 12 Jul 2003 20:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24978 for ; Sat, 12 Jul 2003 20:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bV8s-0000wI-00 for nemo@ietf.org; Sat, 12 Jul 2003 20:55:06 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19bV8r-0000vh-00 for nemo@ietf.org; Sat, 12 Jul 2003 20:55:05 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA00312; Sat, 12 Jul 2003 17:54:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6D0sXK18935; Sat, 12 Jul 2003 17:54:33 -0700 X-mProtect: <200307130054> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDK8cAL; Sat, 12 Jul 2003 17:54:31 PDT Message-ID: <3F10ADC7.CDB3DE9C@iprg.nokia.com> Date: Sat, 12 Jul 2003 17:54:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rdroms@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Ralph, thanks for the draft. a few comments > Other updates to the HA data structures > required as a side effect of prefix delegation are specified by the > particular network mobility protocol. For example, in the case of > "Basic Network Mobility Support" [8], the HA would add an entry in > its binding cache registering the delegated prefix to the MR to which > the prefix was delegated. something is mixed up here. prefix delegation should work indepedent of the binding cache entries for the mobile routers. in the basic support NEMO draft the Home Agent creates routes to the mobile network when it receives a Binding Update from the mobile router. do you see a need to store the delegated prefix in the binding cache entry? this wont work because, the binding cache entry could expire. the lifetime of the binding cache entry shouldnt be related to the lifetime of the delegated prefix. > Following the DHCPv6 Prefix Delegation specification, HAs and MRs > SHOULD use DHCPv6 authentication as described in section > "Authentication of DHCP messages" of the DHCPv6 specification [6], to > guard against attacks mounted through prefix delegation. I dont follow DCHPv6 work. I looked up the DHCPv6 spec. it says the messages are authenticated using an authentication option, while the actual distribution of keys is declared out of scope. is there any work on distributing keys to the DHCPv6 client, especially if the client never comes home. this could be true in the case of NEMO. the mobile router could be away from home all the time. how does one distribute keys? manual keying? I am not saying manual keying wont work, I just want to understand this better. Vijay From nemo-admin@ietf.org Sun Jul 13 11:02:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26849 for ; Sun, 13 Jul 2003 11:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biMT-0001o6-Rv; Sun, 13 Jul 2003 11:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biLg-0001nX-SA for nemo@optimus.ietf.org; Sun, 13 Jul 2003 11:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26795 for ; Sun, 13 Jul 2003 11:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biLe-0005Yq-00 for nemo@ietf.org; Sun, 13 Jul 2003 11:01:10 -0400 Received: from [81.160.96.161] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19biLd-0005Yn-00 for nemo@ietf.org; Sun, 13 Jul 2003 11:01:09 -0400 Received: by squirrel (Postfix, from userid 1000) id 228FD12244B0; Mon, 14 Jul 2003 00:00:36 +0800 (SGT) Subject: Re: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3F0F11EA.9310C7AD@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> <3F0F11EA.9310C7AD@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058112036.1319.4.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 14 Jul 2003 00:00:36 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sat, 2003-07-12 at 03:37, Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > > > > > if the Mobile Router set the R bit to 0 in the Binding > > > Update, it means it is going to behave as a mobile host. > > > > > > > So, does this means that for a static route configuration > > > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > > > the Home Agent should discard packets sent to the Mobile Network Prefix > > > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > > > of the Home Agent in this case can be specified? > > > > > > even in static route configuartion, the HA must > > > consult the binding cache for the MR's current CoA. > > > if there is no binding cache entry, then the packets > > > are sent on link. if there is a binding cache entry > > > and the R bit set to 0, the HA must not forward the > > > packets. > > > > > > is this an acceptable solution? > > > > > Yes, it is. I just thought that this should be reflected in the draft. > > okay. I am changing the following > > The Mobile Router Flag is set to indicate to the Home Agent > that the Binding Update is from a Mobile Router. If the flag > is set to 0, the Home Agent assumes that the Mobile Router is > just behaving as a Mobile Node, and should not forward packets > destined for the mobile network to the Mobile Router. > > to > > The Mobile Router Flag is set to indicate to the Home Agent > that the Binding Update is from a Mobile Router. If the flag > is set to 0, the Home Agent assumes that the Mobile Router is > just behaving as a Mobile Node, and MUST NOT forward packets > destined for the mobile network to the Mobile Router. > > MUST NOT should make it clear that if the R flag is set > to 0, the HA does not forward packets meant for the > mobile network to the mobile router under all > circumstances. > Looks okay to me. > > > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > yes. you are right. the HA should store the prefixes > > > that was sent in the Binding Update. it needs this list > > > of prefixes later on to delete all the routes, if the > > > binding cache entry expires. I will add some text. > > > > > OK. > > here is some text (to be added to Section 6.1) > > The Home Agent SHOULD store the list of Mobile Network Prefixes owned > by a Mobile Router in the corresponding Binding Cache entry. This > list of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current Care-of > address. This information is later used to delete the routes when > the Binding Cache entry for the Mobile Router is deleted. > Sounds ok to me ... just one thing, perhaps the last sentence might be changed to "This information can be later used ..." to suggest that this is more of an implementation issue? Just a suggestion, the original sentence is also alright to me. > The Home Agent also stores the status of the Mobile Router Flag 'R' > in the Binding Cache entry. > > > > > > > > Nothing is mentioned in the operation of Mobile Router about checks on > > > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > > > verify that the inner packet has a destination address that is within > > > > its Mobile Network Prefix? > > > > > > it should perform all the necessary checks when > > > decapsulating and forwarding packets. we will add some > > > text. > > > > > OK > > here is some text. in section 3. > > after > > The Mobile Router > decapsulates the packet and forwards it onto the link where the > Mobile Network is connected. > > add > > The Mobile Router before decapsulating > the tunneled packet, has to check if the Source address on the outer > IPv6 header is the Home Agent's address. It also has to make sure > the destination address on the inner IPv6 header belongs to one of > its Mobile Network Prefixes before forwarding the packet to the > Mobile Network. > Sounds good. Thanks for the effort. /cwng From exim@www1.ietf.org Sun Jul 13 11:02:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26864 for ; Sun, 13 Jul 2003 11:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biMY-0001r7-N5 for nemo-archive@odin.ietf.org; Sun, 13 Jul 2003 11:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DF2630007132 for nemo-archive@odin.ietf.org; Sun, 13 Jul 2003 11:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biMY-0001qx-JY for nemo-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 11:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26841 for ; Sun, 13 Jul 2003 11:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biMW-0005ZN-00 for nemo-web-archive@ietf.org; Sun, 13 Jul 2003 11:02:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19biMV-0005ZK-00 for nemo-web-archive@ietf.org; Sun, 13 Jul 2003 11:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biMT-0001o6-Rv; Sun, 13 Jul 2003 11:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19biLg-0001nX-SA for nemo@optimus.ietf.org; Sun, 13 Jul 2003 11:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26795 for ; Sun, 13 Jul 2003 11:01:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19biLe-0005Yq-00 for nemo@ietf.org; Sun, 13 Jul 2003 11:01:10 -0400 Received: from [81.160.96.161] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19biLd-0005Yn-00 for nemo@ietf.org; Sun, 13 Jul 2003 11:01:09 -0400 Received: by squirrel (Postfix, from userid 1000) id 228FD12244B0; Mon, 14 Jul 2003 00:00:36 +0800 (SGT) Subject: Re: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3F0F11EA.9310C7AD@iprg.nokia.com> References: <1056428391.1789.56.camel@beethoven> <3EF8C394.F91C155F@iprg.nokia.com> <1056766378.1602.21.camel@fox> <3F0F11EA.9310C7AD@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058112036.1319.4.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 14 Jul 2003 00:00:36 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2003-07-12 at 03:37, Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > > > > > if the Mobile Router set the R bit to 0 in the Binding > > > Update, it means it is going to behave as a mobile host. > > > > > > > So, does this means that for a static route configuration > > > > where the next hop for the Mobile Network Prefix is the Mobile Router, > > > > the Home Agent should discard packets sent to the Mobile Network Prefix > > > > if it receives a BU from Mobile Router with R=0? Perhaps the response > > > > of the Home Agent in this case can be specified? > > > > > > even in static route configuartion, the HA must > > > consult the binding cache for the MR's current CoA. > > > if there is no binding cache entry, then the packets > > > are sent on link. if there is a binding cache entry > > > and the R bit set to 0, the HA must not forward the > > > packets. > > > > > > is this an acceptable solution? > > > > > Yes, it is. I just thought that this should be reflected in the draft. > > okay. I am changing the following > > The Mobile Router Flag is set to indicate to the Home Agent > that the Binding Update is from a Mobile Router. If the flag > is set to 0, the Home Agent assumes that the Mobile Router is > just behaving as a Mobile Node, and should not forward packets > destined for the mobile network to the Mobile Router. > > to > > The Mobile Router Flag is set to indicate to the Home Agent > that the Binding Update is from a Mobile Router. If the flag > is set to 0, the Home Agent assumes that the Mobile Router is > just behaving as a Mobile Node, and MUST NOT forward packets > destined for the mobile network to the Mobile Router. > > MUST NOT should make it clear that if the R flag is set > to 0, the HA does not forward packets meant for the > mobile network to the mobile router under all > circumstances. > Looks okay to me. > > > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > yes. you are right. the HA should store the prefixes > > > that was sent in the Binding Update. it needs this list > > > of prefixes later on to delete all the routes, if the > > > binding cache entry expires. I will add some text. > > > > > OK. > > here is some text (to be added to Section 6.1) > > The Home Agent SHOULD store the list of Mobile Network Prefixes owned > by a Mobile Router in the corresponding Binding Cache entry. This > list of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current Care-of > address. This information is later used to delete the routes when > the Binding Cache entry for the Mobile Router is deleted. > Sounds ok to me ... just one thing, perhaps the last sentence might be changed to "This information can be later used ..." to suggest that this is more of an implementation issue? Just a suggestion, the original sentence is also alright to me. > The Home Agent also stores the status of the Mobile Router Flag 'R' > in the Binding Cache entry. > > > > > > > > Nothing is mentioned in the operation of Mobile Router about checks on > > > > received tunnelled packets from Home Agent. Shouldn't the Mobile Router > > > > verify that the inner packet has a destination address that is within > > > > its Mobile Network Prefix? > > > > > > it should perform all the necessary checks when > > > decapsulating and forwarding packets. we will add some > > > text. > > > > > OK > > here is some text. in section 3. > > after > > The Mobile Router > decapsulates the packet and forwards it onto the link where the > Mobile Network is connected. > > add > > The Mobile Router before decapsulating > the tunneled packet, has to check if the Source address on the outer > IPv6 header is the Home Agent's address. It also has to make sure > the destination address on the inner IPv6 header belongs to one of > its Mobile Network Prefixes before forwarding the packet to the > Mobile Network. > Sounds good. Thanks for the effort. /cwng From nemo-admin@ietf.org Sun Jul 13 12:31:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29804 for ; Sun, 13 Jul 2003 12:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjkb-00054g-Qt; Sun, 13 Jul 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjk0-00054E-Sr for nemo@optimus.ietf.org; Sun, 13 Jul 2003 12:30:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29783 for ; Sun, 13 Jul 2003 12:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bjjy-0006Eo-00 for nemo@ietf.org; Sun, 13 Jul 2003 12:30:22 -0400 Received: from [81.160.96.161] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19bjjy-0006El-00 for nemo@ietf.org; Sun, 13 Jul 2003 12:30:22 -0400 Received: by squirrel (Postfix, from userid 1000) id 45FE71264FF4; Mon, 14 Jul 2003 01:30:43 +0800 (SGT) Subject: Re: [nemo] multi-homing scenarios From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG , Julien Charbon , Thierry Ernst In-Reply-To: <3F0F589E.5C231938@iprg.nokia.com> References: <3F0F589E.5C231938@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058117441.5047.12.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 14 Jul 2003 01:30:42 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Vijay, On Sat, 2003-07-12 at 08:38, Vijay Devarapalli wrote: > I read draft-ng-nemo-multihoming-issues-01. a very > useful draft. I have some comments on some of the > scenarios. > Thanks you for your comments and insights. > > > 2.2.3 (0,1,0): Single MR, Multiple HAs, Single Prefix > > > > The (0,1,0) mobile network has only one mobile router advertising a > > single subnet prefix. The mobile router, however, associates to > > multiple home agents, possibly one home agent per home addresses. No > > assumption is made on whether or not the home agents belongs to the > > same administrative domain. > > > > > > AR HA2 > > _ | > > |-|_|-| _ > > _____ | |-|_| > > _ p _ | |-| > > |_|-|<-_ |-|_|-| | > > _ |-|_|=| |_____|-| _ > > |_|-| | | _ |-|_| > > |-|_|-| > > | > > MNNs MR AR Internet AR HA1 > > both HA1 and HA2 start advertising reachability for > the prefix 'p'. this might be okay if both belong to > the same administrative domain. the HA1 and HA2 MUST > NOT belong to different administrative domains. I > think this restriction is necessary. I am a bit confused here. You first say its okay if HA1 and HA2 belong to same administration domain. But immediately after that, you say they MUST NOT belong to the same administration domain. Which do you mean now? > > later in Section 4 you say > > > The case of multiple home agents at different domains > > advertising a route to the same subnet prefix may pose a problem > > in the routing infrastructure as a whole. The implications of > > this aspect needs further exploration. > > this is a serious problem and should be avoided. IMO, > there is no further exploration needed. :) > I was actually hoping we come to this conclusion. > > > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > > > The (0,1,1) mobile network has only one mobile router. However, the > > mobile router advertises more than one subnet prefix, and also > > associates to multiple home agents at the same time, possibly one > > home agent per home address. No assumptions is made on whether or > > not the home agents belongs to the same administrative domain. > > > > > > AR HA2 > > _ | > > |-|_|-| _ > > _____ | |-|_| > > _ p1,p2 _ | |-| > > |_|-|<-_ |-|_|-| | > > _ |-|_|=| |_____|-| _ > > |_|-| | | _ |-|_| > > |-|_|-| > > | > > MNNs MR AR Internet AR HA1 > > if HA1 advertises P1 and HA2 advertises P2, it makes > this very simple. so why dont we place such a > restriction? we dont lose any functionality with this > restriction. > It is a good simplifying requirement. > > > 2.2.5 (1,0,0): Multiple MRs, Single HA, Single Prefix > > > > The (1,0,0) mobile network has more than one mobile router > > advertising global routes. These mobile routers, however, advertise > > the same subnet prefix and associate to the same home agent. Since > > only one subnet prefix is advertised, the mobile network nodes are > > (usually) not multi-homed. > > > > MR2 > > > > p > > <-_ | > > _ |-|_|-| _____ > > |_|-| |-| | > > _ | | |-| _ > > |_|-| _ |-|_____| | _ |-|_| > > |-|_|-| |-|_|-| > > <- | | > > p > > > > MNNs MR1 Internet AR HA > > so where does the HA forward packets meant for the > prefix 'p'? to MR1 or MR2? if the HA uses the routing > table for forwarding packets for P, it clearly cant > have two routing entries. > Why not? AFAIK, it is perfectly legal for routers to contain two routes to the same destination. The metrics will take priority, and if the metrics are identical, its up to implementation. > > > 2.2.6 (1,0,1): Multiple MRs, Single HA, Multiple Prefixes > > for this why dont we place a restriction that MR1 and > MR2 should register P1 and P2, respectively, with the > single Home Agent? this would make it simple. > > > > 2.2.7 (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > again, I think the HAs MUST belong to the same > administrative domain if there is only one Mobile > Network Prefix. > > > > From the above analysis, we can identify the following problems > > relating to multi-homed mobile network: > > > > o Multiple care-of-addresses to one home-address: > > the answer is standardize > draft-wakikawa-mobileip-multiplecoa-00.txt > I agree. But I must analyze this more carefully when we couple multiple CoAs and multiple MNPs. > > > o Multiple prefixes taken care of by a single home-address: > > what is the issue here? you can send multiple prefixes > in the same binding update using the Mobile Network > Prefix option in draft-ietf-nemo-basic-support-00.txt. > the prefixes can be of different prefix lengths. > Yep, but the multihoming draft is published (or at least written) before I rea dthe basic draft ... ;) > > > o A single home-address registered to multiple home agents: > > > > * Is this allowed? > > should be disallowed. > > > > o A single subnet prefix registered to multiple home agents: > > > > * Is this allowed? > > only if both Home Agents belong to the same domain. > > I hope all this gets discussed on Wednesday. :) > I will try my best to make it so. /rgds /cwng From exim@www1.ietf.org Sun Jul 13 12:31:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29819 for ; Sun, 13 Jul 2003 12:31:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjkf-00055i-N4 for nemo-archive@odin.ietf.org; Sun, 13 Jul 2003 12:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DGV5n4019564 for nemo-archive@odin.ietf.org; Sun, 13 Jul 2003 12:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjkf-00055T-J0 for nemo-web-archive@optimus.ietf.org; Sun, 13 Jul 2003 12:31:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29792 for ; Sun, 13 Jul 2003 12:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bjkd-0006Eu-00 for nemo-web-archive@ietf.org; Sun, 13 Jul 2003 12:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bjkd-0006Er-00 for nemo-web-archive@ietf.org; Sun, 13 Jul 2003 12:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjkb-00054g-Qt; Sun, 13 Jul 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bjk0-00054E-Sr for nemo@optimus.ietf.org; Sun, 13 Jul 2003 12:30:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29783 for ; Sun, 13 Jul 2003 12:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bjjy-0006Eo-00 for nemo@ietf.org; Sun, 13 Jul 2003 12:30:22 -0400 Received: from [81.160.96.161] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19bjjy-0006El-00 for nemo@ietf.org; Sun, 13 Jul 2003 12:30:22 -0400 Received: by squirrel (Postfix, from userid 1000) id 45FE71264FF4; Mon, 14 Jul 2003 01:30:43 +0800 (SGT) Subject: Re: [nemo] multi-homing scenarios From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG , Julien Charbon , Thierry Ernst In-Reply-To: <3F0F589E.5C231938@iprg.nokia.com> References: <3F0F589E.5C231938@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058117441.5047.12.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 14 Jul 2003 01:30:42 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Vijay, On Sat, 2003-07-12 at 08:38, Vijay Devarapalli wrote: > I read draft-ng-nemo-multihoming-issues-01. a very > useful draft. I have some comments on some of the > scenarios. > Thanks you for your comments and insights. > > > 2.2.3 (0,1,0): Single MR, Multiple HAs, Single Prefix > > > > The (0,1,0) mobile network has only one mobile router advertising a > > single subnet prefix. The mobile router, however, associates to > > multiple home agents, possibly one home agent per home addresses. No > > assumption is made on whether or not the home agents belongs to the > > same administrative domain. > > > > > > AR HA2 > > _ | > > |-|_|-| _ > > _____ | |-|_| > > _ p _ | |-| > > |_|-|<-_ |-|_|-| | > > _ |-|_|=| |_____|-| _ > > |_|-| | | _ |-|_| > > |-|_|-| > > | > > MNNs MR AR Internet AR HA1 > > both HA1 and HA2 start advertising reachability for > the prefix 'p'. this might be okay if both belong to > the same administrative domain. the HA1 and HA2 MUST > NOT belong to different administrative domains. I > think this restriction is necessary. I am a bit confused here. You first say its okay if HA1 and HA2 belong to same administration domain. But immediately after that, you say they MUST NOT belong to the same administration domain. Which do you mean now? > > later in Section 4 you say > > > The case of multiple home agents at different domains > > advertising a route to the same subnet prefix may pose a problem > > in the routing infrastructure as a whole. The implications of > > this aspect needs further exploration. > > this is a serious problem and should be avoided. IMO, > there is no further exploration needed. :) > I was actually hoping we come to this conclusion. > > > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > > > The (0,1,1) mobile network has only one mobile router. However, the > > mobile router advertises more than one subnet prefix, and also > > associates to multiple home agents at the same time, possibly one > > home agent per home address. No assumptions is made on whether or > > not the home agents belongs to the same administrative domain. > > > > > > AR HA2 > > _ | > > |-|_|-| _ > > _____ | |-|_| > > _ p1,p2 _ | |-| > > |_|-|<-_ |-|_|-| | > > _ |-|_|=| |_____|-| _ > > |_|-| | | _ |-|_| > > |-|_|-| > > | > > MNNs MR AR Internet AR HA1 > > if HA1 advertises P1 and HA2 advertises P2, it makes > this very simple. so why dont we place such a > restriction? we dont lose any functionality with this > restriction. > It is a good simplifying requirement. > > > 2.2.5 (1,0,0): Multiple MRs, Single HA, Single Prefix > > > > The (1,0,0) mobile network has more than one mobile router > > advertising global routes. These mobile routers, however, advertise > > the same subnet prefix and associate to the same home agent. Since > > only one subnet prefix is advertised, the mobile network nodes are > > (usually) not multi-homed. > > > > MR2 > > > > p > > <-_ | > > _ |-|_|-| _____ > > |_|-| |-| | > > _ | | |-| _ > > |_|-| _ |-|_____| | _ |-|_| > > |-|_|-| |-|_|-| > > <- | | > > p > > > > MNNs MR1 Internet AR HA > > so where does the HA forward packets meant for the > prefix 'p'? to MR1 or MR2? if the HA uses the routing > table for forwarding packets for P, it clearly cant > have two routing entries. > Why not? AFAIK, it is perfectly legal for routers to contain two routes to the same destination. The metrics will take priority, and if the metrics are identical, its up to implementation. > > > 2.2.6 (1,0,1): Multiple MRs, Single HA, Multiple Prefixes > > for this why dont we place a restriction that MR1 and > MR2 should register P1 and P2, respectively, with the > single Home Agent? this would make it simple. > > > > 2.2.7 (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > again, I think the HAs MUST belong to the same > administrative domain if there is only one Mobile > Network Prefix. > > > > From the above analysis, we can identify the following problems > > relating to multi-homed mobile network: > > > > o Multiple care-of-addresses to one home-address: > > the answer is standardize > draft-wakikawa-mobileip-multiplecoa-00.txt > I agree. But I must analyze this more carefully when we couple multiple CoAs and multiple MNPs. > > > o Multiple prefixes taken care of by a single home-address: > > what is the issue here? you can send multiple prefixes > in the same binding update using the Mobile Network > Prefix option in draft-ietf-nemo-basic-support-00.txt. > the prefixes can be of different prefix lengths. > Yep, but the multihoming draft is published (or at least written) before I rea dthe basic draft ... ;) > > > o A single home-address registered to multiple home agents: > > > > * Is this allowed? > > should be disallowed. > > > > o A single subnet prefix registered to multiple home agents: > > > > * Is this allowed? > > only if both Home Agents belong to the same domain. > > I hope all this gets discussed on Wednesday. :) > I will try my best to make it so. /rgds /cwng From nemo-admin@ietf.org Mon Jul 14 03:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29818 for ; Mon, 14 Jul 2003 03:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxzA-0000nD-S7; Mon, 14 Jul 2003 03:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxyF-0000im-K7 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 03:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29767 for ; Mon, 14 Jul 2003 03:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxyD-0002M8-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:42:01 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19bxyC-0002Lz-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:42:00 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2003 09:41:34 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6E7dMpt024641; Mon, 14 Jul 2003 09:39:23 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Jul 2003 09:41:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Date: Mon, 14 Jul 2003 08:41:05 +0100 Message-ID: Thread-Topic: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Thread-Index: AcNH1BsRj3+0iQcLS6O/TznPH3uSBwCBr1xg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jongkeun Na" Cc: X-OriginalArrivalTime: 14 Jul 2003 07:41:06.0268 (UTC) FILETIME=[48B039C0:01C349DB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- >=20 > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT > create routes to the Mobile network when the Binding Update > from the Mobile Router is received. The Mobile Router also > MUST NOT include any prefix information in the Binding Update. > Any routes to the Mobile Network are created at the Home > Agent through routing protocol updates. Why should that be? We can configure routers to use different routing protocols at the same time. You need to state how routes are redistributed afterwards but this is business as usual. It is up the the HA config to accept it or not, but I do not see why Nemo should interfere with that. There's no need for the protocol operation to place such a limit. Do I miss something? Pascal From exim@www1.ietf.org Mon Jul 14 03:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29833 for ; Mon, 14 Jul 2003 03:43:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxzN-0000oW-ET for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 03:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E7hDL1003127 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 03:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxzN-0000oM-8E for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 03:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29807 for ; Mon, 14 Jul 2003 03:43:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxzK-0002Mh-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 03:43:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bxzK-0002Md-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 03:43:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxzA-0000nD-S7; Mon, 14 Jul 2003 03:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxyF-0000im-K7 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 03:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29767 for ; Mon, 14 Jul 2003 03:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxyD-0002M8-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:42:01 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19bxyC-0002Lz-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:42:00 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2003 09:41:34 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6E7dMpt024641; Mon, 14 Jul 2003 09:39:23 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Jul 2003 09:41:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Date: Mon, 14 Jul 2003 08:41:05 +0100 Message-ID: Thread-Topic: Issue 6 (was Re: [nemo] Re: The question about NEMO basic support) Thread-Index: AcNH1BsRj3+0iQcLS6O/TznPH3uSBwCBr1xg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jongkeun Na" Cc: X-OriginalArrivalTime: 14 Jul 2003 07:41:06.0268 (UTC) FILETIME=[48B039C0:01C349DB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- >=20 > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT > create routes to the Mobile network when the Binding Update > from the Mobile Router is received. The Mobile Router also > MUST NOT include any prefix information in the Binding Update. > Any routes to the Mobile Network are created at the Home > Agent through routing protocol updates. Why should that be? We can configure routers to use different routing protocols at the same time. You need to state how routes are redistributed afterwards but this is business as usual. It is up the the HA config to accept it or not, but I do not see why Nemo should interfere with that. There's no need for the protocol operation to place such a limit. Do I miss something? Pascal From nemo-admin@ietf.org Mon Jul 14 04:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00365 for ; Mon, 14 Jul 2003 04:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byFd-0001OC-Uu; Mon, 14 Jul 2003 04:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byF8-0001LL-Q0 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 03:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00309 for ; Mon, 14 Jul 2003 03:59:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byF6-0002Sh-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:59:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19byF5-0002SR-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:59:27 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2003 09:59:01 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6E7umY2028680; Mon, 14 Jul 2003 09:56:50 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Jul 2003 09:58:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) Date: Mon, 14 Jul 2003 08:58:49 +0100 Message-ID: Thread-Topic: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) Thread-Index: AcNH5ADf/Z1Hp5tvTEy87Kdt2tV4QQB933SA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: "IETF NEMO WG" X-OriginalArrivalTime: 14 Jul 2003 07:58:50.0493 (UTC) FILETIME=[C30412D0:01C349DD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > yes. you are right. the HA should store the prefixes > > > that was sent in the Binding Update. it needs this list > > > of prefixes later on to delete all the routes, if the > > > binding cache entry expires. I will add some text. > > > > > OK. >=20 > here is some text (to be added to Section 6.1) >=20 > The Home Agent SHOULD store the list of Mobile Network Prefixes owned > by a Mobile Router in the corresponding Binding Cache entry. This > list of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current Care-of > address. This information is later used to delete the routes when > the Binding Cache entry for the Mobile Router is deleted. >=20 > The Home Agent also stores the status of the Mobile Router Flag 'R' > in the Binding Cache entry. >=20 Vijay, can you please be less specific about the data in the BCE? Any handle to the route info is enough; it does not have to take the form of a list of prefixes. For instance it can be pointers to the prefix table. Also, In the case of real static routes, the HA does not install or clear them, so there's no need to keep them in BCE... > here is some text. in section 3. >=20 > after >=20 > The Mobile Router > decapsulates the packet and forwards it onto the link where the > Mobile Network is connected. >=20 > add >=20 > The Mobile Router before decapsulating > the tunneled packet, has to check if the Source address on the outer > IPv6 header is the Home Agent's address. It also has to make sure > the destination address on the inner IPv6 header belongs to one of > its Mobile Network Prefixes before forwarding the packet to the > Mobile Network. >=20 You sure can do that. Please note most of it is already there implicitly. By saying that a packet is received by a MR over the MRHA tunnel, you implicitly say that the outer source is the HA and the outer destination is the MR. The tunnel code has to check that at the time is affects the input interface to the packet. And since the MNet is a stub, any packet that is not for an MNP would be routed back over the tunnel. Which would cause the packet to be dropped by poison reverse... Pascal From exim@www1.ietf.org Mon Jul 14 04:00:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00381 for ; Mon, 14 Jul 2003 04:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byFi-0001PX-CD for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 04:00:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E806M4005415 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 04:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byFg-0001PB-DN for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 04:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00355 for ; Mon, 14 Jul 2003 04:00:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byFd-0002TI-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 04:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19byFd-0002TF-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 04:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byFd-0001OC-Uu; Mon, 14 Jul 2003 04:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byF8-0001LL-Q0 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 03:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00309 for ; Mon, 14 Jul 2003 03:59:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byF6-0002Sh-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:59:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19byF5-0002SR-00 for nemo@ietf.org; Mon, 14 Jul 2003 03:59:27 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2003 09:59:01 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6E7umY2028680; Mon, 14 Jul 2003 09:56:50 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Jul 2003 09:58:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) Date: Mon, 14 Jul 2003 08:58:49 +0100 Message-ID: Thread-Topic: Issue 3 (was Re: [nemo] Design Team draft for NEMO Basic Solution) Thread-Index: AcNH5ADf/Z1Hp5tvTEy87Kdt2tV4QQB933SA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: "IETF NEMO WG" X-OriginalArrivalTime: 14 Jul 2003 07:58:50.0493 (UTC) FILETIME=[C30412D0:01C349DD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > > > > > > Nothing is said about the Data Structure of the Home Agent. Shouldn't > > > > there be changes to the Binding Cache as well? > > > > > > yes. you are right. the HA should store the prefixes > > > that was sent in the Binding Update. it needs this list > > > of prefixes later on to delete all the routes, if the > > > binding cache entry expires. I will add some text. > > > > > OK. >=20 > here is some text (to be added to Section 6.1) >=20 > The Home Agent SHOULD store the list of Mobile Network Prefixes owned > by a Mobile Router in the corresponding Binding Cache entry. This > list of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current Care-of > address. This information is later used to delete the routes when > the Binding Cache entry for the Mobile Router is deleted. >=20 > The Home Agent also stores the status of the Mobile Router Flag 'R' > in the Binding Cache entry. >=20 Vijay, can you please be less specific about the data in the BCE? Any handle to the route info is enough; it does not have to take the form of a list of prefixes. For instance it can be pointers to the prefix table. Also, In the case of real static routes, the HA does not install or clear them, so there's no need to keep them in BCE... > here is some text. in section 3. >=20 > after >=20 > The Mobile Router > decapsulates the packet and forwards it onto the link where the > Mobile Network is connected. >=20 > add >=20 > The Mobile Router before decapsulating > the tunneled packet, has to check if the Source address on the outer > IPv6 header is the Home Agent's address. It also has to make sure > the destination address on the inner IPv6 header belongs to one of > its Mobile Network Prefixes before forwarding the packet to the > Mobile Network. >=20 You sure can do that. Please note most of it is already there implicitly. By saying that a packet is received by a MR over the MRHA tunnel, you implicitly say that the outer source is the HA and the outer destination is the MR. The tunnel code has to check that at the time is affects the input interface to the packet. And since the MNet is a stub, any packet that is not for an MNP would be routed back over the tunnel. Which would cause the packet to be dropped by poison reverse... Pascal From nemo-admin@ietf.org Mon Jul 14 05:17:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03292 for ; Mon, 14 Jul 2003 05:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzS9-0005IF-5R; Mon, 14 Jul 2003 05:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzRK-0005Hc-P2 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 05:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03250 for ; Mon, 14 Jul 2003 05:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzRH-0003Ce-00 for nemo@ietf.org; Mon, 14 Jul 2003 05:16:07 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19bzRG-0003C7-00 for nemo@ietf.org; Mon, 14 Jul 2003 05:16:06 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6E9FZpp025368; Mon, 14 Jul 2003 02:15:35 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-140.cisco.com [10.82.224.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ01927; Mon, 14 Jul 2003 05:15:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030714051152.0487e808@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jul 2003 05:15:30 -0400 To: Vijay Devarapalli From: Ralph Droms Cc: nemo@ietf.org In-Reply-To: <3F10ADC7.CDB3DE9C@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 05:54 PM 7/12/2003 -0700, Vijay Devarapalli wrote: >hi Ralph, > >thanks for the draft. a few comments > > > Other updates to the HA data structures > > required as a side effect of prefix delegation are specified by the > > particular network mobility protocol. For example, in the case of > > "Basic Network Mobility Support" [8], the HA would add an entry in > > its binding cache registering the delegated prefix to the MR to which > > the prefix was delegated. > >something is mixed up here. prefix delegation should work >indepedent of the binding cache entries for the mobile >routers. in the basic support NEMO draft the Home Agent >creates routes to the mobile network when it receives >a Binding Update from the mobile router. do you see a need >to store the delegated prefix in the binding cache entry? >this wont work because, the binding cache entry could >expire. the lifetime of the binding cache entry shouldnt >be related to the lifetime of the delegated prefix. I could well be confused as I'm relatively naive about the mobility and basic NEMO support drafts. The example I cited is apparently not a good one and there may be no examples of HA data structures that have to be updated based on delegation of prefixes... > > Following the DHCPv6 Prefix Delegation specification, HAs and MRs > > SHOULD use DHCPv6 authentication as described in section > > "Authentication of DHCP messages" of the DHCPv6 specification [6], to > > guard against attacks mounted through prefix delegation. > >I dont follow DCHPv6 work. I looked up the DHCPv6 spec. it >says the messages are authenticated using an authentication >option, while the actual distribution of keys is declared >out of scope. is there any work on distributing keys to the >DHCPv6 client, especially if the client never comes home. >this could be true in the case of NEMO. the mobile router >could be away from home all the time. how does one >distribute keys? manual keying? I am not saying manual keying >wont work, I just want to understand this better. Key distribution is not specified by the DHCPv6 spec and assumes manual keying is available. Suggestions for alternatives would be accepted gratefully... >Vijay From exim@www1.ietf.org Mon Jul 14 05:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03307 for ; Mon, 14 Jul 2003 05:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzSG-0005JP-Mo for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 05:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E9H8fY020414 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 05:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzSG-0005JB-Ig for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 05:17:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03275 for ; Mon, 14 Jul 2003 05:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzSD-0003DC-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 05:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bzSC-0003D9-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 05:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzS9-0005IF-5R; Mon, 14 Jul 2003 05:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzRK-0005Hc-P2 for nemo@optimus.ietf.org; Mon, 14 Jul 2003 05:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03250 for ; Mon, 14 Jul 2003 05:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzRH-0003Ce-00 for nemo@ietf.org; Mon, 14 Jul 2003 05:16:07 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19bzRG-0003C7-00 for nemo@ietf.org; Mon, 14 Jul 2003 05:16:06 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6E9FZpp025368; Mon, 14 Jul 2003 02:15:35 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-140.cisco.com [10.82.224.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAQ01927; Mon, 14 Jul 2003 05:15:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030714051152.0487e808@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jul 2003 05:15:30 -0400 To: Vijay Devarapalli From: Ralph Droms Cc: nemo@ietf.org In-Reply-To: <3F10ADC7.CDB3DE9C@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 05:54 PM 7/12/2003 -0700, Vijay Devarapalli wrote: >hi Ralph, > >thanks for the draft. a few comments > > > Other updates to the HA data structures > > required as a side effect of prefix delegation are specified by the > > particular network mobility protocol. For example, in the case of > > "Basic Network Mobility Support" [8], the HA would add an entry in > > its binding cache registering the delegated prefix to the MR to which > > the prefix was delegated. > >something is mixed up here. prefix delegation should work >indepedent of the binding cache entries for the mobile >routers. in the basic support NEMO draft the Home Agent >creates routes to the mobile network when it receives >a Binding Update from the mobile router. do you see a need >to store the delegated prefix in the binding cache entry? >this wont work because, the binding cache entry could >expire. the lifetime of the binding cache entry shouldnt >be related to the lifetime of the delegated prefix. I could well be confused as I'm relatively naive about the mobility and basic NEMO support drafts. The example I cited is apparently not a good one and there may be no examples of HA data structures that have to be updated based on delegation of prefixes... > > Following the DHCPv6 Prefix Delegation specification, HAs and MRs > > SHOULD use DHCPv6 authentication as described in section > > "Authentication of DHCP messages" of the DHCPv6 specification [6], to > > guard against attacks mounted through prefix delegation. > >I dont follow DCHPv6 work. I looked up the DHCPv6 spec. it >says the messages are authenticated using an authentication >option, while the actual distribution of keys is declared >out of scope. is there any work on distributing keys to the >DHCPv6 client, especially if the client never comes home. >this could be true in the case of NEMO. the mobile router >could be away from home all the time. how does one >distribute keys? manual keying? I am not saying manual keying >wont work, I just want to understand this better. Key distribution is not specified by the DHCPv6 spec and assumes manual keying is available. Suggestions for alternatives would be accepted gratefully... >Vijay From nemo-admin@ietf.org Mon Jul 14 07:23:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10070 for ; Mon, 14 Jul 2003 07:23:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1Q5-0007Sm-CR; Mon, 14 Jul 2003 07:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1PE-0007Pw-LU for nemo@optimus.ietf.org; Mon, 14 Jul 2003 07:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09906 for ; Mon, 14 Jul 2003 07:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1PD-00054k-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:22:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19c1PC-00053b-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:22:07 -0400 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 925425D0A4; Mon, 14 Jul 2003 20:21:32 +0900 (JST) Date: Mon, 14 Jul 2003 20:18:40 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tj@kniveton.com Message-Id: <20030714201840.1b1e74f6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO agenda for Wednesday Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, A bit late, but here is the agenda for Wednesday. # NEMO WG Draft Agenda 57th IETF, July 2003, Wien, Austria Chairs: Thierry Ernst T.J. Kniveton # Must Read List for this meeting: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt (missed cut-off date) http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt Other drafts advertised on the NEMO ML (not in today's agenda): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ draft-droms-nemo-dhcpv6-pd-00.txt draft-hkang-nemo-ro-tlmr-00.txt draft-jeong-nemo-ro-ndproxy-00.txt draft-leekj-nemo-ro-pd-00.txt draft-lach-nemo-experiments-overdrive-00.txt draft-ohta-multihomed-isps-00.txt draft-park-mobileip-wifi-handover-00.txt draft-thubert-nemo-ipv4-traversal-01.txt o Agenda Bashing .............................................5 mins Chairs o NEMO status and milestones .................................5 mins Chairs o NEMO Basic Support ........................................30 mins draft-ietf-nemo-basic-support-00.txt Report from the design team and left issues Ryuji Wakikawa o IPR Status.................................................10 mins TJ Kniveton o Multihoming ...............................................20 mins draft-ng-nemo-multihoming-issues-01.txt draft-charbon-nemo-multihoming-evaluation-00.txt - what scenarios must be supported in Basic - issues with NEMO Basic Support - how are we going to proceed o Threat Analysis Discussion ............................... 15 mins draft-jung-nemo-threat-analysis-00.txt - what are the potential threats - how are we going to proceed o Terminology and Requirements Updates.......................15 mins draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt Thierry Ernst o Conclusion and next steps.................................. 5 mins NEMO Chairs. From exim@www1.ietf.org Mon Jul 14 07:23:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10085 for ; Mon, 14 Jul 2003 07:23:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1QG-0007U0-7D for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 07:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EBNCmp028764 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 07:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1QG-0007Tr-41 for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 07:23:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10030 for ; Mon, 14 Jul 2003 07:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1QC-00056p-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 07:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c1QB-00056j-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 07:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1Q5-0007Sm-CR; Mon, 14 Jul 2003 07:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1PE-0007Pw-LU for nemo@optimus.ietf.org; Mon, 14 Jul 2003 07:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09906 for ; Mon, 14 Jul 2003 07:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1PD-00054k-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:22:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19c1PC-00053b-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:22:07 -0400 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 925425D0A4; Mon, 14 Jul 2003 20:21:32 +0900 (JST) Date: Mon, 14 Jul 2003 20:18:40 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tj@kniveton.com Message-Id: <20030714201840.1b1e74f6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO agenda for Wednesday Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, A bit late, but here is the agenda for Wednesday. # NEMO WG Draft Agenda 57th IETF, July 2003, Wien, Austria Chairs: Thierry Ernst T.J. Kniveton # Must Read List for this meeting: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-00.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-00.txt http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt (missed cut-off date) http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-00.txt Other drafts advertised on the NEMO ML (not in today's agenda): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ draft-droms-nemo-dhcpv6-pd-00.txt draft-hkang-nemo-ro-tlmr-00.txt draft-jeong-nemo-ro-ndproxy-00.txt draft-leekj-nemo-ro-pd-00.txt draft-lach-nemo-experiments-overdrive-00.txt draft-ohta-multihomed-isps-00.txt draft-park-mobileip-wifi-handover-00.txt draft-thubert-nemo-ipv4-traversal-01.txt o Agenda Bashing .............................................5 mins Chairs o NEMO status and milestones .................................5 mins Chairs o NEMO Basic Support ........................................30 mins draft-ietf-nemo-basic-support-00.txt Report from the design team and left issues Ryuji Wakikawa o IPR Status.................................................10 mins TJ Kniveton o Multihoming ...............................................20 mins draft-ng-nemo-multihoming-issues-01.txt draft-charbon-nemo-multihoming-evaluation-00.txt - what scenarios must be supported in Basic - issues with NEMO Basic Support - how are we going to proceed o Threat Analysis Discussion ............................... 15 mins draft-jung-nemo-threat-analysis-00.txt - what are the potential threats - how are we going to proceed o Terminology and Requirements Updates.......................15 mins draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt Thierry Ernst o Conclusion and next steps.................................. 5 mins NEMO Chairs. From nemo-admin@ietf.org Mon Jul 14 07:58:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13290 for ; Mon, 14 Jul 2003 07:58:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1xx-0000ZG-2k; Mon, 14 Jul 2003 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1xc-0000Yz-WC for nemo@optimus.ietf.org; Mon, 14 Jul 2003 07:57:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13177 for ; Mon, 14 Jul 2003 07:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1xb-0005wz-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:57:39 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19c1xb-0005wA-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:57:39 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8721B689C7 for ; Mon, 14 Jul 2003 07:57:04 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h6EBv3Lc025283; Mon, 14 Jul 2003 07:57:03 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp130.grc.nasa.gov [139.88.245.130]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h6EBuxYM002370; Mon, 14 Jul 2003 07:57:01 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030714074813.01edb968@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 14 Jul 2003 07:56:10 -0400 To: Soohong Daniel Park From: William D Ivancic Subject: Re: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Cc: nemo@ietf.org In-Reply-To: <000601c3473b$c9151330$b7cbdba8@daniel7209> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >Abstract : >In this draft, we describe a new mobility framework to extend 802.11 >[WLAN] to seamlessly manage roaming into GPRS access network, >whenever the mobile node is out of range from any 802.11 domain. >http://www.ietf.org/internet-drafts/draft-park-mobileip-wifi-handover-00 >.txt > > >Please let me know your view on this with feedback and comment... > >Regards > >Daniel (Soohong Daniel Park) Daniel, I read the draft rather quickly, but have two comments that should be considered. 1) The draft appears to assume that the 802.11 network will be a home domain. I believe this is not general enough. There are many 802.11 system appearing throughout the world that will be outside the mobile's home domain. 2) My limited experience with GPRS in the US is with IPv4 and T-Mobile. We are currently trying to work with T-Mobile to figure out how their NATing scheme is effecting mobile router operation. In theory, in IPv6, NATs will no longer be a problem, but don't count on it. I think we ALL need to work with service providers to educate them on the nastiness of NATing in that some of the problems NATing solves can be done using other mechanisms. Anyway, I suggest working with some GPRS service providers regarding use of GPRS in mobile networks. I believe both parties will learn from such a relationship. Will From exim@www1.ietf.org Mon Jul 14 07:58:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13308 for ; Mon, 14 Jul 2003 07:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1y6-0000bH-0P for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 07:58:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EBw9vs002306 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 07:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1y5-0000b7-O1 for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 07:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13236 for ; Mon, 14 Jul 2003 07:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1y4-0005xm-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 07:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c1y4-0005xj-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 07:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1xx-0000ZG-2k; Mon, 14 Jul 2003 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1xc-0000Yz-WC for nemo@optimus.ietf.org; Mon, 14 Jul 2003 07:57:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13177 for ; Mon, 14 Jul 2003 07:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c1xb-0005wz-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:57:39 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19c1xb-0005wA-00 for nemo@ietf.org; Mon, 14 Jul 2003 07:57:39 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8721B689C7 for ; Mon, 14 Jul 2003 07:57:04 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h6EBv3Lc025283; Mon, 14 Jul 2003 07:57:03 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp130.grc.nasa.gov [139.88.245.130]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h6EBuxYM002370; Mon, 14 Jul 2003 07:57:01 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030714074813.01edb968@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 14 Jul 2003 07:56:10 -0400 To: Soohong Daniel Park From: William D Ivancic Subject: Re: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Cc: nemo@ietf.org In-Reply-To: <000601c3473b$c9151330$b7cbdba8@daniel7209> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > >Abstract : >In this draft, we describe a new mobility framework to extend 802.11 >[WLAN] to seamlessly manage roaming into GPRS access network, >whenever the mobile node is out of range from any 802.11 domain. >http://www.ietf.org/internet-drafts/draft-park-mobileip-wifi-handover-00 >.txt > > >Please let me know your view on this with feedback and comment... > >Regards > >Daniel (Soohong Daniel Park) Daniel, I read the draft rather quickly, but have two comments that should be considered. 1) The draft appears to assume that the 802.11 network will be a home domain. I believe this is not general enough. There are many 802.11 system appearing throughout the world that will be outside the mobile's home domain. 2) My limited experience with GPRS in the US is with IPv4 and T-Mobile. We are currently trying to work with T-Mobile to figure out how their NATing scheme is effecting mobile router operation. In theory, in IPv6, NATs will no longer be a problem, but don't count on it. I think we ALL need to work with service providers to educate them on the nastiness of NATing in that some of the problems NATing solves can be done using other mechanisms. Anyway, I suggest working with some GPRS service providers regarding use of GPRS in mobile networks. I believe both parties will learn from such a relationship. Will From nemo-admin@ietf.org Mon Jul 14 13:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06207 for ; Mon, 14 Jul 2003 13:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xd-0002kW-EI; Mon, 14 Jul 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xa-0002kF-Id for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:17:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06174 for ; Mon, 14 Jul 2003 13:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6xY-0003QO-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:17:56 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c6xX-0003QG-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:17:55 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA02926; Mon, 14 Jul 2003 10:17:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHHMM13876; Mon, 14 Jul 2003 10:17:22 -0700 X-mProtect: <200307141717> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWLCZnU; Mon, 14 Jul 2003 10:17:20 PDT Message-ID: <3F12E5A1.1E15FFD8@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:17:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > The Home Agent SHOULD store the list of Mobile Network Prefixes > owned > > by a Mobile Router in the corresponding Binding Cache entry. This > > list of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > Care-of > > address. This information is later used to delete the routes when > > the Binding Cache entry for the Mobile Router is deleted. > > > > The Home Agent also stores the status of the Mobile Router Flag 'R' > > in the Binding Cache entry. > > > > Vijay, can you please be less specific about the data in the BCE? Any > handle to the route info is enough; it does not have to take the form of > a list of prefixes. For instance it can be pointers to the prefix table. > Also, In the case of real static routes, the HA does not install or > clear them, so there's no need to keep them in BCE... Pascal, there was some confusion regarding storing prefixes in the Binding Cache entry. there were a lot of mails on this. it is better to make it explicit. there are other issues too. Prefix Table itself is an optional data structure. Prefix Table contains the list of all prefixes owned by a particular mobile router, whereas the Binding Cache entry will only contain those prefixes for which routes have been created. anyway, I made some changes so that this is done only when the mobile router had included prefix information in the Binding Update. heres the new text. The Home Agent SHOULD store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information can later be used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. is this okay? Vijay From exim@www1.ietf.org Mon Jul 14 13:18:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06222 for ; Mon, 14 Jul 2003 13:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xk-0002la-57 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHI87X010628 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xj-0002lL-Vn for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Mon, 14 Jul 2003 13:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6xh-0003Qa-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c6xg-0003QX-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xd-0002kW-EI; Mon, 14 Jul 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c6xa-0002kF-Id for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:17:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06174 for ; Mon, 14 Jul 2003 13:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c6xY-0003QO-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:17:56 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c6xX-0003QG-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:17:55 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA02926; Mon, 14 Jul 2003 10:17:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHHMM13876; Mon, 14 Jul 2003 10:17:22 -0700 X-mProtect: <200307141717> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWLCZnU; Mon, 14 Jul 2003 10:17:20 PDT Message-ID: <3F12E5A1.1E15FFD8@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:17:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The Home Agent SHOULD store the list of Mobile Network Prefixes > owned > > by a Mobile Router in the corresponding Binding Cache entry. This > > list of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > Care-of > > address. This information is later used to delete the routes when > > the Binding Cache entry for the Mobile Router is deleted. > > > > The Home Agent also stores the status of the Mobile Router Flag 'R' > > in the Binding Cache entry. > > > > Vijay, can you please be less specific about the data in the BCE? Any > handle to the route info is enough; it does not have to take the form of > a list of prefixes. For instance it can be pointers to the prefix table. > Also, In the case of real static routes, the HA does not install or > clear them, so there's no need to keep them in BCE... Pascal, there was some confusion regarding storing prefixes in the Binding Cache entry. there were a lot of mails on this. it is better to make it explicit. there are other issues too. Prefix Table itself is an optional data structure. Prefix Table contains the list of all prefixes owned by a particular mobile router, whereas the Binding Cache entry will only contain those prefixes for which routes have been created. anyway, I made some changes so that this is done only when the mobile router had included prefix information in the Binding Update. heres the new text. The Home Agent SHOULD store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information can later be used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. is this okay? Vijay From nemo-admin@ietf.org Mon Jul 14 13:42:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07714 for ; Mon, 14 Jul 2003 13:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Kr-0004NR-SM; Mon, 14 Jul 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7KV-0004Mp-TM for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:41:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07665 for ; Mon, 14 Jul 2003 13:41:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7KT-0003oE-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:41:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7KS-0003nq-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:41:37 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03669; Mon, 14 Jul 2003 10:41:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHeuo30225; Mon, 14 Jul 2003 10:40:56 -0700 X-mProtect: <200307141740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFQ8W01; Mon, 14 Jul 2003 10:40:54 PDT Message-ID: <3F12EB27.987DD12E@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:40:55 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: cwng@psl.com.sg CC: nemo@ietf.org, julien@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp Subject: Re: [nemo] multi-homing scenarios Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > both HA1 and HA2 start advertising reachability for > > the prefix 'p'. this might be okay if both belong to > > the same administrative domain. the HA1 and HA2 MUST > > NOT belong to different administrative domains. I > > think this restriction is necessary. > > I am a bit confused here. You first say its okay if HA1 and HA2 belong > to same administration domain. But immediately after that, you say they > MUST NOT belong to the same administration domain. Which do you mean > now? read again. :) I said HA1 and HA2 MUST NOT belong to different administrative domains. > > later in Section 4 you say > > > > > The case of multiple home agents at different domains > > > advertising a route to the same subnet prefix may pose a problem > > > in the routing infrastructure as a whole. The implications of > > > this aspect needs further exploration. > > > > this is a serious problem and should be avoided. IMO, > > there is no further exploration needed. :) > > > I was actually hoping we come to this conclusion. good. > > > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > if HA1 advertises P1 and HA2 advertises P2, it makes > > this very simple. so why dont we place such a > > restriction? we dont lose any functionality with this > > restriction. > > > > It is a good simplifying requirement. great. hope you add this to the next version of your draft. > > Why not? AFAIK, it is perfectly legal for routers to contain two routes > to the same destination. The metrics will take priority, and if the > metrics are identical, its up to implementation. hmmm... I guess you are right. Vijay From exim@www1.ietf.org Mon Jul 14 13:42:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07729 for ; Mon, 14 Jul 2003 13:42:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Kw-0004PX-Du for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHg6FJ016949 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Kw-0004PI-AB for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07700 for ; Mon, 14 Jul 2003 13:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Ku-0003oa-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:42:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7Kt-0003oX-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Kr-0004NR-SM; Mon, 14 Jul 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7KV-0004Mp-TM for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:41:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07665 for ; Mon, 14 Jul 2003 13:41:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7KT-0003oE-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:41:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7KS-0003nq-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:41:37 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03669; Mon, 14 Jul 2003 10:41:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHeuo30225; Mon, 14 Jul 2003 10:40:56 -0700 X-mProtect: <200307141740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFQ8W01; Mon, 14 Jul 2003 10:40:54 PDT Message-ID: <3F12EB27.987DD12E@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:40:55 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: cwng@psl.com.sg CC: nemo@ietf.org, julien@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp Subject: Re: [nemo] multi-homing scenarios Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > both HA1 and HA2 start advertising reachability for > > the prefix 'p'. this might be okay if both belong to > > the same administrative domain. the HA1 and HA2 MUST > > NOT belong to different administrative domains. I > > think this restriction is necessary. > > I am a bit confused here. You first say its okay if HA1 and HA2 belong > to same administration domain. But immediately after that, you say they > MUST NOT belong to the same administration domain. Which do you mean > now? read again. :) I said HA1 and HA2 MUST NOT belong to different administrative domains. > > later in Section 4 you say > > > > > The case of multiple home agents at different domains > > > advertising a route to the same subnet prefix may pose a problem > > > in the routing infrastructure as a whole. The implications of > > > this aspect needs further exploration. > > > > this is a serious problem and should be avoided. IMO, > > there is no further exploration needed. :) > > > I was actually hoping we come to this conclusion. good. > > > 2.2.4 (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > if HA1 advertises P1 and HA2 advertises P2, it makes > > this very simple. so why dont we place such a > > restriction? we dont lose any functionality with this > > restriction. > > > > It is a good simplifying requirement. great. hope you add this to the next version of your draft. > > Why not? AFAIK, it is perfectly legal for routers to contain two routes > to the same destination. The metrics will take priority, and if the > metrics are identical, its up to implementation. hmmm... I guess you are right. Vijay From nemo-admin@ietf.org Mon Jul 14 13:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08301 for ; Mon, 14 Jul 2003 13:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Rc-0004q4-QG; Mon, 14 Jul 2003 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Qz-0004pb-7Q for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:48:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08184 for ; Mon, 14 Jul 2003 13:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Qx-0003x9-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:48:19 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7Qv-0003vu-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:48:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04007; Mon, 14 Jul 2003 10:47:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHlg501895; Mon, 14 Jul 2003 10:47:42 -0700 X-mProtect: <200307141747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbsysvP; Mon, 14 Jul 2003 10:47:40 PDT Message-ID: <3F12ECBD.4852B5FB@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:47:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Pascal, > > -----Original Message----- > > > > When the Mobile Router and the Home Agent exchange routes > > through routing protocol updates, the Home Agent MUST NOT > > create routes to the Mobile network when the Binding Update > > from the Mobile Router is received. The Mobile Router also > > MUST NOT include any prefix information in the Binding Update. > > Any routes to the Mobile Network are created at the Home > > Agent through routing protocol updates. > > Why should that be? We can configure routers to use different routing > protocols at the same time. You need to state how routes are > redistributed afterwards but this is business as usual. I agree with you here. > It is up the the > HA config to accept it or not, isnt it redundant to include prefix information in the binding update if routes are being exchanged through a dynamic routing protocol? > but I do not see why Nemo should > interfere with that. because NEMO is the one specifying including prefix information in the Binding Update. and the NEMO protocol includes HA creating routes based on this prefix information. we are specifying a protocol operation here. > There's no need for the protocol operation to place > such a limit. Do I miss something? well, you want the protocol to be efficient, right? when a dynamic routing protocol is being used, including prefix information in the binding update is both redundant and involves an overhead in terms of the size of binding udpate. Vijay From exim@www1.ietf.org Mon Jul 14 13:49:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08358 for ; Mon, 14 Jul 2003 13:49:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Rr-0004uL-1P for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:49:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHnFbt018861 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Rq-0004u8-TY for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:49:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08281 for ; Mon, 14 Jul 2003 13:49:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Rc-0003yc-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:49:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7Rc-0003yZ-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Rc-0004q4-QG; Mon, 14 Jul 2003 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Qz-0004pb-7Q for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:48:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08184 for ; Mon, 14 Jul 2003 13:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Qx-0003x9-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:48:19 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7Qv-0003vu-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:48:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04007; Mon, 14 Jul 2003 10:47:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHlg501895; Mon, 14 Jul 2003 10:47:42 -0700 X-mProtect: <200307141747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbsysvP; Mon, 14 Jul 2003 10:47:40 PDT Message-ID: <3F12ECBD.4852B5FB@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:47:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Pascal, > > -----Original Message----- > > > > When the Mobile Router and the Home Agent exchange routes > > through routing protocol updates, the Home Agent MUST NOT > > create routes to the Mobile network when the Binding Update > > from the Mobile Router is received. The Mobile Router also > > MUST NOT include any prefix information in the Binding Update. > > Any routes to the Mobile Network are created at the Home > > Agent through routing protocol updates. > > Why should that be? We can configure routers to use different routing > protocols at the same time. You need to state how routes are > redistributed afterwards but this is business as usual. I agree with you here. > It is up the the > HA config to accept it or not, isnt it redundant to include prefix information in the binding update if routes are being exchanged through a dynamic routing protocol? > but I do not see why Nemo should > interfere with that. because NEMO is the one specifying including prefix information in the Binding Update. and the NEMO protocol includes HA creating routes based on this prefix information. we are specifying a protocol operation here. > There's no need for the protocol operation to place > such a limit. Do I miss something? well, you want the protocol to be efficient, right? when a dynamic routing protocol is being used, including prefix information in the binding update is both redundant and involves an overhead in terms of the size of binding udpate. Vijay From nemo-admin@ietf.org Mon Jul 14 13:57:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09097 for ; Mon, 14 Jul 2003 13:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7ZO-0005Ng-2j; Mon, 14 Jul 2003 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Yq-0005Mz-5D for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:56:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09058 for ; Mon, 14 Jul 2003 13:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Yn-0004AM-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:56:25 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7Ym-00049r-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:56:24 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04191; Mon, 14 Jul 2003 10:55:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHtnM06599; Mon, 14 Jul 2003 10:55:49 -0700 X-mProtect: <200307141755> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdix8hRX; Mon, 14 Jul 2003 10:55:47 PDT Message-ID: <3F12EEA4.426A20C0@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:55:48 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rdroms@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > At 05:54 PM 7/12/2003 -0700, Vijay Devarapalli wrote: > something is mixed up here. prefix delegation should work > indepedent of the binding cache entries for the mobile > routers. in the basic support NEMO draft the Home Agent > creates routes to the mobile network when it receives > a Binding Update from the mobile router. do you see a need > to store the delegated prefix in the binding cache entry? > this wont work because, the binding cache entry could > expire. the lifetime of the binding cache entry shouldnt > be related to the lifetime of the delegated prefix. > > I could well be confused as I'm relatively naive about the > mobility and basic NEMO support drafts. The example I cited > is apparently not a good one and there may be no examples > of HA data structures that have to be updated based on > delegation of prefixes... there could be one. in some deployment scenarios, it is important for the HA to figure out if the mobile router actually owns the prefix that it is claiming in the binding update. we have something called a Prefix Table at the HA. the Prefix Table needs to contain the list of prefixes delegated to a particular mobile router. > Key distribution is not specified by the DHCPv6 spec and > assumes manual keying is available. no problem. just wanted to make sure that it is manual keying that you are assuming. Vijay From exim@www1.ietf.org Mon Jul 14 13:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09112 for ; Mon, 14 Jul 2003 13:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7ZS-0005Ot-3L for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:57:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHv6Vq020756 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 13:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7ZR-0005Oh-VY for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 13:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09082 for ; Mon, 14 Jul 2003 13:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ZP-0004B2-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7ZP-0004Az-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 13:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7ZO-0005Ng-2j; Mon, 14 Jul 2003 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Yq-0005Mz-5D for nemo@optimus.ietf.org; Mon, 14 Jul 2003 13:56:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09058 for ; Mon, 14 Jul 2003 13:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Yn-0004AM-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:56:25 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19c7Ym-00049r-00 for nemo@ietf.org; Mon, 14 Jul 2003 13:56:24 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04191; Mon, 14 Jul 2003 10:55:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6EHtnM06599; Mon, 14 Jul 2003 10:55:49 -0700 X-mProtect: <200307141755> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdix8hRX; Mon, 14 Jul 2003 10:55:47 PDT Message-ID: <3F12EEA4.426A20C0@iprg.nokia.com> Date: Mon, 14 Jul 2003 10:55:48 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rdroms@cisco.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > At 05:54 PM 7/12/2003 -0700, Vijay Devarapalli wrote: > something is mixed up here. prefix delegation should work > indepedent of the binding cache entries for the mobile > routers. in the basic support NEMO draft the Home Agent > creates routes to the mobile network when it receives > a Binding Update from the mobile router. do you see a need > to store the delegated prefix in the binding cache entry? > this wont work because, the binding cache entry could > expire. the lifetime of the binding cache entry shouldnt > be related to the lifetime of the delegated prefix. > > I could well be confused as I'm relatively naive about the > mobility and basic NEMO support drafts. The example I cited > is apparently not a good one and there may be no examples > of HA data structures that have to be updated based on > delegation of prefixes... there could be one. in some deployment scenarios, it is important for the HA to figure out if the mobile router actually owns the prefix that it is claiming in the binding update. we have something called a Prefix Table at the HA. the Prefix Table needs to contain the list of prefixes delegated to a particular mobile router. > Key distribution is not specified by the DHCPv6 spec and > assumes manual keying is available. no problem. just wanted to make sure that it is manual keying that you are assuming. Vijay From nemo-admin@ietf.org Mon Jul 14 14:10:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09649 for ; Mon, 14 Jul 2003 14:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7lx-0006Ye-FI; Mon, 14 Jul 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7lr-0006Y7-3v for nemo@optimus.ietf.org; Mon, 14 Jul 2003 14:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09624 for ; Mon, 14 Jul 2003 14:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ln-0004Hu-00 for nemo@ietf.org; Mon, 14 Jul 2003 14:09:51 -0400 Received: from [81.160.165.167] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19c7lm-0004Hr-00 for nemo@ietf.org; Mon, 14 Jul 2003 14:09:50 -0400 Received: by squirrel (Postfix, from userid 1000) id 50611115E85B; Tue, 15 Jul 2003 02:14:15 +0800 (SGT) Subject: Re: [nemo] multi-homing scenarios From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG , Julien Charbon , Thierry Ernst In-Reply-To: <3F12EB27.987DD12E@iprg.nokia.com> References: <3F12EB27.987DD12E@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058206455.1327.7.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 15 Jul 2003 02:14:15 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-07-15 at 01:40, Vijay Devarapalli wrote: > > > both HA1 and HA2 start advertising reachability for > > > the prefix 'p'. this might be okay if both belong to > > > the same administrative domain. the HA1 and HA2 MUST > > > NOT belong to different administrative domains. I > > > think this restriction is necessary. > > > > I am a bit confused here. You first say its okay if HA1 and HA2 belong > > to same administration domain. But immediately after that, you say they > > MUST NOT belong to the same administration domain. Which do you mean > > now? > > read again. :) I said HA1 and HA2 MUST NOT belong to > different administrative domains. Opps, guess I confused myself :). Sorry! /rgds /cwng From exim@www1.ietf.org Mon Jul 14 14:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09664 for ; Mon, 14 Jul 2003 14:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7m1-0006ai-3k for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 14:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIA5cD025330 for nemo-archive@odin.ietf.org; Mon, 14 Jul 2003 14:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7m0-0006aT-Us for nemo-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09629 for ; Mon, 14 Jul 2003 14:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ly-0004I0-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 14:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7ly-0004Hx-00 for nemo-web-archive@ietf.org; Mon, 14 Jul 2003 14:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7lx-0006Ye-FI; Mon, 14 Jul 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7lr-0006Y7-3v for nemo@optimus.ietf.org; Mon, 14 Jul 2003 14:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09624 for ; Mon, 14 Jul 2003 14:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7ln-0004Hu-00 for nemo@ietf.org; Mon, 14 Jul 2003 14:09:51 -0400 Received: from [81.160.165.167] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19c7lm-0004Hr-00 for nemo@ietf.org; Mon, 14 Jul 2003 14:09:50 -0400 Received: by squirrel (Postfix, from userid 1000) id 50611115E85B; Tue, 15 Jul 2003 02:14:15 +0800 (SGT) Subject: Re: [nemo] multi-homing scenarios From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: IETF NEMO WG , Julien Charbon , Thierry Ernst In-Reply-To: <3F12EB27.987DD12E@iprg.nokia.com> References: <3F12EB27.987DD12E@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058206455.1327.7.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 15 Jul 2003 02:14:15 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2003-07-15 at 01:40, Vijay Devarapalli wrote: > > > both HA1 and HA2 start advertising reachability for > > > the prefix 'p'. this might be okay if both belong to > > > the same administrative domain. the HA1 and HA2 MUST > > > NOT belong to different administrative domains. I > > > think this restriction is necessary. > > > > I am a bit confused here. You first say its okay if HA1 and HA2 belong > > to same administration domain. But immediately after that, you say they > > MUST NOT belong to the same administration domain. Which do you mean > > now? > > read again. :) I said HA1 and HA2 MUST NOT belong to > different administrative domains. Opps, guess I confused myself :). Sorry! /rgds /cwng From nemo-admin@ietf.org Wed Jul 16 02:52:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17227 for ; Wed, 16 Jul 2003 02:52:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg90-0003vo-Pb; Wed, 16 Jul 2003 02:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8q-0003sp-WC for nemo@optimus.ietf.org; Wed, 16 Jul 2003 02:51:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17158 for ; Wed, 16 Jul 2003 02:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8i-0003fG-00 for nemo@ietf.org; Wed, 16 Jul 2003 02:51:48 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19cg8X-0003ep-00 for nemo@ietf.org; Wed, 16 Jul 2003 02:51:37 -0400 Received: from localhost (unknown [203.178.138.7]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 3D4D65D1AB; Wed, 16 Jul 2003 15:50:40 +0900 (JST) Date: Wed, 16 Jul 2003 15:50:40 +0900 From: Julien Charbon To: Vijay Devarapalli Cc: nemo@ietf.org, alexandru.petrescu@motorola.com Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030716155040.4aac77b6.julien@sfc.wide.ad.jp> In-Reply-To: <3F0F2DD3.DE75A7D7@iprg.nokia.com> References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> <3F0F2DD3.DE75A7D7@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, Hi all, On Fri, 11 Jul 2003 14:36:19 -0700 Vijay Devarapalli wrote: > Julien Charbon wrote: > > > o Now take a MR inside the bus Tokio - Kyoto: > > > > For Egress Interface: > > > > - Three GPRS interfaces. [480Kb/s][Together] > > > > For Ingress Interface: > > > > - One 802.11b Wi-Fi [11Mb/s] > > > > Here the main interest is to provide a "correct" connection to all > > people inside bus all the time, and because of this bus run forward > > country side, only GPRS is usable during all this trip. Thus you > > multiply the GPRS connections to provide a better bandwidth. > > I guess I found the example I was looking for in my previous > mail. :) I hadnt read this mail then. sorry. > > I have a question here. what do you we need to standardise > here? how the Mobile Router distributes the traffic between > the three egress interface is implementation dependent. > ofcourse you still need the support for registering the same > MNP with multiple CoAs. but there is nothing to standardise > for the load sharing itself. it is internal to the Mobile > Router. Yes your right, the algorithm of distribution is implement specific [currently all solution I have found to support Load-Shring are always implement specific]. And thus there is nothing to specify in NEMO for making Load-Sharing itself but: o To support it you need CoAs identification: [1, Section 2.3 Solution behaviors] or [2] o and If you want _dynamic_ Load-Sharing: You need to put a preference option for each CoA in the BU. [If think this point should discuss at Vienna today] In conclusion, NEMO think about howto support the Load-Sharing [or howto don't prevent Load-Sharing] not howto make Load-Sharing. I will update the drat to be clearer. Thanks. -- Julien [1] http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt [2] http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-01.txt From exim@www1.ietf.org Wed Jul 16 02:53:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17276 for ; Wed, 16 Jul 2003 02:53:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg9N-0004Cn-5I for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qSUv015791 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg9L-00045k-4W for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:52:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17193 for ; Wed, 16 Jul 2003 02:52:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg9H-0003fn-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cg9B-0003fe-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg90-0003vo-Pb; Wed, 16 Jul 2003 02:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8q-0003sp-WC for nemo@optimus.ietf.org; Wed, 16 Jul 2003 02:51:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17158 for ; Wed, 16 Jul 2003 02:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8i-0003fG-00 for nemo@ietf.org; Wed, 16 Jul 2003 02:51:48 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19cg8X-0003ep-00 for nemo@ietf.org; Wed, 16 Jul 2003 02:51:37 -0400 Received: from localhost (unknown [203.178.138.7]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 3D4D65D1AB; Wed, 16 Jul 2003 15:50:40 +0900 (JST) Date: Wed, 16 Jul 2003 15:50:40 +0900 From: Julien Charbon To: Vijay Devarapalli Cc: nemo@ietf.org, alexandru.petrescu@motorola.com Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt Message-Id: <20030716155040.4aac77b6.julien@sfc.wide.ad.jp> In-Reply-To: <3F0F2DD3.DE75A7D7@iprg.nokia.com> References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> <3F0F2DD3.DE75A7D7@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, Hi all, On Fri, 11 Jul 2003 14:36:19 -0700 Vijay Devarapalli wrote: > Julien Charbon wrote: > > > o Now take a MR inside the bus Tokio - Kyoto: > > > > For Egress Interface: > > > > - Three GPRS interfaces. [480Kb/s][Together] > > > > For Ingress Interface: > > > > - One 802.11b Wi-Fi [11Mb/s] > > > > Here the main interest is to provide a "correct" connection to all > > people inside bus all the time, and because of this bus run forward > > country side, only GPRS is usable during all this trip. Thus you > > multiply the GPRS connections to provide a better bandwidth. > > I guess I found the example I was looking for in my previous > mail. :) I hadnt read this mail then. sorry. > > I have a question here. what do you we need to standardise > here? how the Mobile Router distributes the traffic between > the three egress interface is implementation dependent. > ofcourse you still need the support for registering the same > MNP with multiple CoAs. but there is nothing to standardise > for the load sharing itself. it is internal to the Mobile > Router. Yes your right, the algorithm of distribution is implement specific [currently all solution I have found to support Load-Shring are always implement specific]. And thus there is nothing to specify in NEMO for making Load-Sharing itself but: o To support it you need CoAs identification: [1, Section 2.3 Solution behaviors] or [2] o and If you want _dynamic_ Load-Sharing: You need to put a preference option for each CoA in the BU. [If think this point should discuss at Vienna today] In conclusion, NEMO think about howto support the Load-Sharing [or howto don't prevent Load-Sharing] not howto make Load-Sharing. I will update the drat to be clearer. Thanks. -- Julien [1] http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt [2] http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-01.txt From nemo-admin@ietf.org Wed Jul 16 03:40:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19080 for ; Wed, 16 Jul 2003 03:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtN-0007OQ-PY; Wed, 16 Jul 2003 03:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgsl-0007Ne-Al for nemo@optimus.ietf.org; Wed, 16 Jul 2003 03:39:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19022 for ; Wed, 16 Jul 2003 03:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgsi-000486-00 for nemo@ietf.org; Wed, 16 Jul 2003 03:39:20 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19cgsX-00047Z-00 for nemo@ietf.org; Wed, 16 Jul 2003 03:39:09 -0400 Received: from localhost (unknown [203.178.138.7]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id BC4BB5D190; Wed, 16 Jul 2003 16:38:34 +0900 (JST) Date: Wed, 16 Jul 2003 16:38:34 +0900 From: Julien Charbon To: Vijay Devarapalli Cc: nemo@ietf.org Message-Id: <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> In-Reply-To: <3F0F2BAC.F7A1A05F@iprg.nokia.com> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, Hi all, On Fri, 11 Jul 2003 14:27:08 -0700 Vijay Devarapalli wrote: > a very good and useful draft. thanks. Thanks to you. > section 2.2 > > > > > A MR is multi-homed when it has simultaneously more than one > > active connection to the Internet, [...] > > and > > > R12: The solution MUST function for multi-homed MR and > > multi-homed mobile networks as defined in [NEMO-TERMS]). > > Particularly: > > > > R12.1: The solution MUST function for multi-MR mobile > > networks > > does not lead you to > > > > > Thus the NEMO solution MUST manage network traffic > > simultaneously through the several connection of a same MR. > > I dont know how you arrived at the above statement. Oups ! My mistake my reasoning should be: ,----[ draft-ietf-nemo-terminology-00, Section 5. ] | A MR is multihomed when it has simultaneously more than one active | connection to the Internet, that is when it is either: | | [...] | | - multi-egress-interfaced MR: the MR has simultaneously | multiple active egress intefaces on the same link or not `---- with ,----[ draft-ietf-nemo-requirements-01, Section 5. ] | R12: The solution MUST function for multihomed MR and multihomed | mobile networks as defined in [NEMO-TERMS]). Particularly: | | [...] | | R12.2: The solution MUST function for multi-egress | interfaces `---- Thus NEMO MUST function with a MR which as simultaneously multiple active egress intefaces on the same link or not. Depending on the meaning of /function/ maybe my sentence is too oriented Load-Sharing. I will change that. > in case (0,1,0) > > its a mess if the Home Agents belong to different > administrative domains. I looked at the reference [11]. > towards the end of section 5.1.2 in reference [11], I > see some text which says this kind of multi-homining > is rare. I think you should also say that this is rare > and is out of scope for NEMO. frankly, I think it is > not worth solving. Yes, you right. I just wanted to answer at the question "Is possible that theses HAs can be in different AS?". Now I will put: "Yes, _BUT_ ..." And I will put a paragraph on "aggrated network prefix and multiple HAs", because it's maybe a better solution. > in case (1,0,1) and case (1,1,1) > > what if both prefixes are advertised by both Mobile > Routers? is there any difference? Yes, if both prefixes are managed by the both router you have the same behavior than in: Case (0,0,1). (1,0,1) and (1,1,1) are interesting because they show how you can lost the Faul-Tolerance with transparency benefits just by adding a prefix, and because of Ingress Filtering. > for both these cases, you have assumed that each Mobile > Router will advertise a different prefix (which is good > makes things simpler). but is this a valid assumption? Yes, I make this choice because I though about this scenario: In a car you have a MR with two egress interfaces: A GPRS and a Wi-Fi, and because you don't find any provider which provide the both connections, you have to take a contract in two different. And because it's two differents ISPs, they delegate you two Mobile Network Prefix. And here you have the case (0,1,1), and if connections are too differents like I don't know,... For example a satelite bi-directionnal connection [big antenna for a car], and a Infra-Red, you will need two differents MR. [Because difficult to find a MR supporting the both connection]. Thus you find case (1,1,1). In more general way, ISP tend to propose "all in one" package thus: Pack "Internet-in-Car": Connection + MR + HA management. Thus you just have to put the MR in your car, link it to car network, and.. It's ok. But all these comments are IMHO, because I'm nor a car manufacturer, neither an ISP. > > However, based on our analysis, > > we propose some improvements. > > arent these improvements best handled by separate > specifications? Hum, What did you think about ? [What kind of separate specifications I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > o Preference & Priority: > > > > Theses two informations permit to manage the sharing/the policy of > > the Inbound traffic to the Mobile Network through several CoAs > > and/or several HAs. > > > > Theses information could be added to the Prefix-BU, and the > > proposed solution specify a field/an sub-option to permit some > > implementation to provide this benefit; or specify in the next > > release of NEMO protocol. > > > > o Multiple CoAs for the same MNP: > > > > The proposed solution doesn't have to specify anything one this > > subject, just to support it. But a paragraph on this purpose can > > be helpful for implementation's developers. > > can you suggest some text? it is not clear to me what you are > looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt > provide a solution for this? I was rough for keeping a maximum freedom about solution idea, Wakikawa is one solution, but in mip6, thus maybe it should take a long time to be accepted. IMHO. I think these points should be sharply discuss at Vienna today, and after result of comment I will write some text about solutions. [If NEMO deciced to not include any preference nor priority field nor Interface ID for NEMO basic, maybe in the next version of NEMO it will be OK]. Thanks for these good comments. Best regards. -- Julien From exim@www1.ietf.org Wed Jul 16 03:40:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19135 for ; Wed, 16 Jul 2003 03:40:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtd-0007TP-3N for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 03:40:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G7eHIB028721 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 03:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtc-0007TA-VY for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 03:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19073 for ; Wed, 16 Jul 2003 03:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgtX-00048l-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 03:40:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cgtR-00048i-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 03:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgtN-0007OQ-PY; Wed, 16 Jul 2003 03:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cgsl-0007Ne-Al for nemo@optimus.ietf.org; Wed, 16 Jul 2003 03:39:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19022 for ; Wed, 16 Jul 2003 03:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cgsi-000486-00 for nemo@ietf.org; Wed, 16 Jul 2003 03:39:20 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19cgsX-00047Z-00 for nemo@ietf.org; Wed, 16 Jul 2003 03:39:09 -0400 Received: from localhost (unknown [203.178.138.7]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id BC4BB5D190; Wed, 16 Jul 2003 16:38:34 +0900 (JST) Date: Wed, 16 Jul 2003 16:38:34 +0900 From: Julien Charbon To: Vijay Devarapalli Cc: nemo@ietf.org Message-Id: <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> In-Reply-To: <3F0F2BAC.F7A1A05F@iprg.nokia.com> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, Hi all, On Fri, 11 Jul 2003 14:27:08 -0700 Vijay Devarapalli wrote: > a very good and useful draft. thanks. Thanks to you. > section 2.2 > > > > > A MR is multi-homed when it has simultaneously more than one > > active connection to the Internet, [...] > > and > > > R12: The solution MUST function for multi-homed MR and > > multi-homed mobile networks as defined in [NEMO-TERMS]). > > Particularly: > > > > R12.1: The solution MUST function for multi-MR mobile > > networks > > does not lead you to > > > > > Thus the NEMO solution MUST manage network traffic > > simultaneously through the several connection of a same MR. > > I dont know how you arrived at the above statement. Oups ! My mistake my reasoning should be: ,----[ draft-ietf-nemo-terminology-00, Section 5. ] | A MR is multihomed when it has simultaneously more than one active | connection to the Internet, that is when it is either: | | [...] | | - multi-egress-interfaced MR: the MR has simultaneously | multiple active egress intefaces on the same link or not `---- with ,----[ draft-ietf-nemo-requirements-01, Section 5. ] | R12: The solution MUST function for multihomed MR and multihomed | mobile networks as defined in [NEMO-TERMS]). Particularly: | | [...] | | R12.2: The solution MUST function for multi-egress | interfaces `---- Thus NEMO MUST function with a MR which as simultaneously multiple active egress intefaces on the same link or not. Depending on the meaning of /function/ maybe my sentence is too oriented Load-Sharing. I will change that. > in case (0,1,0) > > its a mess if the Home Agents belong to different > administrative domains. I looked at the reference [11]. > towards the end of section 5.1.2 in reference [11], I > see some text which says this kind of multi-homining > is rare. I think you should also say that this is rare > and is out of scope for NEMO. frankly, I think it is > not worth solving. Yes, you right. I just wanted to answer at the question "Is possible that theses HAs can be in different AS?". Now I will put: "Yes, _BUT_ ..." And I will put a paragraph on "aggrated network prefix and multiple HAs", because it's maybe a better solution. > in case (1,0,1) and case (1,1,1) > > what if both prefixes are advertised by both Mobile > Routers? is there any difference? Yes, if both prefixes are managed by the both router you have the same behavior than in: Case (0,0,1). (1,0,1) and (1,1,1) are interesting because they show how you can lost the Faul-Tolerance with transparency benefits just by adding a prefix, and because of Ingress Filtering. > for both these cases, you have assumed that each Mobile > Router will advertise a different prefix (which is good > makes things simpler). but is this a valid assumption? Yes, I make this choice because I though about this scenario: In a car you have a MR with two egress interfaces: A GPRS and a Wi-Fi, and because you don't find any provider which provide the both connections, you have to take a contract in two different. And because it's two differents ISPs, they delegate you two Mobile Network Prefix. And here you have the case (0,1,1), and if connections are too differents like I don't know,... For example a satelite bi-directionnal connection [big antenna for a car], and a Infra-Red, you will need two differents MR. [Because difficult to find a MR supporting the both connection]. Thus you find case (1,1,1). In more general way, ISP tend to propose "all in one" package thus: Pack "Internet-in-Car": Connection + MR + HA management. Thus you just have to put the MR in your car, link it to car network, and.. It's ok. But all these comments are IMHO, because I'm nor a car manufacturer, neither an ISP. > > However, based on our analysis, > > we propose some improvements. > > arent these improvements best handled by separate > specifications? Hum, What did you think about ? [What kind of separate specifications I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > o Preference & Priority: > > > > Theses two informations permit to manage the sharing/the policy of > > the Inbound traffic to the Mobile Network through several CoAs > > and/or several HAs. > > > > Theses information could be added to the Prefix-BU, and the > > proposed solution specify a field/an sub-option to permit some > > implementation to provide this benefit; or specify in the next > > release of NEMO protocol. > > > > o Multiple CoAs for the same MNP: > > > > The proposed solution doesn't have to specify anything one this > > subject, just to support it. But a paragraph on this purpose can > > be helpful for implementation's developers. > > can you suggest some text? it is not clear to me what you are > looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt > provide a solution for this? I was rough for keeping a maximum freedom about solution idea, Wakikawa is one solution, but in mip6, thus maybe it should take a long time to be accepted. IMHO. I think these points should be sharply discuss at Vienna today, and after result of comment I will write some text about solutions. [If NEMO deciced to not include any preference nor priority field nor Interface ID for NEMO basic, maybe in the next version of NEMO it will be OK]. Thanks for these good comments. Best regards. -- Julien From nemo-admin@ietf.org Wed Jul 16 04:07:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20203 for ; Wed, 16 Jul 2003 04:07:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chJV-0000WJ-Ap; Wed, 16 Jul 2003 04:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chIu-0000V8-C6 for nemo@optimus.ietf.org; Wed, 16 Jul 2003 04:06:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20154 for ; Wed, 16 Jul 2003 04:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chIq-0004On-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:06:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19chIc-0004Nv-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:06:09 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2003 10:03:45 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6G81Zea005098; Wed, 16 Jul 2003 10:01:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jul 2003 10:03:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jul 2003 09:03:42 +0100 Message-ID: Thread-Topic: Issue 3 Thread-Index: AcM8PFKiufdwcdE1S/mszwLKx6KuRAPM3V4w From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 16 Jul 2003 08:03:43.0508 (UTC) FILETIME=[C67E1D40:01C34B70] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable "The Home Agent SHOULD store the list of Mobile Network Prefixes=20 owned by a Mobile Router in the corresponding Binding Cache=20 entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list=20 of prefixes should include only those for which the Home Agent=20 currently has routes pointing to the Mobile Router's current=20 Care-of address. This information can later be used to delete=20 the routes when the Binding Cache entry for the Mobile Router=20 is deleted." > is this okay? If the info is to be used to delete the routes, then you need to know which prefixes you actually created routes for, so maybe you need more info associated to the prefixes, like pointers to the adjacencies that were instantiated. This is deep into implementation, a bit to much to my taste. I would have preferred a text saying that "the MR MUST keep all necessary information to clean up whichever routes it installed, for instance by keeping the list of prefix in BCE, whether they come from implicit or explicit source". Vijay, please do not tell people how to implement things (even if your proposal seems perfectly proper). Pascal From exim@www1.ietf.org Wed Jul 16 04:07:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20218 for ; Wed, 16 Jul 2003 04:07:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chJh-0000au-AC for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 04:07:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G87Da7002278 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 04:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chJh-0000ac-0L for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 04:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20179 for ; Wed, 16 Jul 2003 04:07:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chJe-0004PD-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 04:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19chJY-0004PA-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 04:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chJV-0000WJ-Ap; Wed, 16 Jul 2003 04:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chIu-0000V8-C6 for nemo@optimus.ietf.org; Wed, 16 Jul 2003 04:06:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20154 for ; Wed, 16 Jul 2003 04:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chIq-0004On-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:06:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19chIc-0004Nv-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:06:09 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2003 10:03:45 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6G81Zea005098; Wed, 16 Jul 2003 10:01:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jul 2003 10:03:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jul 2003 09:03:42 +0100 Message-ID: Thread-Topic: Issue 3 Thread-Index: AcM8PFKiufdwcdE1S/mszwLKx6KuRAPM3V4w From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 16 Jul 2003 08:03:43.0508 (UTC) FILETIME=[C67E1D40:01C34B70] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable "The Home Agent SHOULD store the list of Mobile Network Prefixes=20 owned by a Mobile Router in the corresponding Binding Cache=20 entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list=20 of prefixes should include only those for which the Home Agent=20 currently has routes pointing to the Mobile Router's current=20 Care-of address. This information can later be used to delete=20 the routes when the Binding Cache entry for the Mobile Router=20 is deleted." > is this okay? If the info is to be used to delete the routes, then you need to know which prefixes you actually created routes for, so maybe you need more info associated to the prefixes, like pointers to the adjacencies that were instantiated. This is deep into implementation, a bit to much to my taste. I would have preferred a text saying that "the MR MUST keep all necessary information to clean up whichever routes it installed, for instance by keeping the list of prefix in BCE, whether they come from implicit or explicit source". Vijay, please do not tell people how to implement things (even if your proposal seems perfectly proper). Pascal From nemo-admin@ietf.org Wed Jul 16 04:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21453 for ; Wed, 16 Jul 2003 04:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chwD-0003Ig-80; Wed, 16 Jul 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chva-0003Hr-96 for nemo@optimus.ietf.org; Wed, 16 Jul 2003 04:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21427 for ; Wed, 16 Jul 2003 04:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chvX-0004mP-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:46:19 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19chvM-0004jM-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:46:08 -0400 Received: from [81.160.236.20] (ryuji-inc.ietf57.telekom.at [81.160.236.20] (may be forged)) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6G8gcGj001547; Wed, 16 Jul 2003 17:42:40 +0900 Date: Wed, 16 Jul 2003 17:42:41 +0900 From: Ryuji Wakikawa To: Julien Charbon Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Cc: Vijay Devarapalli , nemo@ietf.org In-Reply-To: <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> Message-Id: <20030716173214.1D87.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > > > o Multiple CoAs for the same MNP: > > > > > > The proposed solution doesn't have to specify anything one this > > > subject, just to support it. But a paragraph on this purpose can > > > be helpful for implementation's developers. > > > > can you suggest some text? it is not clear to me what you are > > looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt > > provide a solution for this? > > I was rough for keeping a maximum freedom about solution idea, > Wakikawa is one solution, but in mip6, thus maybe it should take a > long time to be accepted. IMHO. I think these points should be sharply > discuss at Vienna today, and after result of comment I will write some > text about solutions. [If NEMO deciced to not include any preference nor > priority field nor Interface ID for NEMO basic, maybe in the next version > of NEMO it will be OK]. I don't think every MIP items takes a long time:-p I submitted my draft to MIP6 WG, because the requirement is not only from NEMO, but also from MIP. I also prefer a common solution for NEMO and MIP. I am always ready to discuss my draft in NEMO WG. Our draft can be simply applied to NEMO basic support. I will update the draft after the meeting. I personally got comments from MIP6 folks. regards ryuji > Thanks for these good comments. > > Best regards. > > -- Julien From exim@www1.ietf.org Wed Jul 16 04:47:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21469 for ; Wed, 16 Jul 2003 04:47:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chwX-0003Nm-Oo for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 04:47:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G8lLUk013002 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 04:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chwX-0003Nd-2T for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 04:47:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21445 for ; Wed, 16 Jul 2003 04:47:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chwU-0004mu-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 04:47:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19chwO-0004mk-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 04:47:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chwD-0003Ig-80; Wed, 16 Jul 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chva-0003Hr-96 for nemo@optimus.ietf.org; Wed, 16 Jul 2003 04:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21427 for ; Wed, 16 Jul 2003 04:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chvX-0004mP-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:46:19 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19chvM-0004jM-00 for nemo@ietf.org; Wed, 16 Jul 2003 04:46:08 -0400 Received: from [81.160.236.20] (ryuji-inc.ietf57.telekom.at [81.160.236.20] (may be forged)) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6G8gcGj001547; Wed, 16 Jul 2003 17:42:40 +0900 Date: Wed, 16 Jul 2003 17:42:41 +0900 From: Ryuji Wakikawa To: Julien Charbon Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Cc: Vijay Devarapalli , nemo@ietf.org In-Reply-To: <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> Message-Id: <20030716173214.1D87.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > > > o Multiple CoAs for the same MNP: > > > > > > The proposed solution doesn't have to specify anything one this > > > subject, just to support it. But a paragraph on this purpose can > > > be helpful for implementation's developers. > > > > can you suggest some text? it is not clear to me what you are > > looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt > > provide a solution for this? > > I was rough for keeping a maximum freedom about solution idea, > Wakikawa is one solution, but in mip6, thus maybe it should take a > long time to be accepted. IMHO. I think these points should be sharply > discuss at Vienna today, and after result of comment I will write some > text about solutions. [If NEMO deciced to not include any preference nor > priority field nor Interface ID for NEMO basic, maybe in the next version > of NEMO it will be OK]. I don't think every MIP items takes a long time:-p I submitted my draft to MIP6 WG, because the requirement is not only from NEMO, but also from MIP. I also prefer a common solution for NEMO and MIP. I am always ready to discuss my draft in NEMO WG. Our draft can be simply applied to NEMO basic support. I will update the draft after the meeting. I personally got comments from MIP6 folks. regards ryuji > Thanks for these good comments. > > Best regards. > > -- Julien From nemo-admin@ietf.org Wed Jul 16 05:31:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23120 for ; Wed, 16 Jul 2003 05:31:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicn-0005eS-3z; Wed, 16 Jul 2003 05:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicO-0005do-FI for nemo@optimus.ietf.org; Wed, 16 Jul 2003 05:30:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23056 for ; Wed, 16 Jul 2003 05:30:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cicL-0005Am-00 for nemo@ietf.org; Wed, 16 Jul 2003 05:30:33 -0400 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 19cicA-0005AW-00 for nemo@ietf.org; Wed, 16 Jul 2003 05:30:22 -0400 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.9/8.12.9) with ESMTP id h6G9TFo1010151; Wed, 16 Jul 2003 02:29:16 -0700 (PDT) Message-ID: <3F1517AC.9010305@cs.ucdavis.edu> Date: Wed, 16 Jul 2003 02:15:24 -0700 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A couple questions related to the relationship between prefix BU and routing protocol exchanges between MR and HA: Vijay Devarapalli wrote: >>> When the Mobile Router and the Home Agent exchange routes >>> through routing protocol updates, the Home Agent MUST NOT >>> create routes to the Mobile network when the Binding Update >>> from the Mobile Router is received. The Mobile Router also >>> MUST NOT include any prefix information in the Binding Update. >>> Any routes to the Mobile Network are created at the Home >>> Agent through routing protocol updates. > > isnt it redundant to include prefix information in the > binding update if routes are being exchanged through a > dynamic routing protocol? In regular router configuration, we have static configured routes and routes learned dynamically from routing protocols such as RIP or OSPF. They both exist in the regular routers. Aren't the prefixes being announced via BU under NEMO like static routes in the regular world, while we at the same time have dynamic routes for other prefixes using the MR (from the HA point of view)? It seems to me that this is a configuration/operation issue. While I agree that the option in discussion (having both BU and dynamic routing updates for prefixes between a particular pair of HA and MR) may be redundent, I wonder in practice whether there are scenarios that we have to have both? > well, you want the protocol to be efficient, right? > when a dynamic routing protocol is being used, including > prefix information in the binding update is both > redundant and involves an overhead in terms of the size > of binding udpate. I have actually a question regarding the prefix table, which in NEMO the HA will use it to check if the MR has the right/ownership to announce the prefix. First, I assume that, for both BU and dynamic routing updates, the HA has to check the table before accepting a route/binding of MR to prefixes. Second, the content of the prefix table should be maintained correctly by the system administrators. (This process is actually a tricky one in some cases.) According to the current drafts, it seems to me that it is possible that two different MRs can be allowed to announce the same prefix (e.g., 169.237.6/24): prefix table: 169.237.6/24 MR1, MR2 Or, maybe more interestingly, MR1 will announce a more specific prefix (e.g., 169.237.6/25) to HA, and the HA should be OK with it. Therefore, it is possible while MR1 is authorized to own 169.237.6/24, it actually only has a smaller portion of it (169.237.6/25) at a particular moment of time. That is why we might need dynamic routing protocol to reflect that change. Is that right? (just try to get clarified....) Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Wed Jul 16 05:31:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23139 for ; Wed, 16 Jul 2003 05:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicz-0005hV-Dd for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 05:31:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G9VDI0021904 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 05:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicz-0005gb-9t for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 05:31:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23106 for ; Wed, 16 Jul 2003 05:31:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cicw-0005BJ-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 05:31:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cicq-0005BG-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 05:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicn-0005eS-3z; Wed, 16 Jul 2003 05:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cicO-0005do-FI for nemo@optimus.ietf.org; Wed, 16 Jul 2003 05:30:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23056 for ; Wed, 16 Jul 2003 05:30:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cicL-0005Am-00 for nemo@ietf.org; Wed, 16 Jul 2003 05:30:33 -0400 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 19cicA-0005AW-00 for nemo@ietf.org; Wed, 16 Jul 2003 05:30:22 -0400 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.9/8.12.9) with ESMTP id h6G9TFo1010151; Wed, 16 Jul 2003 02:29:16 -0700 (PDT) Message-ID: <3F1517AC.9010305@cs.ucdavis.edu> Date: Wed, 16 Jul 2003 02:15:24 -0700 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A couple questions related to the relationship between prefix BU and routing protocol exchanges between MR and HA: Vijay Devarapalli wrote: >>> When the Mobile Router and the Home Agent exchange routes >>> through routing protocol updates, the Home Agent MUST NOT >>> create routes to the Mobile network when the Binding Update >>> from the Mobile Router is received. The Mobile Router also >>> MUST NOT include any prefix information in the Binding Update. >>> Any routes to the Mobile Network are created at the Home >>> Agent through routing protocol updates. > > isnt it redundant to include prefix information in the > binding update if routes are being exchanged through a > dynamic routing protocol? In regular router configuration, we have static configured routes and routes learned dynamically from routing protocols such as RIP or OSPF. They both exist in the regular routers. Aren't the prefixes being announced via BU under NEMO like static routes in the regular world, while we at the same time have dynamic routes for other prefixes using the MR (from the HA point of view)? It seems to me that this is a configuration/operation issue. While I agree that the option in discussion (having both BU and dynamic routing updates for prefixes between a particular pair of HA and MR) may be redundent, I wonder in practice whether there are scenarios that we have to have both? > well, you want the protocol to be efficient, right? > when a dynamic routing protocol is being used, including > prefix information in the binding update is both > redundant and involves an overhead in terms of the size > of binding udpate. I have actually a question regarding the prefix table, which in NEMO the HA will use it to check if the MR has the right/ownership to announce the prefix. First, I assume that, for both BU and dynamic routing updates, the HA has to check the table before accepting a route/binding of MR to prefixes. Second, the content of the prefix table should be maintained correctly by the system administrators. (This process is actually a tricky one in some cases.) According to the current drafts, it seems to me that it is possible that two different MRs can be allowed to announce the same prefix (e.g., 169.237.6/24): prefix table: 169.237.6/24 MR1, MR2 Or, maybe more interestingly, MR1 will announce a more specific prefix (e.g., 169.237.6/25) to HA, and the HA should be OK with it. Therefore, it is possible while MR1 is authorized to own 169.237.6/24, it actually only has a smaller portion of it (169.237.6/25) at a particular moment of time. That is why we might need dynamic routing protocol to reflect that change. Is that right? (just try to get clarified....) Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Wed Jul 16 11:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05242 for ; Wed, 16 Jul 2003 11:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnp3-0000Dc-0h; Wed, 16 Jul 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjkn-00013w-Fc for nemo@optimus.ietf.org; Wed, 16 Jul 2003 06:43:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24777 for ; Wed, 16 Jul 2003 06:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjkj-0005go-00 for nemo@ietf.org; Wed, 16 Jul 2003 06:43:17 -0400 Received: from bay4-f10.bay4.hotmail.com ([65.54.171.10] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19cjkY-0005gS-00 for nemo@ietf.org; Wed, 16 Jul 2003 06:43:06 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Jul 2003 03:41:55 -0700 Received: from 81.160.98.149 by by4fd.bay4.hotmail.msn.com with HTTP; Wed, 16 Jul 2003 10:41:55 GMT X-Originating-IP: [81.160.98.149] X-Originating-Email: [natpt@msn.com] From: "soohong park" To: nemo@ietf.org Cc: soohong.park@samsung.com Subject: Re: Re: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Date: Wed, 16 Jul 2003 19:41:55 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jul 2003 10:41:55.0981 (UTC) FILETIME=[E0728BD0:01C34B86] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Will Thanks your feedback, please look into my inline response 1) The draft appears to assume that the 802.11 network will be a home domain. I believe this is not general enough. There are many 802.11 system appearing throughout the world that will be outside the mobile's home domain. => The status of this draft is only draft. I am trying to address more generalization. 2) My limited experience with GPRS in the US is with IPv4 and T-Mobile. We are currently trying to work with T-Mobile to figure out how their NATing scheme is effecting mobile router operation. In theory, in IPv6, NATs will no longer be a problem, but don't count on it. => It also can be added to the generalization. I think we ALL need to work with service providers to educate them on the nastiness of NATing in that some of the problems NATing solves can be done using other mechanisms. Anyway, I suggest working with some GPRS service providers regarding use of GPRS in mobile networks. I believe both parties will learn from such a relationship. => Good suggestion, so our team (WiFi Team in IPv6 forum) is trying to consider various considerations as well. Basically this working will be processed by team. I believe it is a fit time to discuss this issue at nemo... Any comments ? Daniel _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From exim@www1.ietf.org Wed Jul 16 11:04:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05257 for ; Wed, 16 Jul 2003 11:04:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnpE-0000EZ-Fv for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 11:04:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GF4C4G000899 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 11:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnpD-0000EQ-SH for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05239 for ; Wed, 16 Jul 2003 11:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnpB-0000Ij-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 11:04:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cnp5-0000Ig-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 11:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnp3-0000Dc-0h; Wed, 16 Jul 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjkn-00013w-Fc for nemo@optimus.ietf.org; Wed, 16 Jul 2003 06:43:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24777 for ; Wed, 16 Jul 2003 06:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjkj-0005go-00 for nemo@ietf.org; Wed, 16 Jul 2003 06:43:17 -0400 Received: from bay4-f10.bay4.hotmail.com ([65.54.171.10] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19cjkY-0005gS-00 for nemo@ietf.org; Wed, 16 Jul 2003 06:43:06 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Jul 2003 03:41:55 -0700 Received: from 81.160.98.149 by by4fd.bay4.hotmail.msn.com with HTTP; Wed, 16 Jul 2003 10:41:55 GMT X-Originating-IP: [81.160.98.149] X-Originating-Email: [natpt@msn.com] From: "soohong park" To: nemo@ietf.org Cc: soohong.park@samsung.com Subject: Re: Re: [nemo] 802.11 Mobility Framework Supporting GPRS Handover Date: Wed, 16 Jul 2003 19:41:55 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jul 2003 10:41:55.0981 (UTC) FILETIME=[E0728BD0:01C34B86] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Will Thanks your feedback, please look into my inline response 1) The draft appears to assume that the 802.11 network will be a home domain. I believe this is not general enough. There are many 802.11 system appearing throughout the world that will be outside the mobile's home domain. => The status of this draft is only draft. I am trying to address more generalization. 2) My limited experience with GPRS in the US is with IPv4 and T-Mobile. We are currently trying to work with T-Mobile to figure out how their NATing scheme is effecting mobile router operation. In theory, in IPv6, NATs will no longer be a problem, but don't count on it. => It also can be added to the generalization. I think we ALL need to work with service providers to educate them on the nastiness of NATing in that some of the problems NATing solves can be done using other mechanisms. Anyway, I suggest working with some GPRS service providers regarding use of GPRS in mobile networks. I believe both parties will learn from such a relationship. => Good suggestion, so our team (WiFi Team in IPv6 forum) is trying to consider various considerations as well. Basically this working will be processed by team. I believe it is a fit time to discuss this issue at nemo... Any comments ? Daniel _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From nemo-admin@ietf.org Wed Jul 16 14:26:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11424 for ; Wed, 16 Jul 2003 14:26:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqyX-00044F-Qd; Wed, 16 Jul 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqyC-00043s-6o for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:25:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11399 for ; Wed, 16 Jul 2003 14:25:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqy9-0001wp-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:25:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19cqxt-0001w7-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:25:21 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27414; Wed, 16 Jul 2003 11:22:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIMtT11778; Wed, 16 Jul 2003 11:22:55 -0700 X-mProtect: <200307161822> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd96c6YP; Wed, 16 Jul 2003 11:22:53 PDT Message-ID: <3F1597FD.149D5FC7@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:22:53 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, alexandru.petrescu@motorola.com Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> <3F0F2DD3.DE75A7D7@iprg.nokia.com> <20030716155040.4aac77b6.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Julien Charbon wrote: > > o To support it you need CoAs identification: > > [1, Section 2.3 Solution behaviors] or [2] I support standardizing draft-wakikawa-mobileip-multiplecoa-01.txt. > > o and If you want _dynamic_ Load-Sharing: > > You need to put a preference option for each CoA in the BU. > [If think this point should discuss at Vienna today] for this how about defining a new mobilily option called the Care-of Address Preference option? and I prefer standardizing this option through a separate specification (not in the NEMO basic support). > In conclusion, NEMO think about howto support the Load-Sharing [or > howto don't prevent Load-Sharing] not howto make Load-Sharing. I will > update the drat to be clearer. Thanks. okay. Vijay From exim@www1.ietf.org Wed Jul 16 14:27:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11472 for ; Wed, 16 Jul 2003 14:27:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqzb-00048s-DJ for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIR7nc015918 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqzb-00048f-8b for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11446 for ; Wed, 16 Jul 2003 14:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqzY-0001xI-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cqzT-0001wu-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqyX-00044F-Qd; Wed, 16 Jul 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqyC-00043s-6o for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:25:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11399 for ; Wed, 16 Jul 2003 14:25:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqy9-0001wp-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:25:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19cqxt-0001w7-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:25:21 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27414; Wed, 16 Jul 2003 11:22:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIMtT11778; Wed, 16 Jul 2003 11:22:55 -0700 X-mProtect: <200307161822> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd96c6YP; Wed, 16 Jul 2003 11:22:53 PDT Message-ID: <3F1597FD.149D5FC7@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:22:53 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, alexandru.petrescu@motorola.com Subject: Re: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt References: <20030701222750.7b9ad609.julien@sfc.wide.ad.jp> <3F043046.6020401@motorola.com> <20030707230358.2ef768c4.julien@sfc.wide.ad.jp> <3F0F2DD3.DE75A7D7@iprg.nokia.com> <20030716155040.4aac77b6.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julien Charbon wrote: > > o To support it you need CoAs identification: > > [1, Section 2.3 Solution behaviors] or [2] I support standardizing draft-wakikawa-mobileip-multiplecoa-01.txt. > > o and If you want _dynamic_ Load-Sharing: > > You need to put a preference option for each CoA in the BU. > [If think this point should discuss at Vienna today] for this how about defining a new mobilily option called the Care-of Address Preference option? and I prefer standardizing this option through a separate specification (not in the NEMO basic support). > In conclusion, NEMO think about howto support the Load-Sharing [or > howto don't prevent Load-Sharing] not howto make Load-Sharing. I will > update the drat to be clearer. Thanks. okay. Vijay From nemo-admin@ietf.org Wed Jul 16 14:44:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12105 for ; Wed, 16 Jul 2003 14:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crFx-0005Vd-Du; Wed, 16 Jul 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crFZ-0005VJ-Uw for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12070 for ; Wed, 16 Jul 2003 14:43:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crFX-00024e-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:43:35 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19crFH-000246-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:43:19 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28378; Wed, 16 Jul 2003 11:42:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIgQs02997; Wed, 16 Jul 2003 11:42:26 -0700 X-mProtect: <200307161842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLlCkRF; Wed, 16 Jul 2003 11:42:24 PDT Message-ID: <3F159C90.11F898C3@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:42:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, ernst@sfc.wide.ad.jp, tj@kniveton.com Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Julien Charbon wrote: > > Depending on the meaning of /function/ maybe my sentence is too > oriented Load-Sharing. I will change that. okay. load sharing is a nice feature, but it shouldnt a MUST support for NEMO. it should be an optional mechanism. > > > in case (0,1,0) > > > > its a mess if the Home Agents belong to different > > administrative domains. I looked at the reference [11]. > > towards the end of section 5.1.2 in reference [11], I > > see some text which says this kind of multi-homining > > is rare. I think you should also say that this is rare > > and is out of scope for NEMO. frankly, I think it is > > not worth solving. > > Yes, you right. I just wanted to answer at the question "Is possible > that theses HAs can be in different AS?". > > Now I will put: "Yes, _BUT_ ..." > > And I will put a paragraph on "aggrated network prefix and multiple HAs", > because it's maybe a better solution. cool. > > > in case (1,0,1) and case (1,1,1) > > for both these cases, you have assumed that each Mobile > > Router will advertise a different prefix (which is good > > makes things simpler). but is this a valid assumption? > > Yes, I make this choice because I though about this scenario: good. I also like this assumption because it makes things simpler. how about making this a requirement? > > > However, based on our analysis, > > > we propose some improvements. > > > > arent these improvements best handled by separate > > specifications? > > Hum, What did you think about ? [What kind of separate specifications > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? draft-nemo-multihoming-basic-support. (I even made it a WG document :). the WG chairs have to decide on it. any extensions, improvements, I suggest, should go into this draft. the basic suport draft currently is short and simple. it would be easy to advance it. > [If NEMO deciced to not include any preference nor > priority field nor Interface ID for NEMO basic, maybe in the next version > of NEMO it will be OK]. IMO, NEMO basic support should not include these because they are specific to multi-homing. I prefer defining new mobility options for this. you can have a Care-of Address Preference option, Interface ID option or even a Multi-homing option in draft-nemo-multihoming-basic-support. I can help you with this. Vijay From exim@www1.ietf.org Wed Jul 16 14:44:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12121 for ; Wed, 16 Jul 2003 14:44:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crG4-0005Xh-TJ for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIi805021299 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crG4-0005XS-OC for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:44:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12093 for ; Wed, 16 Jul 2003 14:44:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crG2-00024t-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:44:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crFw-00024q-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crFx-0005Vd-Du; Wed, 16 Jul 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crFZ-0005VJ-Uw for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12070 for ; Wed, 16 Jul 2003 14:43:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crFX-00024e-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:43:35 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19crFH-000246-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:43:19 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28378; Wed, 16 Jul 2003 11:42:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIgQs02997; Wed, 16 Jul 2003 11:42:26 -0700 X-mProtect: <200307161842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLlCkRF; Wed, 16 Jul 2003 11:42:24 PDT Message-ID: <3F159C90.11F898C3@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:42:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julien Charbon CC: nemo@ietf.org, ernst@sfc.wide.ad.jp, tj@kniveton.com Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Julien Charbon wrote: > > Depending on the meaning of /function/ maybe my sentence is too > oriented Load-Sharing. I will change that. okay. load sharing is a nice feature, but it shouldnt a MUST support for NEMO. it should be an optional mechanism. > > > in case (0,1,0) > > > > its a mess if the Home Agents belong to different > > administrative domains. I looked at the reference [11]. > > towards the end of section 5.1.2 in reference [11], I > > see some text which says this kind of multi-homining > > is rare. I think you should also say that this is rare > > and is out of scope for NEMO. frankly, I think it is > > not worth solving. > > Yes, you right. I just wanted to answer at the question "Is possible > that theses HAs can be in different AS?". > > Now I will put: "Yes, _BUT_ ..." > > And I will put a paragraph on "aggrated network prefix and multiple HAs", > because it's maybe a better solution. cool. > > > in case (1,0,1) and case (1,1,1) > > for both these cases, you have assumed that each Mobile > > Router will advertise a different prefix (which is good > > makes things simpler). but is this a valid assumption? > > Yes, I make this choice because I though about this scenario: good. I also like this assumption because it makes things simpler. how about making this a requirement? > > > However, based on our analysis, > > > we propose some improvements. > > > > arent these improvements best handled by separate > > specifications? > > Hum, What did you think about ? [What kind of separate specifications > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? draft-nemo-multihoming-basic-support. (I even made it a WG document :). the WG chairs have to decide on it. any extensions, improvements, I suggest, should go into this draft. the basic suport draft currently is short and simple. it would be easy to advance it. > [If NEMO deciced to not include any preference nor > priority field nor Interface ID for NEMO basic, maybe in the next version > of NEMO it will be OK]. IMO, NEMO basic support should not include these because they are specific to multi-homing. I prefer defining new mobility options for this. you can have a Care-of Address Preference option, Interface ID option or even a Multi-homing option in draft-nemo-multihoming-basic-support. I can help you with this. Vijay From nemo-admin@ietf.org Wed Jul 16 14:51:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12402 for ; Wed, 16 Jul 2003 14:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crMj-00063w-AG; Wed, 16 Jul 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crLp-00060E-Bu for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12379 for ; Wed, 16 Jul 2003 14:50:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crLm-0002B3-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:50:02 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19crLW-0002AS-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:49:46 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28805; Wed, 16 Jul 2003 11:49:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIn1M13364; Wed, 16 Jul 2003 11:49:01 -0700 X-mProtect: <200307161849> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTSGwMm; Wed, 16 Jul 2003 11:49:00 PDT Message-ID: <3F159E1C.65F0711D@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:49:00 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , cwng@psl.com.sg CC: nemo@ietf.org Subject: Re: [nemo] Issue 3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." > > > is this okay? > > If the info is to be used to delete the routes, then you need to know > which prefixes you actually created routes for, This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefix in BCE, whether they come from > implicit or explicit source". Vijay, please do not tell people how to > implement things (even if your proposal seems perfectly proper). :) I do agree that over specification is bad. but I thought it was necessary in this case. please suggest text. Chan-Wah, what do you think? (you raised this issue) Vijay From exim@www1.ietf.org Wed Jul 16 14:51:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12418 for ; Wed, 16 Jul 2003 14:51:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crMt-00066I-90 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:51:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIpB0l023444 for nemo-archive@odin.ietf.org; Wed, 16 Jul 2003 14:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crMt-000663-4T for nemo-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12395 for ; Wed, 16 Jul 2003 14:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crMq-0002BT-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crMk-0002BQ-00 for nemo-web-archive@ietf.org; Wed, 16 Jul 2003 14:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crMj-00063w-AG; Wed, 16 Jul 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crLp-00060E-Bu for nemo@optimus.ietf.org; Wed, 16 Jul 2003 14:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12379 for ; Wed, 16 Jul 2003 14:50:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crLm-0002B3-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:50:02 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19crLW-0002AS-00 for nemo@ietf.org; Wed, 16 Jul 2003 14:49:46 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28805; Wed, 16 Jul 2003 11:49:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6GIn1M13364; Wed, 16 Jul 2003 11:49:01 -0700 X-mProtect: <200307161849> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTSGwMm; Wed, 16 Jul 2003 11:49:00 PDT Message-ID: <3F159E1C.65F0711D@iprg.nokia.com> Date: Wed, 16 Jul 2003 11:49:00 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , cwng@psl.com.sg CC: nemo@ietf.org Subject: Re: [nemo] Issue 3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." > > > is this okay? > > If the info is to be used to delete the routes, then you need to know > which prefixes you actually created routes for, This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefix in BCE, whether they come from > implicit or explicit source". Vijay, please do not tell people how to > implement things (even if your proposal seems perfectly proper). :) I do agree that over specification is bad. but I thought it was necessary in this case. please suggest text. Chan-Wah, what do you think? (you raised this issue) Vijay From nemo-admin@ietf.org Thu Jul 17 03:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20437 for ; Thu, 17 Jul 2003 03:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3J3-0000M3-Kj; Thu, 17 Jul 2003 03:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Id-0000Ca-Nz for nemo@optimus.ietf.org; Thu, 17 Jul 2003 03:35:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20358 for ; Thu, 17 Jul 2003 03:35:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Ib-0002La-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:35:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19d3IQ-0002KF-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:35:22 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2003 09:33:10 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6H7V23j003621; Thu, 17 Jul 2003 09:31:02 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 09:33:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 3 Date: Thu, 17 Jul 2003 08:33:08 +0100 Message-ID: Thread-Topic: [nemo] Issue 3 Thread-Index: AcNLy1QEuk5CzR84Q2GtYNE44TImVQAajtAA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: X-OriginalArrivalTime: 17 Jul 2003 07:33:09.0463 (UTC) FILETIME=[ABBACE70:01C34C35] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 >=20 > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). >=20 > :) I do agree that over specification is bad. but I thought > it was necessary in this case. please suggest text. :) that was suggested text actually Pascal From exim@www1.ietf.org Thu Jul 17 03:37:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20497 for ; Thu, 17 Jul 2003 03:37:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Jd-0000PJ-1F for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 03:36:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7aaEk001564 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 03:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Jc-0000P7-IJ for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:36:36 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20438 for ; Thu, 17 Jul 2003 03:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3J3-0000M3-Kj; Thu, 17 Jul 2003 03:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Id-0000Ca-Nz for nemo@optimus.ietf.org; Thu, 17 Jul 2003 03:35:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20358 for ; Thu, 17 Jul 2003 03:35:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Ib-0002La-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:35:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19d3IQ-0002KF-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:35:22 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2003 09:33:10 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6H7V23j003621; Thu, 17 Jul 2003 09:31:02 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 09:33:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 3 Date: Thu, 17 Jul 2003 08:33:08 +0100 Message-ID: Thread-Topic: [nemo] Issue 3 Thread-Index: AcNLy1QEuk5CzR84Q2GtYNE44TImVQAajtAA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: X-OriginalArrivalTime: 17 Jul 2003 07:33:09.0463 (UTC) FILETIME=[ABBACE70:01C34C35] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 >=20 > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). >=20 > :) I do agree that over specification is bad. but I thought > it was necessary in this case. please suggest text. :) that was suggested text actually Pascal From nemo-admin@ietf.org Thu Jul 17 03:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21518 for ; Thu, 17 Jul 2003 03:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3cQ-0001xE-5Q; Thu, 17 Jul 2003 03:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3bV-0001vX-UD for nemo@optimus.ietf.org; Thu, 17 Jul 2003 03:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21437 for ; Thu, 17 Jul 2003 03:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3bT-0002ak-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:55:03 -0400 Received: from [81.160.169.176] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d3bI-0002Z8-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:54:52 -0400 Received: by squirrel (Postfix, from userid 1000) id 2BDAC1014CC8; Thu, 17 Jul 2003 16:18:11 +0800 (SGT) Subject: Re: [nemo] Issue 3 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <3F159E1C.65F0711D@iprg.nokia.com> References: <3F159E1C.65F0711D@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058429890.1235.16.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 16:18:10 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-07-17 at 02:49, Vijay Devarapalli wrote: > "Pascal Thubert (pthubert)" wrote: > > > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted." > > > > > is this okay? > > > > If the info is to be used to delete the routes, then you need to know > > which prefixes you actually created routes for, > > This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. > > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). > I don't think its "telling people how to implement things", just like in MIPv6, suggesting the conceptual structure of BCE should contain the home address, care-of-address, and the BU flags is not "telling people how to implement things". > :) I do agree that over specification is bad. but I thought > it was necessary in this case. please suggest text. > > Chan-Wah, what do you think? (you raised this issue) > I am okay with both text. All I wanted to make sure is that when routes are injected by the registration of a BU, the HA must have means of removing / or updating those routes when a subsequent BU comes in. /rgds /cwng From exim@www1.ietf.org Thu Jul 17 03:57:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21561 for ; Thu, 17 Jul 2003 03:57:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3cw-000222-1v for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 03:56:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7uXYc007804 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 03:56:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3cv-00021n-KG for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:56:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21519 for ; Thu, 17 Jul 2003 03:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3cQ-0001xE-5Q; Thu, 17 Jul 2003 03:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3bV-0001vX-UD for nemo@optimus.ietf.org; Thu, 17 Jul 2003 03:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21437 for ; Thu, 17 Jul 2003 03:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3bT-0002ak-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:55:03 -0400 Received: from [81.160.169.176] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d3bI-0002Z8-00 for nemo@ietf.org; Thu, 17 Jul 2003 03:54:52 -0400 Received: by squirrel (Postfix, from userid 1000) id 2BDAC1014CC8; Thu, 17 Jul 2003 16:18:11 +0800 (SGT) Subject: Re: [nemo] Issue 3 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Vijay Devarapalli Cc: Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <3F159E1C.65F0711D@iprg.nokia.com> References: <3F159E1C.65F0711D@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058429890.1235.16.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 16:18:10 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-17 at 02:49, Vijay Devarapalli wrote: > "Pascal Thubert (pthubert)" wrote: > > > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted." > > > > > is this okay? > > > > If the info is to be used to delete the routes, then you need to know > > which prefixes you actually created routes for, > > This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. > > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). > I don't think its "telling people how to implement things", just like in MIPv6, suggesting the conceptual structure of BCE should contain the home address, care-of-address, and the BU flags is not "telling people how to implement things". > :) I do agree that over specification is bad. but I thought > it was necessary in this case. please suggest text. > > Chan-Wah, what do you think? (you raised this issue) > I am okay with both text. All I wanted to make sure is that when routes are injected by the registration of a BU, the HA must have means of removing / or updating those routes when a subsequent BU comes in. /rgds /cwng From nemo-admin@ietf.org Thu Jul 17 04:16:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22385 for ; Thu, 17 Jul 2003 04:16:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vn-0003a1-Jj; Thu, 17 Jul 2003 04:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3v6-0003ZX-UI for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22322 for ; Thu, 17 Jul 2003 04:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3v3-0002t3-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19d3us-0002sW-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:06 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2003 10:14:32 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6H8CN7p013171; Thu, 17 Jul 2003 10:12:24 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 10:14:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jul 2003 09:14:30 +0100 Message-ID: Thread-Topic: Issue 7 Thread-Index: AcNLfNCbMgPxmqvXQmKSOPJqNO+5fwAvk7UQ From: "Pascal Thubert (pthubert)" To: "S. Felix Wu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 17 Jul 2003 08:14:31.0354 (UTC) FILETIME=[730D51A0:01C34C3B] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: S. Felix Wu [mailto:wu@cs.ucdavis.edu] > Sent: mercredi 16 juillet 2003 11:15 > To: Vijay Devarapalli > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 >=20 > A couple questions related to the relationship between prefix BU and > routing protocol exchanges between MR and HA: >=20 > Vijay Devarapalli wrote: > >>> When the Mobile Router and the Home Agent exchange routes > >>> through routing protocol updates, the Home Agent MUST NOT > >>> create routes to the Mobile network when the Binding Update > >>> from the Mobile Router is received. The Mobile Router also > >>> MUST NOT include any prefix information in the Binding Update. > >>> Any routes to the Mobile Network are created at the Home > >>> Agent through routing protocol updates. > > > > isnt it redundant to include prefix information in the > > binding update if routes are being exchanged through a > > dynamic routing protocol? >=20 > In regular router configuration, we have static configured routes > and routes learned dynamically from routing protocols such as RIP > or OSPF. They both exist in the regular routers. Aren't the prefixes > being announced via BU under NEMO like static routes in the regular > world, while we at the same time have dynamic routes for other > prefixes using the MR (from the HA point of view)? >=20 > It seems to me that this is a configuration/operation issue. >=20 Yes :) > While I agree that the option in discussion (having both BU and > dynamic routing updates for prefixes between a particular pair of > HA and MR) may be redundent, I wonder in practice whether there > are scenarios that we have to have both? >=20 Same here > > well, you want the protocol to be efficient, right? > > when a dynamic routing protocol is being used, including > > prefix information in the binding update is both > > redundant and involves an overhead in terms of the size > > of binding udpate. >=20 > I have actually a question regarding the prefix table, which in > NEMO the HA will use it to check if the MR has the right/ownership > to announce the prefix. First, I assume that, for both BU and dynamic > routing updates, the HA has to check the table before accepting a > route/binding of MR to prefixes. Second, the content of the prefix > table should be maintained correctly by the system administrators. > (This process is actually a tricky one in some cases.) I support calling this issue 7. Pascal From nemo-admin@ietf.org Thu Jul 17 04:16:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22400 for ; Thu, 17 Jul 2003 04:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vs-0003ao-Pf; Thu, 17 Jul 2003 04:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vK-0003Zc-Re for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22325 for ; Thu, 17 Jul 2003 04:15:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3vI-0002tG-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19d3v7-0002sX-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:21 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6H8EKuD018975; Thu, 17 Jul 2003 01:14:20 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG55538; Thu, 17 Jul 2003 01:11:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 01:14:09 -0700 To: "S. Felix Wu" From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Vijay Devarapalli , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F1517AC.9010305@cs.ucdavis.edu> References: <3F12ECBD.4852B5FB@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Felix. At 02:15 AM 7/16/2003 -0700, S. Felix Wu wrote: >A couple questions related to the relationship between prefix BU and >routing protocol exchanges between MR and HA: > >Vijay Devarapalli wrote: >>>> When the Mobile Router and the Home Agent exchange routes >>>> through routing protocol updates, the Home Agent MUST NOT >>>> create routes to the Mobile network when the Binding Update >>>> from the Mobile Router is received. The Mobile Router also >>>> MUST NOT include any prefix information in the Binding Update. >>>> Any routes to the Mobile Network are created at the Home >>>> Agent through routing protocol updates. > > >>isnt it redundant to include prefix information in the >>binding update if routes are being exchanged through a >>dynamic routing protocol? > >In regular router configuration, we have static configured routes >and routes learned dynamically from routing protocols such as RIP >or OSPF. They both exist in the regular routers. Aren't the prefixes >being announced via BU under NEMO like static routes in the regular >world, while we at the same time have dynamic routes for other >prefixes using the MR (from the HA point of view)? I would see the prefixes info as dynamic NEMO route updates. As Pascal said, there not much difference between two routers exchanging routes via 2 IGPs and administrative metrics selects the preferred route. >It seems to me that this is a configuration/operation issue. Yes I agree. >While I agree that the option in discussion (having both BU and >dynamic routing updates for prefixes between a particular pair of >HA and MR) may be redundent, I wonder in practice whether there >are scenarios that we have to have both? In practice, not sure why anyone would do this. But then the base NEMO should not get into config/operation issue, IMHO, and preclude such possibility. Someone can always dream up some wild scenario where they use functions that weren't foreseen to solve their problems. >>well, you want the protocol to be efficient, right? >>when a dynamic routing protocol is being used, including >>prefix information in the binding update is both redundant and involves >>an overhead in terms of the size >>of binding udpate. I think the base NEMO should be basic and flexible. Best Practices and Informational drafts may be published in the future based on real world deployments. Probably too early to preclude anything that is not obviously detrimental to the health of NEMO itself. Kent >I have actually a question regarding the prefix table, which in >NEMO the HA will use it to check if the MR has the right/ownership >to announce the prefix. First, I assume that, for both BU and dynamic >routing updates, the HA has to check the table before accepting a >route/binding of MR to prefixes. Second, the content of the prefix >table should be maintained correctly by the system administrators. >(This process is actually a tricky one in some cases.) > >According to the current drafts, it seems to me that it is possible >that two different MRs can be allowed to announce the same prefix (e.g., >169.237.6/24): > > prefix table: > 169.237.6/24 MR1, MR2 > >Or, maybe more interestingly, MR1 will announce a more specific prefix >(e.g., 169.237.6/25) to HA, and the HA should be OK with it. >Therefore, it is possible while MR1 is authorized to own 169.237.6/24, >it actually only has a smaller portion of it (169.237.6/25) at a >particular moment of time. That is why we might need dynamic routing >protocol to reflect that change. > >Is that right? (just try to get clarified....) >Thanks. >-Felix > >-- >---------------------------------------------------------------------- >Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu >Associate Professor http://www.cs.ucdavis.edu/~wu >Computer Science Department office: 1-530-754-7070 >University of California at Davis fax: 1-530-752-4767 >---------------------------------------------------------------------- > > From exim@www1.ietf.org Thu Jul 17 04:16:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22417 for ; Thu, 17 Jul 2003 04:16:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3w2-0003g6-Dz for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:16:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8GIw8014132 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3w2-0003fr-2g for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22349 for ; Thu, 17 Jul 2003 04:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3vz-0002tr-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:16:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3vu-0002tj-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:16:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vn-0003a1-Jj; Thu, 17 Jul 2003 04:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3v6-0003ZX-UI for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22322 for ; Thu, 17 Jul 2003 04:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3v3-0002t3-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19d3us-0002sW-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:06 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2003 10:14:32 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6H8CN7p013171; Thu, 17 Jul 2003 10:12:24 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 10:14:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jul 2003 09:14:30 +0100 Message-ID: Thread-Topic: Issue 7 Thread-Index: AcNLfNCbMgPxmqvXQmKSOPJqNO+5fwAvk7UQ From: "Pascal Thubert (pthubert)" To: "S. Felix Wu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 17 Jul 2003 08:14:31.0354 (UTC) FILETIME=[730D51A0:01C34C3B] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: S. Felix Wu [mailto:wu@cs.ucdavis.edu] > Sent: mercredi 16 juillet 2003 11:15 > To: Vijay Devarapalli > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 >=20 > A couple questions related to the relationship between prefix BU and > routing protocol exchanges between MR and HA: >=20 > Vijay Devarapalli wrote: > >>> When the Mobile Router and the Home Agent exchange routes > >>> through routing protocol updates, the Home Agent MUST NOT > >>> create routes to the Mobile network when the Binding Update > >>> from the Mobile Router is received. The Mobile Router also > >>> MUST NOT include any prefix information in the Binding Update. > >>> Any routes to the Mobile Network are created at the Home > >>> Agent through routing protocol updates. > > > > isnt it redundant to include prefix information in the > > binding update if routes are being exchanged through a > > dynamic routing protocol? >=20 > In regular router configuration, we have static configured routes > and routes learned dynamically from routing protocols such as RIP > or OSPF. They both exist in the regular routers. Aren't the prefixes > being announced via BU under NEMO like static routes in the regular > world, while we at the same time have dynamic routes for other > prefixes using the MR (from the HA point of view)? >=20 > It seems to me that this is a configuration/operation issue. >=20 Yes :) > While I agree that the option in discussion (having both BU and > dynamic routing updates for prefixes between a particular pair of > HA and MR) may be redundent, I wonder in practice whether there > are scenarios that we have to have both? >=20 Same here > > well, you want the protocol to be efficient, right? > > when a dynamic routing protocol is being used, including > > prefix information in the binding update is both > > redundant and involves an overhead in terms of the size > > of binding udpate. >=20 > I have actually a question regarding the prefix table, which in > NEMO the HA will use it to check if the MR has the right/ownership > to announce the prefix. First, I assume that, for both BU and dynamic > routing updates, the HA has to check the table before accepting a > route/binding of MR to prefixes. Second, the content of the prefix > table should be maintained correctly by the system administrators. > (This process is actually a tricky one in some cases.) I support calling this issue 7. Pascal From exim@www1.ietf.org Thu Jul 17 04:16:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22416 for ; Thu, 17 Jul 2003 04:16:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3w2-0003gO-PS for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:16:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8GIts014150 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3w2-0003g8-GP for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22352 for ; Thu, 17 Jul 2003 04:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3vz-0002tw-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:16:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3vu-0002tt-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:16:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vs-0003ao-Pf; Thu, 17 Jul 2003 04:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3vK-0003Zc-Re for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22325 for ; Thu, 17 Jul 2003 04:15:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3vI-0002tG-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19d3v7-0002sX-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:15:21 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6H8EKuD018975; Thu, 17 Jul 2003 01:14:20 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG55538; Thu, 17 Jul 2003 01:11:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 01:14:09 -0700 To: "S. Felix Wu" From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Vijay Devarapalli , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F1517AC.9010305@cs.ucdavis.edu> References: <3F12ECBD.4852B5FB@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Felix. At 02:15 AM 7/16/2003 -0700, S. Felix Wu wrote: >A couple questions related to the relationship between prefix BU and >routing protocol exchanges between MR and HA: > >Vijay Devarapalli wrote: >>>> When the Mobile Router and the Home Agent exchange routes >>>> through routing protocol updates, the Home Agent MUST NOT >>>> create routes to the Mobile network when the Binding Update >>>> from the Mobile Router is received. The Mobile Router also >>>> MUST NOT include any prefix information in the Binding Update. >>>> Any routes to the Mobile Network are created at the Home >>>> Agent through routing protocol updates. > > >>isnt it redundant to include prefix information in the >>binding update if routes are being exchanged through a >>dynamic routing protocol? > >In regular router configuration, we have static configured routes >and routes learned dynamically from routing protocols such as RIP >or OSPF. They both exist in the regular routers. Aren't the prefixes >being announced via BU under NEMO like static routes in the regular >world, while we at the same time have dynamic routes for other >prefixes using the MR (from the HA point of view)? I would see the prefixes info as dynamic NEMO route updates. As Pascal said, there not much difference between two routers exchanging routes via 2 IGPs and administrative metrics selects the preferred route. >It seems to me that this is a configuration/operation issue. Yes I agree. >While I agree that the option in discussion (having both BU and >dynamic routing updates for prefixes between a particular pair of >HA and MR) may be redundent, I wonder in practice whether there >are scenarios that we have to have both? In practice, not sure why anyone would do this. But then the base NEMO should not get into config/operation issue, IMHO, and preclude such possibility. Someone can always dream up some wild scenario where they use functions that weren't foreseen to solve their problems. >>well, you want the protocol to be efficient, right? >>when a dynamic routing protocol is being used, including >>prefix information in the binding update is both redundant and involves >>an overhead in terms of the size >>of binding udpate. I think the base NEMO should be basic and flexible. Best Practices and Informational drafts may be published in the future based on real world deployments. Probably too early to preclude anything that is not obviously detrimental to the health of NEMO itself. Kent >I have actually a question regarding the prefix table, which in >NEMO the HA will use it to check if the MR has the right/ownership >to announce the prefix. First, I assume that, for both BU and dynamic >routing updates, the HA has to check the table before accepting a >route/binding of MR to prefixes. Second, the content of the prefix >table should be maintained correctly by the system administrators. >(This process is actually a tricky one in some cases.) > >According to the current drafts, it seems to me that it is possible >that two different MRs can be allowed to announce the same prefix (e.g., >169.237.6/24): > > prefix table: > 169.237.6/24 MR1, MR2 > >Or, maybe more interestingly, MR1 will announce a more specific prefix >(e.g., 169.237.6/25) to HA, and the HA should be OK with it. >Therefore, it is possible while MR1 is authorized to own 169.237.6/24, >it actually only has a smaller portion of it (169.237.6/25) at a >particular moment of time. That is why we might need dynamic routing >protocol to reflect that change. > >Is that right? (just try to get clarified....) >Thanks. >-Felix > >-- >---------------------------------------------------------------------- >Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu >Associate Professor http://www.cs.ucdavis.edu/~wu >Computer Science Department office: 1-530-754-7070 >University of California at Davis fax: 1-530-752-4767 >---------------------------------------------------------------------- > > From nemo-admin@ietf.org Thu Jul 17 04:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22648 for ; Thu, 17 Jul 2003 04:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41Z-00046a-0y; Thu, 17 Jul 2003 04:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41T-00044W-FN for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22614 for ; Thu, 17 Jul 2003 04:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d41Q-000302-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:21:52 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19d41A-0002z1-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:21:37 -0400 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 952F85D0C5; Thu, 17 Jul 2003 17:20:38 +0900 (JST) Date: Thu, 17 Jul 2003 17:17:42 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: julien@sfc.wide.ad.jp, tj@kniveton.com, Vijay Devarapalli Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Message-Id: <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> In-Reply-To: <3F159C90.11F898C3@iprg.nokia.com> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Depending on the meaning of /function/ maybe my sentence is too > > oriented Load-Sharing. I will change that. > > okay. load sharing is a nice feature, but it shouldnt a > MUST support for NEMO. it should be an optional mechanism. In draft-ietf-nemo-requirements we have: R18: The solution SHOULD preserve sessions established through another egress interface when one fails [PROPOSED BY EDITOR OF THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE MAILING LIST] So far, I put "SHOULD". It may even by "MAY", or requirement could be removed because it's not a NEMO issue. Thoughts on this are appreciated to clarify the requirements draft. > > Hum, What did you think about ? [What kind of separate specifications > > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > draft-nemo-multihoming-basic-support. (I even made it a > WG document :). the WG chairs have to decide on it. any > extensions, improvements, I suggest, should go into this > draft. the basic suport draft currently is short and > simple. it would be easy to advance it. The decision doesn't belong to the chairs, but to the WG. Indeed, we asked if the multihoming analysis should become a WG document: show of hands is about +30 "YES", none "NO". I agree the basic support draft should not speak about that (but make sure it provides room for the needed extensions, so we should be careful about this). > > > [If NEMO deciced to not include any preference nor > > priority field nor Interface ID for NEMO basic, maybe in the next version > > of NEMO it will be OK]. > > IMO, NEMO basic support should not include these because > they are specific to multi-homing. I prefer defining new > mobility options for this. you can have a Care-of Address > Preference option, Interface ID option or even a > Multi-homing option in > draft-nemo-multihoming-basic-support. I can help you with > this. This is a good direction, I think. Thierry. From exim@www1.ietf.org Thu Jul 17 04:22:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22663 for ; Thu, 17 Jul 2003 04:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41f-0004Bt-Ll for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8M7q2016094 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41f-0004BM-FC for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:22:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22623 for ; Thu, 17 Jul 2003 04:22:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d41c-00030P-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:22:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d41X-00030M-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 04:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41Z-00046a-0y; Thu, 17 Jul 2003 04:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d41T-00044W-FN for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22614 for ; Thu, 17 Jul 2003 04:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d41Q-000302-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:21:52 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19d41A-0002z1-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:21:37 -0400 Received: from localhost.nautilus6.org (unknown [81.160.206.92]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 952F85D0C5; Thu, 17 Jul 2003 17:20:38 +0900 (JST) Date: Thu, 17 Jul 2003 17:17:42 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: julien@sfc.wide.ad.jp, tj@kniveton.com, Vijay Devarapalli Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation Message-Id: <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> In-Reply-To: <3F159C90.11F898C3@iprg.nokia.com> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Depending on the meaning of /function/ maybe my sentence is too > > oriented Load-Sharing. I will change that. > > okay. load sharing is a nice feature, but it shouldnt a > MUST support for NEMO. it should be an optional mechanism. In draft-ietf-nemo-requirements we have: R18: The solution SHOULD preserve sessions established through another egress interface when one fails [PROPOSED BY EDITOR OF THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE MAILING LIST] So far, I put "SHOULD". It may even by "MAY", or requirement could be removed because it's not a NEMO issue. Thoughts on this are appreciated to clarify the requirements draft. > > Hum, What did you think about ? [What kind of separate specifications > > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > draft-nemo-multihoming-basic-support. (I even made it a > WG document :). the WG chairs have to decide on it. any > extensions, improvements, I suggest, should go into this > draft. the basic suport draft currently is short and > simple. it would be easy to advance it. The decision doesn't belong to the chairs, but to the WG. Indeed, we asked if the multihoming analysis should become a WG document: show of hands is about +30 "YES", none "NO". I agree the basic support draft should not speak about that (but make sure it provides room for the needed extensions, so we should be careful about this). > > > [If NEMO deciced to not include any preference nor > > priority field nor Interface ID for NEMO basic, maybe in the next version > > of NEMO it will be OK]. > > IMO, NEMO basic support should not include these because > they are specific to multi-homing. I prefer defining new > mobility options for this. you can have a Care-of Address > Preference option, Interface ID option or even a > Multi-homing option in > draft-nemo-multihoming-basic-support. I can help you with > this. This is a good direction, I think. Thierry. From nemo-admin@ietf.org Thu Jul 17 04:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23782 for ; Thu, 17 Jul 2003 04:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Sf-0006Oj-6D; Thu, 17 Jul 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4SP-0006O4-Fc for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:49:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23731 for ; Thu, 17 Jul 2003 04:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4SM-0003Qj-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:49:42 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19d4SB-0003Qd-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:49:31 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6H8nPnX013793; Thu, 17 Jul 2003 10:49:25 +0200 Message-ID: <3F166149.6000205@dpt-info.u-strasbg.fr> Date: Thu, 17 Jul 2003 10:41:45 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa , mobileip , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] multiple CoAs registration Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ryuji, I read your draft on multiple CoAs registration and I also think that we really need to define a solution to use MIPv6 with a multiple interfaces MN. Here are some comments on your draft: - Why do you introduce the interface identification (IFID) ? It could be sufficient to only register a CoA with the associated priority. Therefore, when the MN has to choose the destination address for a HoA, it can take the most preferred CoA, which is bound to the most preferred interface of the MN. Anyway you use a one-to-one mapping between a CoA and a IFID, therefore you don't need both, or I missed a point ? IMO, this is easier than all the mechanism to manage the IFID (generation, maintenance...) - If I well understand your draft, when the MN registers a CoA with a CN, the MN has to first register the primary CoA. Then it can send a Binding Update (after the RR procedure) to regsiter other CoA(s), with the associated priority. However, you say that the lowest priority is the preferred CoA/IF, and that the primary CoA has the priority 0. Therefore, each CN will use the primary CoA with the MN. Then, you are not able to perform load balancing, aren't you ? - Last point: If you return home with your primary interface (you connect to your home network with P-IF), do you have to de-register all CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? Regards, Nicolas From exim@www1.ietf.org Thu Jul 17 04:51:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23805 for ; Thu, 17 Jul 2003 04:51:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4TF-0006US-M9 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:50:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8obqc024947 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 04:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4TF-0006UI-GM for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:50:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23783 for ; Thu, 17 Jul 2003 04:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Sf-0006Oj-6D; Thu, 17 Jul 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4SP-0006O4-Fc for nemo@optimus.ietf.org; Thu, 17 Jul 2003 04:49:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23731 for ; Thu, 17 Jul 2003 04:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4SM-0003Qj-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:49:42 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19d4SB-0003Qd-00 for nemo@ietf.org; Thu, 17 Jul 2003 04:49:31 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6H8nPnX013793; Thu, 17 Jul 2003 10:49:25 +0200 Message-ID: <3F166149.6000205@dpt-info.u-strasbg.fr> Date: Thu, 17 Jul 2003 10:41:45 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa , mobileip , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] multiple CoAs registration Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ryuji, I read your draft on multiple CoAs registration and I also think that we really need to define a solution to use MIPv6 with a multiple interfaces MN. Here are some comments on your draft: - Why do you introduce the interface identification (IFID) ? It could be sufficient to only register a CoA with the associated priority. Therefore, when the MN has to choose the destination address for a HoA, it can take the most preferred CoA, which is bound to the most preferred interface of the MN. Anyway you use a one-to-one mapping between a CoA and a IFID, therefore you don't need both, or I missed a point ? IMO, this is easier than all the mechanism to manage the IFID (generation, maintenance...) - If I well understand your draft, when the MN registers a CoA with a CN, the MN has to first register the primary CoA. Then it can send a Binding Update (after the RR procedure) to regsiter other CoA(s), with the associated priority. However, you say that the lowest priority is the preferred CoA/IF, and that the primary CoA has the priority 0. Therefore, each CN will use the primary CoA with the MN. Then, you are not able to perform load balancing, aren't you ? - Last point: If you return home with your primary interface (you connect to your home network with P-IF), do you have to de-register all CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? Regards, Nicolas From nemo-admin@ietf.org Thu Jul 17 05:05:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24345 for ; Thu, 17 Jul 2003 05:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hA-0007n0-Ry; Thu, 17 Jul 2003 05:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gP-0007mH-Tm for nemo@optimus.ietf.org; Thu, 17 Jul 2003 05:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24271 for ; Thu, 17 Jul 2003 05:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4gM-0003WQ-00 for nemo@ietf.org; Thu, 17 Jul 2003 05:04:10 -0400 Received: from [81.160.248.11] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d4gB-0003V6-00 for nemo@ietf.org; Thu, 17 Jul 2003 05:04:00 -0400 Received: by squirrel (Postfix, from userid 1000) id 678731014CC8; Thu, 17 Jul 2003 16:59:43 +0800 (SGT) Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Thierry Ernst Cc: IETF NEMO WG , Julien Charbon , "T.J. Kniveton" , Vijay Devarapalli In-Reply-To: <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058432382.1226.7.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 16:59:42 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-07-17 at 16:17, Thierry Ernst wrote: > > > Depending on the meaning of /function/ maybe my sentence is too > > > oriented Load-Sharing. I will change that. > > > > okay. load sharing is a nice feature, but it shouldnt a > > MUST support for NEMO. it should be an optional mechanism. > > In draft-ietf-nemo-requirements we have: > > R18: The solution SHOULD preserve sessions established through > another egress interface when one fails [PROPOSED BY EDITOR OF > THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE > MAILING LIST] > > So far, I put "SHOULD". It may even by "MAY", or requirement could be > removed because it's not a NEMO issue. Thoughts on this are appreciated > to clarify the requirements draft. I would say ts okay to be a SHOULD or a MAY, but it should remain. It may not seems like a NEMO issue, but you must consider that NEMO would experience this problem more often then other multihomed networks. But of-course, I may be biased! ;) > > > > Hum, What did you think about ? [What kind of separate specifications > > > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > > > draft-nemo-multihoming-basic-support. (I even made it a > > WG document :). the WG chairs have to decide on it. any > > extensions, improvements, I suggest, should go into this > > draft. the basic suport draft currently is short and > > simple. it would be easy to advance it. > > The decision doesn't belong to the chairs, but to the WG. Indeed, we > asked if the multihoming analysis should become a WG document: show of > hands is about +30 "YES", none "NO". I agree the basic support draft > should not speak about that (but make sure it provides room for the > needed extensions, so we should be careful about this). > I thank the WG for accepting it. I will propose combining draft-ng-multihoming-issues and draft-charbon-nemo-evaluation into a single draft-ietf-nemo-multihoming-basic-support. /rgds /cwng From exim@www1.ietf.org Thu Jul 17 05:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24360 for ; Thu, 17 Jul 2003 05:05:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hI-0007qi-LH for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H958jN030168 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 05:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hI-0007qR-Fu for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:05:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24291 for ; Thu, 17 Jul 2003 05:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4hF-0003Wz-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 05:05:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4h9-0003Ww-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 05:04:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4hA-0007n0-Ry; Thu, 17 Jul 2003 05:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4gP-0007mH-Tm for nemo@optimus.ietf.org; Thu, 17 Jul 2003 05:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24271 for ; Thu, 17 Jul 2003 05:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4gM-0003WQ-00 for nemo@ietf.org; Thu, 17 Jul 2003 05:04:10 -0400 Received: from [81.160.248.11] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d4gB-0003V6-00 for nemo@ietf.org; Thu, 17 Jul 2003 05:04:00 -0400 Received: by squirrel (Postfix, from userid 1000) id 678731014CC8; Thu, 17 Jul 2003 16:59:43 +0800 (SGT) Subject: Re: [nemo] Re: Comments on draft-charbon-nemo-multihoming-evaluation From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Thierry Ernst Cc: IETF NEMO WG , Julien Charbon , "T.J. Kniveton" , Vijay Devarapalli In-Reply-To: <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058432382.1226.7.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 16:59:42 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-07-17 at 16:17, Thierry Ernst wrote: > > > Depending on the meaning of /function/ maybe my sentence is too > > > oriented Load-Sharing. I will change that. > > > > okay. load sharing is a nice feature, but it shouldnt a > > MUST support for NEMO. it should be an optional mechanism. > > In draft-ietf-nemo-requirements we have: > > R18: The solution SHOULD preserve sessions established through > another egress interface when one fails [PROPOSED BY EDITOR OF > THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE > MAILING LIST] > > So far, I put "SHOULD". It may even by "MAY", or requirement could be > removed because it's not a NEMO issue. Thoughts on this are appreciated > to clarify the requirements draft. I would say ts okay to be a SHOULD or a MAY, but it should remain. It may not seems like a NEMO issue, but you must consider that NEMO would experience this problem more often then other multihomed networks. But of-course, I may be biased! ;) > > > > Hum, What did you think about ? [What kind of separate specifications > > > I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ? > > > > draft-nemo-multihoming-basic-support. (I even made it a > > WG document :). the WG chairs have to decide on it. any > > extensions, improvements, I suggest, should go into this > > draft. the basic suport draft currently is short and > > simple. it would be easy to advance it. > > The decision doesn't belong to the chairs, but to the WG. Indeed, we > asked if the multihoming analysis should become a WG document: show of > hands is about +30 "YES", none "NO". I agree the basic support draft > should not speak about that (but make sure it provides room for the > needed extensions, so we should be careful about this). > I thank the WG for accepting it. I will propose combining draft-ng-multihoming-issues and draft-charbon-nemo-evaluation into a single draft-ietf-nemo-multihoming-basic-support. /rgds /cwng From nemo-admin@ietf.org Thu Jul 17 06:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28269 for ; Thu, 17 Jul 2003 06:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5kz-00051c-Uu; Thu, 17 Jul 2003 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5kE-00050d-01 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28225 for ; Thu, 17 Jul 2003 06:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d5kA-0004JY-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:12:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19d5jz-0004Iz-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:11:59 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HAB889026278 for ; Thu, 17 Jul 2003 03:11:08 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG61510; Thu, 17 Jul 2003 03:07:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 03:10:59 -0700 To: nemo@ietf.org From: Kent Leung Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Explicit combined mode name Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A nit. The "Explicit combined" mode is confusing to me. Combined with what? Just a suggestion, marked by "->". Explicit: -> Explicit Network In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the Mobile Network. Explicit combined: -> Explicit Prefix Length In this mode, the Mobile Router instructs the Home Agent to derive the Mobile Network Prefix by using: (1) the Home Address in the Home Address Option carried in the Destination Options header of the same packet that carries the Mobility Header containing this Binding Update and (2) the prefix length carried in the Mobile Network Prefix Length Option. In this case, Mobile Router includes one and only one Mobile Network Prefix Length Option. It MUST not include a Mobile Network Prefix Option if this method is used. Kent From exim@www1.ietf.org Thu Jul 17 06:13:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28284 for ; Thu, 17 Jul 2003 06:13:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5l9-00052p-8H for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HADBVg019385 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5l9-00052a-3E for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 06:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28262 for ; Thu, 17 Jul 2003 06:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d5l5-0004Kn-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:13:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d5kz-0004Kk-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5kz-00051c-Uu; Thu, 17 Jul 2003 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d5kE-00050d-01 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28225 for ; Thu, 17 Jul 2003 06:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d5kA-0004JY-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:12:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19d5jz-0004Iz-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:11:59 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HAB889026278 for ; Thu, 17 Jul 2003 03:11:08 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG61510; Thu, 17 Jul 2003 03:07:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 03:10:59 -0700 To: nemo@ietf.org From: Kent Leung Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Explicit combined mode name Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A nit. The "Explicit combined" mode is confusing to me. Combined with what? Just a suggestion, marked by "->". Explicit: -> Explicit Network In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the Mobile Network. Explicit combined: -> Explicit Prefix Length In this mode, the Mobile Router instructs the Home Agent to derive the Mobile Network Prefix by using: (1) the Home Address in the Home Address Option carried in the Destination Options header of the same packet that carries the Mobility Header containing this Binding Update and (2) the prefix length carried in the Mobile Network Prefix Length Option. In this case, Mobile Router includes one and only one Mobile Network Prefix Length Option. It MUST not include a Mobile Network Prefix Option if this method is used. Kent From nemo-admin@ietf.org Thu Jul 17 06:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28793 for ; Thu, 17 Jul 2003 06:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64K-00062B-Mi; Thu, 17 Jul 2003 06:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64C-000620-Bn for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28766 for ; Thu, 17 Jul 2003 06:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d648-0004V9-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:32:48 -0400 Received: from [194.201.150.21] (helo=gatekeeper.panasonic-owl.co.uk) by ietf-mx with smtp (Exim 4.12) id 19d63x-0004Uc-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:32:37 -0400 Received: from mailhost.panasonic-owl.co.uk (unverified) by gatekeeper.panasonic-owl.co.uk (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 17 Jul 2003 11:27:50 +0100 Received: from ferret ([10.96.152.109]) by mailhost.panasonic-owl.co.uk with Microsoft SMTPSVC (5.0.2195.5329); Thu, 17 Jul 2003 11:30:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 To: nemo@ietf.org From: Colm McCartan Organization: Panasonic OWL Date: Thu, 17 Jul 2003 11:30:41 +0100 Message-ID: User-Agent: Opera7.02/Win32 M2 build 2668 X-OriginalArrivalTime: 17 Jul 2003 10:30:41.0990 (UTC) FILETIME=[79216E60:01C34C4E] Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] NEMO additional server availability Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello all, We are having difficulty connecting to the Additional NEMO webpage=20 referenced from the group's IETF homepage, i.e. the url: http://www.nal.motlabs.com/nemo/ On Tuesday, we saw reports that the hostname could not be resolved and=20 today, although we can now get an IP address, the server appears to be=20 refusing connections. Apologies=A0if we have missed any announcements to th= e=20 list but are other people having success in accessing the page? Many thanks, Colm McCartan --=20 ...................................................................... colm.mccartan@panasonic-owl.co.uk ***************************************************************************= ***** CONFIDENTIALITY NOTICE The information contained in this Email, and any attachment is intended for= the=20 named recipient(s) only. It may contain confidential and / or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y=20 mistake, please advise the sender by using the reply facility in your Email= software, and then delete it. ***************************************************************************= ***** From exim@www1.ietf.org Thu Jul 17 06:33:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28811 for ; Thu, 17 Jul 2003 06:33:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64U-00063F-PV for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HAXAWS023257 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64U-000632-MA for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 06:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28781 for ; Thu, 17 Jul 2003 06:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d64Q-0004VW-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d64L-0004VT-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64K-00062B-Mi; Thu, 17 Jul 2003 06:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d64C-000620-Bn for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28766 for ; Thu, 17 Jul 2003 06:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d648-0004V9-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:32:48 -0400 Received: from [194.201.150.21] (helo=gatekeeper.panasonic-owl.co.uk) by ietf-mx with smtp (Exim 4.12) id 19d63x-0004Uc-00 for nemo@ietf.org; Thu, 17 Jul 2003 06:32:37 -0400 Received: from mailhost.panasonic-owl.co.uk (unverified) by gatekeeper.panasonic-owl.co.uk (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 17 Jul 2003 11:27:50 +0100 Received: from ferret ([10.96.152.109]) by mailhost.panasonic-owl.co.uk with Microsoft SMTPSVC (5.0.2195.5329); Thu, 17 Jul 2003 11:30:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 To: nemo@ietf.org From: Colm McCartan Organization: Panasonic OWL Date: Thu, 17 Jul 2003 11:30:41 +0100 Message-ID: User-Agent: Opera7.02/Win32 M2 build 2668 X-OriginalArrivalTime: 17 Jul 2003 10:30:41.0990 (UTC) FILETIME=[79216E60:01C34C4E] Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] NEMO additional server availability Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello all, We are having difficulty connecting to the Additional NEMO webpage=20 referenced from the group's IETF homepage, i.e. the url: http://www.nal.motlabs.com/nemo/ On Tuesday, we saw reports that the hostname could not be resolved and=20 today, although we can now get an IP address, the server appears to be=20 refusing connections. Apologies=A0if we have missed any announcements to th= e=20 list but are other people having success in accessing the page? Many thanks, Colm McCartan --=20 ...................................................................... colm.mccartan@panasonic-owl.co.uk ***************************************************************************= ***** CONFIDENTIALITY NOTICE The information contained in this Email, and any attachment is intended for= the=20 named recipient(s) only. It may contain confidential and / or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y=20 mistake, please advise the sender by using the reply facility in your Email= software, and then delete it. ***************************************************************************= ***** From nemo-admin@ietf.org Thu Jul 17 06:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28913 for ; Thu, 17 Jul 2003 06:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d66H-0006TC-Bt; Thu, 17 Jul 2003 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d65r-0006E2-Pk for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:34:36 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28850 for ; Thu, 17 Jul 2003 06:34:29 -0400 (EDT) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2003 03:28:41 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6HASxuG005356; Thu, 17 Jul 2003 03:28:59 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG62326; Thu, 17 Jul 2003 03:25:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 03:28:48 -0700 To: cwng@psl.com.sg From: Kent Leung Subject: Re: [nemo] Issue 3 Cc: Vijay Devarapalli , Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <1058429890.1235.16.camel@squirrel> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 04:18 PM 7/17/2003 +0800, Chan-Wah Ng wrote: >I am okay with both text. All I wanted to make sure is that when routes >are injected by the registration of a BU, the HA must have means of >removing / or updating those routes when a subsequent BU comes in. > >/rgds >/cwng Then the goal is clear and consensual. > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." This text may be a bit too specific and incomplete. One can incorrectly interpret that route is only deleted when BCE is deleted. >I would have preferred a text saying that "the MR MUST keep all >necessary information to clean up whichever routes it installed, for >instance by keeping the list of prefix in BCE, whether they come from >implicit or explicit source". Vijay, please do not tell people how to >implement things (even if your proposal seems perfectly proper). >Pascal This text doesn't cover the case when routes need to be re-injected into the routing table. My suggestion: "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." Kent From exim@www1.ietf.org Thu Jul 17 06:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28929 for ; Thu, 17 Jul 2003 06:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d66N-0006eU-LR for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HAZ7Ad025564 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 06:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d66N-0006eF-HW for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 06:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28892 for ; Thu, 17 Jul 2003 06:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d66J-0004Wl-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d66E-0004Wi-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 06:34:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d66H-0006TC-Bt; Thu, 17 Jul 2003 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d65r-0006E2-Pk for nemo@optimus.ietf.org; Thu, 17 Jul 2003 06:34:36 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28850 for ; Thu, 17 Jul 2003 06:34:29 -0400 (EDT) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2003 03:28:41 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6HASxuG005356; Thu, 17 Jul 2003 03:28:59 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-81.cisco.com [10.21.64.81]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJG62326; Thu, 17 Jul 2003 03:25:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 03:28:48 -0700 To: cwng@psl.com.sg From: Kent Leung Subject: Re: [nemo] Issue 3 Cc: Vijay Devarapalli , Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <1058429890.1235.16.camel@squirrel> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 04:18 PM 7/17/2003 +0800, Chan-Wah Ng wrote: >I am okay with both text. All I wanted to make sure is that when routes >are injected by the registration of a BU, the HA must have means of >removing / or updating those routes when a subsequent BU comes in. > >/rgds >/cwng Then the goal is clear and consensual. > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." This text may be a bit too specific and incomplete. One can incorrectly interpret that route is only deleted when BCE is deleted. >I would have preferred a text saying that "the MR MUST keep all >necessary information to clean up whichever routes it installed, for >instance by keeping the list of prefix in BCE, whether they come from >implicit or explicit source". Vijay, please do not tell people how to >implement things (even if your proposal seems perfectly proper). >Pascal This text doesn't cover the case when routes need to be re-injected into the routing table. My suggestion: "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." Kent From nemo-admin@ietf.org Thu Jul 17 07:22:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00018 for ; Thu, 17 Jul 2003 07:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6pl-0001It-JN; Thu, 17 Jul 2003 07:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6or-0001IU-Vg for nemo@optimus.ietf.org; Thu, 17 Jul 2003 07:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29995 for ; Thu, 17 Jul 2003 07:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6or-0004ul-00 for nemo@ietf.org; Thu, 17 Jul 2003 07:21:05 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19d6ny-0004ub-00 for nemo@ietf.org; Thu, 17 Jul 2003 07:20:10 -0400 Received: from kniveton.com (L5130747.NOE.Nokia.com [81.160.151.184] (may be forged)) by multihop.net (8.12.9/8.12.9) with ESMTP id h6HBJ3ql093017 for ; Thu, 17 Jul 2003 04:19:04 -0700 (PDT) (envelope-from tj@kniveton.com) Message-ID: <3F1685EB.5070203@kniveton.com> Date: Thu, 17 Jul 2003 04:18:03 -0700 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] NEMO additional server availability References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru, who has been maintaining the web page, is on vacation at the moment, and I believe they are moving around machines at Motorola. We'll get everything back up ASAP. Thanks for your patience, TJ Colm McCartan wrote: > Hello all, > > We are having difficulty connecting to the Additional NEMO webpage > referenced from the group's IETF homepage, i.e. the url: > > http://www.nal.motlabs.com/nemo/ > > On Tuesday, we saw reports that the hostname could not be resolved and > today, although we can now get an IP address, the server appears to be > refusing connections. Apologies if we have missed any announcements to > the list but are other people having success in accessing the page? > > Many thanks, > Colm McCartan > From exim@www1.ietf.org Thu Jul 17 07:22:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00033 for ; Thu, 17 Jul 2003 07:22:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6q4-0001Kp-Is for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 07:22:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HBMKrg005092 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 07:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6q4-0001Jp-E9 for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 07:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00007 for ; Thu, 17 Jul 2003 07:22:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6q3-0004vD-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 07:22:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d6py-0004vA-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 07:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6pl-0001It-JN; Thu, 17 Jul 2003 07:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6or-0001IU-Vg for nemo@optimus.ietf.org; Thu, 17 Jul 2003 07:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29995 for ; Thu, 17 Jul 2003 07:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6or-0004ul-00 for nemo@ietf.org; Thu, 17 Jul 2003 07:21:05 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19d6ny-0004ub-00 for nemo@ietf.org; Thu, 17 Jul 2003 07:20:10 -0400 Received: from kniveton.com (L5130747.NOE.Nokia.com [81.160.151.184] (may be forged)) by multihop.net (8.12.9/8.12.9) with ESMTP id h6HBJ3ql093017 for ; Thu, 17 Jul 2003 04:19:04 -0700 (PDT) (envelope-from tj@kniveton.com) Message-ID: <3F1685EB.5070203@kniveton.com> Date: Thu, 17 Jul 2003 04:18:03 -0700 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] NEMO additional server availability References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru, who has been maintaining the web page, is on vacation at the moment, and I believe they are moving around machines at Motorola. We'll get everything back up ASAP. Thanks for your patience, TJ Colm McCartan wrote: > Hello all, > > We are having difficulty connecting to the Additional NEMO webpage > referenced from the group's IETF homepage, i.e. the url: > > http://www.nal.motlabs.com/nemo/ > > On Tuesday, we saw reports that the hostname could not be resolved and > today, although we can now get an IP address, the server appears to be > refusing connections. Apologies if we have missed any announcements to > the list but are other people having success in accessing the page? > > Many thanks, > Colm McCartan > From nemo-admin@ietf.org Thu Jul 17 10:08:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07523 for ; Thu, 17 Jul 2003 10:08:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9QP-0003Mp-4x; Thu, 17 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9PX-00031U-Jm for nemo@optimus.ietf.org; Thu, 17 Jul 2003 10:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07304 for ; Thu, 17 Jul 2003 10:07:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9PV-0006eL-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:07:05 -0400 Received: from [81.160.225.61] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d9PK-0006eB-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:06:55 -0400 Received: by squirrel (Postfix, from userid 1000) id 83B891014CC8; Thu, 17 Jul 2003 22:10:14 +0800 (SGT) Subject: Re: [nemo] Issue 3 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Kent Leung Cc: Vijay Devarapalli , Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058451013.1216.12.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 22:10:14 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Kent, Vijay, Pascal, and all, On Thu, 2003-07-17 at 18:28, Kent Leung wrote: > >I would have preferred a text saying that "the MR MUST keep all > >necessary information to clean up whichever routes it installed, for > >instance by keeping the list of prefix in BCE, whether they come from > >implicit or explicit source". Vijay, please do not tell people how to > >implement things (even if your proposal seems perfectly proper). > > This text doesn't cover the case when routes need to be re-injected into > the routing table. > > My suggestion: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." > Hmm, this drops the implicit and explicit source part, which I think is important. May I propose to further refine the text to "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time, whether the routes come from implicit or explicit source(s). For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." /rgds /cwng From exim@www1.ietf.org Thu Jul 17 10:08:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07556 for ; Thu, 17 Jul 2003 10:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9QZ-0003Nz-Di for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 10:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HE8B1X013009 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 10:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9QZ-0003Nf-6v for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 10:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07455 for ; Thu, 17 Jul 2003 10:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9QX-0006fB-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 10:08:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d9QR-0006f8-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 10:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9QP-0003Mp-4x; Thu, 17 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9PX-00031U-Jm for nemo@optimus.ietf.org; Thu, 17 Jul 2003 10:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07304 for ; Thu, 17 Jul 2003 10:07:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9PV-0006eL-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:07:05 -0400 Received: from [81.160.225.61] (helo=squirrel) by ietf-mx with esmtp (Exim 4.12) id 19d9PK-0006eB-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:06:55 -0400 Received: by squirrel (Postfix, from userid 1000) id 83B891014CC8; Thu, 17 Jul 2003 22:10:14 +0800 (SGT) Subject: Re: [nemo] Issue 3 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: Kent Leung Cc: Vijay Devarapalli , Pascal "Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058451013.1216.12.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 17 Jul 2003 22:10:14 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Vijay, Pascal, and all, On Thu, 2003-07-17 at 18:28, Kent Leung wrote: > >I would have preferred a text saying that "the MR MUST keep all > >necessary information to clean up whichever routes it installed, for > >instance by keeping the list of prefix in BCE, whether they come from > >implicit or explicit source". Vijay, please do not tell people how to > >implement things (even if your proposal seems perfectly proper). > > This text doesn't cover the case when routes need to be re-injected into > the routing table. > > My suggestion: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." > Hmm, this drops the implicit and explicit source part, which I think is important. May I propose to further refine the text to "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time, whether the routes come from implicit or explicit source(s). For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." /rgds /cwng From nemo-admin@ietf.org Thu Jul 17 10:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08815 for ; Thu, 17 Jul 2003 10:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9dw-0003zt-Td; Thu, 17 Jul 2003 10:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9dD-0003wp-2H for nemo@optimus.ietf.org; Thu, 17 Jul 2003 10:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08779 for ; Thu, 17 Jul 2003 10:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9dA-0006k6-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:21:12 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19d9cu-0006jt-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:20:56 -0400 Received: from [81.160.15.235] ([81.160.15.235]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6HEJkef016950; Thu, 17 Jul 2003 23:19:49 +0900 Date: Thu, 17 Jul 2003 23:19:51 +0900 From: Ryuji Wakikawa To: Nicolas Montavont Subject: Re: [nemo] multiple CoAs registration Cc: mobileip , nemo@ietf.org In-Reply-To: <3F166149.6000205@dpt-info.u-strasbg.fr> References: <3F166149.6000205@dpt-info.u-strasbg.fr> Message-Id: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Nicolas thanks for comments. > Hi Ryuji, > > I read your draft on multiple CoAs registration and I also think that we > really need to define a solution to use MIPv6 with a multiple interfaces > MN. > > Here are some comments on your draft: > > - Why do you introduce the interface identification (IFID) ? It could > be sufficient to only register a CoA with the associated priority. > Therefore, when the MN has to choose the destination address for a HoA, > it can take the most preferred CoA, which is bound to the most preferred > interface of the MN. Priority can be changed by some reason during communication, but IFID can not be changed until MN want to change it. > Anyway you use a one-to-one mapping between a CoA and a IFID, therefore > you don't need both, or I missed a point ? > > IMO, this is easier than all the mechanism to manage the IFID > (generation, maintenance...) could be, but I don't know why the maintenance and generation are so difficult. > - If I well understand your draft, when the MN registers a CoA with a > CN, the MN has to first register the primary CoA. Then it can send a > Binding Update (after the RR procedure) to regsiter other CoA(s), with > the associated priority. However, you say that the lowest priority is > the preferred CoA/IF, and that the primary CoA has the priority 0. > Therefore, each CN will use the primary CoA with the MN. Then, you are > not able to perform load balancing, aren't you ? Well, the draft does not mention about how to utilize multiple care-of addresses. I don't think MIP is only way to manage policy sets to divide flows to each CoAs. If you really want load-balancing, you need some mechanism to maintain policy sets between MN and CNs. Load-balancing, for example, can be supported by upper layers. The point is that CN must be able to accept packets sent from multiple .CoAs of MN. > - Last point: If you return home with your primary interface (you > connect to your home network with P-IF), do you have to de-register all > CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? You are right. I personally got the same comment. I just keep protocol simple. I will update the draft before the next meeting. thanks again! regards, ryuji From exim@www1.ietf.org Thu Jul 17 10:22:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08841 for ; Thu, 17 Jul 2003 10:22:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9e5-00042w-5w for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 10:22:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HEM9aw015548 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 10:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9e5-00042h-0s for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 10:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08799 for ; Thu, 17 Jul 2003 10:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9e2-0006ka-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 10:22:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d9dx-0006kX-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 10:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9dw-0003zt-Td; Thu, 17 Jul 2003 10:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d9dD-0003wp-2H for nemo@optimus.ietf.org; Thu, 17 Jul 2003 10:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08779 for ; Thu, 17 Jul 2003 10:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d9dA-0006k6-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:21:12 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19d9cu-0006jt-00 for nemo@ietf.org; Thu, 17 Jul 2003 10:20:56 -0400 Received: from [81.160.15.235] ([81.160.15.235]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6HEJkef016950; Thu, 17 Jul 2003 23:19:49 +0900 Date: Thu, 17 Jul 2003 23:19:51 +0900 From: Ryuji Wakikawa To: Nicolas Montavont Subject: Re: [nemo] multiple CoAs registration Cc: mobileip , nemo@ietf.org In-Reply-To: <3F166149.6000205@dpt-info.u-strasbg.fr> References: <3F166149.6000205@dpt-info.u-strasbg.fr> Message-Id: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Nicolas thanks for comments. > Hi Ryuji, > > I read your draft on multiple CoAs registration and I also think that we > really need to define a solution to use MIPv6 with a multiple interfaces > MN. > > Here are some comments on your draft: > > - Why do you introduce the interface identification (IFID) ? It could > be sufficient to only register a CoA with the associated priority. > Therefore, when the MN has to choose the destination address for a HoA, > it can take the most preferred CoA, which is bound to the most preferred > interface of the MN. Priority can be changed by some reason during communication, but IFID can not be changed until MN want to change it. > Anyway you use a one-to-one mapping between a CoA and a IFID, therefore > you don't need both, or I missed a point ? > > IMO, this is easier than all the mechanism to manage the IFID > (generation, maintenance...) could be, but I don't know why the maintenance and generation are so difficult. > - If I well understand your draft, when the MN registers a CoA with a > CN, the MN has to first register the primary CoA. Then it can send a > Binding Update (after the RR procedure) to regsiter other CoA(s), with > the associated priority. However, you say that the lowest priority is > the preferred CoA/IF, and that the primary CoA has the priority 0. > Therefore, each CN will use the primary CoA with the MN. Then, you are > not able to perform load balancing, aren't you ? Well, the draft does not mention about how to utilize multiple care-of addresses. I don't think MIP is only way to manage policy sets to divide flows to each CoAs. If you really want load-balancing, you need some mechanism to maintain policy sets between MN and CNs. Load-balancing, for example, can be supported by upper layers. The point is that CN must be able to accept packets sent from multiple .CoAs of MN. > - Last point: If you return home with your primary interface (you > connect to your home network with P-IF), do you have to de-register all > CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? You are right. I personally got the same comment. I just keep protocol simple. I will update the draft before the next meeting. thanks again! regards, ryuji From nemo-admin@ietf.org Thu Jul 17 13:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14890 for ; Thu, 17 Jul 2003 13:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCkX-00075Z-Ej; Thu, 17 Jul 2003 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCjo-00075A-HI for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14837 for ; Thu, 17 Jul 2003 13:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCjm-0000As-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:40:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dCjW-0000A9-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:39:58 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21504; Thu, 17 Jul 2003 10:38:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHcPl32269; Thu, 17 Jul 2003 10:38:25 -0700 X-mProtect: <200307171738> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLtEqoO; Thu, 17 Jul 2003 10:38:24 PDT Message-ID: <3F16DF10.AA82DBE6@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:38:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Issue 3 References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > My suggestion: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." hmm.. this doesnt tell me if I should store only those prefixes for which the MR has requested the HA to create routes, or all the prefixes. it doesnt make sense to include all prefixes. that is why there was more specific text in my proposal. to store the list of all prefixes owned by the Mobile Router we have the prefix table. Binding cache entries are removed when they expire. the Prefix Table stays on. Vijay From exim@www1.ietf.org Thu Jul 17 13:41:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14905 for ; Thu, 17 Jul 2003 13:41:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCkf-00076Y-P9 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 13:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HHf9QX027304 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 13:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCkf-00076J-KM for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 13:41:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14866 for ; Thu, 17 Jul 2003 13:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCkd-0000Bf-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 13:41:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dCkX-0000Bc-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 13:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCkX-00075Z-Ej; Thu, 17 Jul 2003 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCjo-00075A-HI for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14837 for ; Thu, 17 Jul 2003 13:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCjm-0000As-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:40:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dCjW-0000A9-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:39:58 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21504; Thu, 17 Jul 2003 10:38:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHcPl32269; Thu, 17 Jul 2003 10:38:25 -0700 X-mProtect: <200307171738> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLtEqoO; Thu, 17 Jul 2003 10:38:24 PDT Message-ID: <3F16DF10.AA82DBE6@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:38:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Issue 3 References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > My suggestion: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." hmm.. this doesnt tell me if I should store only those prefixes for which the MR has requested the HA to create routes, or all the prefixes. it doesnt make sense to include all prefixes. that is why there was more specific text in my proposal. to store the list of all prefixes owned by the Mobile Router we have the prefix table. Binding cache entries are removed when they expire. the Prefix Table stays on. Vijay From nemo-admin@ietf.org Thu Jul 17 13:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15100 for ; Thu, 17 Jul 2003 13:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqL-0007IH-8S; Thu, 17 Jul 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqB-0007H4-RJ for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15088 for ; Thu, 17 Jul 2003 13:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCq9-0000EZ-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:46:49 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dCpt-0000EG-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:46:33 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21903; Thu, 17 Jul 2003 10:45:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHjfX10165; Thu, 17 Jul 2003 10:45:41 -0700 X-mProtect: <200307171745> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzNsJda; Thu, 17 Jul 2003 10:45:40 PDT Message-ID: <3F16E0C4.26647604@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:45:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org, julien@sfc.wide.ad.jp, tj@kniveton.com Subject: Re: [nemo] Re: Comments ondraft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > > Depending on the meaning of /function/ maybe my sentence is too > > > oriented Load-Sharing. I will change that. > > > > okay. load sharing is a nice feature, but it shouldnt a > > MUST support for NEMO. it should be an optional mechanism. > > In draft-ietf-nemo-requirements we have: > > R18: The solution SHOULD preserve sessions established through > another egress interface when one fails [PROPOSED BY EDITOR OF > THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE > MAILING LIST] > > So far, I put "SHOULD". It may even by "MAY", or requirement could be > removed because it's not a NEMO issue. Thoughts on this are appreciated > to clarify the requirements draft. arent we talking about two different things? I was talking about load sharing requirement in draft-charbon which said if the NEMO network has multiple egress interfaces, load MUST be distributed among the different interfaces. I was objecting to this MUST. infact I even said this is implementation specific. R18 is about, if one egress interface fails, sessions SHOULD be preserved by switching to another interface. IMHO, both should be a MAY. SHOULD is too strong for these optional mechanisms. > > draft-nemo-multihoming-basic-support. (I even made it a > > WG document :). the WG chairs have to decide on it. any > > extensions, improvements, I suggest, should go into this > > draft. the basic suport draft currently is short and > > simple. it would be easy to advance it. > > The decision doesn't belong to the chairs, but to the WG. Indeed, we > asked if the multihoming analysis should become a WG document: show of > hands is about +30 "YES", none "NO". I agree the basic support draft > should not speak about that (but make sure it provides room for the > needed extensions, so we should be careful about this). yes. I agree. > > > > > > [If NEMO deciced to not include any preference nor > > > priority field nor Interface ID for NEMO basic, maybe in the next version > > > of NEMO it will be OK]. > > > > IMO, NEMO basic support should not include these because > > they are specific to multi-homing. I prefer defining new > > mobility options for this. you can have a Care-of Address > > Preference option, Interface ID option or even a > > Multi-homing option in > > draft-nemo-multihoming-basic-support. I can help you with > > this. > > This is a good direction, I think. great. Vijay From exim@www1.ietf.org Thu Jul 17 13:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15116 for ; Thu, 17 Jul 2003 13:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqR-0007Mz-ES for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 13:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HHl71E028323 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 13:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqR-0007Mk-9K for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 13:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15093 for ; Thu, 17 Jul 2003 13:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCqP-0000Eg-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 13:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dCqJ-0000Ed-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 13:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqL-0007IH-8S; Thu, 17 Jul 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCqB-0007H4-RJ for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15088 for ; Thu, 17 Jul 2003 13:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCq9-0000EZ-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:46:49 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dCpt-0000EG-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:46:33 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21903; Thu, 17 Jul 2003 10:45:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHjfX10165; Thu, 17 Jul 2003 10:45:41 -0700 X-mProtect: <200307171745> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzNsJda; Thu, 17 Jul 2003 10:45:40 PDT Message-ID: <3F16E0C4.26647604@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:45:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org, julien@sfc.wide.ad.jp, tj@kniveton.com Subject: Re: [nemo] Re: Comments ondraft-charbon-nemo-multihoming-evaluation References: <3F0F2BAC.F7A1A05F@iprg.nokia.com> <20030716163834.30ac8d72.julien@sfc.wide.ad.jp> <3F159C90.11F898C3@iprg.nokia.com> <20030717171742.5982d24a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > > Depending on the meaning of /function/ maybe my sentence is too > > > oriented Load-Sharing. I will change that. > > > > okay. load sharing is a nice feature, but it shouldnt a > > MUST support for NEMO. it should be an optional mechanism. > > In draft-ietf-nemo-requirements we have: > > R18: The solution SHOULD preserve sessions established through > another egress interface when one fails [PROPOSED BY EDITOR OF > THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE > MAILING LIST] > > So far, I put "SHOULD". It may even by "MAY", or requirement could be > removed because it's not a NEMO issue. Thoughts on this are appreciated > to clarify the requirements draft. arent we talking about two different things? I was talking about load sharing requirement in draft-charbon which said if the NEMO network has multiple egress interfaces, load MUST be distributed among the different interfaces. I was objecting to this MUST. infact I even said this is implementation specific. R18 is about, if one egress interface fails, sessions SHOULD be preserved by switching to another interface. IMHO, both should be a MAY. SHOULD is too strong for these optional mechanisms. > > draft-nemo-multihoming-basic-support. (I even made it a > > WG document :). the WG chairs have to decide on it. any > > extensions, improvements, I suggest, should go into this > > draft. the basic suport draft currently is short and > > simple. it would be easy to advance it. > > The decision doesn't belong to the chairs, but to the WG. Indeed, we > asked if the multihoming analysis should become a WG document: show of > hands is about +30 "YES", none "NO". I agree the basic support draft > should not speak about that (but make sure it provides room for the > needed extensions, so we should be careful about this). yes. I agree. > > > > > > [If NEMO deciced to not include any preference nor > > > priority field nor Interface ID for NEMO basic, maybe in the next version > > > of NEMO it will be OK]. > > > > IMO, NEMO basic support should not include these because > > they are specific to multi-homing. I prefer defining new > > mobility options for this. you can have a Care-of Address > > Preference option, Interface ID option or even a > > Multi-homing option in > > draft-nemo-multihoming-basic-support. I can help you with > > this. > > This is a good direction, I think. great. Vijay From nemo-admin@ietf.org Thu Jul 17 14:00:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15473 for ; Thu, 17 Jul 2003 14:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD2w-0007oq-5A; Thu, 17 Jul 2003 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD2C-0007o6-Io for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:59:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15393 for ; Thu, 17 Jul 2003 13:59:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dD2A-0000Hz-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:59:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dD1u-0000Hd-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:58:58 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA22606; Thu, 17 Jul 2003 10:58:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHwDC27269; Thu, 17 Jul 2003 10:58:13 -0700 X-mProtect: <200307171758> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjvFos4; Thu, 17 Jul 2003 10:58:12 PDT Message-ID: <3F16E3B4.981208B2@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:58:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: nemo@ietf.org Subject: Re: [nemo] Explicit combined mode name References: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > A nit. The "Explicit combined" mode is confusing to me. Combined with what? > Just a suggestion, marked by "->". > > Explicit: -> Explicit Network > > In this mode, the Mobile Router includes one or more Mobile > Network Prefix Options in the Binding Update. These options > contain information about the Mobile Network Prefix(es) > configured on the Mobile Network. > > Explicit combined: -> Explicit Prefix Length > > In this mode, the Mobile Router instructs the Home Agent to > derive the Mobile Network Prefix by using: (1) the Home > Address in the Home Address Option carried in the Destination > Options header of the same packet that carries the Mobility > Header containing this Binding Update and (2) the prefix length > carried in the Mobile Network Prefix Length Option. In this > case, Mobile Router includes one and only one Mobile Network > Prefix Length Option. It MUST not include a Mobile Network > Prefix Option if this method is used. we just couldnt come with good names. :) I am fine with what you suggest. Vijay From exim@www1.ietf.org Thu Jul 17 14:01:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15572 for ; Thu, 17 Jul 2003 14:01:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD3R-0007tF-U1 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:00:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HI0Xao030323 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD3R-0007t0-Lf for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:00:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15474 for ; Thu, 17 Jul 2003 14:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD2w-0007oq-5A; Thu, 17 Jul 2003 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dD2C-0007o6-Io for nemo@optimus.ietf.org; Thu, 17 Jul 2003 13:59:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15393 for ; Thu, 17 Jul 2003 13:59:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dD2A-0000Hz-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:59:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dD1u-0000Hd-00 for nemo@ietf.org; Thu, 17 Jul 2003 13:58:58 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA22606; Thu, 17 Jul 2003 10:58:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HHwDC27269; Thu, 17 Jul 2003 10:58:13 -0700 X-mProtect: <200307171758> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjvFos4; Thu, 17 Jul 2003 10:58:12 PDT Message-ID: <3F16E3B4.981208B2@iprg.nokia.com> Date: Thu, 17 Jul 2003 10:58:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: nemo@ietf.org Subject: Re: [nemo] Explicit combined mode name References: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > A nit. The "Explicit combined" mode is confusing to me. Combined with what? > Just a suggestion, marked by "->". > > Explicit: -> Explicit Network > > In this mode, the Mobile Router includes one or more Mobile > Network Prefix Options in the Binding Update. These options > contain information about the Mobile Network Prefix(es) > configured on the Mobile Network. > > Explicit combined: -> Explicit Prefix Length > > In this mode, the Mobile Router instructs the Home Agent to > derive the Mobile Network Prefix by using: (1) the Home > Address in the Home Address Option carried in the Destination > Options header of the same packet that carries the Mobility > Header containing this Binding Update and (2) the prefix length > carried in the Mobile Network Prefix Length Option. In this > case, Mobile Router includes one and only one Mobile Network > Prefix Length Option. It MUST not include a Mobile Network > Prefix Option if this method is used. we just couldnt come with good names. :) I am fine with what you suggest. Vijay From nemo-admin@ietf.org Thu Jul 17 14:09:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15977 for ; Thu, 17 Jul 2003 14:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDBd-00006v-JC; Thu, 17 Jul 2003 14:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDAn-00005Q-8I for nemo@optimus.ietf.org; Thu, 17 Jul 2003 14:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15957 for ; Thu, 17 Jul 2003 14:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDAk-0000N4-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:08:06 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dDAU-0000Mi-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:07:50 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA23086; Thu, 17 Jul 2003 11:07:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HI73s05618; Thu, 17 Jul 2003 11:07:03 -0700 X-mProtect: <200307171807> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhgMJJn; Thu, 17 Jul 2003 11:07:02 PDT Message-ID: <3F16E5C6.1A78C99A@iprg.nokia.com> Date: Thu, 17 Jul 2003 11:07:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > >While I agree that the option in discussion (having both BU and > >dynamic routing updates for prefixes between a particular pair of > >HA and MR) may be redundent, I wonder in practice whether there > >are scenarios that we have to have both? > > In practice, not sure why anyone would do this. But then the base NEMO > should not get into config/operation issue, IMHO, and preclude such > possibility. > Someone can always dream up some wild scenario where they use functions > that weren't foreseen to solve their problems. I dont buy this argument. a protocol specification has to be tight and exact. I dont see why would need both for the same prefix. I disagree characterising this as an "config/operation" issue. I would agree if the Binding Updates and Routing Protocol updates carry different prefixes, i.e. if the MR uses a Binding Update to have the HA create routes for a certain perfix and it uses a routing protocol update for creating routes for a different prefix. Vijay From exim@www1.ietf.org Thu Jul 17 14:09:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16033 for ; Thu, 17 Jul 2003 14:09:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDC8-0000BJ-RP for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:09:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HI9W2E000690 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDC8-0000B3-MH for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:09:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15978 for ; Thu, 17 Jul 2003 14:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDBd-00006v-JC; Thu, 17 Jul 2003 14:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDAn-00005Q-8I for nemo@optimus.ietf.org; Thu, 17 Jul 2003 14:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15957 for ; Thu, 17 Jul 2003 14:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDAk-0000N4-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:08:06 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dDAU-0000Mi-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:07:50 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA23086; Thu, 17 Jul 2003 11:07:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HI73s05618; Thu, 17 Jul 2003 11:07:03 -0700 X-mProtect: <200307171807> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhgMJJn; Thu, 17 Jul 2003 11:07:02 PDT Message-ID: <3F16E5C6.1A78C99A@iprg.nokia.com> Date: Thu, 17 Jul 2003 11:07:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > >While I agree that the option in discussion (having both BU and > >dynamic routing updates for prefixes between a particular pair of > >HA and MR) may be redundent, I wonder in practice whether there > >are scenarios that we have to have both? > > In practice, not sure why anyone would do this. But then the base NEMO > should not get into config/operation issue, IMHO, and preclude such > possibility. > Someone can always dream up some wild scenario where they use functions > that weren't foreseen to solve their problems. I dont buy this argument. a protocol specification has to be tight and exact. I dont see why would need both for the same prefix. I disagree characterising this as an "config/operation" issue. I would agree if the Binding Updates and Routing Protocol updates carry different prefixes, i.e. if the MR uses a Binding Update to have the HA create routes for a certain perfix and it uses a routing protocol update for creating routes for a different prefix. Vijay From nemo-admin@ietf.org Thu Jul 17 14:23:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16596 for ; Thu, 17 Jul 2003 14:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDPB-0000ub-FT; Thu, 17 Jul 2003 14:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDOQ-0000sM-TH for nemo@optimus.ietf.org; Thu, 17 Jul 2003 14:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16557 for ; Thu, 17 Jul 2003 14:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDON-0000Sm-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:22:11 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dDO7-0000SE-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:21:56 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24363; Thu, 17 Jul 2003 11:21:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HILBM23760; Thu, 17 Jul 2003 11:21:11 -0700 X-mProtect: <200307171821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpC4to9; Thu, 17 Jul 2003 11:21:09 PDT Message-ID: <3F16E916.B6752EA4@iprg.nokia.com> Date: Thu, 17 Jul 2003 11:21:10 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "S. Felix Wu" CC: pthubert@cisco.com, nemo@ietf.org Subject: Issue 7 (was Re: [nemo] RE: Issue 6) References: <3F12ECBD.4852B5FB@iprg.nokia.com> <3F1517AC.9010305@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "S. Felix Wu" wrote: > I have actually a question regarding the prefix table, which in > NEMO the HA will use it to check if the MR has the right/ownership > to announce the prefix. First, I assume that, for both BU and dynamic > routing updates, the HA has to check the table before accepting a > route/binding of MR to prefixes. no. it is currently used only for checking prefixes in the binding updates. we assume routing protocols have their own mechanisms to authenticate and authorize prefixes. Pascal in a private email wrote > My suggestion is to open issue 7 to cover authorization of explicit, and > to word the fact that we allow but do not control or modify that > activity of an existing routing protocol on the tunnel. I agree with him. > Second, the content of the prefix > table should be maintained correctly by the system administrators. > (This process is actually a tricky one in some cases.) note that the prefix table is an optional data structure to be used only when you want to prevent a misbehaving (but authenticated) mobile router from claiming prefixes that actually belong to another mobile router. if you have another means of checking this (or if you expect the MR not to misbehave) you dont have to implement the prefix table. Vijay From exim@www1.ietf.org Thu Jul 17 14:23:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16618 for ; Thu, 17 Jul 2003 14:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDPJ-0000yC-RF for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HIN9L0003724 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 14:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDPJ-0000xz-Ni for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:23:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16585 for ; Thu, 17 Jul 2003 14:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDPH-0000TB-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 14:23:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dDPB-0000T8-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 14:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDPB-0000ub-FT; Thu, 17 Jul 2003 14:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDOQ-0000sM-TH for nemo@optimus.ietf.org; Thu, 17 Jul 2003 14:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16557 for ; Thu, 17 Jul 2003 14:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDON-0000Sm-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:22:11 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dDO7-0000SE-00 for nemo@ietf.org; Thu, 17 Jul 2003 14:21:56 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24363; Thu, 17 Jul 2003 11:21:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HILBM23760; Thu, 17 Jul 2003 11:21:11 -0700 X-mProtect: <200307171821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpC4to9; Thu, 17 Jul 2003 11:21:09 PDT Message-ID: <3F16E916.B6752EA4@iprg.nokia.com> Date: Thu, 17 Jul 2003 11:21:10 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "S. Felix Wu" CC: pthubert@cisco.com, nemo@ietf.org Subject: Issue 7 (was Re: [nemo] RE: Issue 6) References: <3F12ECBD.4852B5FB@iprg.nokia.com> <3F1517AC.9010305@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "S. Felix Wu" wrote: > I have actually a question regarding the prefix table, which in > NEMO the HA will use it to check if the MR has the right/ownership > to announce the prefix. First, I assume that, for both BU and dynamic > routing updates, the HA has to check the table before accepting a > route/binding of MR to prefixes. no. it is currently used only for checking prefixes in the binding updates. we assume routing protocols have their own mechanisms to authenticate and authorize prefixes. Pascal in a private email wrote > My suggestion is to open issue 7 to cover authorization of explicit, and > to word the fact that we allow but do not control or modify that > activity of an existing routing protocol on the tunnel. I agree with him. > Second, the content of the prefix > table should be maintained correctly by the system administrators. > (This process is actually a tricky one in some cases.) note that the prefix table is an optional data structure to be used only when you want to prevent a misbehaving (but authenticated) mobile router from claiming prefixes that actually belong to another mobile router. if you have another means of checking this (or if you expect the MR not to misbehave) you dont have to implement the prefix table. Vijay From nemo-admin@ietf.org Thu Jul 17 16:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22032 for ; Thu, 17 Jul 2003 16:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFcb-0007b1-Ct; Thu, 17 Jul 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFbh-0007aG-C7 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 16:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21988 for ; Thu, 17 Jul 2003 16:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dFbf-0001Fy-00 for nemo@ietf.org; Thu, 17 Jul 2003 16:44:03 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dFbU-0001Fn-00 for nemo@ietf.org; Thu, 17 Jul 2003 16:43:52 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6HKhavG022020; Thu, 17 Jul 2003 13:43:36 -0700 (MST) Received: from motorola.com (t-il06-v-port6.corp.mot.com [129.188.170.36]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6HKhVIM016178; Thu, 17 Jul 2003 15:43:32 -0500 Message-ID: <3F172636.2040207@motorola.com> Date: Fri, 18 Jul 2003 00:41:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: nemo@ietf.org Subject: Re: [nemo] Explicit combined mode name References: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > A nit. The "Explicit combined" mode is confusing to me. Combined with > what? Confusing to me too. We looked hard for names. Combined are the home address and the mobile network prefix. > Just a suggestion, marked by "->". > > Explicit: -> Explicit Network > > In this mode, the Mobile Router includes one or more Mobile > Network Prefix Options in the Binding Update. These options > contain information about the Mobile Network Prefix(es) > configured on the Mobile Network. > > Explicit combined: -> Explicit Prefix Length > > In this mode, the Mobile Router instructs the Home Agent to > derive the Mobile Network Prefix by using: (1) the Home > Address in the Home Address Option carried in the Destination > Options header of the same packet that carries the Mobility > Header containing this Binding Update and (2) the prefix length > carried in the Mobile Network Prefix Length Option. In this > case, Mobile Router includes one and only one Mobile Network > Prefix Length Option. It MUST not include a Mobile Network > Prefix Option if this method is used. Good idea. Alex GBU From exim@www1.ietf.org Thu Jul 17 16:45:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22060 for ; Thu, 17 Jul 2003 16:45:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFcj-0007cL-Kd for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 16:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HKj9ZP029277 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 16:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFcj-0007c8-HE for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 16:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22026 for ; Thu, 17 Jul 2003 16:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dFch-0001Gw-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 16:45:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dFcc-0001Gt-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 16:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFcb-0007b1-Ct; Thu, 17 Jul 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFbh-0007aG-C7 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 16:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21988 for ; Thu, 17 Jul 2003 16:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dFbf-0001Fy-00 for nemo@ietf.org; Thu, 17 Jul 2003 16:44:03 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dFbU-0001Fn-00 for nemo@ietf.org; Thu, 17 Jul 2003 16:43:52 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6HKhavG022020; Thu, 17 Jul 2003 13:43:36 -0700 (MST) Received: from motorola.com (t-il06-v-port6.corp.mot.com [129.188.170.36]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6HKhVIM016178; Thu, 17 Jul 2003 15:43:32 -0500 Message-ID: <3F172636.2040207@motorola.com> Date: Fri, 18 Jul 2003 00:41:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: nemo@ietf.org Subject: Re: [nemo] Explicit combined mode name References: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20030717025110.02e02130@mira-sjcm-2.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > A nit. The "Explicit combined" mode is confusing to me. Combined with > what? Confusing to me too. We looked hard for names. Combined are the home address and the mobile network prefix. > Just a suggestion, marked by "->". > > Explicit: -> Explicit Network > > In this mode, the Mobile Router includes one or more Mobile > Network Prefix Options in the Binding Update. These options > contain information about the Mobile Network Prefix(es) > configured on the Mobile Network. > > Explicit combined: -> Explicit Prefix Length > > In this mode, the Mobile Router instructs the Home Agent to > derive the Mobile Network Prefix by using: (1) the Home > Address in the Home Address Option carried in the Destination > Options header of the same packet that carries the Mobility > Header containing this Binding Update and (2) the prefix length > carried in the Mobile Network Prefix Length Option. In this > case, Mobile Router includes one and only one Mobile Network > Prefix Length Option. It MUST not include a Mobile Network > Prefix Option if this method is used. Good idea. Alex GBU From nemo-admin@ietf.org Thu Jul 17 17:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23923 for ; Thu, 17 Jul 2003 17:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGiL-0001i9-EK; Thu, 17 Jul 2003 17:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGhz-0001ex-Mr for nemo@optimus.ietf.org; Thu, 17 Jul 2003 17:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23916 for ; Thu, 17 Jul 2003 17:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dGhx-0001hm-00 for nemo@ietf.org; Thu, 17 Jul 2003 17:54:37 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dGhm-0001hd-00 for nemo@ietf.org; Thu, 17 Jul 2003 17:54:26 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HLrDpp017315; Thu, 17 Jul 2003 14:53:13 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH41550; Thu, 17 Jul 2003 14:49:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 14:53:02 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F16E5C6.1A78C99A@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 11:07 AM 7/17/2003 -0700, Vijay Devarapalli wrote: >I dont buy this argument. a protocol specification has to be >tight and exact. I dont see why would need both for the same >prefix. Hmm. Original text issue is below. Not sure if you are assuming same prefix, which may not be always the case. >Vijay Devarapalli wrote: When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. >I disagree characterising this as an "config/operation" issue. > >I would agree if the Binding Updates and Routing Protocol >updates carry different prefixes, i.e. if the MR uses a >Binding Update to have the HA create routes for a certain >perfix and it uses a routing protocol update for creating >routes for a different prefix. Yes, the original text was exclusive in which method was used to update the HA. Still I don't agree there needs to be any additional checks. Again, what is the harm? The result is still traffic to MNP are tunneled to the MR. What about inter-mixing statically configured MNP with BU extensions or IGP? This is something that multi-protocol routers deal with since they were invented. Why is this such a special case? Kent From exim@www1.ietf.org Thu Jul 17 17:55:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23940 for ; Thu, 17 Jul 2003 17:55:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGiU-0001j4-Oa for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 17:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HLtA48006631 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 17:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGiU-0001is-3j for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 17:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23920 for ; Thu, 17 Jul 2003 17:55:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dGiR-0001hu-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 17:55:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dGiM-0001hr-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 17:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGiL-0001i9-EK; Thu, 17 Jul 2003 17:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dGhz-0001ex-Mr for nemo@optimus.ietf.org; Thu, 17 Jul 2003 17:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23916 for ; Thu, 17 Jul 2003 17:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dGhx-0001hm-00 for nemo@ietf.org; Thu, 17 Jul 2003 17:54:37 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dGhm-0001hd-00 for nemo@ietf.org; Thu, 17 Jul 2003 17:54:26 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HLrDpp017315; Thu, 17 Jul 2003 14:53:13 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH41550; Thu, 17 Jul 2003 14:49:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 14:53:02 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F16E5C6.1A78C99A@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 11:07 AM 7/17/2003 -0700, Vijay Devarapalli wrote: >I dont buy this argument. a protocol specification has to be >tight and exact. I dont see why would need both for the same >prefix. Hmm. Original text issue is below. Not sure if you are assuming same prefix, which may not be always the case. >Vijay Devarapalli wrote: When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. >I disagree characterising this as an "config/operation" issue. > >I would agree if the Binding Updates and Routing Protocol >updates carry different prefixes, i.e. if the MR uses a >Binding Update to have the HA create routes for a certain >perfix and it uses a routing protocol update for creating >routes for a different prefix. Yes, the original text was exclusive in which method was used to update the HA. Still I don't agree there needs to be any additional checks. Again, what is the harm? The result is still traffic to MNP are tunneled to the MR. What about inter-mixing statically configured MNP with BU extensions or IGP? This is something that multi-protocol routers deal with since they were invented. Why is this such a special case? Kent From nemo-admin@ietf.org Thu Jul 17 18:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25438 for ; Thu, 17 Jul 2003 18:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4b-0002Va-VH; Thu, 17 Jul 2003 18:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4O-0002V0-Ss for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25403 for ; Thu, 17 Jul 2003 18:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dH4M-0001pw-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:17:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19dH4B-0001pJ-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:17:35 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 15:20:52 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HMFw89024022; Thu, 17 Jul 2003 15:15:58 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH44415; Thu, 17 Jul 2003 15:12:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717132317.02e65a78@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 15:15:48 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] Issue 3 Cc: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <3F16DF10.AA82DBE6@iprg.nokia.com> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 10:38 AM 7/17/2003 -0700, Vijay Devarapalli wrote: >Kent Leung wrote: > > > > My suggestion: > > > > "The Home Agent MUST keep all necessary information to be able to add or > > delete routes associated with the Mobile Router at the time. For instance, > > the list of Mobile Network Prefixes may be stored in the Binding Cache > > entry." > >hmm.. this doesnt tell me if I should store only those prefixes >for which the MR has requested the HA to create routes, or all >the prefixes. Right, deliberately so. That's implementation details, IMHO. The key point is that HA has to have "all necessary information" to do the right thing for route addition/deletion. Some coders may store prefixes from MR in BCE and some coders may store all prefixes in BCE. Why should the spec care? As long as the objective is achieved. >it doesnt make sense to include all prefixes. >that is why there was more specific text in my proposal. See above. >to store the list of all prefixes owned by the Mobile Router >we have the prefix table. Binding cache entries are removed >when they expire. the Prefix Table stays on. You have a good pt here. I was coming from the angle of not over-specifying or too much details. I can't come up with a good reason for some cases where all prefixes would be useful, right now. Since this is in the sentence that starts with "For instance", then there's no objection from me. :) The objective is covered by HA MUST keep relevant info to properly maintain the routing table. Kent From exim@www1.ietf.org Thu Jul 17 18:18:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25462 for ; Thu, 17 Jul 2003 18:18:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4v-0002aO-GR for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 18:18:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HMILJK009936 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 18:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4v-0002aB-Ba for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 18:18:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25414 for ; Thu, 17 Jul 2003 18:18:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dH4g-0001qG-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 18:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dH4a-0001qD-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 18:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4b-0002Va-VH; Thu, 17 Jul 2003 18:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dH4O-0002V0-Ss for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25403 for ; Thu, 17 Jul 2003 18:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dH4M-0001pw-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:17:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19dH4B-0001pJ-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:17:35 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 15:20:52 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6HMFw89024022; Thu, 17 Jul 2003 15:15:58 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH44415; Thu, 17 Jul 2003 15:12:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717132317.02e65a78@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 15:15:48 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] Issue 3 Cc: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG In-Reply-To: <3F16DF10.AA82DBE6@iprg.nokia.com> References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 10:38 AM 7/17/2003 -0700, Vijay Devarapalli wrote: >Kent Leung wrote: > > > > My suggestion: > > > > "The Home Agent MUST keep all necessary information to be able to add or > > delete routes associated with the Mobile Router at the time. For instance, > > the list of Mobile Network Prefixes may be stored in the Binding Cache > > entry." > >hmm.. this doesnt tell me if I should store only those prefixes >for which the MR has requested the HA to create routes, or all >the prefixes. Right, deliberately so. That's implementation details, IMHO. The key point is that HA has to have "all necessary information" to do the right thing for route addition/deletion. Some coders may store prefixes from MR in BCE and some coders may store all prefixes in BCE. Why should the spec care? As long as the objective is achieved. >it doesnt make sense to include all prefixes. >that is why there was more specific text in my proposal. See above. >to store the list of all prefixes owned by the Mobile Router >we have the prefix table. Binding cache entries are removed >when they expire. the Prefix Table stays on. You have a good pt here. I was coming from the angle of not over-specifying or too much details. I can't come up with a good reason for some cases where all prefixes would be useful, right now. Since this is in the sentence that starts with "For instance", then there's no objection from me. :) The objective is covered by HA MUST keep relevant info to properly maintain the routing table. Kent From nemo-admin@ietf.org Thu Jul 17 18:44:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25943 for ; Thu, 17 Jul 2003 18:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHTk-0003Rj-Ru; Thu, 17 Jul 2003 18:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHSu-0003RD-78 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25907 for ; Thu, 17 Jul 2003 18:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHSr-00020B-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:43:05 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dHSb-0001zo-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:42:49 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA11721; Thu, 17 Jul 2003 15:41:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HMfes23921; Thu, 17 Jul 2003 15:41:40 -0700 X-mProtect: <200307172241> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz9dPDh; Thu, 17 Jul 2003 15:41:39 PDT Message-ID: <3F172623.B164939E@iprg.nokia.com> Date: Thu, 17 Jul 2003 15:41:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Issue 3 References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717132317.02e65a78@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > At 10:38 AM 7/17/2003 -0700, Vijay Devarapalli wrote: > >Kent Leung wrote: > > > > > > My suggestion: > > > > > > "The Home Agent MUST keep all necessary information to be able to add or > > > delete routes associated with the Mobile Router at the time. For instance, > > > the list of Mobile Network Prefixes may be stored in the Binding Cache > > > entry." > > > >hmm.. this doesnt tell me if I should store only those prefixes > >for which the MR has requested the HA to create routes, or all > >the prefixes. > > Right, deliberately so. That's implementation details, IMHO. The key > point is that HA has to have "all necessary information" to do the > right thing for route addition/deletion. Some coders may store prefixes > from MR in BCE and some coders may store all prefixes in BCE. binding cache entries expire. > Why should the spec care? it should, IMO. > > >to store the list of all prefixes owned by the Mobile Router > >we have the prefix table. Binding cache entries are removed > >when they expire. the Prefix Table stays on. > > You have a good pt here. I was coming from the angle of not > over-specifying or too much details. I can't come up with a good > reason for some cases where all prefixes would be useful, right now. > > Since this is in the sentence that starts with "For instance", then > there's no objection from me. :) The objective is covered by HA MUST > keep relevant info to properly maintain the routing table. the problem with a sentence like The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. is that it is too vague. what information are we talking about? where do you keep the information? you have another data structure in mind? Mobile IPv6 has a brief description on Binding Cache structure. we are just extending it. see section 6.1 of http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre01.txt. this contains the latest text. Vijay From exim@www1.ietf.org Thu Jul 17 18:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25962 for ; Thu, 17 Jul 2003 18:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHTr-0003Tx-NW for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 18:44:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HMi7bq013381 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 18:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHTr-0003Tk-JF for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 18:44:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25920 for ; Thu, 17 Jul 2003 18:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHTo-00020j-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 18:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dHTj-00020g-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 18:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHTk-0003Rj-Ru; Thu, 17 Jul 2003 18:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHSu-0003RD-78 for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25907 for ; Thu, 17 Jul 2003 18:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHSr-00020B-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:43:05 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dHSb-0001zo-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:42:49 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA11721; Thu, 17 Jul 2003 15:41:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HMfes23921; Thu, 17 Jul 2003 15:41:40 -0700 X-mProtect: <200307172241> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz9dPDh; Thu, 17 Jul 2003 15:41:39 PDT Message-ID: <3F172623.B164939E@iprg.nokia.com> Date: Thu, 17 Jul 2003 15:41:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: cwng@psl.com.sg, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Issue 3 References: <3F159E1C.65F0711D@iprg.nokia.com> <3F159E1C.65F0711D@iprg.nokia.com> <4.3.2.7.2.20030717011916.02ddbf08@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717132317.02e65a78@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > At 10:38 AM 7/17/2003 -0700, Vijay Devarapalli wrote: > >Kent Leung wrote: > > > > > > My suggestion: > > > > > > "The Home Agent MUST keep all necessary information to be able to add or > > > delete routes associated with the Mobile Router at the time. For instance, > > > the list of Mobile Network Prefixes may be stored in the Binding Cache > > > entry." > > > >hmm.. this doesnt tell me if I should store only those prefixes > >for which the MR has requested the HA to create routes, or all > >the prefixes. > > Right, deliberately so. That's implementation details, IMHO. The key > point is that HA has to have "all necessary information" to do the > right thing for route addition/deletion. Some coders may store prefixes > from MR in BCE and some coders may store all prefixes in BCE. binding cache entries expire. > Why should the spec care? it should, IMO. > > >to store the list of all prefixes owned by the Mobile Router > >we have the prefix table. Binding cache entries are removed > >when they expire. the Prefix Table stays on. > > You have a good pt here. I was coming from the angle of not > over-specifying or too much details. I can't come up with a good > reason for some cases where all prefixes would be useful, right now. > > Since this is in the sentence that starts with "For instance", then > there's no objection from me. :) The objective is covered by HA MUST > keep relevant info to properly maintain the routing table. the problem with a sentence like The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. is that it is too vague. what information are we talking about? where do you keep the information? you have another data structure in mind? Mobile IPv6 has a brief description on Binding Cache structure. we are just extending it. see section 6.1 of http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre01.txt. this contains the latest text. Vijay From nemo-admin@ietf.org Thu Jul 17 19:00:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26200 for ; Thu, 17 Jul 2003 19:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHjF-0003uy-Mb; Thu, 17 Jul 2003 19:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHip-0003tm-Nd for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:59:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26148 for ; Thu, 17 Jul 2003 18:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHim-00024W-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:59:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dHiW-00023y-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:59:16 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA12518; Thu, 17 Jul 2003 15:58:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HMwWc09848; Thu, 17 Jul 2003 15:58:32 -0700 X-mProtect: <200307172258> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbdyf8E; Thu, 17 Jul 2003 15:58:30 PDT Message-ID: <3F172A16.CD479640@iprg.nokia.com> Date: Thu, 17 Jul 2003 15:58:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > >I dont buy this argument. a protocol specification has to be > >tight and exact. I dont see why would need both for the same > >prefix. > > Hmm. Original text issue is below. Not sure if you are assuming > same prefix, which may not be always the case. > > >Vijay Devarapalli wrote: > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT > create routes to the Mobile network when the Binding Update > from the Mobile Router is received. The Mobile Router also > MUST NOT include any prefix information in the Binding Update. > Any routes to the Mobile Network are created at the Home > Agent through routing protocol updates. this was proposed a few days back. the latest discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > >I disagree characterising this as an "config/operation" issue. > > > >I would agree if the Binding Updates and Routing Protocol > >updates carry different prefixes, i.e. if the MR uses a > >Binding Update to have the HA create routes for a certain > >perfix and it uses a routing protocol update for creating > >routes for a different prefix. > > Yes, the original text was exclusive in which method was used to > update the HA. Still I don't agree there needs to be any additional > checks. Again, what is the harm? what is the need? I dont see any. > The result is still traffic to MNP > are tunneled to the MR. *extra* traffic. > What about inter-mixing statically configured MNP with BU extensions > or IGP? > > This is something that multi-protocol routers deal with since they were > invented. Why is this such a special case? didnt follow the argument. my question is why add to that? I see that you already have to deal with a lot of mechanisms for adding routes. why add yet another mechanism when it can used exclusive to the IGP over the bi-directional tunnel. Vijay From exim@www1.ietf.org Thu Jul 17 19:00:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26215 for ; Thu, 17 Jul 2003 19:00:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHjS-0003wA-O9 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 19:00:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HN0EUB015130 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 19:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHjS-0003vx-J8 for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 19:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26185 for ; Thu, 17 Jul 2003 19:00:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHjP-00025Q-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 19:00:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dHjJ-00025N-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 19:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHjF-0003uy-Mb; Thu, 17 Jul 2003 19:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHip-0003tm-Nd for nemo@optimus.ietf.org; Thu, 17 Jul 2003 18:59:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26148 for ; Thu, 17 Jul 2003 18:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHim-00024W-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:59:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dHiW-00023y-00 for nemo@ietf.org; Thu, 17 Jul 2003 18:59:16 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA12518; Thu, 17 Jul 2003 15:58:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6HMwWc09848; Thu, 17 Jul 2003 15:58:32 -0700 X-mProtect: <200307172258> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbdyf8E; Thu, 17 Jul 2003 15:58:30 PDT Message-ID: <3F172A16.CD479640@iprg.nokia.com> Date: Thu, 17 Jul 2003 15:58:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > >I dont buy this argument. a protocol specification has to be > >tight and exact. I dont see why would need both for the same > >prefix. > > Hmm. Original text issue is below. Not sure if you are assuming > same prefix, which may not be always the case. > > >Vijay Devarapalli wrote: > When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT > create routes to the Mobile network when the Binding Update > from the Mobile Router is received. The Mobile Router also > MUST NOT include any prefix information in the Binding Update. > Any routes to the Mobile Network are created at the Home > Agent through routing protocol updates. this was proposed a few days back. the latest discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > >I disagree characterising this as an "config/operation" issue. > > > >I would agree if the Binding Updates and Routing Protocol > >updates carry different prefixes, i.e. if the MR uses a > >Binding Update to have the HA create routes for a certain > >perfix and it uses a routing protocol update for creating > >routes for a different prefix. > > Yes, the original text was exclusive in which method was used to > update the HA. Still I don't agree there needs to be any additional > checks. Again, what is the harm? what is the need? I dont see any. > The result is still traffic to MNP > are tunneled to the MR. *extra* traffic. > What about inter-mixing statically configured MNP with BU extensions > or IGP? > > This is something that multi-protocol routers deal with since they were > invented. Why is this such a special case? didnt follow the argument. my question is why add to that? I see that you already have to deal with a lot of mechanisms for adding routes. why add yet another mechanism when it can used exclusive to the IGP over the bi-directional tunnel. Vijay From nemo-admin@ietf.org Thu Jul 17 19:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26799 for ; Thu, 17 Jul 2003 19:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9N-0004tY-2a; Thu, 17 Jul 2003 19:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9M-0004tK-EB for nemo@optimus.ietf.org; Thu, 17 Jul 2003 19:27:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26770 for ; Thu, 17 Jul 2003 19:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dI9K-0002Hu-00 for nemo@ietf.org; Thu, 17 Jul 2003 19:26:58 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dI99-0002Hb-00 for nemo@ietf.org; Thu, 17 Jul 2003 19:26:48 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HNPnpp012842; Thu, 17 Jul 2003 16:25:49 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH53999; Thu, 17 Jul 2003 16:22:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 16:25:39 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F172A16.CD479640@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 03:58 PM 7/17/2003 -0700, Vijay Devarapalli wrote: >this was proposed a few days back. the latest >discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. Seems like I've been regurgitating some of the comments that Pascal had sent. > Again, what is the harm? > >what is the need? I dont see any. Stalemate. :) > > The result is still traffic to MNP > > are tunneled to the MR. > >*extra* traffic. Extra control traffic? Data traffic is still the same irregardless which protocol sets up the route to MNP. If it's control traffic, the MR is sending the BU with extensions and doing IGP. How is this avoided? >didnt follow the argument. my question is why add to >that? I see that you already have to deal with a lot >of mechanisms for adding routes. why add yet another >mechanism when it can used exclusive to the IGP over >the bi-directional tunnel. I'm saying that this is not yet another mechanism. It's the same mechanism. MIP is just another IGP in this context. Kent From exim@www1.ietf.org Thu Jul 17 19:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26816 for ; Thu, 17 Jul 2003 19:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9W-0004uT-8t for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 19:27:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HNRAss018869 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 19:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9W-0004uG-3t for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 19:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26777 for ; Thu, 17 Jul 2003 19:27:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dI9U-0002I7-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 19:27:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dI9P-0002I4-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 19:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9N-0004tY-2a; Thu, 17 Jul 2003 19:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dI9M-0004tK-EB for nemo@optimus.ietf.org; Thu, 17 Jul 2003 19:27:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26770 for ; Thu, 17 Jul 2003 19:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dI9K-0002Hu-00 for nemo@ietf.org; Thu, 17 Jul 2003 19:26:58 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dI99-0002Hb-00 for nemo@ietf.org; Thu, 17 Jul 2003 19:26:48 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HNPnpp012842; Thu, 17 Jul 2003 16:25:49 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn3-195.cisco.com [10.21.64.195]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJH53999; Thu, 17 Jul 2003 16:22:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 16:25:39 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F172A16.CD479640@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 03:58 PM 7/17/2003 -0700, Vijay Devarapalli wrote: >this was proposed a few days back. the latest >discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. Seems like I've been regurgitating some of the comments that Pascal had sent. > Again, what is the harm? > >what is the need? I dont see any. Stalemate. :) > > The result is still traffic to MNP > > are tunneled to the MR. > >*extra* traffic. Extra control traffic? Data traffic is still the same irregardless which protocol sets up the route to MNP. If it's control traffic, the MR is sending the BU with extensions and doing IGP. How is this avoided? >didnt follow the argument. my question is why add to >that? I see that you already have to deal with a lot >of mechanisms for adding routes. why add yet another >mechanism when it can used exclusive to the IGP over >the bi-directional tunnel. I'm saying that this is not yet another mechanism. It's the same mechanism. MIP is just another IGP in this context. Kent From nemo-admin@ietf.org Thu Jul 17 20:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28099 for ; Thu, 17 Jul 2003 20:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIvk-00077H-N2; Thu, 17 Jul 2003 20:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIun-00076d-SZ for nemo@optimus.ietf.org; Thu, 17 Jul 2003 20:16:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28047 for ; Thu, 17 Jul 2003 20:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dIul-0002hn-00 for nemo@ietf.org; Thu, 17 Jul 2003 20:15:59 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dIuV-0002h8-00 for nemo@ietf.org; Thu, 17 Jul 2003 20:15:43 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA18092; Thu, 17 Jul 2003 17:14:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6I0EkG17636; Thu, 17 Jul 2003 17:14:46 -0700 X-mProtect: <200307180014> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7cvyCl; Thu, 17 Jul 2003 17:14:45 PDT Message-ID: <3F173BF6.F60CD3F3@iprg.nokia.com> Date: Thu, 17 Jul 2003 17:14:46 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > > Again, what is the harm? > > > >what is the need? I dont see any. > > Stalemate. :) > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > >*extra* traffic. > > Extra control traffic? Data traffic is still the same irregardless which > protocol > sets up the route to MNP. If it's control traffic, the MR is sending the BU > with extensions and doing IGP. How is this avoided? if MR includes same prefix in both the BU and the IGP message, then it is extra traffic. > > >didnt follow the argument. my question is why add to > >that? I see that you already have to deal with a lot > >of mechanisms for adding routes. why add yet another > >mechanism when it can used exclusive to the IGP over > >the bi-directional tunnel. > > I'm saying that this is not yet another mechanism. It's the same > mechanism. MIP is just another IGP in this context. MIP adding prefix routes is a new mechanism. if you want to call it an IGP, its fine. but I wouldnt. anybody else has an opinion on this? this thread is going nowhere. Vijay From exim@www1.ietf.org Thu Jul 17 20:17:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28122 for ; Thu, 17 Jul 2003 20:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIvv-00078N-N5 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 20:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I0HBDS027417 for nemo-archive@odin.ietf.org; Thu, 17 Jul 2003 20:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIvv-000788-Ia for nemo-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 20:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28091 for ; Thu, 17 Jul 2003 20:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dIvt-0002ii-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 20:17:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dIvo-0002if-00 for nemo-web-archive@ietf.org; Thu, 17 Jul 2003 20:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIvk-00077H-N2; Thu, 17 Jul 2003 20:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dIun-00076d-SZ for nemo@optimus.ietf.org; Thu, 17 Jul 2003 20:16:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28047 for ; Thu, 17 Jul 2003 20:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dIul-0002hn-00 for nemo@ietf.org; Thu, 17 Jul 2003 20:15:59 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dIuV-0002h8-00 for nemo@ietf.org; Thu, 17 Jul 2003 20:15:43 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA18092; Thu, 17 Jul 2003 17:14:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6I0EkG17636; Thu, 17 Jul 2003 17:14:46 -0700 X-mProtect: <200307180014> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7cvyCl; Thu, 17 Jul 2003 17:14:45 PDT Message-ID: <3F173BF6.F60CD3F3@iprg.nokia.com> Date: Thu, 17 Jul 2003 17:14:46 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > > Again, what is the harm? > > > >what is the need? I dont see any. > > Stalemate. :) > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > >*extra* traffic. > > Extra control traffic? Data traffic is still the same irregardless which > protocol > sets up the route to MNP. If it's control traffic, the MR is sending the BU > with extensions and doing IGP. How is this avoided? if MR includes same prefix in both the BU and the IGP message, then it is extra traffic. > > >didnt follow the argument. my question is why add to > >that? I see that you already have to deal with a lot > >of mechanisms for adding routes. why add yet another > >mechanism when it can used exclusive to the IGP over > >the bi-directional tunnel. > > I'm saying that this is not yet another mechanism. It's the same > mechanism. MIP is just another IGP in this context. MIP adding prefix routes is a new mechanism. if you want to call it an IGP, its fine. but I wouldnt. anybody else has an opinion on this? this thread is going nowhere. Vijay From nemo-admin@ietf.org Fri Jul 18 12:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05253 for ; Fri, 18 Jul 2003 12:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYNp-0005Gs-Gh; Fri, 18 Jul 2003 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYMs-0005G9-JQ for nemo@optimus.ietf.org; Fri, 18 Jul 2003 12:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05177 for ; Fri, 18 Jul 2003 12:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dYLs-00020B-00 for nemo@ietf.org; Fri, 18 Jul 2003 12:45:00 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19dYLh-0001zg-00 for nemo@ietf.org; Fri, 18 Jul 2003 12:44:50 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6IGhvnX029174; Fri, 18 Jul 2003 18:43:58 +0200 Message-ID: <3F1821FE.80308@dpt-info.u-strasbg.fr> Date: Fri, 18 Jul 2003 18:36:14 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: mobileip , nemo@ietf.org Subject: Re: [nemo] multiple CoAs registration References: <3F166149.6000205@dpt-info.u-strasbg.fr> <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ryuji, I carry on my remarks... hope it helps ! Ryuji Wakikawa wrote: >Hello Nicolas > >thanks for comments. > > > >>Hi Ryuji, >> >>I read your draft on multiple CoAs registration and I also think that we >>really need to define a solution to use MIPv6 with a multiple interfaces >>MN. >> >>Here are some comments on your draft: >> >> - Why do you introduce the interface identification (IFID) ? It could >>be sufficient to only register a CoA with the associated priority. >>Therefore, when the MN has to choose the destination address for a HoA, >>it can take the most preferred CoA, which is bound to the most preferred >>interface of the MN. >> >> > >Priority can be changed by some reason during communication, but IFID >can not be changed until MN want to change it. > Ok, I understand that. But what I mean is that I don't see the requirement to have the IFID... In the Binding Cache, an entry could be identified by both the Home address and the CoA. It is sufficient to distinguish tow different entries. The priority field is then used to choose the CoA, i.e. the interface. No need to have the IFID I guess. > > > >>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore >>you don't need both, or I missed a point ? >> >>IMO, this is easier than all the mechanism to manage the IFID >>(generation, maintenance...) >> >> > >could be, but I don't know why the maintenance and generation are so >difficult. > I don't say they are so much difficult, but they are not useful, since the IFID is not necessary (from my point of view). Maybe you can explain me when the IFID is useful ? > > > >> - If I well understand your draft, when the MN registers a CoA with a >>CN, the MN has to first register the primary CoA. Then it can send a >>Binding Update (after the RR procedure) to regsiter other CoA(s), with >>the associated priority. However, you say that the lowest priority is >>the preferred CoA/IF, and that the primary CoA has the priority 0. >>Therefore, each CN will use the primary CoA with the MN. Then, you are >>not able to perform load balancing, aren't you ? >> >> > >Well, the draft does not mention about how to utilize multiple care-of >addresses. I don't think MIP is only way to manage policy sets to divide >flows to each CoAs. If you really want load-balancing, you need some >mechanism to maintain policy sets between MN and CNs. > >Load-balancing, for example, can be supported by upper >layers. >The point is that CN must be able to accept packets sent from multiple >.CoAs of MN. > Ok I agree with you. But is it necessary to impose that a MN MUST register the pCoA with the highest priority with CN ? I thnik it is important that the MN does it with the HA, but I don't think it is necessary with CN. If you have the choice to register the pCoA with a different priority with different CNs, you let an open door for upper layers to decide some load balancing policies. > > > >> - Last point: If you return home with your primary interface (you >>connect to your home network with P-IF), do you have to de-register all >>CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? >> >> > >You are right. I personally got the same comment. >I just keep protocol simple. >I will update the draft before the next meeting. > >thanks again! > >regards, >ryuji > > > From exim@www1.ietf.org Fri Jul 18 12:47:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05268 for ; Fri, 18 Jul 2003 12:47:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYO6-0005JO-Fr for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 12:47:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IGlIEv020414 for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 12:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYO6-0005JB-C3 for nemo-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 12:47:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05221 for ; Fri, 18 Jul 2003 12:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dYO4-00021P-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 12:47:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dYNz-00021A-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 12:47:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYNp-0005Gs-Gh; Fri, 18 Jul 2003 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dYMs-0005G9-JQ for nemo@optimus.ietf.org; Fri, 18 Jul 2003 12:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05177 for ; Fri, 18 Jul 2003 12:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dYLs-00020B-00 for nemo@ietf.org; Fri, 18 Jul 2003 12:45:00 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19dYLh-0001zg-00 for nemo@ietf.org; Fri, 18 Jul 2003 12:44:50 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6IGhvnX029174; Fri, 18 Jul 2003 18:43:58 +0200 Message-ID: <3F1821FE.80308@dpt-info.u-strasbg.fr> Date: Fri, 18 Jul 2003 18:36:14 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: mobileip , nemo@ietf.org Subject: Re: [nemo] multiple CoAs registration References: <3F166149.6000205@dpt-info.u-strasbg.fr> <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ryuji, I carry on my remarks... hope it helps ! Ryuji Wakikawa wrote: >Hello Nicolas > >thanks for comments. > > > >>Hi Ryuji, >> >>I read your draft on multiple CoAs registration and I also think that we >>really need to define a solution to use MIPv6 with a multiple interfaces >>MN. >> >>Here are some comments on your draft: >> >> - Why do you introduce the interface identification (IFID) ? It could >>be sufficient to only register a CoA with the associated priority. >>Therefore, when the MN has to choose the destination address for a HoA, >>it can take the most preferred CoA, which is bound to the most preferred >>interface of the MN. >> >> > >Priority can be changed by some reason during communication, but IFID >can not be changed until MN want to change it. > Ok, I understand that. But what I mean is that I don't see the requirement to have the IFID... In the Binding Cache, an entry could be identified by both the Home address and the CoA. It is sufficient to distinguish tow different entries. The priority field is then used to choose the CoA, i.e. the interface. No need to have the IFID I guess. > > > >>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore >>you don't need both, or I missed a point ? >> >>IMO, this is easier than all the mechanism to manage the IFID >>(generation, maintenance...) >> >> > >could be, but I don't know why the maintenance and generation are so >difficult. > I don't say they are so much difficult, but they are not useful, since the IFID is not necessary (from my point of view). Maybe you can explain me when the IFID is useful ? > > > >> - If I well understand your draft, when the MN registers a CoA with a >>CN, the MN has to first register the primary CoA. Then it can send a >>Binding Update (after the RR procedure) to regsiter other CoA(s), with >>the associated priority. However, you say that the lowest priority is >>the preferred CoA/IF, and that the primary CoA has the priority 0. >>Therefore, each CN will use the primary CoA with the MN. Then, you are >>not able to perform load balancing, aren't you ? >> >> > >Well, the draft does not mention about how to utilize multiple care-of >addresses. I don't think MIP is only way to manage policy sets to divide >flows to each CoAs. If you really want load-balancing, you need some >mechanism to maintain policy sets between MN and CNs. > >Load-balancing, for example, can be supported by upper >layers. >The point is that CN must be able to accept packets sent from multiple >.CoAs of MN. > Ok I agree with you. But is it necessary to impose that a MN MUST register the pCoA with the highest priority with CN ? I thnik it is important that the MN does it with the HA, but I don't think it is necessary with CN. If you have the choice to register the pCoA with a different priority with different CNs, you let an open door for upper layers to decide some load balancing policies. > > > >> - Last point: If you return home with your primary interface (you >>connect to your home network with P-IF), do you have to de-register all >>CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? >> >> > >You are right. I personally got the same comment. >I just keep protocol simple. >I will update the draft before the next meeting. > >thanks again! > >regards, >ryuji > > > From nemo-admin@ietf.org Fri Jul 18 17:22:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14044 for ; Fri, 18 Jul 2003 17:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dcfx-0005hK-Al; Fri, 18 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dcfK-0005h1-Tx for nemo@optimus.ietf.org; Fri, 18 Jul 2003 17:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14039 for ; Fri, 18 Jul 2003 17:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dcfI-0003iq-00 for nemo@ietf.org; Fri, 18 Jul 2003 17:21:20 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dcf7-0003ij-00 for nemo@ietf.org; Fri, 18 Jul 2003 17:21:09 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6ILKOPr013895; Fri, 18 Jul 2003 14:20:24 -0700 (MST) Received: from motorola.com (t_il01_e_port7.corp.mot.com [199.2.172.137]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6ILKIIM006329; Fri, 18 Jul 2003 16:20:19 -0500 Message-ID: <3F18804E.1000202@motorola.com> Date: Sat, 19 Jul 2003 01:18:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.com> In-Reply-To: <3F173BF6.F60CD3F3@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Kent Leung wrote: > >>> Again, what is the harm? >>> >>> what is the need? I dont see any. >> >> Stalemate. :) Puzzled. >>>> The result is still traffic to MNP are tunneled to the MR. >>> >>> *extra* traffic. >> >> Extra control traffic? Data traffic is still the same irregardless >> which protocol sets up the route to MNP. If it's control traffic, >> the MR is sending the BU with extensions and doing IGP. How is >> this avoided? > > > if MR includes same prefix in both the BU and the IGP message, then > it is extra traffic. > > >>> didnt follow the argument. my question is why add to that? I see >>> that you already have to deal with a lot of mechanisms for >>> adding routes. why add yet another mechanism when it can used >>> exclusive to the IGP over the bi-directional tunnel. >> >> I'm saying that this is not yet another mechanism. It's the same >> mechanism. MIP is just another IGP in this context. > > > MIP adding prefix routes is a new mechanism. if you want to call it > an IGP, its fine. but I wouldnt. > > anybody else has an opinion on this? Yes. My personal oppinion is my preference for "implicit" mode and let the rt protocols manage routes exclusively and not include prefixes at all in BU. Someone indicated that MIP might be seen as a rt protocol when it adds routes. However, I suspect there are tons of parameters (besides the prefix itself) that are used by rt protocol messaging, like metrics and such. Those paramaters should not be included in the BU's. And MIP replicating rt protocol functionality is probably redundant, IMHO. > this thread is going nowhere. Depends on where you want it to go. One might think of sitting and analyzing more, and better describing the rt protocol - MIP interactions... Alex GBU From exim@www1.ietf.org Fri Jul 18 17:25:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14080 for ; Fri, 18 Jul 2003 17:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dciQ-0005mC-QC for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 17:24:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ILOYAI022198 for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 17:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dciQ-0005lx-C2 for nemo-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 17:24:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14077 for ; Fri, 18 Jul 2003 17:24:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dciO-0003jA-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 17:24:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dci8-0003iw-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 17:24:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dcfx-0005hK-Al; Fri, 18 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dcfK-0005h1-Tx for nemo@optimus.ietf.org; Fri, 18 Jul 2003 17:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14039 for ; Fri, 18 Jul 2003 17:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dcfI-0003iq-00 for nemo@ietf.org; Fri, 18 Jul 2003 17:21:20 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dcf7-0003ij-00 for nemo@ietf.org; Fri, 18 Jul 2003 17:21:09 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6ILKOPr013895; Fri, 18 Jul 2003 14:20:24 -0700 (MST) Received: from motorola.com (t_il01_e_port7.corp.mot.com [199.2.172.137]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6ILKIIM006329; Fri, 18 Jul 2003 16:20:19 -0500 Message-ID: <3F18804E.1000202@motorola.com> Date: Sat, 19 Jul 2003 01:18:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.com> In-Reply-To: <3F173BF6.F60CD3F3@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Kent Leung wrote: > >>> Again, what is the harm? >>> >>> what is the need? I dont see any. >> >> Stalemate. :) Puzzled. >>>> The result is still traffic to MNP are tunneled to the MR. >>> >>> *extra* traffic. >> >> Extra control traffic? Data traffic is still the same irregardless >> which protocol sets up the route to MNP. If it's control traffic, >> the MR is sending the BU with extensions and doing IGP. How is >> this avoided? > > > if MR includes same prefix in both the BU and the IGP message, then > it is extra traffic. > > >>> didnt follow the argument. my question is why add to that? I see >>> that you already have to deal with a lot of mechanisms for >>> adding routes. why add yet another mechanism when it can used >>> exclusive to the IGP over the bi-directional tunnel. >> >> I'm saying that this is not yet another mechanism. It's the same >> mechanism. MIP is just another IGP in this context. > > > MIP adding prefix routes is a new mechanism. if you want to call it > an IGP, its fine. but I wouldnt. > > anybody else has an opinion on this? Yes. My personal oppinion is my preference for "implicit" mode and let the rt protocols manage routes exclusively and not include prefixes at all in BU. Someone indicated that MIP might be seen as a rt protocol when it adds routes. However, I suspect there are tons of parameters (besides the prefix itself) that are used by rt protocol messaging, like metrics and such. Those paramaters should not be included in the BU's. And MIP replicating rt protocol functionality is probably redundant, IMHO. > this thread is going nowhere. Depends on where you want it to go. One might think of sitting and analyzing more, and better describing the rt protocol - MIP interactions... Alex GBU From nemo-admin@ietf.org Fri Jul 18 20:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18748 for ; Fri, 18 Jul 2003 20:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfOK-0002Ej-MH; Fri, 18 Jul 2003 20:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfNc-0002ES-NT for nemo@optimus.ietf.org; Fri, 18 Jul 2003 20:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18733 for ; Fri, 18 Jul 2003 20:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dfNa-0004rA-00 for nemo@ietf.org; Fri, 18 Jul 2003 20:15:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dfNP-0004qV-00 for nemo@ietf.org; Fri, 18 Jul 2003 20:15:04 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA11580; Fri, 18 Jul 2003 17:14:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6J0EMB10524; Fri, 18 Jul 2003 17:14:22 -0700 X-mProtect: <200307190014> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoqcqtS; Fri, 18 Jul 2003 17:14:20 PDT Message-ID: <3F188D5D.A1EC79E2@iprg.nokia.com> Date: Fri, 18 Jul 2003 17:14:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pekka.paakkonen@vtt.fi, juhani.latvakoski@vtt.fi CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Pekka and Juhani, this draft is a very good alternative to using DHCPv6 for prefix delegation (however, I will let the WG decide if we need an alternative to DHCPv6 for NEMO prefix delegation). some comments > MNP Delegator Query (0) > > The MNP Delegator Query message is used by the MR to query MNP > delegators (HAs) and their abilities to delegate MNP(s). This > message is sent to MR's HA during the MNP Query sequence. > > > MNP Delegator (4) > > A MNP Delegator message is sent by the HA during MNP Query > sequence. It is used to inform MR of MNP(s) HA is capable of > delegating. I suggest getting rid of these two messages. the HA can always respond with MNP Unavailable in response to a MNP Request message. do you need a query round before the request? > 5.3.2 MNP Data Option > > MNP Data Option holds MNP information related to a single MNP. > > Option format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Preferred lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Valid lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Prefix length | IPv6 prefix (16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > | | > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Match | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I dont think you need both a valid lifetime and preferred lifetime field. in your examples in section 5.5 you always set both lifetime fields to the same value :). here is a new format with an alignment requirement of 8n+1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Prefix Length | Match | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > After the MR has queried > the capabilities of its HAs with this sequence, MR should advance to > MNP Delegation sequence with the chosen HA to proceed with MNP > delegation. this is clearly not needed. if the HA responds with MNP Unavailable in case it cant delegate a prefix, you can do the same in two round trips. OTOH if the HA can delegate a prefix, you can have a prefix delegated in just one round trip. > If these checks are not valid, HA MUST silently ignore the message. the HA should generate an ICMP error message instead of silently dropping the message. I just skimmed the rest of the draft. IMHO, you can get rid of section 5.5. there isnt much in it. it would make the draft shorter. Vijay From exim@www1.ietf.org Fri Jul 18 20:16:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18763 for ; Fri, 18 Jul 2003 20:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfOU-0002Fe-5L for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 20:16:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6J0GAn6008650 for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 20:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfOU-0002FR-1h for nemo-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 20:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18738 for ; Fri, 18 Jul 2003 20:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dfOS-0004rU-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 20:16:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dfOM-0004rR-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 20:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfOK-0002Ej-MH; Fri, 18 Jul 2003 20:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dfNc-0002ES-NT for nemo@optimus.ietf.org; Fri, 18 Jul 2003 20:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18733 for ; Fri, 18 Jul 2003 20:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dfNa-0004rA-00 for nemo@ietf.org; Fri, 18 Jul 2003 20:15:14 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dfNP-0004qV-00 for nemo@ietf.org; Fri, 18 Jul 2003 20:15:04 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA11580; Fri, 18 Jul 2003 17:14:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6J0EMB10524; Fri, 18 Jul 2003 17:14:22 -0700 X-mProtect: <200307190014> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoqcqtS; Fri, 18 Jul 2003 17:14:20 PDT Message-ID: <3F188D5D.A1EC79E2@iprg.nokia.com> Date: Fri, 18 Jul 2003 17:14:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pekka.paakkonen@vtt.fi, juhani.latvakoski@vtt.fi CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Pekka and Juhani, this draft is a very good alternative to using DHCPv6 for prefix delegation (however, I will let the WG decide if we need an alternative to DHCPv6 for NEMO prefix delegation). some comments > MNP Delegator Query (0) > > The MNP Delegator Query message is used by the MR to query MNP > delegators (HAs) and their abilities to delegate MNP(s). This > message is sent to MR's HA during the MNP Query sequence. > > > MNP Delegator (4) > > A MNP Delegator message is sent by the HA during MNP Query > sequence. It is used to inform MR of MNP(s) HA is capable of > delegating. I suggest getting rid of these two messages. the HA can always respond with MNP Unavailable in response to a MNP Request message. do you need a query round before the request? > 5.3.2 MNP Data Option > > MNP Data Option holds MNP information related to a single MNP. > > Option format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Preferred lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Valid lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Prefix length | IPv6 prefix (16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > | | > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Match | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I dont think you need both a valid lifetime and preferred lifetime field. in your examples in section 5.5 you always set both lifetime fields to the same value :). here is a new format with an alignment requirement of 8n+1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Prefix Length | Match | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > After the MR has queried > the capabilities of its HAs with this sequence, MR should advance to > MNP Delegation sequence with the chosen HA to proceed with MNP > delegation. this is clearly not needed. if the HA responds with MNP Unavailable in case it cant delegate a prefix, you can do the same in two round trips. OTOH if the HA can delegate a prefix, you can have a prefix delegated in just one round trip. > If these checks are not valid, HA MUST silently ignore the message. the HA should generate an ICMP error message instead of silently dropping the message. I just skimmed the rest of the draft. IMHO, you can get rid of section 5.5. there isnt much in it. it would make the draft shorter. Vijay From nemo-admin@ietf.org Fri Jul 18 22:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20724 for ; Fri, 18 Jul 2003 22:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhHQ-00059p-TS; Fri, 18 Jul 2003 22:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhGZ-00059U-Jh for nemo@optimus.ietf.org; Fri, 18 Jul 2003 22:16:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20710 for ; Fri, 18 Jul 2003 22:16:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dhGW-0005Wo-00 for nemo@ietf.org; Fri, 18 Jul 2003 22:16:04 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dhGL-0005WP-00 for nemo@ietf.org; Fri, 18 Jul 2003 22:15:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA18262; Fri, 18 Jul 2003 19:15:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6J2F2Z30285; Fri, 18 Jul 2003 19:15:02 -0700 X-mProtect: <200307190215> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdooV7je; Fri, 18 Jul 2003 19:15:01 PDT Message-ID: <3F18A9A5.3EEA474E@iprg.nokia.com> Date: Fri, 18 Jul 2003 19:15:01 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > anybody else has an opinion on this? > > Yes. My personal oppinion is my preference for "implicit" mode and let > the rt protocols manage routes exclusively and not include prefixes at > all in BU. Alex and others, let me phrase the issue better. the question is should the mobile router be able to use both prefix information in the binding update and a dynamic routing protocol simultaneously to create routes at the HA? or should these two mechanisms be used exclusive to each other? my proposal is When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. Kent and Pascal argue that this restriction should not be there. it is currently possible (according to them) to run two IGP protocol at the same time and nothing breaks. so there is no reason to have this restriction. my argument is where do you use it? how does the MR know which prefix should be sent in the BU and which in the routing protocol message? if same prefix is sent in both, then it is redundant. I probably have not listed all the arguments here. the entire discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. Vijay From exim@www1.ietf.org Fri Jul 18 22:17:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20749 for ; Fri, 18 Jul 2003 22:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhHZ-0005Ah-Vh for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 22:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6J2H9Kl019878 for nemo-archive@odin.ietf.org; Fri, 18 Jul 2003 22:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhHZ-0005AX-Pi for nemo-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 22:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20714 for ; Fri, 18 Jul 2003 22:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dhHW-0005XI-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 22:17:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dhHR-0005XF-00 for nemo-web-archive@ietf.org; Fri, 18 Jul 2003 22:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhHQ-00059p-TS; Fri, 18 Jul 2003 22:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dhGZ-00059U-Jh for nemo@optimus.ietf.org; Fri, 18 Jul 2003 22:16:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20710 for ; Fri, 18 Jul 2003 22:16:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dhGW-0005Wo-00 for nemo@ietf.org; Fri, 18 Jul 2003 22:16:04 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19dhGL-0005WP-00 for nemo@ietf.org; Fri, 18 Jul 2003 22:15:53 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA18262; Fri, 18 Jul 2003 19:15:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6J2F2Z30285; Fri, 18 Jul 2003 19:15:02 -0700 X-mProtect: <200307190215> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdooV7je; Fri, 18 Jul 2003 19:15:01 PDT Message-ID: <3F18A9A5.3EEA474E@iprg.nokia.com> Date: Fri, 18 Jul 2003 19:15:01 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > anybody else has an opinion on this? > > Yes. My personal oppinion is my preference for "implicit" mode and let > the rt protocols manage routes exclusively and not include prefixes at > all in BU. Alex and others, let me phrase the issue better. the question is should the mobile router be able to use both prefix information in the binding update and a dynamic routing protocol simultaneously to create routes at the HA? or should these two mechanisms be used exclusive to each other? my proposal is When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. Kent and Pascal argue that this restriction should not be there. it is currently possible (according to them) to run two IGP protocol at the same time and nothing breaks. so there is no reason to have this restriction. my argument is where do you use it? how does the MR know which prefix should be sent in the BU and which in the routing protocol message? if same prefix is sent in both, then it is redundant. I probably have not listed all the arguments here. the entire discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. Vijay From nemo-admin@ietf.org Sat Jul 19 08:15:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12494 for ; Sat, 19 Jul 2003 08:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqcA-00063Z-2K; Sat, 19 Jul 2003 08:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqbV-0005zk-9C for nemo@optimus.ietf.org; Sat, 19 Jul 2003 08:14:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12433 for ; Sat, 19 Jul 2003 08:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dqbU-0001bh-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:14:20 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19dqbJ-0001bH-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:14:09 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JCD3ef005863; Sat, 19 Jul 2003 21:13:05 +0900 Date: Sat, 19 Jul 2003 21:15:50 +0900 From: Ryuji Wakikawa To: Nicolas Montavont Subject: Re: [mobile-ip] Re: [nemo] multiple CoAs registration Cc: mobileip , nemo@ietf.org In-Reply-To: <3F1821FE.80308@dpt-info.u-strasbg.fr> References: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> <3F1821FE.80308@dpt-info.u-strasbg.fr> Message-Id: <20030719205301.93B9.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Nicolas > Hi Ryuji, > > I carry on my remarks... hope it helps ! > > Ryuji Wakikawa wrote: > > >Hello Nicolas > > > >thanks for comments. > > > > > > > >>Hi Ryuji, > >> > >>I read your draft on multiple CoAs registration and I also think that we > >>really need to define a solution to use MIPv6 with a multiple interfaces > >>MN. > >> > >>Here are some comments on your draft: > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I disagree. ID is needed when CoA is changed. If CoA1 is changed to CoA2, MN sends a BU with CoA2 to CN. Before receiving the BU, CN has the binding entry which associate with CoA1 and HoA, but BU carries new CoA2 in it. CN can not know which binding cache entry should be updated for the BU. CN might create a new entry for the BU, because the pair of CoA1 and HoA is different from CoA2 and HoA. ID is enable CN to update the correspondent binding entry even if CoA is changed. > > > > > > > >>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore > >>you don't need both, or I missed a point ? > >> > >>IMO, this is easier than all the mechanism to manage the IFID > >>(generation, maintenance...) > >> > >> > > > >could be, but I don't know why the maintenance and generation are so > >difficult. > > > I don't say they are so much difficult, but they are not useful, since > the IFID is not necessary (from my point of view). Maybe you can explain > me when the IFID is useful ? see above. > > > > > > > >> - If I well understand your draft, when the MN registers a CoA with a > >>CN, the MN has to first register the primary CoA. Then it can send a > >>Binding Update (after the RR procedure) to regsiter other CoA(s), with > >>the associated priority. However, you say that the lowest priority is > >>the preferred CoA/IF, and that the primary CoA has the priority 0. > >>Therefore, each CN will use the primary CoA with the MN. Then, you are > >>not able to perform load balancing, aren't you ? > >> > >> > > > >Well, the draft does not mention about how to utilize multiple care-of > >addresses. I don't think MIP is only way to manage policy sets to divide > >flows to each CoAs. If you really want load-balancing, you need some > >mechanism to maintain policy sets between MN and CNs. > > > >Load-balancing, for example, can be supported by upper > >layers. > >The point is that CN must be able to accept packets sent from multiple > >.CoAs of MN. > > > Ok I agree with you. But is it necessary to impose that a MN MUST > register the pCoA with the highest priority with CN ? I thnik it is > important that the MN does it with the HA, but I don't think it is > necessary with CN. I got comments from WGchair whether I need priority field or not. Policy can be treated as one of policy. I might remove the priority field and keep the field as reserved. If there are no policies and priority values on CN, CN uses the first matched BC entry for outgoing packets. > If you have the choice to register the pCoA with a different priority > with different CNs, you let an open door for upper layers to decide some > load balancing policies. This management is difficult. How does MN give different priority for each CNs. One of my intention is to eliminate these MN's decision from the draft. I am interested in the policy management and notification, but it should be described in a separate draft. anyway, the issue of priority field is in my todo lists. I appreciate if anybody has comments on this regards, ryuji > > > > > > > >> - Last point: If you return home with your primary interface (you > >>connect to your home network with P-IF), do you have to de-register all > >>CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? > >> > >> > > > >You are right. I personally got the same comment. > >I just keep protocol simple. > >I will update the draft before the next meeting. > > > >thanks again! > > > >regards, > >ryuji > > > > > > > From exim@www1.ietf.org Sat Jul 19 08:15:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12510 for ; Sat, 19 Jul 2003 08:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqcL-00066J-1Q for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 08:15:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JCFD9Y023445 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 08:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqcK-000664-TN for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 08:15:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12482 for ; Sat, 19 Jul 2003 08:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dqcJ-0001cw-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 08:15:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dqcD-0001ct-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 08:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqcA-00063Z-2K; Sat, 19 Jul 2003 08:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dqbV-0005zk-9C for nemo@optimus.ietf.org; Sat, 19 Jul 2003 08:14:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12433 for ; Sat, 19 Jul 2003 08:14:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dqbU-0001bh-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:14:20 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19dqbJ-0001bH-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:14:09 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JCD3ef005863; Sat, 19 Jul 2003 21:13:05 +0900 Date: Sat, 19 Jul 2003 21:15:50 +0900 From: Ryuji Wakikawa To: Nicolas Montavont Subject: Re: [mobile-ip] Re: [nemo] multiple CoAs registration Cc: mobileip , nemo@ietf.org In-Reply-To: <3F1821FE.80308@dpt-info.u-strasbg.fr> References: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> <3F1821FE.80308@dpt-info.u-strasbg.fr> Message-Id: <20030719205301.93B9.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Nicolas > Hi Ryuji, > > I carry on my remarks... hope it helps ! > > Ryuji Wakikawa wrote: > > >Hello Nicolas > > > >thanks for comments. > > > > > > > >>Hi Ryuji, > >> > >>I read your draft on multiple CoAs registration and I also think that we > >>really need to define a solution to use MIPv6 with a multiple interfaces > >>MN. > >> > >>Here are some comments on your draft: > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I disagree. ID is needed when CoA is changed. If CoA1 is changed to CoA2, MN sends a BU with CoA2 to CN. Before receiving the BU, CN has the binding entry which associate with CoA1 and HoA, but BU carries new CoA2 in it. CN can not know which binding cache entry should be updated for the BU. CN might create a new entry for the BU, because the pair of CoA1 and HoA is different from CoA2 and HoA. ID is enable CN to update the correspondent binding entry even if CoA is changed. > > > > > > > >>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore > >>you don't need both, or I missed a point ? > >> > >>IMO, this is easier than all the mechanism to manage the IFID > >>(generation, maintenance...) > >> > >> > > > >could be, but I don't know why the maintenance and generation are so > >difficult. > > > I don't say they are so much difficult, but they are not useful, since > the IFID is not necessary (from my point of view). Maybe you can explain > me when the IFID is useful ? see above. > > > > > > > >> - If I well understand your draft, when the MN registers a CoA with a > >>CN, the MN has to first register the primary CoA. Then it can send a > >>Binding Update (after the RR procedure) to regsiter other CoA(s), with > >>the associated priority. However, you say that the lowest priority is > >>the preferred CoA/IF, and that the primary CoA has the priority 0. > >>Therefore, each CN will use the primary CoA with the MN. Then, you are > >>not able to perform load balancing, aren't you ? > >> > >> > > > >Well, the draft does not mention about how to utilize multiple care-of > >addresses. I don't think MIP is only way to manage policy sets to divide > >flows to each CoAs. If you really want load-balancing, you need some > >mechanism to maintain policy sets between MN and CNs. > > > >Load-balancing, for example, can be supported by upper > >layers. > >The point is that CN must be able to accept packets sent from multiple > >.CoAs of MN. > > > Ok I agree with you. But is it necessary to impose that a MN MUST > register the pCoA with the highest priority with CN ? I thnik it is > important that the MN does it with the HA, but I don't think it is > necessary with CN. I got comments from WGchair whether I need priority field or not. Policy can be treated as one of policy. I might remove the priority field and keep the field as reserved. If there are no policies and priority values on CN, CN uses the first matched BC entry for outgoing packets. > If you have the choice to register the pCoA with a different priority > with different CNs, you let an open door for upper layers to decide some > load balancing policies. This management is difficult. How does MN give different priority for each CNs. One of my intention is to eliminate these MN's decision from the draft. I am interested in the policy management and notification, but it should be described in a separate draft. anyway, the issue of priority field is in my todo lists. I appreciate if anybody has comments on this regards, ryuji > > > > > > > >> - Last point: If you return home with your primary interface (you > >>connect to your home network with P-IF), do you have to de-register all > >>CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ? > >> > >> > > > >You are right. I personally got the same comment. > >I just keep protocol simple. > >I will update the draft before the next meeting. > > > >thanks again! > > > >regards, > >ryuji > > > > > > > From nemo-admin@ietf.org Sat Jul 19 08:56:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13090 for ; Sat, 19 Jul 2003 08:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drFq-000706-2T; Sat, 19 Jul 2003 08:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drF2-0006zh-1M for nemo@optimus.ietf.org; Sat, 19 Jul 2003 08:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13079 for ; Sat, 19 Jul 2003 08:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19drF0-0001oM-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:55:10 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19drEp-0001nv-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:54:59 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JCs1ef006081; Sat, 19 Jul 2003 21:54:03 +0900 Date: Sat, 19 Jul 2003 21:56:50 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] IGP and MIP routes. Cc: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F18A9A5.3EEA474E@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> Message-Id: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, > Alexandru Petrescu wrote: > > > > > anybody else has an opinion on this? > > > > Yes. My personal oppinion is my preference for "implicit" mode and let > > the rt protocols manage routes exclusively and not include prefixes at > > all in BU. > > Alex and others, > > let me phrase the issue better. > > the question is should the mobile router be able to > use both prefix information in the binding update and > a dynamic routing protocol simultaneously to create > routes at the HA? or should these two mechanisms be > used exclusive to each other? > > my proposal is > > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. > > Kent and Pascal argue that this restriction should > not be there. it is currently possible (according to > them) to run two IGP protocol at the same time and > nothing breaks. so there is no reason to have this > restriction. > > my argument is where do you use it? If we say routing procols, which routing protocols do you have in mind? for example, MANET is also a routing protocol. If specially reactive protocols such as AODV and DSR are used on MR, MR prefer using BU to manage MNP with HA. I am not sure if people wants to use AODV on MR, but the current text limits the use of it. Does anybody have some other examples?? > how does the MR know which prefix should be sent in the BU and which > in the routing protocol message? if same prefix is > sent in both, then it is redundant. You are right, it is hard to know which prefix should be carried by the BU or by the routing protocol. An easiest way is just sending same prefix in both. I don't see big problem to send same prefix in both the BU and the routing protocol. It is redundant, but it's not so big deal, isn't it?! Isn't some warning enough in the base spec? This is operation matter unless the NEMO protocol is consistent. regards, ryuji > I probably have not listed all the arguments here. > the entire discussion is at > http://people.nokia.net/vijayd/nemo/issue6.txt. > > Vijay From exim@www1.ietf.org Sat Jul 19 08:56:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13105 for ; Sat, 19 Jul 2003 08:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drFx-000713-Ha for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 08:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JCu97O026963 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 08:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drFx-00070o-DE for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 08:56:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13087 for ; Sat, 19 Jul 2003 08:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19drFw-0001oe-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 08:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19drFq-0001ob-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 08:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drFq-000706-2T; Sat, 19 Jul 2003 08:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19drF2-0006zh-1M for nemo@optimus.ietf.org; Sat, 19 Jul 2003 08:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13079 for ; Sat, 19 Jul 2003 08:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19drF0-0001oM-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:55:10 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19drEp-0001nv-00 for nemo@ietf.org; Sat, 19 Jul 2003 08:54:59 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JCs1ef006081; Sat, 19 Jul 2003 21:54:03 +0900 Date: Sat, 19 Jul 2003 21:56:50 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] IGP and MIP routes. Cc: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F18A9A5.3EEA474E@iprg.nokia.com> References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> Message-Id: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, > Alexandru Petrescu wrote: > > > > > anybody else has an opinion on this? > > > > Yes. My personal oppinion is my preference for "implicit" mode and let > > the rt protocols manage routes exclusively and not include prefixes at > > all in BU. > > Alex and others, > > let me phrase the issue better. > > the question is should the mobile router be able to > use both prefix information in the binding update and > a dynamic routing protocol simultaneously to create > routes at the HA? or should these two mechanisms be > used exclusive to each other? > > my proposal is > > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. > > Kent and Pascal argue that this restriction should > not be there. it is currently possible (according to > them) to run two IGP protocol at the same time and > nothing breaks. so there is no reason to have this > restriction. > > my argument is where do you use it? If we say routing procols, which routing protocols do you have in mind? for example, MANET is also a routing protocol. If specially reactive protocols such as AODV and DSR are used on MR, MR prefer using BU to manage MNP with HA. I am not sure if people wants to use AODV on MR, but the current text limits the use of it. Does anybody have some other examples?? > how does the MR know which prefix should be sent in the BU and which > in the routing protocol message? if same prefix is > sent in both, then it is redundant. You are right, it is hard to know which prefix should be carried by the BU or by the routing protocol. An easiest way is just sending same prefix in both. I don't see big problem to send same prefix in both the BU and the routing protocol. It is redundant, but it's not so big deal, isn't it?! Isn't some warning enough in the base spec? This is operation matter unless the NEMO protocol is consistent. regards, ryuji > I probably have not listed all the arguments here. > the entire discussion is at > http://people.nokia.net/vijayd/nemo/issue6.txt. > > Vijay From nemo-admin@ietf.org Sat Jul 19 12:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17551 for ; Sat, 19 Jul 2003 12:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duX3-0003xF-Cg; Sat, 19 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duWN-0003wt-G4 for nemo@optimus.ietf.org; Sat, 19 Jul 2003 12:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17544 for ; Sat, 19 Jul 2003 12:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duWL-00031S-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:25:17 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19duWA-00031I-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:25:07 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6JGOaUb012514; Sat, 19 Jul 2003 09:24:36 -0700 (MST) Received: from motorola.com (t_il06_s_port5.corp.mot.com [129.188.171.47]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6JGOHH1029968; Sat, 19 Jul 2003 11:24:18 -0500 Message-ID: <3F198C70.8030209@motorola.com> Date: Sat, 19 Jul 2003 20:22:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > If we say routing procols, which routing protocols do you have in > mind? There are only a few that are in widespread use, look for those. > for example, MANET is also a routing protocol. If specially reactive > protocols such as AODV and DSR are used on MR, MR prefer using BU to > manage MNP with HA. I am not sure if people wants to use AODV on MR, I first want RIP and OSPF, then the experimentals (which are btw derivations from the former). > but the current text limits the use of it. So the current text forbids AODV and DSR? I haven't seen that limitation, could you please more explicit, what's the limitation more exactly? Alex GBU From exim@www1.ietf.org Sat Jul 19 12:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17577 for ; Sat, 19 Jul 2003 12:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duXA-0003zM-Sq for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 12:26:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JGQ8Cu015326 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 12:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duXA-0003z7-NX for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 12:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17548 for ; Sat, 19 Jul 2003 12:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duX9-00031b-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 12:26:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19duX3-00031Y-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 12:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duX3-0003xF-Cg; Sat, 19 Jul 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duWN-0003wt-G4 for nemo@optimus.ietf.org; Sat, 19 Jul 2003 12:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17544 for ; Sat, 19 Jul 2003 12:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duWL-00031S-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:25:17 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19duWA-00031I-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:25:07 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6JGOaUb012514; Sat, 19 Jul 2003 09:24:36 -0700 (MST) Received: from motorola.com (t_il06_s_port5.corp.mot.com [129.188.171.47]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6JGOHH1029968; Sat, 19 Jul 2003 11:24:18 -0500 Message-ID: <3F198C70.8030209@motorola.com> Date: Sat, 19 Jul 2003 20:22:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > If we say routing procols, which routing protocols do you have in > mind? There are only a few that are in widespread use, look for those. > for example, MANET is also a routing protocol. If specially reactive > protocols such as AODV and DSR are used on MR, MR prefer using BU to > manage MNP with HA. I am not sure if people wants to use AODV on MR, I first want RIP and OSPF, then the experimentals (which are btw derivations from the former). > but the current text limits the use of it. So the current text forbids AODV and DSR? I haven't seen that limitation, could you please more explicit, what's the limitation more exactly? Alex GBU From nemo-admin@ietf.org Sat Jul 19 12:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17817 for ; Sat, 19 Jul 2003 12:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duwE-0004c3-4u; Sat, 19 Jul 2003 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duw7-0004bi-0U for nemo@optimus.ietf.org; Sat, 19 Jul 2003 12:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17802 for ; Sat, 19 Jul 2003 12:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duw5-00035Z-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:51:53 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19duvu-00035O-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:51:42 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JGoRef007281; Sun, 20 Jul 2003 01:50:27 +0900 Date: Sun, 20 Jul 2003 01:53:12 +0900 From: Ryuji Wakikawa To: Alexandru Petrescu Subject: Re: [nemo] IGP and MIP routes. Cc: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F198C70.8030209@motorola.com> References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> Message-Id: <20030720012939.1231.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Ryuji Wakikawa wrote: > > If we say routing procols, which routing protocols do you have in > > mind? > > There are only a few that are in widespread use, look for those. > > for example, MANET is also a routing protocol. If specially reactive > > protocols such as AODV and DSR are used on MR, MR prefer using BU to > > manage MNP with HA. I am not sure if people wants to use AODV on MR, > > I first want RIP and OSPF, then the experimentals (which are btw > derivations from the former). > > > but the current text limits the use of it. > > So the current text forbids AODV and DSR? I haven't seen that > limitation, could you please more explicit, what's the limitation more > exactly? You misinterpret here. I said the current text forbids to send MNP in the BU when MR runs AODV or DSR. It is OK to use only AODV or DSR to carry MNP to HA, but there might be some requirement to use NEMO as well to ensure the registration. The use of BU might be redundant, but more reliable in some situation. I want to change the text something like below. original When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. suggestion When the Mobile Router and the Home Agent exchange routes of specific mobile network prefixes through routing protocol updates, the Home Agent MUST NOT create the routes of the mobile network prefixes to the Mobile Router when the Binding Update from the Mobile Router is received. The Mobile Router also SHOULD NOT include the mobile network prefixes exchanged by routing protocol in the Binding Update. The routes of the mobile network prefixes to the Mobile Router SHOULD be created at the Home Agent through routing protocol updates. ryuji From exim@www1.ietf.org Sat Jul 19 12:52:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17855 for ; Sat, 19 Jul 2003 12:52:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duwa-0004qD-8y for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 12:52:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JGqOX7018603 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 12:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duwa-0004py-4J for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 12:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17814 for ; Sat, 19 Jul 2003 12:52:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duwY-00035m-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 12:52:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19duwS-00035c-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 12:52:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duwE-0004c3-4u; Sat, 19 Jul 2003 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19duw7-0004bi-0U for nemo@optimus.ietf.org; Sat, 19 Jul 2003 12:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17802 for ; Sat, 19 Jul 2003 12:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19duw5-00035Z-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:51:53 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19duvu-00035O-00 for nemo@ietf.org; Sat, 19 Jul 2003 12:51:42 -0400 Received: from [192.168.0.11] (p29b46c.tkyoac00.ap.so-net.ne.jp [218.41.180.108]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6JGoRef007281; Sun, 20 Jul 2003 01:50:27 +0900 Date: Sun, 20 Jul 2003 01:53:12 +0900 From: Ryuji Wakikawa To: Alexandru Petrescu Subject: Re: [nemo] IGP and MIP routes. Cc: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org In-Reply-To: <3F198C70.8030209@motorola.com> References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> Message-Id: <20030720012939.1231.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Ryuji Wakikawa wrote: > > If we say routing procols, which routing protocols do you have in > > mind? > > There are only a few that are in widespread use, look for those. > > for example, MANET is also a routing protocol. If specially reactive > > protocols such as AODV and DSR are used on MR, MR prefer using BU to > > manage MNP with HA. I am not sure if people wants to use AODV on MR, > > I first want RIP and OSPF, then the experimentals (which are btw > derivations from the former). > > > but the current text limits the use of it. > > So the current text forbids AODV and DSR? I haven't seen that > limitation, could you please more explicit, what's the limitation more > exactly? You misinterpret here. I said the current text forbids to send MNP in the BU when MR runs AODV or DSR. It is OK to use only AODV or DSR to carry MNP to HA, but there might be some requirement to use NEMO as well to ensure the registration. The use of BU might be redundant, but more reliable in some situation. I want to change the text something like below. original When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. suggestion When the Mobile Router and the Home Agent exchange routes of specific mobile network prefixes through routing protocol updates, the Home Agent MUST NOT create the routes of the mobile network prefixes to the Mobile Router when the Binding Update from the Mobile Router is received. The Mobile Router also SHOULD NOT include the mobile network prefixes exchanged by routing protocol in the Binding Update. The routes of the mobile network prefixes to the Mobile Router SHOULD be created at the Home Agent through routing protocol updates. ryuji From nemo-admin@ietf.org Sat Jul 19 17:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22846 for ; Sat, 19 Jul 2003 17:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0n-0002jQ-GT; Sat, 19 Jul 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0X-0002jD-7P for nemo@optimus.ietf.org; Sat, 19 Jul 2003 17:12:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22826 for ; Sat, 19 Jul 2003 17:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz0U-0004Ji-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:12:43 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dz0K-0004JQ-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:12:32 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6JLBsPr010756; Sat, 19 Jul 2003 14:11:54 -0700 (MST) Received: from motorola.com (t-il06ac-port21.corp.mot.com [129.188.170.169]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6JLBnIM016653; Sat, 19 Jul 2003 16:11:50 -0500 Message-ID: <3F19CFCB.8040007@motorola.com> Date: Sun, 20 Jul 2003 01:10:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> <20030720012939.1231.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20030720012939.1231.RYUJI@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >> Ryuji Wakikawa wrote: >> >>> If we say routing procols, which routing protocols do you have in >>> mind? >> >> There are only a few that are in widespread use, look for those. >> >>> for example, MANET is also a routing protocol. If specially >>> reactive protocols such as AODV and DSR are used on MR, MR prefer >>> using BU to manage MNP with HA. I am not sure if people wants to >>> use AODV on MR, >> >> I first want RIP and OSPF, then the experimentals (which are btw >> derivations from the former). >> >> >>> but the current text limits the use of it. >> >> So the current text forbids AODV and DSR? I haven't seen that >> limitation, could you please more explicit, what's the limitation >> more exactly? > > > You misinterpret here. Sorry. > I said the current text forbids to send MNP in the BU when MR runs > AODV or DSR. It is OK to use only AODV or DSR to carry MNP to HA, I think DSR will not put any form of MNP in any form of message (be it BU or route update). I mean no prefix, but list of addresses. So you come down to AODV only which can be treated from a RIP perspective. > but there might be some requirement to use NEMO as well to ensure the > registration. The use of BU might be redundant, but more reliable in > some situation. > > I want to change the text something like below. Ok... > original When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT create > routes to the Mobile network when the Binding Update from the Mobile > Router is received. The Mobile Router also MUST NOT include any > prefix information in the Binding Update. Any routes to the Mobile > Network are created at the Home Agent through routing protocol > updates. > > suggestion When the Mobile Router and the Home Agent exchange routes > of specific mobile network prefixes through routing protocol updates, > the Home Agent MUST NOT create the routes of the mobile network > prefixes to the Mobile Router when the Binding Update from the Mobile > Router is received. The Mobile Router also SHOULD NOT include the > mobile network prefixes exchanged by routing protocol in the Binding > Update. The routes of the mobile network prefixes to the Mobile > Router SHOULD be created at the Home Agent through routing protocol > updates. To me, they both sound good. Alex GBU From exim@www1.ietf.org Sat Jul 19 17:13:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22863 for ; Sat, 19 Jul 2003 17:13:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0x-0002kM-PO for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 17:13:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JLDBLg010554 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 17:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0x-0002k9-L9 for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 17:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22835 for ; Sat, 19 Jul 2003 17:13:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz0v-0004Jr-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 17:13:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dz0p-0004Jo-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 17:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0n-0002jQ-GT; Sat, 19 Jul 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz0X-0002jD-7P for nemo@optimus.ietf.org; Sat, 19 Jul 2003 17:12:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22826 for ; Sat, 19 Jul 2003 17:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz0U-0004Ji-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:12:43 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19dz0K-0004JQ-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:12:32 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6JLBsPr010756; Sat, 19 Jul 2003 14:11:54 -0700 (MST) Received: from motorola.com (t-il06ac-port21.corp.mot.com [129.188.170.169]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6JLBnIM016653; Sat, 19 Jul 2003 16:11:50 -0500 Message-ID: <3F19CFCB.8040007@motorola.com> Date: Sun, 20 Jul 2003 01:10:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Vijay Devarapalli , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> <20030720012939.1231.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20030720012939.1231.RYUJI@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >> Ryuji Wakikawa wrote: >> >>> If we say routing procols, which routing protocols do you have in >>> mind? >> >> There are only a few that are in widespread use, look for those. >> >>> for example, MANET is also a routing protocol. If specially >>> reactive protocols such as AODV and DSR are used on MR, MR prefer >>> using BU to manage MNP with HA. I am not sure if people wants to >>> use AODV on MR, >> >> I first want RIP and OSPF, then the experimentals (which are btw >> derivations from the former). >> >> >>> but the current text limits the use of it. >> >> So the current text forbids AODV and DSR? I haven't seen that >> limitation, could you please more explicit, what's the limitation >> more exactly? > > > You misinterpret here. Sorry. > I said the current text forbids to send MNP in the BU when MR runs > AODV or DSR. It is OK to use only AODV or DSR to carry MNP to HA, I think DSR will not put any form of MNP in any form of message (be it BU or route update). I mean no prefix, but list of addresses. So you come down to AODV only which can be treated from a RIP perspective. > but there might be some requirement to use NEMO as well to ensure the > registration. The use of BU might be redundant, but more reliable in > some situation. > > I want to change the text something like below. Ok... > original When the Mobile Router and the Home Agent exchange routes > through routing protocol updates, the Home Agent MUST NOT create > routes to the Mobile network when the Binding Update from the Mobile > Router is received. The Mobile Router also MUST NOT include any > prefix information in the Binding Update. Any routes to the Mobile > Network are created at the Home Agent through routing protocol > updates. > > suggestion When the Mobile Router and the Home Agent exchange routes > of specific mobile network prefixes through routing protocol updates, > the Home Agent MUST NOT create the routes of the mobile network > prefixes to the Mobile Router when the Binding Update from the Mobile > Router is received. The Mobile Router also SHOULD NOT include the > mobile network prefixes exchanged by routing protocol in the Binding > Update. The routes of the mobile network prefixes to the Mobile > Router SHOULD be created at the Home Agent through routing protocol > updates. To me, they both sound good. Alex GBU From nemo-admin@ietf.org Sat Jul 19 17:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23035 for ; Sat, 19 Jul 2003 17:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9U-0002vr-85; Sat, 19 Jul 2003 17:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9P-0002vd-7d for nemo@optimus.ietf.org; Sat, 19 Jul 2003 17:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23013 for ; Sat, 19 Jul 2003 17:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz9M-0004M0-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:21:53 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19dz9C-0004Lk-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:21:42 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h6JLKpqk025803; Sat, 19 Jul 2003 14:20:52 -0700 (MST) Received: from motorola.com (t-il06ac-port21.corp.mot.com [129.188.170.169]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6JLKkIM020342; Sat, 19 Jul 2003 16:20:47 -0500 Message-ID: <3F19D1E4.4090900@motorola.com> Date: Sun, 20 Jul 2003 01:19:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> In-Reply-To: <3F18A9A5.3EEA474E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>> anybody else has an opinion on this? >> >> Yes. My personal oppinion is my preference for "implicit" mode and >> let the rt protocols manage routes exclusively and not include >> prefixes at all in BU. > > > Alex and others, > > let me phrase the issue better. > > the question is should the mobile router be able to use both prefix > information in the binding update and a dynamic routing protocol > simultaneously to create routes at the HA? or should these two > mechanisms be used exclusive to each other? I would say that if Explicit mode, then the two mechanisms should be exclusive. > my proposal is > > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router is > received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. This sounds good to me as I can understand it. > Kent and Pascal argue that this restriction should not be there. it > is currently possible (according to them) to run two IGP protocol at > the same time and nothing breaks. So maybe they want to give an example. Kent, Pascal, how can one run several routing protocols on a machine and nothing breaks? I suppose that if one routing protocol adds a route, and another routing protocol deletes the same route, then some things might break. Or, maybe this spec should not care at all about routing protocols, and be entirely silent about how MIP interacts with IGP? > my argument is where do you use it? how does the MR know which prefix > should be sent in the BU and which in the routing protocol message? > if same prefix is sent in both, then it is redundant. I agree with the redundancy aspect. If the mobile network is made of several fixed links and several fixed routers, then it makes sense to run IGP in the mobile network, over the MR-HA tunnel, and in the home domain. It is highly redundant to have prefixes both in BU's and in the rt protocol updates, no? Alex GBU From exim@www1.ietf.org Sat Jul 19 17:22:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23050 for ; Sat, 19 Jul 2003 17:22:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9b-0002zf-6q for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 17:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JLM787011472 for nemo-archive@odin.ietf.org; Sat, 19 Jul 2003 17:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9b-0002xq-1k for nemo-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 17:22:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23023 for ; Sat, 19 Jul 2003 17:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz9Y-0004MD-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 17:22:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dz9T-0004MA-00 for nemo-web-archive@ietf.org; Sat, 19 Jul 2003 17:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9U-0002vr-85; Sat, 19 Jul 2003 17:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dz9P-0002vd-7d for nemo@optimus.ietf.org; Sat, 19 Jul 2003 17:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23013 for ; Sat, 19 Jul 2003 17:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dz9M-0004M0-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:21:53 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19dz9C-0004Lk-00 for nemo@ietf.org; Sat, 19 Jul 2003 17:21:42 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h6JLKpqk025803; Sat, 19 Jul 2003 14:20:52 -0700 (MST) Received: from motorola.com (t-il06ac-port21.corp.mot.com [129.188.170.169]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h6JLKkIM020342; Sat, 19 Jul 2003 16:20:47 -0500 Message-ID: <3F19D1E4.4090900@motorola.com> Date: Sun, 20 Jul 2003 01:19:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co <3F18A9A5.3EEA474E@iprg.nokia.com> In-Reply-To: <3F18A9A5.3EEA474E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>> anybody else has an opinion on this? >> >> Yes. My personal oppinion is my preference for "implicit" mode and >> let the rt protocols manage routes exclusively and not include >> prefixes at all in BU. > > > Alex and others, > > let me phrase the issue better. > > the question is should the mobile router be able to use both prefix > information in the binding update and a dynamic routing protocol > simultaneously to create routes at the HA? or should these two > mechanisms be used exclusive to each other? I would say that if Explicit mode, then the two mechanisms should be exclusive. > my proposal is > > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router is > received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. This sounds good to me as I can understand it. > Kent and Pascal argue that this restriction should not be there. it > is currently possible (according to them) to run two IGP protocol at > the same time and nothing breaks. So maybe they want to give an example. Kent, Pascal, how can one run several routing protocols on a machine and nothing breaks? I suppose that if one routing protocol adds a route, and another routing protocol deletes the same route, then some things might break. Or, maybe this spec should not care at all about routing protocols, and be entirely silent about how MIP interacts with IGP? > my argument is where do you use it? how does the MR know which prefix > should be sent in the BU and which in the routing protocol message? > if same prefix is sent in both, then it is redundant. I agree with the redundancy aspect. If the mobile network is made of several fixed links and several fixed routers, then it makes sense to run IGP in the mobile network, over the MR-HA tunnel, and in the home domain. It is highly redundant to have prefixes both in BU's and in the rt protocol updates, no? Alex GBU From nemo-admin@ietf.org Mon Jul 21 01:33:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06070 for ; Mon, 21 Jul 2003 01:33:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTID-0005FS-DL; Mon, 21 Jul 2003 01:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTHn-0005FG-CT for nemo@optimus.ietf.org; Mon, 21 Jul 2003 01:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06060 for ; Mon, 21 Jul 2003 01:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eTHk-0007jq-00 for nemo@ietf.org; Mon, 21 Jul 2003 01:32:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19eTHZ-0007jl-00 for nemo@ietf.org; Mon, 21 Jul 2003 01:32:21 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA18914; Sun, 20 Jul 2003 22:31:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6L5VLq25127; Sun, 20 Jul 2003 22:31:21 -0700 X-mProtect: <200307210531> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.98, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz2TJgr; Sun, 20 Jul 2003 22:31:20 PDT Message-ID: <3F1B7AA6.6040505@iprg.nokia.com> Date: Sun, 20 Jul 2003 22:31:18 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co In-Reply-To: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > Hi Vijay, > > If we say routing procols, which routing protocols do you have in mind? > for example, MANET is also a routing protocol. If specially reactive > protocols such as AODV and DSR are used on MR, MR prefer using BU to > manage MNP with HA. I am not sure if people wants to use AODV on MR, but > the current text limits the use of it. RIPng, OSPFv3 for example. Vijay From exim@www1.ietf.org Mon Jul 21 01:33:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06085 for ; Mon, 21 Jul 2003 01:33:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTIW-0005GN-Q3 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 01:33:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L5XKvU020227 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 01:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTIW-0005GA-Gi for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 01:33:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06067 for ; Mon, 21 Jul 2003 01:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eTIT-0007jz-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 01:33:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eTIN-0007jv-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 01:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTID-0005FS-DL; Mon, 21 Jul 2003 01:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eTHn-0005FG-CT for nemo@optimus.ietf.org; Mon, 21 Jul 2003 01:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06060 for ; Mon, 21 Jul 2003 01:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eTHk-0007jq-00 for nemo@ietf.org; Mon, 21 Jul 2003 01:32:32 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19eTHZ-0007jl-00 for nemo@ietf.org; Mon, 21 Jul 2003 01:32:21 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA18914; Sun, 20 Jul 2003 22:31:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6L5VLq25127; Sun, 20 Jul 2003 22:31:21 -0700 X-mProtect: <200307210531> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.98, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz2TJgr; Sun, 20 Jul 2003 22:31:20 PDT Message-ID: <3F1B7AA6.6040505@iprg.nokia.com> Date: Sun, 20 Jul 2003 22:31:18 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <3F12ECBD.4852B5FB@iprg.nokia.com> <4.3.2.7.2.20030717010058.02df2b00@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717140950.02e82bb0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030717161622.02deb6f8@mira-sjcm-2.cisco.com> <3F173BF6.F60CD3F3@iprg.nokia.co In-Reply-To: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > Hi Vijay, > > If we say routing procols, which routing protocols do you have in mind? > for example, MANET is also a routing protocol. If specially reactive > protocols such as AODV and DSR are used on MR, MR prefer using BU to > manage MNP with HA. I am not sure if people wants to use AODV on MR, but > the current text limits the use of it. RIPng, OSPFv3 for example. Vijay From nemo-admin@ietf.org Mon Jul 21 02:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18926 for ; Mon, 21 Jul 2003 02:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6Y-0007yG-5O; Mon, 21 Jul 2003 02:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6Q-0007xP-7K for nemo@optimus.ietf.org; Mon, 21 Jul 2003 02:24:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18905 for ; Mon, 21 Jul 2003 02:24:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eU6M-0000BU-00 for nemo@ietf.org; Mon, 21 Jul 2003 02:24:50 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19eU6B-0000BL-00 for nemo@ietf.org; Mon, 21 Jul 2003 02:24:39 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6L6OCnX015658; Mon, 21 Jul 2003 08:24:12 +0200 Message-ID: <3F1B8537.40602@dpt-info.u-strasbg.fr> Date: Mon, 21 Jul 2003 08:16:23 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: mobileip , nemo@ietf.org Subject: Re: [mobile-ip] Re: [nemo] multiple CoAs registration References: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> <3F1821FE.80308@dpt-info.u-strasbg.fr> <20030719205301.93B9.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ryuji, Ryuji Wakikawa wrote: >Hello Nicolas > > > >>Hi Ryuji, >> >>I carry on my remarks... hope it helps ! >> >>Ryuji Wakikawa wrote: >> >> >> >>>Hello Nicolas >>> >>>thanks for comments. >>> >>> >>> >>> >>> >>>>Hi Ryuji, >>>> >>>>I read your draft on multiple CoAs registration and I also think that we >>>>really need to define a solution to use MIPv6 with a multiple interfaces >>>>MN. >>>> >>>>Here are some comments on your draft: >>>> >>>> - Why do you introduce the interface identification (IFID) ? It could >>>>be sufficient to only register a CoA with the associated priority. >>>>Therefore, when the MN has to choose the destination address for a HoA, >>>>it can take the most preferred CoA, which is bound to the most preferred >>>>interface of the MN. >>>> >>>> >>>> >>>> >>>Priority can be changed by some reason during communication, but IFID >>>can not be changed until MN want to change it. >>> >>> >>> >>Ok, I understand that. But what I mean is that I don't see the >>requirement to have the IFID... In the Binding Cache, an entry could be >>identified by both the Home address and the CoA. It is sufficient to >>distinguish tow different entries. The priority field is then used to >>choose the CoA, i.e. the interface. No need to have the IFID I guess. >> >> > >I disagree. >ID is needed when CoA is changed. >If CoA1 is changed to CoA2, MN sends a BU with CoA2 to CN. >Before receiving the BU, CN has the binding entry which associate with >CoA1 and HoA, but BU carries new CoA2 in it. CN can not know which >binding cache entry should be updated for the BU. > >CN might create a new entry for the BU, because the pair of CoA1 and HoA >is different from CoA2 and HoA. > >ID is enable CN to update the correspondent binding entry even if CoA is >changed. > OK, now I get your point ! Do you think that this explanation should be introduced in the draft ? > > > >>> >>> >>> >>> >>>>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore >>>>you don't need both, or I missed a point ? >>>> >>>>IMO, this is easier than all the mechanism to manage the IFID >>>>(generation, maintenance...) >>>> >>>> >>>> >>>> >>>could be, but I don't know why the maintenance and generation are so >>>difficult. >>> >>> >>> >>I don't say they are so much difficult, but they are not useful, since >>the IFID is not necessary (from my point of view). Maybe you can explain >>me when the IFID is useful ? >> >> > >see above. > > > >>> >>> >>> >>> >>>> - If I well understand your draft, when the MN registers a CoA with a >>>>CN, the MN has to first register the primary CoA. Then it can send a >>>>Binding Update (after the RR procedure) to regsiter other CoA(s), with >>>>the associated priority. However, you say that the lowest priority is >>>>the preferred CoA/IF, and that the primary CoA has the priority 0. >>>>Therefore, each CN will use the primary CoA with the MN. Then, you are >>>>not able to perform load balancing, aren't you ? >>>> >>>> >>>> >>>> >>>Well, the draft does not mention about how to utilize multiple care-of >>>addresses. I don't think MIP is only way to manage policy sets to divide >>>flows to each CoAs. If you really want load-balancing, you need some >>>mechanism to maintain policy sets between MN and CNs. >>> >>>Load-balancing, for example, can be supported by upper >>>layers. >>>The point is that CN must be able to accept packets sent from multiple >>>.CoAs of MN. >>> >>> >>> >>Ok I agree with you. But is it necessary to impose that a MN MUST >>register the pCoA with the highest priority with CN ? I thnik it is >>important that the MN does it with the HA, but I don't think it is >>necessary with CN. >> >> > >I got comments from WGchair whether I need priority field or not. >Policy can be treated as one of policy. I might remove the priority >field and keep the field as reserved. > >If there are no policies and priority values on CN, CN uses the first >matched BC entry for outgoing packets. > > > >>If you have the choice to register the pCoA with a different priority >>with different CNs, you let an open door for upper layers to decide some >>load balancing policies. >> >> > >This management is difficult. >How does MN give different priority for each CNs. > This is exactly what is out of scope of the draft. But this would allow upper layers to take decision on flows mapping on interfaces and then to apply it. > >One of my intention is to eliminate these MN's decision from the draft. >I am interested in the policy management and notification, but it should >be described in a separate draft. > >anyway, the issue of priority field is in my todo lists. >I appreciate if anybody has comments on this > My personal feeling is that your draft should specify that the MN can send different priorities on its interfaces to different CNs. But, the attribution of the priority is out of scope of the draft. Regards, Nicolas From exim@www1.ietf.org Mon Jul 21 02:25:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18942 for ; Mon, 21 Jul 2003 02:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6g-00080I-Sk for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 02:25:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L6PA72030766 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 02:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6f-0007z1-EH for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 02:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18914 for ; Mon, 21 Jul 2003 02:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eU6b-0000Bs-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 02:25:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eU6W-0000Bp-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 02:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6Y-0007yG-5O; Mon, 21 Jul 2003 02:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eU6Q-0007xP-7K for nemo@optimus.ietf.org; Mon, 21 Jul 2003 02:24:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18905 for ; Mon, 21 Jul 2003 02:24:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eU6M-0000BU-00 for nemo@ietf.org; Mon, 21 Jul 2003 02:24:50 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19eU6B-0000BL-00 for nemo@ietf.org; Mon, 21 Jul 2003 02:24:39 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6L6OCnX015658; Mon, 21 Jul 2003 08:24:12 +0200 Message-ID: <3F1B8537.40602@dpt-info.u-strasbg.fr> Date: Mon, 21 Jul 2003 08:16:23 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: mobileip , nemo@ietf.org Subject: Re: [mobile-ip] Re: [nemo] multiple CoAs registration References: <20030717230918.E07B.RYUJI@sfc.wide.ad.jp> <3F1821FE.80308@dpt-info.u-strasbg.fr> <20030719205301.93B9.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ryuji, Ryuji Wakikawa wrote: >Hello Nicolas > > > >>Hi Ryuji, >> >>I carry on my remarks... hope it helps ! >> >>Ryuji Wakikawa wrote: >> >> >> >>>Hello Nicolas >>> >>>thanks for comments. >>> >>> >>> >>> >>> >>>>Hi Ryuji, >>>> >>>>I read your draft on multiple CoAs registration and I also think that we >>>>really need to define a solution to use MIPv6 with a multiple interfaces >>>>MN. >>>> >>>>Here are some comments on your draft: >>>> >>>> - Why do you introduce the interface identification (IFID) ? It could >>>>be sufficient to only register a CoA with the associated priority. >>>>Therefore, when the MN has to choose the destination address for a HoA, >>>>it can take the most preferred CoA, which is bound to the most preferred >>>>interface of the MN. >>>> >>>> >>>> >>>> >>>Priority can be changed by some reason during communication, but IFID >>>can not be changed until MN want to change it. >>> >>> >>> >>Ok, I understand that. But what I mean is that I don't see the >>requirement to have the IFID... In the Binding Cache, an entry could be >>identified by both the Home address and the CoA. It is sufficient to >>distinguish tow different entries. The priority field is then used to >>choose the CoA, i.e. the interface. No need to have the IFID I guess. >> >> > >I disagree. >ID is needed when CoA is changed. >If CoA1 is changed to CoA2, MN sends a BU with CoA2 to CN. >Before receiving the BU, CN has the binding entry which associate with >CoA1 and HoA, but BU carries new CoA2 in it. CN can not know which >binding cache entry should be updated for the BU. > >CN might create a new entry for the BU, because the pair of CoA1 and HoA >is different from CoA2 and HoA. > >ID is enable CN to update the correspondent binding entry even if CoA is >changed. > OK, now I get your point ! Do you think that this explanation should be introduced in the draft ? > > > >>> >>> >>> >>> >>>>Anyway you use a one-to-one mapping between a CoA and a IFID, therefore >>>>you don't need both, or I missed a point ? >>>> >>>>IMO, this is easier than all the mechanism to manage the IFID >>>>(generation, maintenance...) >>>> >>>> >>>> >>>> >>>could be, but I don't know why the maintenance and generation are so >>>difficult. >>> >>> >>> >>I don't say they are so much difficult, but they are not useful, since >>the IFID is not necessary (from my point of view). Maybe you can explain >>me when the IFID is useful ? >> >> > >see above. > > > >>> >>> >>> >>> >>>> - If I well understand your draft, when the MN registers a CoA with a >>>>CN, the MN has to first register the primary CoA. Then it can send a >>>>Binding Update (after the RR procedure) to regsiter other CoA(s), with >>>>the associated priority. However, you say that the lowest priority is >>>>the preferred CoA/IF, and that the primary CoA has the priority 0. >>>>Therefore, each CN will use the primary CoA with the MN. Then, you are >>>>not able to perform load balancing, aren't you ? >>>> >>>> >>>> >>>> >>>Well, the draft does not mention about how to utilize multiple care-of >>>addresses. I don't think MIP is only way to manage policy sets to divide >>>flows to each CoAs. If you really want load-balancing, you need some >>>mechanism to maintain policy sets between MN and CNs. >>> >>>Load-balancing, for example, can be supported by upper >>>layers. >>>The point is that CN must be able to accept packets sent from multiple >>>.CoAs of MN. >>> >>> >>> >>Ok I agree with you. But is it necessary to impose that a MN MUST >>register the pCoA with the highest priority with CN ? I thnik it is >>important that the MN does it with the HA, but I don't think it is >>necessary with CN. >> >> > >I got comments from WGchair whether I need priority field or not. >Policy can be treated as one of policy. I might remove the priority >field and keep the field as reserved. > >If there are no policies and priority values on CN, CN uses the first >matched BC entry for outgoing packets. > > > >>If you have the choice to register the pCoA with a different priority >>with different CNs, you let an open door for upper layers to decide some >>load balancing policies. >> >> > >This management is difficult. >How does MN give different priority for each CNs. > This is exactly what is out of scope of the draft. But this would allow upper layers to take decision on flows mapping on interfaces and then to apply it. > >One of my intention is to eliminate these MN's decision from the draft. >I am interested in the policy management and notification, but it should >be described in a separate draft. > >anyway, the issue of priority field is in my todo lists. >I appreciate if anybody has comments on this > My personal feeling is that your draft should specify that the MN can send different priorities on its interfaces to different CNs. But, the attribution of the priority is out of scope of the draft. Regards, Nicolas From nemo-admin@ietf.org Mon Jul 21 10:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29102 for ; Mon, 21 Jul 2003 10:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebc1-0006ot-9h; Mon, 21 Jul 2003 10:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebbP-0006oB-IV for nemo@optimus.ietf.org; Mon, 21 Jul 2003 10:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29052 for ; Mon, 21 Jul 2003 10:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebbN-0003Gh-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:25:21 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ebbC-0003G0-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:25:10 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LELGNP024256; Mon, 21 Jul 2003 16:21:42 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 16:23:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 3 Date: Mon, 21 Jul 2003 15:23:42 +0100 Message-ID: Thread-Topic: [nemo] Issue 3 Thread-Index: AcNMTkDkY/7H9oDmTPKieFho2iEj3wDRLwag From: "Pascal Thubert (pthubert)" To: "Kent Leung (kleung)" , Cc: "Vijay Devarapalli" , "IETF NEMO WG" X-OriginalArrivalTime: 21 Jul 2003 14:23:43.0286 (UTC) FILETIME=[B048E560:01C34F93] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > >I would have preferred a text saying that "the MR MUST keep all > >necessary information to clean up whichever routes it installed, for > >instance by keeping the list of prefix in BCE, whether they come from > >implicit or explicit source". Vijay, please do not tell people how to > >implement things (even if your proposal seems perfectly proper). >=20 >=20 > This text doesn't cover the case when routes need to be re-injected into > the routing table. The BCE is transient data, a state, as opposed to the prefix table, which is configuration. Actually in the considered flow, it's all gone, and may be recreated later. So the prefix list has to be renewed from its source (implicit or explicit) in order to be reinjected.=20 >=20 > My suggestion: >=20 > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." >=20 I tend to think that the first sentence alone fits the bill... > Kent From exim@www1.ietf.org Mon Jul 21 10:26:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29124 for ; Mon, 21 Jul 2003 10:26:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebcC-0006qy-0L for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 10:26:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEQBLq026340 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 10:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebcB-0006ql-EL for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 10:26:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29078 for ; Mon, 21 Jul 2003 10:26:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebc9-0003HF-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 10:26:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ebc3-0003HC-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 10:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebc1-0006ot-9h; Mon, 21 Jul 2003 10:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebbP-0006oB-IV for nemo@optimus.ietf.org; Mon, 21 Jul 2003 10:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29052 for ; Mon, 21 Jul 2003 10:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebbN-0003Gh-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:25:21 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ebbC-0003G0-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:25:10 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LELGNP024256; Mon, 21 Jul 2003 16:21:42 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 16:23:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 3 Date: Mon, 21 Jul 2003 15:23:42 +0100 Message-ID: Thread-Topic: [nemo] Issue 3 Thread-Index: AcNMTkDkY/7H9oDmTPKieFho2iEj3wDRLwag From: "Pascal Thubert (pthubert)" To: "Kent Leung (kleung)" , Cc: "Vijay Devarapalli" , "IETF NEMO WG" X-OriginalArrivalTime: 21 Jul 2003 14:23:43.0286 (UTC) FILETIME=[B048E560:01C34F93] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >I would have preferred a text saying that "the MR MUST keep all > >necessary information to clean up whichever routes it installed, for > >instance by keeping the list of prefix in BCE, whether they come from > >implicit or explicit source". Vijay, please do not tell people how to > >implement things (even if your proposal seems perfectly proper). >=20 >=20 > This text doesn't cover the case when routes need to be re-injected into > the routing table. The BCE is transient data, a state, as opposed to the prefix table, which is configuration. Actually in the considered flow, it's all gone, and may be recreated later. So the prefix list has to be renewed from its source (implicit or explicit) in order to be reinjected.=20 >=20 > My suggestion: >=20 > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For instance, > the list of Mobile Network Prefixes may be stored in the Binding Cache > entry." >=20 I tend to think that the first sentence alone fits the bill... > Kent From nemo-admin@ietf.org Mon Jul 21 10:44:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29722 for ; Mon, 21 Jul 2003 10:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebtR-0007kC-9I; Mon, 21 Jul 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebsV-0007jr-PX for nemo@optimus.ietf.org; Mon, 21 Jul 2003 10:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29708 for ; Mon, 21 Jul 2003 10:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebsT-0003Rh-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:43:01 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19ebsI-0003Qp-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:42:50 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6LEfNbj003606; Mon, 21 Jul 2003 08:41:23 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6LEfFQ05610; Mon, 21 Jul 2003 16:41:16 +0200 (MEST) Date: Mon, 21 Jul 2003 16:39:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] comments on draft-paakkonen-nemo-prefix-delegation-00.txt To: Vijay Devarapalli Cc: pekka.paakkonen@vtt.fi, juhani.latvakoski@vtt.fi, nemo@ietf.org In-Reply-To: "Your message with ID" <3F188D5D.A1EC79E2@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > this draft is a very good alternative to using DHCPv6 > for prefix delegation (however, I will let the WG decide > if we need an alternative to DHCPv6 for NEMO prefix > delegation). IMHO having Nemo reinvent yet another configuration protocol is not time well spent. Working on solutions for mobile networks is time better spent. Erik From exim@www1.ietf.org Mon Jul 21 10:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29737 for ; Mon, 21 Jul 2003 10:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebta-0007mH-T8 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 10:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LEiAog029891 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 10:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebta-0007m2-N7 for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 10:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29717 for ; Mon, 21 Jul 2003 10:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebtY-0003S2-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 10:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ebtS-0003Rz-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 10:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebtR-0007kC-9I; Mon, 21 Jul 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebsV-0007jr-PX for nemo@optimus.ietf.org; Mon, 21 Jul 2003 10:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29708 for ; Mon, 21 Jul 2003 10:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebsT-0003Rh-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:43:01 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19ebsI-0003Qp-00 for nemo@ietf.org; Mon, 21 Jul 2003 10:42:50 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6LEfNbj003606; Mon, 21 Jul 2003 08:41:23 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6LEfFQ05610; Mon, 21 Jul 2003 16:41:16 +0200 (MEST) Date: Mon, 21 Jul 2003 16:39:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] comments on draft-paakkonen-nemo-prefix-delegation-00.txt To: Vijay Devarapalli Cc: pekka.paakkonen@vtt.fi, juhani.latvakoski@vtt.fi, nemo@ietf.org In-Reply-To: "Your message with ID" <3F188D5D.A1EC79E2@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > this draft is a very good alternative to using DHCPv6 > for prefix delegation (however, I will let the WG decide > if we need an alternative to DHCPv6 for NEMO prefix > delegation). IMHO having Nemo reinvent yet another configuration protocol is not time well spent. Working on solutions for mobile networks is time better spent. Erik From nemo-admin@ietf.org Mon Jul 21 11:05:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00176 for ; Mon, 21 Jul 2003 11:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDl-0008L6-7t; Mon, 21 Jul 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDb-0008Kl-9l for nemo@optimus.ietf.org; Mon, 21 Jul 2003 11:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00153 for ; Mon, 21 Jul 2003 11:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecDY-0003bV-00 for nemo@ietf.org; Mon, 21 Jul 2003 11:04:48 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ecDN-0003bC-00 for nemo@ietf.org; Mon, 21 Jul 2003 11:04:37 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LF1NMO003525; Mon, 21 Jul 2003 17:01:29 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 17:03:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Mon, 21 Jul 2003 16:03:29 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNNcnI4c16FfUwTTDy6KwUGyQbm8wCJV6Pg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 15:03:30.0082 (UTC) FILETIME=[3EED1020:01C34F99] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > MIP adding prefix routes is a new mechanism. if you want to call it > > an IGP, its fine. but I wouldnt. I think it's key to let the Routing protocols operate on our tunnel the way they do otherwise. Also, it's over-design to have MIP monitor that (for just how many protocols?). We had that chat long ago. This thing (BU) injects routes, and even if it does not propagate them (which makes it much simpler than traditional IGPs) it should still inherit from IGPs its properties, such as the redistribution mechanism. The admin distance allows a user a prefer a source (an IGP) over an other for a same prefix. This MUST work for Nemo explicit and implicit modes the same way. Pascal From exim@www1.ietf.org Mon Jul 21 11:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00194 for ; Mon, 21 Jul 2003 11:05:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDt-0008ND-Mt for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 11:05:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LF598q032181 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 11:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDt-0008My-Ht for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 11:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00171 for ; Mon, 21 Jul 2003 11:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecDr-0003bq-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 11:05:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ecDl-0003bn-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 11:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDl-0008L6-7t; Mon, 21 Jul 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecDb-0008Kl-9l for nemo@optimus.ietf.org; Mon, 21 Jul 2003 11:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00153 for ; Mon, 21 Jul 2003 11:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecDY-0003bV-00 for nemo@ietf.org; Mon, 21 Jul 2003 11:04:48 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ecDN-0003bC-00 for nemo@ietf.org; Mon, 21 Jul 2003 11:04:37 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LF1NMO003525; Mon, 21 Jul 2003 17:01:29 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 17:03:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Mon, 21 Jul 2003 16:03:29 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNNcnI4c16FfUwTTDy6KwUGyQbm8wCJV6Pg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 15:03:30.0082 (UTC) FILETIME=[3EED1020:01C34F99] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > MIP adding prefix routes is a new mechanism. if you want to call it > > an IGP, its fine. but I wouldnt. I think it's key to let the Routing protocols operate on our tunnel the way they do otherwise. Also, it's over-design to have MIP monitor that (for just how many protocols?). We had that chat long ago. This thing (BU) injects routes, and even if it does not propagate them (which makes it much simpler than traditional IGPs) it should still inherit from IGPs its properties, such as the redistribution mechanism. The admin distance allows a user a prefer a source (an IGP) over an other for a same prefix. This MUST work for Nemo explicit and implicit modes the same way. Pascal From nemo-admin@ietf.org Mon Jul 21 13:04:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04036 for ; Mon, 21 Jul 2003 13:04:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee4v-0004oY-L4; Mon, 21 Jul 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee4L-0004o0-9Q for nemo@optimus.ietf.org; Mon, 21 Jul 2003 13:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03882 for ; Mon, 21 Jul 2003 13:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ee3z-0004g4-00 for nemo@ietf.org; Mon, 21 Jul 2003 13:03:03 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19ee3o-0004fQ-00 for nemo@ietf.org; Mon, 21 Jul 2003 13:02:52 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24885; Mon, 21 Jul 2003 10:02:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6LH2Ei03889; Mon, 21 Jul 2003 10:02:14 -0700 X-mProtect: <200307211702> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdV18K4i; Mon, 21 Jul 2003 10:00:11 PDT Message-ID: <3F1C1C1B.79C56CAB@iprg.nokia.com> Date: Mon, 21 Jul 2003 10:00:11 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> <20030720012939.1231.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > > I want to change the text something like below. > > original > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. > > suggestion > When the Mobile Router and the Home Agent exchange routes of specific mobile > network prefixes through routing protocol updates, the Home Agent MUST > NOT create the routes of the mobile network prefixes to > the Mobile Router when the Binding Update from the Mobile Router > is received. The Mobile Router also SHOULD NOT include the mobile > network prefixes exchanged by routing protocol in the Binding Update. > The routes of the mobile network prefixes to the Mobile Router SHOULD be > created at the Home Agent through routing protocol updates. I am fine with your suggestion. Kent, Pascal? Vijay From exim@www1.ietf.org Mon Jul 21 13:57:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04067 for ; Mon, 21 Jul 2003 13:05:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee5s-0004tP-0m for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 13:05:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LH4xLm018801 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 13:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee5S-0004sv-RD for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 13:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03999 for ; Mon, 21 Jul 2003 13:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ee58-0004hT-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 13:04:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ee53-0004hQ-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 13:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee4v-0004oY-L4; Mon, 21 Jul 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ee4L-0004o0-9Q for nemo@optimus.ietf.org; Mon, 21 Jul 2003 13:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03882 for ; Mon, 21 Jul 2003 13:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ee3z-0004g4-00 for nemo@ietf.org; Mon, 21 Jul 2003 13:03:03 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19ee3o-0004fQ-00 for nemo@ietf.org; Mon, 21 Jul 2003 13:02:52 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24885; Mon, 21 Jul 2003 10:02:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6LH2Ei03889; Mon, 21 Jul 2003 10:02:14 -0700 X-mProtect: <200307211702> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdV18K4i; Mon, 21 Jul 2003 10:00:11 PDT Message-ID: <3F1C1C1B.79C56CAB@iprg.nokia.com> Date: Mon, 21 Jul 2003 10:00:11 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryuji Wakikawa CC: Alexandru Petrescu , Kent Leung , "S. Felix Wu" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] IGP and MIP routes. References: <20030719213021.93BF.RYUJI@sfc.wide.ad.jp> <3F198C70.8030209@motorola.com> <20030720012939.1231.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > > I want to change the text something like below. > > original > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. > > suggestion > When the Mobile Router and the Home Agent exchange routes of specific mobile > network prefixes through routing protocol updates, the Home Agent MUST > NOT create the routes of the mobile network prefixes to > the Mobile Router when the Binding Update from the Mobile Router > is received. The Mobile Router also SHOULD NOT include the mobile > network prefixes exchanged by routing protocol in the Binding Update. > The routes of the mobile network prefixes to the Mobile Router SHOULD be > created at the Home Agent through routing protocol updates. I am fine with your suggestion. Kent, Pascal? Vijay From nemo-admin@ietf.org Mon Jul 21 14:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06069 for ; Mon, 21 Jul 2003 14:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT3-00089k-B2; Mon, 21 Jul 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efSv-00089F-4V for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06025 for ; Mon, 21 Jul 2003 14:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efSs-0005Hq-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSh-0005HA-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:39 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITc8K010269; Mon, 21 Jul 2003 20:29:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] Explicit combined mode name Date: Mon, 21 Jul 2003 19:31:43 +0100 Message-ID: Thread-Topic: [nemo] Explicit combined mode name Thread-Index: AcNMpGZCc8kHvOBlTdi5MvV4rASZ6ADDbvgw From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Kent Leung (kleung)" Cc: X-OriginalArrivalTime: 21 Jul 2003 18:31:43.0881 (UTC) FILETIME=[55CF7F90:01C34FB6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Fine with me too :) Can we call that issue 8 and make it resolved shortly? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: vendredi 18 juillet 2003 00:42 > To: Kent Leung (kleung) > Cc: nemo@ietf.org > Subject: Re: [nemo] Explicit combined mode name >=20 > Kent Leung wrote: > > A nit. The "Explicit combined" mode is confusing to me. Combined with > > what? >=20 > Confusing to me too. We looked hard for names. Combined are the home > address and the mobile network prefix. >=20 > > Just a suggestion, marked by "->". > > > > Explicit: -> Explicit Network > > > > In this mode, the Mobile Router includes one or more Mobile > > Network Prefix Options in the Binding Update. These options > > contain information about the Mobile Network Prefix(es) > > configured on the Mobile Network. > > > > Explicit combined: -> Explicit Prefix Length > > > > In this mode, the Mobile Router instructs the Home Agent to > > derive the Mobile Network Prefix by using: (1) the Home > > Address in the Home Address Option carried in the Destination > > Options header of the same packet that carries the Mobility > > Header containing this Binding Update and (2) the prefix length > > carried in the Mobile Network Prefix Length Option. In this > > case, Mobile Router includes one and only one Mobile Network > > Prefix Length Option. It MUST not include a Mobile Network > > Prefix Option if this method is used. >=20 > Good idea. >=20 > Alex > GBU >=20 From nemo-admin@ietf.org Mon Jul 21 14:33:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06068 for ; Mon, 21 Jul 2003 14:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT3-0008A6-Na; Mon, 21 Jul 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efSv-00089E-3Q for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06026 for ; Mon, 21 Jul 2003 14:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efSs-0005Hp-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSh-0005HE-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:39 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITc8I010269; Mon, 21 Jul 2003 20:29:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2003 19:31:40 +0100 Message-ID: Thread-Topic: IGP and MIP routes. Thread-Index: AcNOO6olAO0cWUmkS3miytTRd+jmoABeM8VQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 18:31:41.0615 (UTC) FILETIME=[5475BBF0:01C34FB6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > So maybe they want to give an example. Kent, Pascal, how can one run > several routing protocols on a machine and nothing breaks? I suppose > that if one routing protocol adds a route, and another routing protocol > deletes the same route, then some things might break. >=20 The response is depends on the implementation. One thing is sure, when multiple processes (sa ospf, rip and bgp) can insert/delete routes, the system had better keep track of whom inserts the route for ownership checking and easier administration. On IOS, you'll find a letter like O for OSPF and M for Mobile when you display the routing table. Also, there'd better be an arbitration mechanism that selects which route is chosen when 2 different protocols present a route to the exact same prefix/length. Since the cost is meaningful only within one process, the arbitration is based on an other setting. This is called administrative distance in cisco routers.=20 For routers, managing routes is a full time business - not a hobby like for hosts - and they do it well. > Or, maybe this spec should not care at all about routing protocols, and > be entirely silent about how MIP interacts with IGP? >=20 :) Pascal From exim@www1.ietf.org Mon Jul 21 14:33:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06101 for ; Mon, 21 Jul 2003 14:33:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efTD-0008Bf-11 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIXBDc031465 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efTC-0008BQ-T7 for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06056 for ; Mon, 21 Jul 2003 14:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efTA-0005Ic-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19efT4-0005IX-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT3-0008A6-Na; Mon, 21 Jul 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efSv-00089E-3Q for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06026 for ; Mon, 21 Jul 2003 14:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efSs-0005Hp-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSh-0005HE-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:39 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITc8I010269; Mon, 21 Jul 2003 20:29:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2003 19:31:40 +0100 Message-ID: Thread-Topic: IGP and MIP routes. Thread-Index: AcNOO6olAO0cWUmkS3miytTRd+jmoABeM8VQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 18:31:41.0615 (UTC) FILETIME=[5475BBF0:01C34FB6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > So maybe they want to give an example. Kent, Pascal, how can one run > several routing protocols on a machine and nothing breaks? I suppose > that if one routing protocol adds a route, and another routing protocol > deletes the same route, then some things might break. >=20 The response is depends on the implementation. One thing is sure, when multiple processes (sa ospf, rip and bgp) can insert/delete routes, the system had better keep track of whom inserts the route for ownership checking and easier administration. On IOS, you'll find a letter like O for OSPF and M for Mobile when you display the routing table. Also, there'd better be an arbitration mechanism that selects which route is chosen when 2 different protocols present a route to the exact same prefix/length. Since the cost is meaningful only within one process, the arbitration is based on an other setting. This is called administrative distance in cisco routers.=20 For routers, managing routes is a full time business - not a hobby like for hosts - and they do it well. > Or, maybe this spec should not care at all about routing protocols, and > be entirely silent about how MIP interacts with IGP? >=20 :) Pascal From exim@www1.ietf.org Mon Jul 21 14:33:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06116 for ; Mon, 21 Jul 2003 14:33:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efTD-0008Bw-Lh for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIXBMr031482 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efTC-0008BP-Qs for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06055 for ; Mon, 21 Jul 2003 14:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efTA-0005Ie-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19efT4-0005IY-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT3-00089k-B2; Mon, 21 Jul 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efSv-00089F-4V for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06025 for ; Mon, 21 Jul 2003 14:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efSs-0005Hq-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSh-0005HA-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:39 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITc8K010269; Mon, 21 Jul 2003 20:29:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] Explicit combined mode name Date: Mon, 21 Jul 2003 19:31:43 +0100 Message-ID: Thread-Topic: [nemo] Explicit combined mode name Thread-Index: AcNMpGZCc8kHvOBlTdi5MvV4rASZ6ADDbvgw From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Kent Leung (kleung)" Cc: X-OriginalArrivalTime: 21 Jul 2003 18:31:43.0881 (UTC) FILETIME=[55CF7F90:01C34FB6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fine with me too :) Can we call that issue 8 and make it resolved shortly? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: vendredi 18 juillet 2003 00:42 > To: Kent Leung (kleung) > Cc: nemo@ietf.org > Subject: Re: [nemo] Explicit combined mode name >=20 > Kent Leung wrote: > > A nit. The "Explicit combined" mode is confusing to me. Combined with > > what? >=20 > Confusing to me too. We looked hard for names. Combined are the home > address and the mobile network prefix. >=20 > > Just a suggestion, marked by "->". > > > > Explicit: -> Explicit Network > > > > In this mode, the Mobile Router includes one or more Mobile > > Network Prefix Options in the Binding Update. These options > > contain information about the Mobile Network Prefix(es) > > configured on the Mobile Network. > > > > Explicit combined: -> Explicit Prefix Length > > > > In this mode, the Mobile Router instructs the Home Agent to > > derive the Mobile Network Prefix by using: (1) the Home > > Address in the Home Address Option carried in the Destination > > Options header of the same packet that carries the Mobility > > Header containing this Binding Update and (2) the prefix length > > carried in the Mobile Network Prefix Length Option. In this > > case, Mobile Router includes one and only one Mobile Network > > Prefix Length Option. It MUST not include a Mobile Network > > Prefix Option if this method is used. >=20 > Good idea. >=20 > Alex > GBU >=20 From nemo-admin@ietf.org Mon Jul 21 14:34:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06180 for ; Mon, 21 Jul 2003 14:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU1-0008ER-C5; Mon, 21 Jul 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT5-0008AP-MW for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06031 for ; Mon, 21 Jul 2003 14:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efT3-0005IA-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:33:01 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSr-0005HT-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LIU04q010316; Mon, 21 Jul 2003 20:30:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] multiple CoAs registration Date: Mon, 21 Jul 2003 19:31:43 +0100 Message-ID: Thread-Topic: [nemo] multiple CoAs registration Thread-Index: AcNNTEfXcQKiZqTOR3arkwoIpvvs5gCZgx+Q From: "Pascal Thubert (pthubert)" To: "Nicolas Montavont" , "Ryuji Wakikawa" Cc: "mobileip" , X-OriginalArrivalTime: 21 Jul 2003 18:31:44.0553 (UTC) FILETIME=[56360990:01C34FB6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I believe we talked about that a lot already; there seems to be a consensus on using the home address to identify uniquely a registration, for checking and cleanup purposes. The IFID should not be used to that purpose, and a registration should be able to migrate interface on the MR side. If we do not find a valid usage for ifid (I have none in mind at the moment) then it should be dropped, shouldn't it? >=20 > > > > > > Pascal =20 From nemo-admin@ietf.org Mon Jul 21 14:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06185 for ; Mon, 21 Jul 2003 14:34:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU1-0008FD-PT; Mon, 21 Jul 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT8-0008BK-6y for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06038 for ; Mon, 21 Jul 2003 14:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efT5-0005II-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:33:03 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSu-0005HU-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:52 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITxsB010315; Mon, 21 Jul 2003 20:30:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2003 19:31:44 +0100 Message-ID: Thread-Topic: IGP and MIP routes. Thread-Index: AcNNm7nd0/IJuSB0ShaiJC8Q/ASrDwCF03yw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 18:31:45.0225 (UTC) FILETIME=[569C9390:01C34FB6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: samedi 19 juillet 2003 04:15 > To: Alexandru Petrescu > Cc: Kent Leung (kleung); S. Felix Wu; Pascal Thubert (pthubert); nemo@ietf.org > Subject: IGP and MIP routes. >=20 > Alexandru Petrescu wrote: > > > > > anybody else has an opinion on this? > > > > Yes. My personal oppinion is my preference for "implicit" mode and let > > the rt protocols manage routes exclusively and not include prefixes at > > all in BU. >=20 > Alex and others, >=20 > let me phrase the issue better. >=20 > the question is should the mobile router be able to > use both prefix information in the binding update and > a dynamic routing protocol simultaneously to create > routes at the HA? or should these two mechanisms be > used exclusive to each other? >=20 > my proposal is >=20 > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. >=20 > Kent and Pascal argue that this restriction should > not be there. it is currently possible (according to > them) to run two IGP protocol at the same time and > nothing breaks. so there is no reason to have this > restriction. >=20 > my argument is where do you use it? how does the MR > know which prefix should be sent in the BU and which > in the routing protocol message? if same prefix is > sent in both, then it is redundant. Note that ( I believe that ) the "keep it simple" argument is on our side. On a real router with multiple protocols running, such a checking may be real hard to implement, and seems like a process violation. Our proposal is to let the router operate as it normally does. Doing otherwise will create controversy for years. Note also that Kent and I did not discuss that offline, but naturally came to the same conclusion from our experience on router operations. Pascal From exim@www1.ietf.org Mon Jul 21 14:34:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06215 for ; Mon, 21 Jul 2003 14:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU8-0008JN-2k for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIY8B3031943 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU7-0008J8-Up for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06155 for ; Mon, 21 Jul 2003 14:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efU5-0005JM-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19efTz-0005JJ-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU1-0008FD-PT; Mon, 21 Jul 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT8-0008BK-6y for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06038 for ; Mon, 21 Jul 2003 14:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efT5-0005II-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:33:03 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSu-0005HU-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:52 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LITxsB010315; Mon, 21 Jul 2003 20:30:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2003 19:31:44 +0100 Message-ID: Thread-Topic: IGP and MIP routes. Thread-Index: AcNNm7nd0/IJuSB0ShaiJC8Q/ASrDwCF03yw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 21 Jul 2003 18:31:45.0225 (UTC) FILETIME=[569C9390:01C34FB6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: samedi 19 juillet 2003 04:15 > To: Alexandru Petrescu > Cc: Kent Leung (kleung); S. Felix Wu; Pascal Thubert (pthubert); nemo@ietf.org > Subject: IGP and MIP routes. >=20 > Alexandru Petrescu wrote: > > > > > anybody else has an opinion on this? > > > > Yes. My personal oppinion is my preference for "implicit" mode and let > > the rt protocols manage routes exclusively and not include prefixes at > > all in BU. >=20 > Alex and others, >=20 > let me phrase the issue better. >=20 > the question is should the mobile router be able to > use both prefix information in the binding update and > a dynamic routing protocol simultaneously to create > routes at the HA? or should these two mechanisms be > used exclusive to each other? >=20 > my proposal is >=20 > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. >=20 > Kent and Pascal argue that this restriction should > not be there. it is currently possible (according to > them) to run two IGP protocol at the same time and > nothing breaks. so there is no reason to have this > restriction. >=20 > my argument is where do you use it? how does the MR > know which prefix should be sent in the BU and which > in the routing protocol message? if same prefix is > sent in both, then it is redundant. Note that ( I believe that ) the "keep it simple" argument is on our side. On a real router with multiple protocols running, such a checking may be real hard to implement, and seems like a process violation. Our proposal is to let the router operate as it normally does. Doing otherwise will create controversy for years. Note also that Kent and I did not discuss that offline, but naturally came to the same conclusion from our experience on router operations. Pascal From exim@www1.ietf.org Mon Jul 21 14:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06218 for ; Mon, 21 Jul 2003 14:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU7-0008J4-K7 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIY7Mn031927 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU7-0008Is-GP for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06152 for ; Mon, 21 Jul 2003 14:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efU4-0005JH-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19efTz-0005JE-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 14:33:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efU1-0008ER-C5; Mon, 21 Jul 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efT5-0008AP-MW for nemo@optimus.ietf.org; Mon, 21 Jul 2003 14:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06031 for ; Mon, 21 Jul 2003 14:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efT3-0005IA-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:33:01 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19efSr-0005HT-00 for nemo@ietf.org; Mon, 21 Jul 2003 14:32:50 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6LIU04q010316; Mon, 21 Jul 2003 20:30:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Jul 2003 20:31:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] multiple CoAs registration Date: Mon, 21 Jul 2003 19:31:43 +0100 Message-ID: Thread-Topic: [nemo] multiple CoAs registration Thread-Index: AcNNTEfXcQKiZqTOR3arkwoIpvvs5gCZgx+Q From: "Pascal Thubert (pthubert)" To: "Nicolas Montavont" , "Ryuji Wakikawa" Cc: "mobileip" , X-OriginalArrivalTime: 21 Jul 2003 18:31:44.0553 (UTC) FILETIME=[56360990:01C34FB6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I believe we talked about that a lot already; there seems to be a consensus on using the home address to identify uniquely a registration, for checking and cleanup purposes. The IFID should not be used to that purpose, and a registration should be able to migrate interface on the MR side. If we do not find a valid usage for ifid (I have none in mind at the moment) then it should be dropped, shouldn't it? >=20 > > > > > > Pascal =20 From nemo-admin@ietf.org Mon Jul 21 21:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16988 for ; Mon, 21 Jul 2003 21:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em5N-0006vZ-5I; Mon, 21 Jul 2003 21:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em4V-0006uu-EV for nemo@optimus.ietf.org; Mon, 21 Jul 2003 21:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16964 for ; Mon, 21 Jul 2003 21:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19em4S-0000AW-00 for nemo@ietf.org; Mon, 21 Jul 2003 21:36:04 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19em4I-0000AH-00 for nemo@ietf.org; Mon, 21 Jul 2003 21:35:54 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6M1Z6pp004119; Mon, 21 Jul 2003 18:35:06 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn4-709.cisco.com [10.21.82.197]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJL02984; Mon, 21 Jul 2003 18:31:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jul 2003 18:34:48 -0700 To: "Pascal Thubert (pthubert)" From: Kent Leung Cc: "Alexandru Petrescu" , "Vijay Devarapalli" , "S. Felix Wu" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The router will not "break" because it keeps track of the IGPs and maintains the routing table properly as Pascal described. Routers are built to deal with multiple IGPs. :) Kent At 07:31 PM 7/21/2003 +0100, Pascal Thubert (pthubert) wrote: > > So maybe they want to give an example. Kent, Pascal, how can one run > > several routing protocols on a machine and nothing breaks? I suppose > > that if one routing protocol adds a route, and another routing >protocol > > deletes the same route, then some things might break. > > > >The response is depends on the implementation. One thing is sure, when >multiple processes (sa ospf, rip and bgp) can insert/delete routes, the >system had better keep track of whom inserts the route for ownership >checking and easier administration. On IOS, you'll find a letter like O >for OSPF and M for Mobile when you display the routing table. > >Also, there'd better be an arbitration mechanism that selects which >route is chosen when 2 different protocols present a route to the exact >same prefix/length. Since the cost is meaningful only within one >process, the arbitration is based on an other setting. This is called >administrative distance in cisco routers. > >For routers, managing routes is a full time business - not a hobby like >for hosts - and they do it well. > > > Or, maybe this spec should not care at all about routing protocols, >and > > be entirely silent about how MIP interacts with IGP? > > > >:) > >Pascal From exim@www1.ietf.org Mon Jul 21 21:38:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17012 for ; Mon, 21 Jul 2003 21:38:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em65-0007Bt-0T for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 21:37:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M1biAT027635 for nemo-archive@odin.ietf.org; Mon, 21 Jul 2003 21:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em64-0007Be-PC for nemo-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 21:37:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17004 for ; Mon, 21 Jul 2003 21:37:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19em62-0000BI-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 21:37:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19em5w-0000B2-00 for nemo-web-archive@ietf.org; Mon, 21 Jul 2003 21:37:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em5N-0006vZ-5I; Mon, 21 Jul 2003 21:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19em4V-0006uu-EV for nemo@optimus.ietf.org; Mon, 21 Jul 2003 21:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16964 for ; Mon, 21 Jul 2003 21:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19em4S-0000AW-00 for nemo@ietf.org; Mon, 21 Jul 2003 21:36:04 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19em4I-0000AH-00 for nemo@ietf.org; Mon, 21 Jul 2003 21:35:54 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6M1Z6pp004119; Mon, 21 Jul 2003 18:35:06 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn4-709.cisco.com [10.21.82.197]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJL02984; Mon, 21 Jul 2003 18:31:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jul 2003 18:34:48 -0700 To: "Pascal Thubert (pthubert)" From: Kent Leung Cc: "Alexandru Petrescu" , "Vijay Devarapalli" , "S. Felix Wu" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] RE: IGP and MIP routes. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The router will not "break" because it keeps track of the IGPs and maintains the routing table properly as Pascal described. Routers are built to deal with multiple IGPs. :) Kent At 07:31 PM 7/21/2003 +0100, Pascal Thubert (pthubert) wrote: > > So maybe they want to give an example. Kent, Pascal, how can one run > > several routing protocols on a machine and nothing breaks? I suppose > > that if one routing protocol adds a route, and another routing >protocol > > deletes the same route, then some things might break. > > > >The response is depends on the implementation. One thing is sure, when >multiple processes (sa ospf, rip and bgp) can insert/delete routes, the >system had better keep track of whom inserts the route for ownership >checking and easier administration. On IOS, you'll find a letter like O >for OSPF and M for Mobile when you display the routing table. > >Also, there'd better be an arbitration mechanism that selects which >route is chosen when 2 different protocols present a route to the exact >same prefix/length. Since the cost is meaningful only within one >process, the arbitration is based on an other setting. This is called >administrative distance in cisco routers. > >For routers, managing routes is a full time business - not a hobby like >for hosts - and they do it well. > > > Or, maybe this spec should not care at all about routing protocols, >and > > be entirely silent about how MIP interacts with IGP? > > > >:) > >Pascal From nemo-admin@ietf.org Tue Jul 22 03:14:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03931 for ; Tue, 22 Jul 2003 03:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erLV-0000xf-Le; Tue, 22 Jul 2003 03:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erKw-0000wz-77 for nemo@optimus.ietf.org; Tue, 22 Jul 2003 03:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03917 for ; Tue, 22 Jul 2003 03:13:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19erKu-000252-00 for nemo@ietf.org; Tue, 22 Jul 2003 03:13:24 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19erKi-000242-00 for nemo@ietf.org; Tue, 22 Jul 2003 03:13:13 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h6M74Ma10929 for ; Tue, 22 Jul 2003 15:04:22 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id A377410E95DB; Tue, 22 Jul 2003 15:10:18 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058857818.28106.31.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 22 Jul 2003 15:10:18 +0800 Content-Transfer-Encoding: 7bit Subject: [nemo] supported multihoming scenarios Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, all, Base on discussion from IETF-57, there is an issue of which multihoming scenarios should be supported by Basic Solution. I hereby list them all, and give a brief description of the issues. Like to seek working group consensus on which multihoming scenarios the NMEO basic solution should be supported. For detailed analysis of each scenario, please refer to draft-ng-nemo-multihoming-issues-01.txt and drfat-charbon-nemo-multihoming-evaluation-00.txt (should be available in IETF repository soon, otherwise you can always retrieve it from [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt]). * (0,0,0): Single MR, Single HA, Single Prefix - No major issue * (0,0,1): Single MR, Single HA, Multiple Prefixes - No Major issues * (0,1,0): Single MR, Multiple HAs, Single Prefix - Do we support only the case where every HA belongs to the same administrative domain? - If HAs belong to different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes - Do we restrict ourselves to only the case where each prefix is only registered to HA within the same domain? - If the same prefix is registered to HAs from different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (1,0,0): Multiple MRs, Single HA, Single Prefix - No major issues * (1,0,1): Multiple MRs, Single HA, Multiple Prefixes - No major issues * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix - Do we support only the case where every HA belongs to the same administrative domain? - If HAs belong to different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes - Do we restrict ourselves to only the case where each prefix is only registered to HA within the same domain? - If the same prefix is registered to HAs from different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. /rgds /cwng From exim@www1.ietf.org Tue Jul 22 03:14:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03949 for ; Tue, 22 Jul 2003 03:14:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erLm-00011u-IP for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 03:14:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M7EIDt003958 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 03:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erLl-00011l-Q5 for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 03:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03923 for ; Tue, 22 Jul 2003 03:14:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19erLj-00025Z-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 03:14:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19erLe-00025U-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 03:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erLV-0000xf-Le; Tue, 22 Jul 2003 03:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19erKw-0000wz-77 for nemo@optimus.ietf.org; Tue, 22 Jul 2003 03:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03917 for ; Tue, 22 Jul 2003 03:13:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19erKu-000252-00 for nemo@ietf.org; Tue, 22 Jul 2003 03:13:24 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19erKi-000242-00 for nemo@ietf.org; Tue, 22 Jul 2003 03:13:13 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h6M74Ma10929 for ; Tue, 22 Jul 2003 15:04:22 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id A377410E95DB; Tue, 22 Jul 2003 15:10:18 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058857818.28106.31.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 22 Jul 2003 15:10:18 +0800 Content-Transfer-Encoding: 7bit Subject: [nemo] supported multihoming scenarios Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, all, Base on discussion from IETF-57, there is an issue of which multihoming scenarios should be supported by Basic Solution. I hereby list them all, and give a brief description of the issues. Like to seek working group consensus on which multihoming scenarios the NMEO basic solution should be supported. For detailed analysis of each scenario, please refer to draft-ng-nemo-multihoming-issues-01.txt and drfat-charbon-nemo-multihoming-evaluation-00.txt (should be available in IETF repository soon, otherwise you can always retrieve it from [http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt]). * (0,0,0): Single MR, Single HA, Single Prefix - No major issue * (0,0,1): Single MR, Single HA, Multiple Prefixes - No Major issues * (0,1,0): Single MR, Multiple HAs, Single Prefix - Do we support only the case where every HA belongs to the same administrative domain? - If HAs belong to different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes - Do we restrict ourselves to only the case where each prefix is only registered to HA within the same domain? - If the same prefix is registered to HAs from different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (1,0,0): Multiple MRs, Single HA, Single Prefix - No major issues * (1,0,1): Multiple MRs, Single HA, Multiple Prefixes - No major issues * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix - Do we support only the case where every HA belongs to the same administrative domain? - If HAs belong to different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes - Do we restrict ourselves to only the case where each prefix is only registered to HA within the same domain? - If the same prefix is registered to HAs from different domains, it may interfere with global routing since different domains now advertise routes to the same prefix.. /rgds /cwng From exim@www1.ietf.org Tue Jul 22 04:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05092 for ; Tue, 22 Jul 2003 04:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es86-0002s4-Is for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 04:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M84E8v011037 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 04:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es85-0002rw-QK for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 04:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05056 for ; Tue, 22 Jul 2003 04:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19es82-0002R4-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 04:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19es7w-0002R1-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 04:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es7t-0002qk-Mn; Tue, 22 Jul 2003 04:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es7N-0002qA-JP for nemo@optimus.ietf.org; Tue, 22 Jul 2003 04:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05048 for ; Tue, 22 Jul 2003 04:03:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19es7L-0002Qd-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:03:27 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19es7A-0002PF-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:03:16 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6M7w90l023313; Tue, 22 Jul 2003 09:58:20 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 10:00:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] IGP and MIP routes. Date: Tue, 22 Jul 2003 09:00:26 +0100 Message-ID: Thread-Topic: [nemo] IGP and MIP routes. Thread-Index: AcNOFeZ7oZnMzzjFQbOQo19sXtKD5QCD74Zg From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , "Alexandru Petrescu" Cc: "Vijay Devarapalli" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 08:00:27.0527 (UTC) FILETIME=[50284970:01C35027] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > original > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. >=20 > suggestion > When the Mobile Router and the Home Agent exchange routes of specific mobile > network prefixes through routing protocol updates, the Home Agent MUST > NOT create the routes of the mobile network prefixes to > the Mobile Router when the Binding Update from the Mobile Router > is received. The Mobile Router also SHOULD NOT include the mobile > network prefixes exchanged by routing protocol in the Binding Update. > The routes of the mobile network prefixes to the Mobile Router SHOULD be > created at the Home Agent through routing protocol updates. >=20 I waited for other people to get some pulse there. You know my point from the start. And Ryuji's proposal is not really much better.=20 It is (and it should stay) up to the admin of the router to decide, in case of a same prefix advertised by multiple IGPs, to select which source is preferred. The way this is done is implementation dependent. Because it is a router setting, not something in a protocol. MIP does not have to be any different. Note that the explicit comes at BU time before the IGP can even run. The MR has no way to check whether the MNP route will be exchanged later and by which IGP. I do not want any text there, but if you really want some, then I'd suggest something that says that Mobile behaves like other IGPs when it comes to route injection, deletion and redistribution. Pascal=20 From nemo-admin@ietf.org Tue Jul 22 04:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06232 for ; Tue, 22 Jul 2003 04:52:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essL-0004nU-LK; Tue, 22 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esrh-0004mb-4x for nemo@optimus.ietf.org; Tue, 22 Jul 2003 04:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06190 for ; Tue, 22 Jul 2003 04:51:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esre-0002iV-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:51:18 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19esrT-0002gd-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:51:07 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6M8leUg024661; Tue, 22 Jul 2003 01:47:40 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6M8isQ24226; Tue, 22 Jul 2003 10:44:55 +0200 (MEST) Date: Tue, 22 Jul 2003 10:43:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Chan-Wah Ng Cc: IETF NEMO WG In-Reply-To: "Your message with ID" <1058857818.28106.31.camel@beethoven> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? I don't think it is the admin domain which is really pertinent but a more general concept: The multiple HAs must be located so that the single prefix is not part of an aggregated prefix where the aggregation occurs between the HAs. For example if the HAs are in a single routing domain which uses OSPF or IS-IS then either the HAs must be part of the same IGP area, or the prefix assigned to the mobile network must not be aggregated at the area boundary. > - If HAs belong to different domains, it may interfere with global > routing since different domains now advertise routes to the same > prefix.. I think this statement is backwards since there tends to be filtering of advertised prefixes at AS boundaries. Thus if this were to be done it is likely that things would not work due to the routes for the mobile network's prefix are likely to be filtered. > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? > - If the same prefix is registered to HAs from different domains, it may > interfere with global routing since different domains now advertise > routes to the same prefix.. same comment as above. But there is an addition point of view which is that in this case the mobile network can be viewed as a multihomed site similar a home being multihomed to both a DLS provider and a cable modem provider. I'm concerned that the categorization you use don't capture the important distinction between the case when the MR(s) are independent of the HA(s) (as is the case in the site multihoming view) and when the MR(s) are operated by the same entity as the HA(s). In either case there are existing techniques that can be applied independently of Nemo, but the techniques would be quite different in the two cases. When there are multiple prefixes assigned to the mobile network this is most likely due to the MR(s) being independent of the HA(s) i.e. the site multihoming view. > * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? > - If HAs belong to different domains, it may interfere with global > routing since different domains now advertise routes to the same > prefix.. see above > * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? > - If the same prefix is registered to HAs from different domains, it may > interfere with global routing since different domains now advertise > routes to the same prefix.. see above Erik From exim@www1.ietf.org Tue Jul 22 04:52:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06248 for ; Tue, 22 Jul 2003 04:52:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essT-0004pY-HI for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 04:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M8q9wi018564 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 04:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essT-0004pL-CX for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 04:52:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06204 for ; Tue, 22 Jul 2003 04:52:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19essQ-0002iq-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 04:52:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19essK-0002in-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 04:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19essL-0004nU-LK; Tue, 22 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esrh-0004mb-4x for nemo@optimus.ietf.org; Tue, 22 Jul 2003 04:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06190 for ; Tue, 22 Jul 2003 04:51:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esre-0002iV-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:51:18 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19esrT-0002gd-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:51:07 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6M8leUg024661; Tue, 22 Jul 2003 01:47:40 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6M8isQ24226; Tue, 22 Jul 2003 10:44:55 +0200 (MEST) Date: Tue, 22 Jul 2003 10:43:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Chan-Wah Ng Cc: IETF NEMO WG In-Reply-To: "Your message with ID" <1058857818.28106.31.camel@beethoven> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? I don't think it is the admin domain which is really pertinent but a more general concept: The multiple HAs must be located so that the single prefix is not part of an aggregated prefix where the aggregation occurs between the HAs. For example if the HAs are in a single routing domain which uses OSPF or IS-IS then either the HAs must be part of the same IGP area, or the prefix assigned to the mobile network must not be aggregated at the area boundary. > - If HAs belong to different domains, it may interfere with global > routing since different domains now advertise routes to the same > prefix.. I think this statement is backwards since there tends to be filtering of advertised prefixes at AS boundaries. Thus if this were to be done it is likely that things would not work due to the routes for the mobile network's prefix are likely to be filtered. > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? > - If the same prefix is registered to HAs from different domains, it may > interfere with global routing since different domains now advertise > routes to the same prefix.. same comment as above. But there is an addition point of view which is that in this case the mobile network can be viewed as a multihomed site similar a home being multihomed to both a DLS provider and a cable modem provider. I'm concerned that the categorization you use don't capture the important distinction between the case when the MR(s) are independent of the HA(s) (as is the case in the site multihoming view) and when the MR(s) are operated by the same entity as the HA(s). In either case there are existing techniques that can be applied independently of Nemo, but the techniques would be quite different in the two cases. When there are multiple prefixes assigned to the mobile network this is most likely due to the MR(s) being independent of the HA(s) i.e. the site multihoming view. > * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? > - If HAs belong to different domains, it may interfere with global > routing since different domains now advertise routes to the same > prefix.. see above > * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? > - If the same prefix is registered to HAs from different domains, it may > interfere with global routing since different domains now advertise > routes to the same prefix.. see above Erik From nemo-admin@ietf.org Tue Jul 22 04:52:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05094 for ; Tue, 22 Jul 2003 04:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es7t-0002qk-Mn; Tue, 22 Jul 2003 04:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19es7N-0002qA-JP for nemo@optimus.ietf.org; Tue, 22 Jul 2003 04:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05048 for ; Tue, 22 Jul 2003 04:03:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19es7L-0002Qd-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:03:27 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19es7A-0002PF-00 for nemo@ietf.org; Tue, 22 Jul 2003 04:03:16 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6M7w90l023313; Tue, 22 Jul 2003 09:58:20 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 10:00:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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] IGP and MIP routes. Date: Tue, 22 Jul 2003 09:00:26 +0100 Message-ID: Thread-Topic: [nemo] IGP and MIP routes. Thread-Index: AcNOFeZ7oZnMzzjFQbOQo19sXtKD5QCD74Zg From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , "Alexandru Petrescu" Cc: "Vijay Devarapalli" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 08:00:27.0527 (UTC) FILETIME=[50284970:01C35027] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > original > When the Mobile Router and the Home Agent exchange routes through > routing protocol updates, the Home Agent MUST NOT create routes to > the Mobile network when the Binding Update from the Mobile Router > is received. The Mobile Router also MUST NOT include any prefix > information in the Binding Update. Any routes to the Mobile Network > are created at the Home Agent through routing protocol updates. >=20 > suggestion > When the Mobile Router and the Home Agent exchange routes of specific mobile > network prefixes through routing protocol updates, the Home Agent MUST > NOT create the routes of the mobile network prefixes to > the Mobile Router when the Binding Update from the Mobile Router > is received. The Mobile Router also SHOULD NOT include the mobile > network prefixes exchanged by routing protocol in the Binding Update. > The routes of the mobile network prefixes to the Mobile Router SHOULD be > created at the Home Agent through routing protocol updates. >=20 I waited for other people to get some pulse there. You know my point from the start. And Ryuji's proposal is not really much better.=20 It is (and it should stay) up to the admin of the router to decide, in case of a same prefix advertised by multiple IGPs, to select which source is preferred. The way this is done is implementation dependent. Because it is a router setting, not something in a protocol. MIP does not have to be any different. Note that the explicit comes at BU time before the IGP can even run. The MR has no way to check whether the MNP route will be exchanged later and by which IGP. I do not want any text there, but if you really want some, then I'd suggest something that says that Mobile behaves like other IGPs when it comes to route injection, deletion and redistribution. Pascal=20 From nemo-admin@ietf.org Tue Jul 22 07:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09483 for ; Tue, 22 Jul 2003 07:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4l-0001tK-AC; Tue, 22 Jul 2003 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev3w-0001t3-9i for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09447 for ; Tue, 22 Jul 2003 07:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev3v-0003at-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:12:07 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19ev3d-0003ad-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:11:50 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6MB8H6t002978; Tue, 22 Jul 2003 20:08:17 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" , "'Kent Leung'" Cc: "'S. Felix Wu'" , , Subject: RE: [nemo] RE: Issue 6 Date: Tue, 22 Jul 2003 20:13:16 +0900 Message-ID: <000001c35042$4036c260$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3F172A16.CD479640@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Vijay and all, I want to clarify again my point about issue 6 because I firstly raised this issue. First I've pointed that the basic support protocol doesn't properly work in case of implicit mode BU and dynamic routing protocol assumed. In the case that prefix table not properly pre-configurated, HA will reply BACK error for BU of implicit mode according to last paragraph of section 6.6. I guess this case should be considered as the following choices which we can do now. 1) Section 6.6 last paragraph additionally describes this case. Already that commented by Ryuji about using new flag field in the entry of prefix table. The administrator of HA should mark new field in the entry mapped with HoA of MR for indicating that the MNP will be set and managed by any other mechanism e.g. dynamic routing protocol. Therefore, HA will not send BACK error for implicit mode BU if new flag is set. 2) It should be described in somewhere that MNP allowed to MR should be set in prefix table by the administration regardless of dynamic routing protocol used through HA-MR tunnel. And, if the implicit mode allowed then prefix table must be managed by HA, that must be not optional in that case. In other words, there is a need to clarify the dependence between use of implicit mode and usage of prefix table. And, in this case of using dynamic routing protocol, I think specifying of MNP in prefix table is redundant. Am I missing something of this thread? Please correct me. Otherwise, please consider above cases. /jongkeun > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay > Devarapalli > Sent: Friday, July 18, 2003 7:59 AM > To: Kent Leung > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 > > Kent Leung wrote: > > > > > >I dont buy this argument. a protocol specification has to be > > >tight and exact. I dont see why would need both for the same > > >prefix. > > > > Hmm. Original text issue is below. Not sure if you are assuming > > same prefix, which may not be always the case. > > > > >Vijay Devarapalli wrote: > > When the Mobile Router and the Home Agent exchange routes > > through routing protocol updates, the Home Agent MUST NOT > > create routes to the Mobile network when the Binding Update > > from the Mobile Router is received. The Mobile Router also > > MUST NOT include any prefix information in the Binding Update. > > Any routes to the Mobile Network are created at the Home > > Agent through routing protocol updates. > > this was proposed a few days back. the latest > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > >I disagree characterising this as an "config/operation" issue. > > > > > >I would agree if the Binding Updates and Routing Protocol > > >updates carry different prefixes, i.e. if the MR uses a > > >Binding Update to have the HA create routes for a certain > > >perfix and it uses a routing protocol update for creating > > >routes for a different prefix. > > > > Yes, the original text was exclusive in which method was used to > > update the HA. Still I don't agree there needs to be any additional > > checks. Again, what is the harm? > > what is the need? I dont see any. > > > The result is still traffic to MNP > > are tunneled to the MR. > > *extra* traffic. > > > What about inter-mixing statically configured MNP with BU extensions > > or IGP? > > > > This is something that multi-protocol routers deal with since they were > > invented. Why is this such a special case? > > didnt follow the argument. my question is why add to > that? I see that you already have to deal with a lot > of mechanisms for adding routes. why add yet another > mechanism when it can used exclusive to the IGP over > the bi-directional tunnel. > > Vijay From exim@www1.ietf.org Tue Jul 22 07:13:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09498 for ; Tue, 22 Jul 2003 07:13:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4u-0001uO-QC for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:13:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MBD8aF007332 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4u-0001uB-LY for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 07:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09477 for ; Tue, 22 Jul 2003 07:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev4u-0003bQ-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:13:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ev4o-0003bN-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev4l-0001tK-AC; Tue, 22 Jul 2003 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev3w-0001t3-9i for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09447 for ; Tue, 22 Jul 2003 07:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev3v-0003at-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:12:07 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19ev3d-0003ad-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:11:50 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6MB8H6t002978; Tue, 22 Jul 2003 20:08:17 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" , "'Kent Leung'" Cc: "'S. Felix Wu'" , , Subject: RE: [nemo] RE: Issue 6 Date: Tue, 22 Jul 2003 20:13:16 +0900 Message-ID: <000001c35042$4036c260$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3F172A16.CD479640@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Vijay and all, I want to clarify again my point about issue 6 because I firstly raised this issue. First I've pointed that the basic support protocol doesn't properly work in case of implicit mode BU and dynamic routing protocol assumed. In the case that prefix table not properly pre-configurated, HA will reply BACK error for BU of implicit mode according to last paragraph of section 6.6. I guess this case should be considered as the following choices which we can do now. 1) Section 6.6 last paragraph additionally describes this case. Already that commented by Ryuji about using new flag field in the entry of prefix table. The administrator of HA should mark new field in the entry mapped with HoA of MR for indicating that the MNP will be set and managed by any other mechanism e.g. dynamic routing protocol. Therefore, HA will not send BACK error for implicit mode BU if new flag is set. 2) It should be described in somewhere that MNP allowed to MR should be set in prefix table by the administration regardless of dynamic routing protocol used through HA-MR tunnel. And, if the implicit mode allowed then prefix table must be managed by HA, that must be not optional in that case. In other words, there is a need to clarify the dependence between use of implicit mode and usage of prefix table. And, in this case of using dynamic routing protocol, I think specifying of MNP in prefix table is redundant. Am I missing something of this thread? Please correct me. Otherwise, please consider above cases. /jongkeun > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay > Devarapalli > Sent: Friday, July 18, 2003 7:59 AM > To: Kent Leung > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 > > Kent Leung wrote: > > > > > >I dont buy this argument. a protocol specification has to be > > >tight and exact. I dont see why would need both for the same > > >prefix. > > > > Hmm. Original text issue is below. Not sure if you are assuming > > same prefix, which may not be always the case. > > > > >Vijay Devarapalli wrote: > > When the Mobile Router and the Home Agent exchange routes > > through routing protocol updates, the Home Agent MUST NOT > > create routes to the Mobile network when the Binding Update > > from the Mobile Router is received. The Mobile Router also > > MUST NOT include any prefix information in the Binding Update. > > Any routes to the Mobile Network are created at the Home > > Agent through routing protocol updates. > > this was proposed a few days back. the latest > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > >I disagree characterising this as an "config/operation" issue. > > > > > >I would agree if the Binding Updates and Routing Protocol > > >updates carry different prefixes, i.e. if the MR uses a > > >Binding Update to have the HA create routes for a certain > > >perfix and it uses a routing protocol update for creating > > >routes for a different prefix. > > > > Yes, the original text was exclusive in which method was used to > > update the HA. Still I don't agree there needs to be any additional > > checks. Again, what is the harm? > > what is the need? I dont see any. > > > The result is still traffic to MNP > > are tunneled to the MR. > > *extra* traffic. > > > What about inter-mixing statically configured MNP with BU extensions > > or IGP? > > > > This is something that multi-protocol routers deal with since they were > > invented. Why is this such a special case? > > didnt follow the argument. my question is why add to > that? I see that you already have to deal with a lot > of mechanisms for adding routes. why add yet another > mechanism when it can used exclusive to the IGP over > the bi-directional tunnel. > > Vijay From nemo-admin@ietf.org Tue Jul 22 07:14:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09550 for ; Tue, 22 Jul 2003 07:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5l-0001yQ-9i; Tue, 22 Jul 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5b-0001xu-2N for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09515 for ; Tue, 22 Jul 2003 07:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev5a-0003bl-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:13:50 -0400 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 19ev5P-0003bY-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:13:39 -0400 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h6MBD78Y025201 for ; Tue, 22 Jul 2003 14:13:11 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id OAA07387 for ; Tue, 22 Jul 2003 14:13:07 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030722141236.00bf7cf0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jul 2003 14:13:06 +0300 To: nemo@ietf.org From: Pekka =?iso-8859-1?Q?Pääkkönen?= Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 14:26 30.6.2003 -0400, Ralph Droms wrote: >All, > >Following up on our conversation a couple of months ago >about using DHCPv6 PD for prefix delegation to mobile >routers, I've published "DHCPv6 Prefix Delegation for >NEMO" . This draft >describes the use of DHCPv6 to meet my understanding >of the requirements for prefix delegation to mobile >routers. Comments welcome... > >- Ralph > > This draft helps in understanding how to use DHCPv6 with NEMO networks. Just one comment: link-local addressing related to tunnel-interfaces: No document specifies to my knowledge how to configure link-local addresses for tunnel-interfaces. If DHCPv6 messages are reverse-tunneled, link-local addresses have to be configured on the tunnel-interfaces of both the MR and HA. The same link-local addresses used on non-tunnel interfaces could be configured also on the tunnel-interfaces (it was mentioned earlier by Erik ?). Maybe this could also be mentioned in the draft? Comments? Pekka From exim@www1.ietf.org Tue Jul 22 07:14:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09566 for ; Tue, 22 Jul 2003 07:14:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5r-00022p-IK for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:14:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MBE7XZ007853 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5r-00022a-DU for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 07:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09522 for ; Tue, 22 Jul 2003 07:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev5q-0003bu-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ev5l-0003br-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5l-0001yQ-9i; Tue, 22 Jul 2003 07:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ev5b-0001xu-2N for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09515 for ; Tue, 22 Jul 2003 07:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ev5a-0003bl-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:13:50 -0400 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 19ev5P-0003bY-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:13:39 -0400 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h6MBD78Y025201 for ; Tue, 22 Jul 2003 14:13:11 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id OAA07387 for ; Tue, 22 Jul 2003 14:13:07 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030722141236.00bf7cf0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jul 2003 14:13:06 +0300 To: nemo@ietf.org From: Pekka =?iso-8859-1?Q?Pääkkönen?= Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 14:26 30.6.2003 -0400, Ralph Droms wrote: >All, > >Following up on our conversation a couple of months ago >about using DHCPv6 PD for prefix delegation to mobile >routers, I've published "DHCPv6 Prefix Delegation for >NEMO" . This draft >describes the use of DHCPv6 to meet my understanding >of the requirements for prefix delegation to mobile >routers. Comments welcome... > >- Ralph > > This draft helps in understanding how to use DHCPv6 with NEMO networks. Just one comment: link-local addressing related to tunnel-interfaces: No document specifies to my knowledge how to configure link-local addresses for tunnel-interfaces. If DHCPv6 messages are reverse-tunneled, link-local addresses have to be configured on the tunnel-interfaces of both the MR and HA. The same link-local addresses used on non-tunnel interfaces could be configured also on the tunnel-interfaces (it was mentioned earlier by Erik ?). Maybe this could also be mentioned in the draft? Comments? Pekka From nemo-admin@ietf.org Tue Jul 22 07:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09983 for ; Tue, 22 Jul 2003 07:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evP6-0002Zo-JT; Tue, 22 Jul 2003 07:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evOa-0002XU-Np for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09969 for ; Tue, 22 Jul 2003 07:33:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evOa-0003i6-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:33:28 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19evOP-0003hr-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:33:17 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6MBTmWA007544; Tue, 22 Jul 2003 13:30:04 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 13:32:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Tue, 22 Jul 2003 12:31:59 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQQgsu3uGDAR/RS5+Fbe9e5dbE5AAAgnvw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" , "Kent Leung (kleung)" Cc: "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 11:32:00.0295 (UTC) FILETIME=[DDA2FB70:01C35044] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Can't we just drop code 143 and accept the implicit whatever? There are at least 3 cases of implicit with different problems associated: - static route: HA could check for a static route but it does not control it. The admin may change it. Should we drop the binding then? - prefix table: source of our recent discussion on how it compares with other IGPs - dynamic route: HA does not have the associated routes yet. No clue if there will eventually be one? Should we drop the binding if none come up? You see code 143 is tricky to use for not much added value. Sugestion, get rid of the last paragraph and if the code. In implicit mode, the HA does its best and that's it. Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 22 juillet 2003 13:13 > To: 'Vijay Devarapalli'; Kent Leung (kleung) > Cc: 'S. Felix Wu'; Pascal Thubert (pthubert); nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 >=20 > Hello Vijay and all, >=20 > I want to clarify again my point about issue 6 because I firstly raised > this issue. > First I've pointed that the basic support protocol doesn't properly work > in case of implicit mode BU and dynamic routing protocol assumed. In the > case that prefix table not properly pre-configurated, HA will reply BACK > error for BU of implicit mode according to last paragraph of section > 6.6. I guess this case should be considered as the following choices > which we can do now. > 1) Section 6.6 last paragraph additionally describes this case. Already > that commented by Ryuji about using new flag field in the entry of > prefix table. The administrator of HA should mark new field in the entry > mapped with HoA of MR for indicating that the MNP will be set and > managed by any other mechanism e.g. dynamic routing protocol. Therefore, > HA will not send BACK error for implicit mode BU if new flag is set. > 2) It should be described in somewhere that MNP allowed to MR should be > set in prefix table by the administration regardless of dynamic routing > protocol used through HA-MR tunnel. And, if the implicit mode allowed > then prefix table must be managed by HA, that must be not optional in > that case. In other words, there is a need to clarify the dependence > between use of implicit mode and usage of prefix table. And, in this > case of using dynamic routing protocol, I think specifying of MNP in > prefix table is redundant. >=20 > Am I missing something of this thread? Please correct me. > Otherwise, please consider above cases. >=20 > /jongkeun >=20 > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Vijay > > Devarapalli > > Sent: Friday, July 18, 2003 7:59 AM > > To: Kent Leung > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > Kent Leung wrote: > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > >tight and exact. I dont see why would need both for the same > > > >prefix. > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > same prefix, which may not be always the case. > > > > > > >Vijay Devarapalli wrote: > > > When the Mobile Router and the Home Agent exchange routes > > > through routing protocol updates, the Home Agent MUST NOT > > > create routes to the Mobile network when the Binding Update > > > from the Mobile Router is received. The Mobile Router also > > > MUST NOT include any prefix information in the Binding Update. > > > Any routes to the Mobile Network are created at the Home > > > Agent through routing protocol updates. > > > > this was proposed a few days back. the latest > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > >updates carry different prefixes, i.e. if the MR uses a > > > >Binding Update to have the HA create routes for a certain > > > >perfix and it uses a routing protocol update for creating > > > >routes for a different prefix. > > > > > > Yes, the original text was exclusive in which method was used to > > > update the HA. Still I don't agree there needs to be any additional > > > checks. Again, what is the harm? > > > > what is the need? I dont see any. > > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > > *extra* traffic. > > > > > What about inter-mixing statically configured MNP with BU extensions > > > or IGP? > > > > > > This is something that multi-protocol routers deal with since they > were > > > invented. Why is this such a special case? > > > > didnt follow the argument. my question is why add to > > that? I see that you already have to deal with a lot > > of mechanisms for adding routes. why add yet another > > mechanism when it can used exclusive to the IGP over > > the bi-directional tunnel. > > > > Vijay From exim@www1.ietf.org Tue Jul 22 07:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09998 for ; Tue, 22 Jul 2003 07:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evPE-0002ak-5u for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MBY87N009958 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 07:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evPE-0002aW-1g for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 07:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09976 for ; Tue, 22 Jul 2003 07:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evPD-0003iC-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:34:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19evP7-0003i9-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 07:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evP6-0002Zo-JT; Tue, 22 Jul 2003 07:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evOa-0002XU-Np for nemo@optimus.ietf.org; Tue, 22 Jul 2003 07:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09969 for ; Tue, 22 Jul 2003 07:33:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evOa-0003i6-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:33:28 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19evOP-0003hr-00 for nemo@ietf.org; Tue, 22 Jul 2003 07:33:17 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6MBTmWA007544; Tue, 22 Jul 2003 13:30:04 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 13:32:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Tue, 22 Jul 2003 12:31:59 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQQgsu3uGDAR/RS5+Fbe9e5dbE5AAAgnvw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" , "Kent Leung (kleung)" Cc: "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 11:32:00.0295 (UTC) FILETIME=[DDA2FB70:01C35044] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Can't we just drop code 143 and accept the implicit whatever? There are at least 3 cases of implicit with different problems associated: - static route: HA could check for a static route but it does not control it. The admin may change it. Should we drop the binding then? - prefix table: source of our recent discussion on how it compares with other IGPs - dynamic route: HA does not have the associated routes yet. No clue if there will eventually be one? Should we drop the binding if none come up? You see code 143 is tricky to use for not much added value. Sugestion, get rid of the last paragraph and if the code. In implicit mode, the HA does its best and that's it. Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 22 juillet 2003 13:13 > To: 'Vijay Devarapalli'; Kent Leung (kleung) > Cc: 'S. Felix Wu'; Pascal Thubert (pthubert); nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 >=20 > Hello Vijay and all, >=20 > I want to clarify again my point about issue 6 because I firstly raised > this issue. > First I've pointed that the basic support protocol doesn't properly work > in case of implicit mode BU and dynamic routing protocol assumed. In the > case that prefix table not properly pre-configurated, HA will reply BACK > error for BU of implicit mode according to last paragraph of section > 6.6. I guess this case should be considered as the following choices > which we can do now. > 1) Section 6.6 last paragraph additionally describes this case. Already > that commented by Ryuji about using new flag field in the entry of > prefix table. The administrator of HA should mark new field in the entry > mapped with HoA of MR for indicating that the MNP will be set and > managed by any other mechanism e.g. dynamic routing protocol. Therefore, > HA will not send BACK error for implicit mode BU if new flag is set. > 2) It should be described in somewhere that MNP allowed to MR should be > set in prefix table by the administration regardless of dynamic routing > protocol used through HA-MR tunnel. And, if the implicit mode allowed > then prefix table must be managed by HA, that must be not optional in > that case. In other words, there is a need to clarify the dependence > between use of implicit mode and usage of prefix table. And, in this > case of using dynamic routing protocol, I think specifying of MNP in > prefix table is redundant. >=20 > Am I missing something of this thread? Please correct me. > Otherwise, please consider above cases. >=20 > /jongkeun >=20 > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Vijay > > Devarapalli > > Sent: Friday, July 18, 2003 7:59 AM > > To: Kent Leung > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > Kent Leung wrote: > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > >tight and exact. I dont see why would need both for the same > > > >prefix. > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > same prefix, which may not be always the case. > > > > > > >Vijay Devarapalli wrote: > > > When the Mobile Router and the Home Agent exchange routes > > > through routing protocol updates, the Home Agent MUST NOT > > > create routes to the Mobile network when the Binding Update > > > from the Mobile Router is received. The Mobile Router also > > > MUST NOT include any prefix information in the Binding Update. > > > Any routes to the Mobile Network are created at the Home > > > Agent through routing protocol updates. > > > > this was proposed a few days back. the latest > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > >updates carry different prefixes, i.e. if the MR uses a > > > >Binding Update to have the HA create routes for a certain > > > >perfix and it uses a routing protocol update for creating > > > >routes for a different prefix. > > > > > > Yes, the original text was exclusive in which method was used to > > > update the HA. Still I don't agree there needs to be any additional > > > checks. Again, what is the harm? > > > > what is the need? I dont see any. > > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > > *extra* traffic. > > > > > What about inter-mixing statically configured MNP with BU extensions > > > or IGP? > > > > > > This is something that multi-protocol routers deal with since they > were > > > invented. Why is this such a special case? > > > > didnt follow the argument. my question is why add to > > that? I see that you already have to deal with a lot > > of mechanisms for adding routes. why add yet another > > mechanism when it can used exclusive to the IGP over > > the bi-directional tunnel. > > > > Vijay From nemo-admin@ietf.org Tue Jul 22 08:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10550 for ; Tue, 22 Jul 2003 08:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evs9-0003Yc-8x; Tue, 22 Jul 2003 08:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evrO-0003Xo-Ez for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10512 for ; Tue, 22 Jul 2003 08:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evrN-0003uE-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:03:13 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19evr7-0003uB-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:02:57 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6MBxY6t003112; Tue, 22 Jul 2003 20:59:34 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" , "'Kent Leung \(kleung\)'" Cc: "'S. Felix Wu'" , Subject: RE: [nemo] RE: Issue 6 Date: Tue, 22 Jul 2003 21:04:33 +0900 Message-ID: <000001c35049$69c3a510$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Pascal, Your suggestion is not bad, I think. If so, the prefix table no needed more. Right? I guess we need to again consider about why prefix table proposed at first time. If there is no problem, I'll be okay with the deletion of the stuff. /Jongkeun > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, July 22, 2003 8:32 PM > To: Jongkeun Na; Vijay Devarapalli; Kent Leung (kleung) > Cc: S. Felix Wu; nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 > > Can't we just drop code 143 and accept the implicit whatever? > > There are at least 3 cases of implicit with different problems > associated: > > - static route: HA could check for a static route but it does not > control it. The admin may change it. Should we drop the binding then? > - prefix table: source of our recent discussion on how it compares with > other IGPs > - dynamic route: HA does not have the associated routes yet. No clue if > there will eventually be one? Should we drop the binding if none come > up? > > > You see code 143 is tricky to use for not much added value. Sugestion, > get rid of the last paragraph and if the code. In implicit mode, the HA > does its best and that's it. > > Pascal > > > > > -----Original Message----- > > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > > Sent: mardi 22 juillet 2003 13:13 > > To: 'Vijay Devarapalli'; Kent Leung (kleung) > > Cc: 'S. Felix Wu'; Pascal Thubert (pthubert); nemo@ietf.org > > Subject: RE: [nemo] RE: Issue 6 > > > > Hello Vijay and all, > > > > I want to clarify again my point about issue 6 because I firstly > raised > > this issue. > > First I've pointed that the basic support protocol doesn't properly > work > > in case of implicit mode BU and dynamic routing protocol assumed. In > the > > case that prefix table not properly pre-configurated, HA will reply > BACK > > error for BU of implicit mode according to last paragraph of section > > 6.6. I guess this case should be considered as the following choices > > which we can do now. > > 1) Section 6.6 last paragraph additionally describes this case. > Already > > that commented by Ryuji about using new flag field in the entry of > > prefix table. The administrator of HA should mark new field in the > entry > > mapped with HoA of MR for indicating that the MNP will be set and > > managed by any other mechanism e.g. dynamic routing protocol. > Therefore, > > HA will not send BACK error for implicit mode BU if new flag is set. > > 2) It should be described in somewhere that MNP allowed to MR should > be > > set in prefix table by the administration regardless of dynamic > routing > > protocol used through HA-MR tunnel. And, if the implicit mode allowed > > then prefix table must be managed by HA, that must be not optional in > > that case. In other words, there is a need to clarify the dependence > > between use of implicit mode and usage of prefix table. And, in this > > case of using dynamic routing protocol, I think specifying of MNP in > > prefix table is redundant. > > > > Am I missing something of this thread? Please correct me. > > Otherwise, please consider above cases. > > > > /jongkeun > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Vijay > > > Devarapalli > > > Sent: Friday, July 18, 2003 7:59 AM > > > To: Kent Leung > > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > > Subject: Re: [nemo] RE: Issue 6 > > > > > > Kent Leung wrote: > > > > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > > >tight and exact. I dont see why would need both for the same > > > > >prefix. > > > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > > same prefix, which may not be always the case. > > > > > > > > >Vijay Devarapalli wrote: > > > > When the Mobile Router and the Home Agent exchange routes > > > > through routing protocol updates, the Home Agent MUST NOT > > > > create routes to the Mobile network when the Binding Update > > > > from the Mobile Router is received. The Mobile Router also > > > > MUST NOT include any prefix information in the Binding Update. > > > > Any routes to the Mobile Network are created at the Home > > > > Agent through routing protocol updates. > > > > > > this was proposed a few days back. the latest > > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > > >updates carry different prefixes, i.e. if the MR uses a > > > > >Binding Update to have the HA create routes for a certain > > > > >perfix and it uses a routing protocol update for creating > > > > >routes for a different prefix. > > > > > > > > Yes, the original text was exclusive in which method was used to > > > > update the HA. Still I don't agree there needs to be any > additional > > > > checks. Again, what is the harm? > > > > > > what is the need? I dont see any. > > > > > > > The result is still traffic to MNP > > > > are tunneled to the MR. > > > > > > *extra* traffic. > > > > > > > What about inter-mixing statically configured MNP with BU > extensions > > > > or IGP? > > > > > > > > This is something that multi-protocol routers deal with since they > > were > > > > invented. Why is this such a special case? > > > > > > didnt follow the argument. my question is why add to > > > that? I see that you already have to deal with a lot > > > of mechanisms for adding routes. why add yet another > > > mechanism when it can used exclusive to the IGP over > > > the bi-directional tunnel. > > > > > > Vijay From exim@www1.ietf.org Tue Jul 22 08:04:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10565 for ; Tue, 22 Jul 2003 08:04:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evsH-0003as-DB for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MC49XV013808 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evsH-0003ad-9E for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 08:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10538 for ; Tue, 22 Jul 2003 08:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evsG-0003uk-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:04:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19evsA-0003uh-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evs9-0003Yc-8x; Tue, 22 Jul 2003 08:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19evrO-0003Xo-Ez for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10512 for ; Tue, 22 Jul 2003 08:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19evrN-0003uE-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:03:13 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19evr7-0003uB-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:02:57 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h6MBxY6t003112; Tue, 22 Jul 2003 20:59:34 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" , "'Kent Leung \(kleung\)'" Cc: "'S. Felix Wu'" , Subject: RE: [nemo] RE: Issue 6 Date: Tue, 22 Jul 2003 21:04:33 +0900 Message-ID: <000001c35049$69c3a510$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Pascal, Your suggestion is not bad, I think. If so, the prefix table no needed more. Right? I guess we need to again consider about why prefix table proposed at first time. If there is no problem, I'll be okay with the deletion of the stuff. /Jongkeun > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, July 22, 2003 8:32 PM > To: Jongkeun Na; Vijay Devarapalli; Kent Leung (kleung) > Cc: S. Felix Wu; nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 > > Can't we just drop code 143 and accept the implicit whatever? > > There are at least 3 cases of implicit with different problems > associated: > > - static route: HA could check for a static route but it does not > control it. The admin may change it. Should we drop the binding then? > - prefix table: source of our recent discussion on how it compares with > other IGPs > - dynamic route: HA does not have the associated routes yet. No clue if > there will eventually be one? Should we drop the binding if none come > up? > > > You see code 143 is tricky to use for not much added value. Sugestion, > get rid of the last paragraph and if the code. In implicit mode, the HA > does its best and that's it. > > Pascal > > > > > -----Original Message----- > > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > > Sent: mardi 22 juillet 2003 13:13 > > To: 'Vijay Devarapalli'; Kent Leung (kleung) > > Cc: 'S. Felix Wu'; Pascal Thubert (pthubert); nemo@ietf.org > > Subject: RE: [nemo] RE: Issue 6 > > > > Hello Vijay and all, > > > > I want to clarify again my point about issue 6 because I firstly > raised > > this issue. > > First I've pointed that the basic support protocol doesn't properly > work > > in case of implicit mode BU and dynamic routing protocol assumed. In > the > > case that prefix table not properly pre-configurated, HA will reply > BACK > > error for BU of implicit mode according to last paragraph of section > > 6.6. I guess this case should be considered as the following choices > > which we can do now. > > 1) Section 6.6 last paragraph additionally describes this case. > Already > > that commented by Ryuji about using new flag field in the entry of > > prefix table. The administrator of HA should mark new field in the > entry > > mapped with HoA of MR for indicating that the MNP will be set and > > managed by any other mechanism e.g. dynamic routing protocol. > Therefore, > > HA will not send BACK error for implicit mode BU if new flag is set. > > 2) It should be described in somewhere that MNP allowed to MR should > be > > set in prefix table by the administration regardless of dynamic > routing > > protocol used through HA-MR tunnel. And, if the implicit mode allowed > > then prefix table must be managed by HA, that must be not optional in > > that case. In other words, there is a need to clarify the dependence > > between use of implicit mode and usage of prefix table. And, in this > > case of using dynamic routing protocol, I think specifying of MNP in > > prefix table is redundant. > > > > Am I missing something of this thread? Please correct me. > > Otherwise, please consider above cases. > > > > /jongkeun > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Vijay > > > Devarapalli > > > Sent: Friday, July 18, 2003 7:59 AM > > > To: Kent Leung > > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > > Subject: Re: [nemo] RE: Issue 6 > > > > > > Kent Leung wrote: > > > > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > > >tight and exact. I dont see why would need both for the same > > > > >prefix. > > > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > > same prefix, which may not be always the case. > > > > > > > > >Vijay Devarapalli wrote: > > > > When the Mobile Router and the Home Agent exchange routes > > > > through routing protocol updates, the Home Agent MUST NOT > > > > create routes to the Mobile network when the Binding Update > > > > from the Mobile Router is received. The Mobile Router also > > > > MUST NOT include any prefix information in the Binding Update. > > > > Any routes to the Mobile Network are created at the Home > > > > Agent through routing protocol updates. > > > > > > this was proposed a few days back. the latest > > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > > >updates carry different prefixes, i.e. if the MR uses a > > > > >Binding Update to have the HA create routes for a certain > > > > >perfix and it uses a routing protocol update for creating > > > > >routes for a different prefix. > > > > > > > > Yes, the original text was exclusive in which method was used to > > > > update the HA. Still I don't agree there needs to be any > additional > > > > checks. Again, what is the harm? > > > > > > what is the need? I dont see any. > > > > > > > The result is still traffic to MNP > > > > are tunneled to the MR. > > > > > > *extra* traffic. > > > > > > > What about inter-mixing statically configured MNP with BU > extensions > > > > or IGP? > > > > > > > > This is something that multi-protocol routers deal with since they > > were > > > > invented. Why is this such a special case? > > > > > > didnt follow the argument. my question is why add to > > > that? I see that you already have to deal with a lot > > > of mechanisms for adding routes. why add yet another > > > mechanism when it can used exclusive to the IGP over > > > the bi-directional tunnel. > > > > > > Vijay From nemo-admin@ietf.org Tue Jul 22 08:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11067 for ; Tue, 22 Jul 2003 08:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewFN-0004f1-7H; Tue, 22 Jul 2003 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewEo-0004ea-1a for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11049 for ; Tue, 22 Jul 2003 08:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewEm-00047H-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:27:24 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19ewEc-00047E-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:27:14 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6MCQk6q017822; Tue, 22 Jul 2003 05:26:46 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h6MCQcJA011839; Tue, 22 Jul 2003 07:26:40 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 340322EC86; Tue, 22 Jul 2003 14:26:38 +0200 (CEST) Message-ID: <3F1D2D7E.2040707@motorola.com> Date: Tue, 22 Jul 2003 14:26:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung Cc: "Pascal Thubert (pthubert)" , Vijay Devarapalli , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: IGP and MIP routes. References: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > The router will not "break" because it keeps track of the IGPs and > maintains the routing table properly as Pascal described. Routers > are built to deal with multiple IGPs. :) Pascal described a particular router. I have another router that begs to differ from Pascal's particular router. My router won't break either and figures out which routes are "mobile". But what of this breakingness can go in a spec if we don't say how exactly the break situations are avoided... Alex GBU From exim@www1.ietf.org Tue Jul 22 08:28:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11083 for ; Tue, 22 Jul 2003 08:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewFV-0004h4-EK for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MCS91f018036 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewFV-0004gp-8e for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 08:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11054 for ; Tue, 22 Jul 2003 08:28:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewFU-00047T-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:28:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ewFO-00047Q-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewFN-0004f1-7H; Tue, 22 Jul 2003 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewEo-0004ea-1a for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11049 for ; Tue, 22 Jul 2003 08:27:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewEm-00047H-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:27:24 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19ewEc-00047E-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:27:14 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6MCQk6q017822; Tue, 22 Jul 2003 05:26:46 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h6MCQcJA011839; Tue, 22 Jul 2003 07:26:40 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 340322EC86; Tue, 22 Jul 2003 14:26:38 +0200 (CEST) Message-ID: <3F1D2D7E.2040707@motorola.com> Date: Tue, 22 Jul 2003 14:26:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung Cc: "Pascal Thubert (pthubert)" , Vijay Devarapalli , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: IGP and MIP routes. References: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20030721182842.02b2e380@mira-sjcm-2.cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > The router will not "break" because it keeps track of the IGPs and > maintains the routing table properly as Pascal described. Routers > are built to deal with multiple IGPs. :) Pascal described a particular router. I have another router that begs to differ from Pascal's particular router. My router won't break either and figures out which routes are "mobile". But what of this breakingness can go in a spec if we don't say how exactly the break situations are avoided... Alex GBU From nemo-admin@ietf.org Tue Jul 22 08:39:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11281 for ; Tue, 22 Jul 2003 08:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewQ1-0005Ga-MK; Tue, 22 Jul 2003 08:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewPj-0005Fw-PV for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11239 for ; Tue, 22 Jul 2003 08:38:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewPi-0004AW-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:38:42 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ewPX-0004A7-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:38:31 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6MCZHS9020105; Tue, 22 Jul 2003 14:35:21 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 14:37:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: IGP and MIP routes. Date: Tue, 22 Jul 2003 13:37:16 +0100 Message-ID: Thread-Topic: [nemo] RE: IGP and MIP routes. Thread-Index: AcNQTKNl8KzyRUtWRdicvfPvDEF8WAAAEovQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Kent Leung (kleung)" Cc: "Vijay Devarapalli" , "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 12:37:17.0617 (UTC) FILETIME=[FC8AE210:01C3504D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 22 juillet 2003 14:27 > To: Kent Leung (kleung) > Cc: Pascal Thubert (pthubert); Vijay Devarapalli; S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: IGP and MIP routes. >=20 > Kent Leung wrote: > > The router will not "break" because it keeps track of the IGPs and > > maintains the routing table properly as Pascal described. Routers > > are built to deal with multiple IGPs. :) >=20 > Pascal described a particular router. I have another router that begs > to differ from Pascal's particular router. My router won't break either > and figures out which routes are "mobile". >=20 I had a life before cisco :) All routers implementations I've worked on, not only cisco, had a way to let the admin control which protocol would win in case of a tie. > But what of this breakingness can go in a spec if we don't say how > exactly the break situations are avoided... >=20 Agreed. We need to point out if it differs from traditional IGP to IGP arbitration. Otherwise, we'd better just say that Nemo basic explicit and implicit modes (here I mean implicit with a prefix table, not static routes or dynamic routing protocol) are just yet an other IGP and that should be administrable in a similar fashion as the other IGPs, which is implementation dependant. Pascal From exim@www1.ietf.org Tue Jul 22 08:39:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11296 for ; Tue, 22 Jul 2003 08:39:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewQ9-0005Jq-D5 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:39:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MCd9Xp020442 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 08:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewQ9-0005Jd-9L for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 08:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11261 for ; Tue, 22 Jul 2003 08:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewQ8-0004At-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:39:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ewQ2-0004Aq-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 08:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewQ1-0005Ga-MK; Tue, 22 Jul 2003 08:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewPj-0005Fw-PV for nemo@optimus.ietf.org; Tue, 22 Jul 2003 08:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11239 for ; Tue, 22 Jul 2003 08:38:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewPi-0004AW-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:38:42 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ewPX-0004A7-00 for nemo@ietf.org; Tue, 22 Jul 2003 08:38:31 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6MCZHS9020105; Tue, 22 Jul 2003 14:35:21 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 14:37:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: IGP and MIP routes. Date: Tue, 22 Jul 2003 13:37:16 +0100 Message-ID: Thread-Topic: [nemo] RE: IGP and MIP routes. Thread-Index: AcNQTKNl8KzyRUtWRdicvfPvDEF8WAAAEovQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Kent Leung (kleung)" Cc: "Vijay Devarapalli" , "S. Felix Wu" , X-OriginalArrivalTime: 22 Jul 2003 12:37:17.0617 (UTC) FILETIME=[FC8AE210:01C3504D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 22 juillet 2003 14:27 > To: Kent Leung (kleung) > Cc: Pascal Thubert (pthubert); Vijay Devarapalli; S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: IGP and MIP routes. >=20 > Kent Leung wrote: > > The router will not "break" because it keeps track of the IGPs and > > maintains the routing table properly as Pascal described. Routers > > are built to deal with multiple IGPs. :) >=20 > Pascal described a particular router. I have another router that begs > to differ from Pascal's particular router. My router won't break either > and figures out which routes are "mobile". >=20 I had a life before cisco :) All routers implementations I've worked on, not only cisco, had a way to let the admin control which protocol would win in case of a tie. > But what of this breakingness can go in a spec if we don't say how > exactly the break situations are avoided... >=20 Agreed. We need to point out if it differs from traditional IGP to IGP arbitration. Otherwise, we'd better just say that Nemo basic explicit and implicit modes (here I mean implicit with a prefix table, not static routes or dynamic routing protocol) are just yet an other IGP and that should be administrable in a similar fashion as the other IGPs, which is implementation dependant. Pascal From nemo-admin@ietf.org Tue Jul 22 09:06:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12094 for ; Tue, 22 Jul 2003 09:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewq9-00069E-Ir; Tue, 22 Jul 2003 09:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewpe-00068A-Vz for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:05:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12042 for ; Tue, 22 Jul 2003 09:05:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewpd-0004Oh-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:05:29 -0400 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 19ewpS-0004OB-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:05:18 -0400 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h6MD4l8s029245; Tue, 22 Jul 2003 16:04:56 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id PAA08894; Tue, 22 Jul 2003 15:31:30 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030722143157.00bf9a80@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jul 2003 15:31:30 +0300 To: Vijay Devarapalli , juhani.latvakoski@vtt.fi From: Pekka =?iso-8859-1?Q?Pääkkönen?= Cc: nemo@ietf.org In-Reply-To: <3F188D5D.A1EC79E2@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 17:14 18.7.2003 -0700, Vijay Devarapalli wrote: >hi Pekka and Juhani, > >this draft is a very good alternative to using DHCPv6 >for prefix delegation (however, I will let the WG decide >if we need an alternative to DHCPv6 for NEMO prefix >delegation). > >some comments > > > MNP Delegator Query (0) > > > > The MNP Delegator Query message is used by the MR to query MNP > > delegators (HAs) and their abilities to delegate MNP(s). This > > message is sent to MR's HA during the MNP Query sequence. > > > > > > MNP Delegator (4) > > > > A MNP Delegator message is sent by the HA during MNP Query > > sequence. It is used to inform MR of MNP(s) HA is capable of > > delegating. > >I suggest getting rid of these two messages. the HA can >always respond with MNP Unavailable in response to a >MNP Request message. do you need a query round before >the request? Actually the query sequence is optional, and the delegation sequence can be executed without the query sequence. IMHO the query sequence can be used in situations in which the MR first wants to query the capabilities of its HA for MNP delegation, and after that proceeds to MNP delegation sequence. Maybe this feature could be used in a situation in which the MR wants to query for multiple different MNPs and then select one MNP for delegation? > > 5.3.2 MNP Data Option > > > > MNP Data Option holds MNP information related to a single MNP. > > > > Option format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Preferred > lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Valid lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Prefix length | IPv6 prefix (16 octets) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > > | | > > | | > > | | > > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | Match | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >I dont think you need both a valid lifetime and preferred >lifetime field. in your examples in section 5.5 you always >set both lifetime fields to the same value :). here is a >new format with an alignment requirement of 8n+1 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Prefix Length | Match >| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + >+ > | | > + IPv6 Prefix + > | | > + + > | >| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I agree. > > After the MR has queried > > the capabilities of its HAs with this sequence, MR should advance to > > MNP Delegation sequence with the chosen HA to proceed with MNP > > delegation. > >this is clearly not needed. if the HA responds with MNP >Unavailable in case it cant delegate a prefix, you can >do the same in two round trips. OTOH if the HA can >delegate a prefix, you can have a prefix delegated in >just one round trip. See my first comment. > > If these checks are not valid, HA MUST silently ignore the message. >the HA should generate an ICMP error message instead of >silently dropping the message. You may be right. Do you have a specific existing ICMP error message in mind? >I just skimmed the rest of the draft. IMHO, you can get >rid of section 5.5. there isnt much in it. it would >make the draft shorter. > >Vijay Section 5.5 is just for illustration. It could be left out of the draft. Thanks for the comments. I think the bottom line about dynamic MNP delegation is this: DHCPv6 can be used in a NEMO environment. Do we need an alternative such as the one depicted in this draft? If people see a need for it then maybe this (or some other) solution should be developed further. Pekka From exim@www1.ietf.org Tue Jul 22 09:06:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12113 for ; Tue, 22 Jul 2003 09:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewqJ-0006EF-55 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MD6B6w023937 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewqJ-0006E0-1P for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 09:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12055 for ; Tue, 22 Jul 2003 09:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewqG-0004PD-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:06:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ewqA-0004PA-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewq9-00069E-Ir; Tue, 22 Jul 2003 09:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewpe-00068A-Vz for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:05:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12042 for ; Tue, 22 Jul 2003 09:05:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewpd-0004Oh-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:05:29 -0400 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 19ewpS-0004OB-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:05:18 -0400 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h6MD4l8s029245; Tue, 22 Jul 2003 16:04:56 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id PAA08894; Tue, 22 Jul 2003 15:31:30 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030722143157.00bf9a80@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jul 2003 15:31:30 +0300 To: Vijay Devarapalli , juhani.latvakoski@vtt.fi From: Pekka =?iso-8859-1?Q?Pääkkönen?= Cc: nemo@ietf.org In-Reply-To: <3F188D5D.A1EC79E2@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 17:14 18.7.2003 -0700, Vijay Devarapalli wrote: >hi Pekka and Juhani, > >this draft is a very good alternative to using DHCPv6 >for prefix delegation (however, I will let the WG decide >if we need an alternative to DHCPv6 for NEMO prefix >delegation). > >some comments > > > MNP Delegator Query (0) > > > > The MNP Delegator Query message is used by the MR to query MNP > > delegators (HAs) and their abilities to delegate MNP(s). This > > message is sent to MR's HA during the MNP Query sequence. > > > > > > MNP Delegator (4) > > > > A MNP Delegator message is sent by the HA during MNP Query > > sequence. It is used to inform MR of MNP(s) HA is capable of > > delegating. > >I suggest getting rid of these two messages. the HA can >always respond with MNP Unavailable in response to a >MNP Request message. do you need a query round before >the request? Actually the query sequence is optional, and the delegation sequence can be executed without the query sequence. IMHO the query sequence can be used in situations in which the MR first wants to query the capabilities of its HA for MNP delegation, and after that proceeds to MNP delegation sequence. Maybe this feature could be used in a situation in which the MR wants to query for multiple different MNPs and then select one MNP for delegation? > > 5.3.2 MNP Data Option > > > > MNP Data Option holds MNP information related to a single MNP. > > > > Option format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Preferred > lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Valid lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Prefix length | IPv6 prefix (16 octets) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > > | | > > | | > > | | > > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | Match | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >I dont think you need both a valid lifetime and preferred >lifetime field. in your examples in section 5.5 you always >set both lifetime fields to the same value :). here is a >new format with an alignment requirement of 8n+1 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Prefix Length | Match >| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + >+ > | | > + IPv6 Prefix + > | | > + + > | >| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I agree. > > After the MR has queried > > the capabilities of its HAs with this sequence, MR should advance to > > MNP Delegation sequence with the chosen HA to proceed with MNP > > delegation. > >this is clearly not needed. if the HA responds with MNP >Unavailable in case it cant delegate a prefix, you can >do the same in two round trips. OTOH if the HA can >delegate a prefix, you can have a prefix delegated in >just one round trip. See my first comment. > > If these checks are not valid, HA MUST silently ignore the message. >the HA should generate an ICMP error message instead of >silently dropping the message. You may be right. Do you have a specific existing ICMP error message in mind? >I just skimmed the rest of the draft. IMHO, you can get >rid of section 5.5. there isnt much in it. it would >make the draft shorter. > >Vijay Section 5.5 is just for illustration. It could be left out of the draft. Thanks for the comments. I think the bottom line about dynamic MNP delegation is this: DHCPv6 can be used in a NEMO environment. Do we need an alternative such as the one depicted in this draft? If people see a need for it then maybe this (or some other) solution should be developed further. Pekka From nemo-admin@ietf.org Tue Jul 22 09:36:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13061 for ; Tue, 22 Jul 2003 09:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exJB-0007Ei-Lz; Tue, 22 Jul 2003 09:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exIb-0007EJ-1c for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13012 for ; Tue, 22 Jul 2003 09:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exIZ-0004eJ-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:35:23 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19exIO-0004e1-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:35:12 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6MDYeK28579; Tue, 22 Jul 2003 15:34:41 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Pascal Thubert \(pthubert\)'" , "'Nicolas Montavont'" , "'Ryuji Wakikawa'" Cc: "'mobileip'" , Subject: AW: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Tue, 22 Jul 2003 15:34:39 +0200 Message-ID: <000601c35056$013e3750$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Pascal, Ryuji, Nicolas & others, We have also submitted a v6 draft related to your discussions recently. = We have been researching in this particular area in IPv4 for a long time = and=20 already have a IETF draft at, http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. Our new draft for the v6 is based on the experience we gained with the implementation of v4 draft. You can access this draft at our web-site (http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobileip= -fi lters-00.txt) until it gets added at the IETF list. In summary, this draft focuses on - Handling multiple CoAs even with single home address - Differentiation and distribution of IP flows among available points of = attachment It is compatible with Route Optimization, Hierarchical Mobile IP & multi-homing. Please give your comments on this as well. Kind regards Koojana -----Urspr=FCngliche Nachricht----- Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Pascal = Thubert (pthubert) Gesendet: Montag, 21. Juli 2003 20:32 An: Nicolas Montavont; Ryuji Wakikawa Cc: mobileip; nemo@ietf.org Betreff: [mobile-ip] RE: [nemo] multiple CoAs registration > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I believe we talked about that a lot already; there seems to be a consensus on using the home address to identify uniquely a registration, for checking and cleanup purposes. The IFID should not be used to that purpose, and a registration should be able to migrate interface on the MR side. If we do not find a valid usage for ifid (I have none in mind at the moment) then it should be dropped, shouldn't it? >=20 > > > > > > Pascal =20 From exim@www1.ietf.org Tue Jul 22 09:36:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13085 for ; Tue, 22 Jul 2003 09:36:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exJM-0007H1-2Z for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:36:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MDaCam027954 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exJL-0007Gn-Tn for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 09:36:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13050 for ; Tue, 22 Jul 2003 09:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exJK-0004et-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:36:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19exJE-0004eq-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exJB-0007Ei-Lz; Tue, 22 Jul 2003 09:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exIb-0007EJ-1c for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:35:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13012 for ; Tue, 22 Jul 2003 09:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exIZ-0004eJ-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:35:23 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19exIO-0004e1-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:35:12 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6MDYeK28579; Tue, 22 Jul 2003 15:34:41 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Pascal Thubert \(pthubert\)'" , "'Nicolas Montavont'" , "'Ryuji Wakikawa'" Cc: "'mobileip'" , Subject: AW: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Tue, 22 Jul 2003 15:34:39 +0200 Message-ID: <000601c35056$013e3750$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pascal, Ryuji, Nicolas & others, We have also submitted a v6 draft related to your discussions recently. = We have been researching in this particular area in IPv4 for a long time = and=20 already have a IETF draft at, http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. Our new draft for the v6 is based on the experience we gained with the implementation of v4 draft. You can access this draft at our web-site (http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobileip= -fi lters-00.txt) until it gets added at the IETF list. In summary, this draft focuses on - Handling multiple CoAs even with single home address - Differentiation and distribution of IP flows among available points of = attachment It is compatible with Route Optimization, Hierarchical Mobile IP & multi-homing. Please give your comments on this as well. Kind regards Koojana -----Urspr=FCngliche Nachricht----- Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Pascal = Thubert (pthubert) Gesendet: Montag, 21. Juli 2003 20:32 An: Nicolas Montavont; Ryuji Wakikawa Cc: mobileip; nemo@ietf.org Betreff: [mobile-ip] RE: [nemo] multiple CoAs registration > >> > >> - Why do you introduce the interface identification (IFID) ? It could > >>be sufficient to only register a CoA with the associated priority. > >>Therefore, when the MN has to choose the destination address for a HoA, > >>it can take the most preferred CoA, which is bound to the most preferred > >>interface of the MN. > >> > >> > > > >Priority can be changed by some reason during communication, but IFID > >can not be changed until MN want to change it. > > > Ok, I understand that. But what I mean is that I don't see the > requirement to have the IFID... In the Binding Cache, an entry could be > identified by both the Home address and the CoA. It is sufficient to > distinguish tow different entries. The priority field is then used to > choose the CoA, i.e. the interface. No need to have the IFID I guess. I believe we talked about that a lot already; there seems to be a consensus on using the home address to identify uniquely a registration, for checking and cleanup purposes. The IFID should not be used to that purpose, and a registration should be able to migrate interface on the MR side. If we do not find a valid usage for ifid (I have none in mind at the moment) then it should be dropped, shouldn't it? >=20 > > > > > > Pascal =20 From nemo-admin@ietf.org Tue Jul 22 09:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13377 for ; Tue, 22 Jul 2003 09:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exZd-0007r0-6s; Tue, 22 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exYl-0007qS-8o for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13355 for ; Tue, 22 Jul 2003 09:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exYj-0004lZ-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:52:05 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19exYY-0004lW-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:51:54 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MDpRnX003868; Tue, 22 Jul 2003 15:51:27 +0200 Message-ID: <3F1D3F85.6020202@dpt-info.u-strasbg.fr> Date: Tue, 22 Jul 2003 15:43:33 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Koojana Kuladinithi CC: "'Pascal Thubert (pthubert)'" , "'Ryuji Wakikawa'" , "'mobileip'" , nemo@ietf.org Subject: Re: AW: [mobile-ip] RE: [nemo] multiple CoAs registration References: <000601c35056$013e3750$989b6686@scoobydoo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h6MDpRnX003868 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, We're also working on this issue. We're just finishing an I-D quite=20 similar to your. It will be online tomorrow, I'll send an URL. Regards, Nicolas Koojana Kuladinithi wrote: >Hi Pascal, Ryuji, Nicolas & others, > >We have also submitted a v6 draft related to your discussions recently. = We >have been researching in this particular area in IPv4 for a long time an= d=20 >already have a IETF draft at, > >http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. > >Our new draft for the v6 is based on the experience we gained with the >implementation of v4 draft. You can access this draft at our web-site >(http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobilei= p-fi >lters-00.txt) until it gets added at the IETF list. > >In summary, this draft focuses on > >- Handling multiple CoAs even with single home address >- Differentiation and distribution of IP flows among available points of= =20 >attachment > >It is compatible with Route Optimization, Hierarchical Mobile IP & >multi-homing. > >Please give your comments on this as well. > >Kind regards > >Koojana > >-----Urspr=FCngliche Nachricht----- >Von: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Pascal Thube= rt >(pthubert) >Gesendet: Montag, 21. Juli 2003 20:32 >An: Nicolas Montavont; Ryuji Wakikawa >Cc: mobileip; nemo@ietf.org >Betreff: [mobile-ip] RE: [nemo] multiple CoAs registration > > =20 > >>>> - Why do you introduce the interface identification (IFID) ? It >>>> =20 >>>> >could > =20 > >>>>be sufficient to only register a CoA with the associated priority. >>>>Therefore, when the MN has to choose the destination address for a >>>> =20 >>>> >HoA, > =20 > >>>>it can take the most preferred CoA, which is bound to the most >>>> =20 >>>> >preferred > =20 > >>>>interface of the MN. >>>> >>>> >>>> =20 >>>> >>>Priority can be changed by some reason during communication, but IFID >>>can not be changed until MN want to change it. >>> >>> =20 >>> >>Ok, I understand that. But what I mean is that I don't see the >>requirement to have the IFID... In the Binding Cache, an entry could >> =20 >> >be > =20 > >>identified by both the Home address and the CoA. It is sufficient to >>distinguish tow different entries. The priority field is then used to >>choose the CoA, i.e. the interface. No need to have the IFID I guess. >> =20 >> > >I believe we talked about that a lot already; there seems to be a >consensus on using the home address to identify uniquely a registration, >for checking and cleanup purposes. The IFID should not be used to that >purpose, and a registration should be able to migrate interface on the >MR side. If we do not find a valid usage for ifid (I have none in mind >at the moment) then it should be dropped, shouldn't it? > > =20 > >>> >>> =20 >>> > >Pascal >=20 > > > =20 > From exim@www1.ietf.org Tue Jul 22 09:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13392 for ; Tue, 22 Jul 2003 09:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exZk-0007ry-N2 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:53:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MDr8dd030246 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 09:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exZk-0007rl-Ix for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 09:53:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13365 for ; Tue, 22 Jul 2003 09:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exZi-0004lo-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:53:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19exZd-0004ll-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 09:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exZd-0007r0-6s; Tue, 22 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19exYl-0007qS-8o for nemo@optimus.ietf.org; Tue, 22 Jul 2003 09:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13355 for ; Tue, 22 Jul 2003 09:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19exYj-0004lZ-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:52:05 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19exYY-0004lW-00 for nemo@ietf.org; Tue, 22 Jul 2003 09:51:54 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MDpRnX003868; Tue, 22 Jul 2003 15:51:27 +0200 Message-ID: <3F1D3F85.6020202@dpt-info.u-strasbg.fr> Date: Tue, 22 Jul 2003 15:43:33 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Koojana Kuladinithi CC: "'Pascal Thubert (pthubert)'" , "'Ryuji Wakikawa'" , "'mobileip'" , nemo@ietf.org Subject: Re: AW: [mobile-ip] RE: [nemo] multiple CoAs registration References: <000601c35056$013e3750$989b6686@scoobydoo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h6MDpRnX003868 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, We're also working on this issue. We're just finishing an I-D quite=20 similar to your. It will be online tomorrow, I'll send an URL. Regards, Nicolas Koojana Kuladinithi wrote: >Hi Pascal, Ryuji, Nicolas & others, > >We have also submitted a v6 draft related to your discussions recently. = We >have been researching in this particular area in IPv4 for a long time an= d=20 >already have a IETF draft at, > >http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. > >Our new draft for the v6 is based on the experience we gained with the >implementation of v4 draft. You can access this draft at our web-site >(http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobilei= p-fi >lters-00.txt) until it gets added at the IETF list. > >In summary, this draft focuses on > >- Handling multiple CoAs even with single home address >- Differentiation and distribution of IP flows among available points of= =20 >attachment > >It is compatible with Route Optimization, Hierarchical Mobile IP & >multi-homing. > >Please give your comments on this as well. > >Kind regards > >Koojana > >-----Urspr=FCngliche Nachricht----- >Von: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Pascal Thube= rt >(pthubert) >Gesendet: Montag, 21. Juli 2003 20:32 >An: Nicolas Montavont; Ryuji Wakikawa >Cc: mobileip; nemo@ietf.org >Betreff: [mobile-ip] RE: [nemo] multiple CoAs registration > > =20 > >>>> - Why do you introduce the interface identification (IFID) ? It >>>> =20 >>>> >could > =20 > >>>>be sufficient to only register a CoA with the associated priority. >>>>Therefore, when the MN has to choose the destination address for a >>>> =20 >>>> >HoA, > =20 > >>>>it can take the most preferred CoA, which is bound to the most >>>> =20 >>>> >preferred > =20 > >>>>interface of the MN. >>>> >>>> >>>> =20 >>>> >>>Priority can be changed by some reason during communication, but IFID >>>can not be changed until MN want to change it. >>> >>> =20 >>> >>Ok, I understand that. But what I mean is that I don't see the >>requirement to have the IFID... In the Binding Cache, an entry could >> =20 >> >be > =20 > >>identified by both the Home address and the CoA. It is sufficient to >>distinguish tow different entries. The priority field is then used to >>choose the CoA, i.e. the interface. No need to have the IFID I guess. >> =20 >> > >I believe we talked about that a lot already; there seems to be a >consensus on using the home address to identify uniquely a registration, >for checking and cleanup purposes. The IFID should not be used to that >purpose, and a registration should be able to migrate interface on the >MR side. If we do not find a valid usage for ifid (I have none in mind >at the moment) then it should be dropped, shouldn't it? > > =20 > >>> >>> =20 >>> > >Pascal >=20 > > > =20 > From nemo-admin@ietf.org Tue Jul 22 13:36:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20507 for ; Tue, 22 Jul 2003 13:36:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f13R-0008P5-Sh; Tue, 22 Jul 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f139-0008Of-C5 for nemo@optimus.ietf.org; Tue, 22 Jul 2003 13:35:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20472 for ; Tue, 22 Jul 2003 13:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f137-00069f-00 for nemo@ietf.org; Tue, 22 Jul 2003 13:35:41 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f12w-00068o-00 for nemo@ietf.org; Tue, 22 Jul 2003 13:35:30 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA23144; Tue, 22 Jul 2003 10:34:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6MHY0U13145; Tue, 22 Jul 2003 10:34:00 -0700 X-mProtect: <200307221734> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.184, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5yENRT; Tue, 22 Jul 2003 10:33:57 PDT Message-ID: <3F1D7584.3030700@iprg.nokia.com> Date: Tue, 22 Jul 2003 10:33:56 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng CC: IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: <1058857818.28106.31.camel@beethoven> In-Reply-To: <1058857818.28106.31.camel@beethoven> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > * (0,0,0): Single MR, Single HA, Single Prefix > > - No major issue > > > * (0,0,1): Single MR, Single HA, Multiple Prefixes > > - No Major issues > > > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? I think this should be a MUST for a single Prefix. > > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? yes. > > * (1,0,0): Multiple MRs, Single HA, Single Prefix > > - No major issues > > > * (1,0,1): Multiple MRs, Single HA, Multiple Prefixes > > - No major issues > > > * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? yes. > > * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? yes. Vijay From exim@www1.ietf.org Tue Jul 22 13:36:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20522 for ; Tue, 22 Jul 2003 13:36:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f13h-0008RF-5Q for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 13:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHaH0G032436 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 13:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f13h-0008R4-1w for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 13:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20482 for ; Tue, 22 Jul 2003 13:36:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f13f-00069y-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 13:36:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f13Z-00069v-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 13:36:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f13R-0008P5-Sh; Tue, 22 Jul 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f139-0008Of-C5 for nemo@optimus.ietf.org; Tue, 22 Jul 2003 13:35:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20472 for ; Tue, 22 Jul 2003 13:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f137-00069f-00 for nemo@ietf.org; Tue, 22 Jul 2003 13:35:41 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f12w-00068o-00 for nemo@ietf.org; Tue, 22 Jul 2003 13:35:30 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA23144; Tue, 22 Jul 2003 10:34:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6MHY0U13145; Tue, 22 Jul 2003 10:34:00 -0700 X-mProtect: <200307221734> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.184, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5yENRT; Tue, 22 Jul 2003 10:33:57 PDT Message-ID: <3F1D7584.3030700@iprg.nokia.com> Date: Tue, 22 Jul 2003 10:33:56 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng CC: IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: <1058857818.28106.31.camel@beethoven> In-Reply-To: <1058857818.28106.31.camel@beethoven> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > * (0,0,0): Single MR, Single HA, Single Prefix > > - No major issue > > > * (0,0,1): Single MR, Single HA, Multiple Prefixes > > - No Major issues > > > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? I think this should be a MUST for a single Prefix. > > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? yes. > > * (1,0,0): Multiple MRs, Single HA, Single Prefix > > - No major issues > > > * (1,0,1): Multiple MRs, Single HA, Multiple Prefixes > > - No major issues > > > * (1,1,0): Multiple MRs, Multiple HAs, Single Prefix > > - Do we support only the case where every HA belongs to the same > administrative domain? yes. > > * (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes > > - Do we restrict ourselves to only the case where each prefix is only > registered to HA within the same domain? yes. Vijay From nemo-admin@ietf.org Tue Jul 22 16:50:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26399 for ; Tue, 22 Jul 2003 16:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f45B-0000Fs-0H; Tue, 22 Jul 2003 16:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f44o-0000FB-Eo for nemo@optimus.ietf.org; Tue, 22 Jul 2003 16:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26352 for ; Tue, 22 Jul 2003 16:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f44m-0007L1-00 for nemo@ietf.org; Tue, 22 Jul 2003 16:49:36 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f44b-0007Kg-00 for nemo@ietf.org; Tue, 22 Jul 2003 16:49:25 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA03569; Tue, 22 Jul 2003 13:48:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6MKm8s00514; Tue, 22 Jul 2003 13:48:08 -0700 X-mProtect: <200307222048> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9xdaAq; Tue, 22 Jul 2003 13:48:07 PDT Message-ID: <3F1DA307.E0119078@iprg.nokia.com> Date: Tue, 22 Jul 2003 13:48:07 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka P??kk?nen CC: juhani.latvakoski@vtt.fi, nemo@ietf.org References: <4.3.2.7.2.20030722143157.00bf9a80@elemail.ele.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pekka P??kk?nen wrote: > > > > > > MNP Delegator Query (0) > > > > > > The MNP Delegator Query message is used by the MR to query MNP > > > delegators (HAs) and their abilities to delegate MNP(s). This > > > message is sent to MR's HA during the MNP Query sequence. > > > > > > > > > MNP Delegator (4) > > > > > > A MNP Delegator message is sent by the HA during MNP Query > > > sequence. It is used to inform MR of MNP(s) HA is capable of > > > delegating. > > > >I suggest getting rid of these two messages. the HA can > >always respond with MNP Unavailable in response to a > >MNP Request message. do you need a query round before > >the request? > > Actually the query sequence is optional, and the delegation sequence > can be executed without the query sequence. I didnt get that reading the draft. > IMHO the query sequence can be used in situations in which the MR > first wants to query the capabilities of its HA for MNP delegation, and > after that proceeds to MNP delegation sequence. if there is a significant delay between the query and request, then the earlier query might not be useful at all. the MR needs to know if the HA can delegate a prefix right now. not sometime back. > Maybe this feature could be used in a situation in which the MR > wants to query for multiple different MNPs and then select one MNP for > delegation? I am not sure I understood. > > > If these checks are not valid, HA MUST silently ignore the message. > >the HA should generate an ICMP error message instead of > >silently dropping the message. > > You may be right. Do you have a specific existing ICMP error message in mind? ICMP error message with the ICMP code set to different values based on what caused the HA to drop the packet. > DHCPv6 can be used in a NEMO environment. Do we need an alternative such as > the > one depicted in this draft? If people see a need for it then maybe this (or > some other) solution > should be developed further. I dont have an answer to this question. the WG needs to decide on this. Erik is right in saying > Working on solutions for mobile networks is time better spent it is upto you to convince the WG. Vijay From exim@www1.ietf.org Tue Jul 22 16:51:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26434 for ; Tue, 22 Jul 2003 16:51:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f45i-0000LR-AP for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 16:50:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MKoY9b001321 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 16:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f45i-0000LE-5s for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 16:50:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26400 for ; Tue, 22 Jul 2003 16:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f45B-0000Fs-0H; Tue, 22 Jul 2003 16:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f44o-0000FB-Eo for nemo@optimus.ietf.org; Tue, 22 Jul 2003 16:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26352 for ; Tue, 22 Jul 2003 16:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f44m-0007L1-00 for nemo@ietf.org; Tue, 22 Jul 2003 16:49:36 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f44b-0007Kg-00 for nemo@ietf.org; Tue, 22 Jul 2003 16:49:25 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA03569; Tue, 22 Jul 2003 13:48:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6MKm8s00514; Tue, 22 Jul 2003 13:48:08 -0700 X-mProtect: <200307222048> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9xdaAq; Tue, 22 Jul 2003 13:48:07 PDT Message-ID: <3F1DA307.E0119078@iprg.nokia.com> Date: Tue, 22 Jul 2003 13:48:07 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka P??kk?nen CC: juhani.latvakoski@vtt.fi, nemo@ietf.org References: <4.3.2.7.2.20030722143157.00bf9a80@elemail.ele.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: comments on draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka P??kk?nen wrote: > > > > > > MNP Delegator Query (0) > > > > > > The MNP Delegator Query message is used by the MR to query MNP > > > delegators (HAs) and their abilities to delegate MNP(s). This > > > message is sent to MR's HA during the MNP Query sequence. > > > > > > > > > MNP Delegator (4) > > > > > > A MNP Delegator message is sent by the HA during MNP Query > > > sequence. It is used to inform MR of MNP(s) HA is capable of > > > delegating. > > > >I suggest getting rid of these two messages. the HA can > >always respond with MNP Unavailable in response to a > >MNP Request message. do you need a query round before > >the request? > > Actually the query sequence is optional, and the delegation sequence > can be executed without the query sequence. I didnt get that reading the draft. > IMHO the query sequence can be used in situations in which the MR > first wants to query the capabilities of its HA for MNP delegation, and > after that proceeds to MNP delegation sequence. if there is a significant delay between the query and request, then the earlier query might not be useful at all. the MR needs to know if the HA can delegate a prefix right now. not sometime back. > Maybe this feature could be used in a situation in which the MR > wants to query for multiple different MNPs and then select one MNP for > delegation? I am not sure I understood. > > > If these checks are not valid, HA MUST silently ignore the message. > >the HA should generate an ICMP error message instead of > >silently dropping the message. > > You may be right. Do you have a specific existing ICMP error message in mind? ICMP error message with the ICMP code set to different values based on what caused the HA to drop the packet. > DHCPv6 can be used in a NEMO environment. Do we need an alternative such as > the > one depicted in this draft? If people see a need for it then maybe this (or > some other) solution > should be developed further. I dont have an answer to this question. the WG needs to decide on this. Erik is right in saying > Working on solutions for mobile networks is time better spent it is upto you to convince the WG. Vijay From nemo-admin@ietf.org Tue Jul 22 17:04:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26836 for ; Tue, 22 Jul 2003 17:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Ij-0000lP-91; Tue, 22 Jul 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4IY-0000kc-OR for nemo@optimus.ietf.org; Tue, 22 Jul 2003 17:03:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26827 for ; Tue, 22 Jul 2003 17:03:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4IW-0007PM-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:03:48 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f4IL-0007Oy-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:03:37 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04272; Tue, 22 Jul 2003 14:02:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ML2wc18437; Tue, 22 Jul 2003 14:02:58 -0700 X-mProtect: <200307222102> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYa7q8B; Tue, 22 Jul 2003 14:02:57 PDT Message-ID: <3F1DA681.D3E5B6C3@iprg.nokia.com> Date: Tue, 22 Jul 2003 14:02:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: "'Kent Leung'" , "'S. Felix Wu'" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <000001c35042$4036c260$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jongkeun and others, there are few things mixed up here... implicit mode is where the MR assumes the HA knows how to figure out the MNP and add routes. the prefix table is a MUST if an IGP is not used over the bi-directional tunnel. if an IGP is not being used, and also the prefix table contains no entries for the MR, then the HA returns a Binding Ack with status code 143 (Mobile Network Prefix information unavailable). the prefix table is not needed in case the MR and HA are exchanging routes using an IGP. we assume the MR can prove ownership of prefixes using the IGP. the prefix table is also used in explicit mode, if the HA needs to prevent a misbehaving mobile router from claiming MNPs belonging to another mobile router. Vijay Jongkeun Na wrote: > > Hello Vijay and all, > > I want to clarify again my point about issue 6 because I firstly raised > this issue. > First I've pointed that the basic support protocol doesn't properly work > in case of implicit mode BU and dynamic routing protocol assumed. In the > case that prefix table not properly pre-configurated, HA will reply BACK > error for BU of implicit mode according to last paragraph of section > 6.6. I guess this case should be considered as the following choices > which we can do now. > 1) Section 6.6 last paragraph additionally describes this case. Already > that commented by Ryuji about using new flag field in the entry of > prefix table. The administrator of HA should mark new field in the entry > mapped with HoA of MR for indicating that the MNP will be set and > managed by any other mechanism e.g. dynamic routing protocol. Therefore, > HA will not send BACK error for implicit mode BU if new flag is set. > 2) It should be described in somewhere that MNP allowed to MR should be > set in prefix table by the administration regardless of dynamic routing > protocol used through HA-MR tunnel. And, if the implicit mode allowed > then prefix table must be managed by HA, that must be not optional in > that case. In other words, there is a need to clarify the dependence > between use of implicit mode and usage of prefix table. And, in this > case of using dynamic routing protocol, I think specifying of MNP in > prefix table is redundant. > > Am I missing something of this thread? Please correct me. > Otherwise, please consider above cases. > > /jongkeun > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Vijay > > Devarapalli > > Sent: Friday, July 18, 2003 7:59 AM > > To: Kent Leung > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > Kent Leung wrote: > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > >tight and exact. I dont see why would need both for the same > > > >prefix. > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > same prefix, which may not be always the case. > > > > > > >Vijay Devarapalli wrote: > > > When the Mobile Router and the Home Agent exchange routes > > > through routing protocol updates, the Home Agent MUST NOT > > > create routes to the Mobile network when the Binding Update > > > from the Mobile Router is received. The Mobile Router also > > > MUST NOT include any prefix information in the Binding Update. > > > Any routes to the Mobile Network are created at the Home > > > Agent through routing protocol updates. > > > > this was proposed a few days back. the latest > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > >updates carry different prefixes, i.e. if the MR uses a > > > >Binding Update to have the HA create routes for a certain > > > >perfix and it uses a routing protocol update for creating > > > >routes for a different prefix. > > > > > > Yes, the original text was exclusive in which method was used to > > > update the HA. Still I don't agree there needs to be any additional > > > checks. Again, what is the harm? > > > > what is the need? I dont see any. > > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > > *extra* traffic. > > > > > What about inter-mixing statically configured MNP with BU extensions > > > or IGP? > > > > > > This is something that multi-protocol routers deal with since they > were > > > invented. Why is this such a special case? > > > > didnt follow the argument. my question is why add to > > that? I see that you already have to deal with a lot > > of mechanisms for adding routes. why add yet another > > mechanism when it can used exclusive to the IGP over > > the bi-directional tunnel. > > > > Vijay From exim@www1.ietf.org Tue Jul 22 17:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26853 for ; Tue, 22 Jul 2003 17:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Is-0000oO-HZ for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 17:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ML4AKx003115 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 17:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Ir-0000oA-0a for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 17:04:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26831 for ; Tue, 22 Jul 2003 17:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4Io-0007PX-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 17:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f4Ij-0007PU-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 17:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Ij-0000lP-91; Tue, 22 Jul 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4IY-0000kc-OR for nemo@optimus.ietf.org; Tue, 22 Jul 2003 17:03:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26827 for ; Tue, 22 Jul 2003 17:03:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4IW-0007PM-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:03:48 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f4IL-0007Oy-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:03:37 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04272; Tue, 22 Jul 2003 14:02:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ML2wc18437; Tue, 22 Jul 2003 14:02:58 -0700 X-mProtect: <200307222102> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYa7q8B; Tue, 22 Jul 2003 14:02:57 PDT Message-ID: <3F1DA681.D3E5B6C3@iprg.nokia.com> Date: Tue, 22 Jul 2003 14:02:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: "'Kent Leung'" , "'S. Felix Wu'" , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <000001c35042$4036c260$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jongkeun and others, there are few things mixed up here... implicit mode is where the MR assumes the HA knows how to figure out the MNP and add routes. the prefix table is a MUST if an IGP is not used over the bi-directional tunnel. if an IGP is not being used, and also the prefix table contains no entries for the MR, then the HA returns a Binding Ack with status code 143 (Mobile Network Prefix information unavailable). the prefix table is not needed in case the MR and HA are exchanging routes using an IGP. we assume the MR can prove ownership of prefixes using the IGP. the prefix table is also used in explicit mode, if the HA needs to prevent a misbehaving mobile router from claiming MNPs belonging to another mobile router. Vijay Jongkeun Na wrote: > > Hello Vijay and all, > > I want to clarify again my point about issue 6 because I firstly raised > this issue. > First I've pointed that the basic support protocol doesn't properly work > in case of implicit mode BU and dynamic routing protocol assumed. In the > case that prefix table not properly pre-configurated, HA will reply BACK > error for BU of implicit mode according to last paragraph of section > 6.6. I guess this case should be considered as the following choices > which we can do now. > 1) Section 6.6 last paragraph additionally describes this case. Already > that commented by Ryuji about using new flag field in the entry of > prefix table. The administrator of HA should mark new field in the entry > mapped with HoA of MR for indicating that the MNP will be set and > managed by any other mechanism e.g. dynamic routing protocol. Therefore, > HA will not send BACK error for implicit mode BU if new flag is set. > 2) It should be described in somewhere that MNP allowed to MR should be > set in prefix table by the administration regardless of dynamic routing > protocol used through HA-MR tunnel. And, if the implicit mode allowed > then prefix table must be managed by HA, that must be not optional in > that case. In other words, there is a need to clarify the dependence > between use of implicit mode and usage of prefix table. And, in this > case of using dynamic routing protocol, I think specifying of MNP in > prefix table is redundant. > > Am I missing something of this thread? Please correct me. > Otherwise, please consider above cases. > > /jongkeun > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Vijay > > Devarapalli > > Sent: Friday, July 18, 2003 7:59 AM > > To: Kent Leung > > Cc: S. Felix Wu; pthubert@cisco.com; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > Kent Leung wrote: > > > > > > > > >I dont buy this argument. a protocol specification has to be > > > >tight and exact. I dont see why would need both for the same > > > >prefix. > > > > > > Hmm. Original text issue is below. Not sure if you are assuming > > > same prefix, which may not be always the case. > > > > > > >Vijay Devarapalli wrote: > > > When the Mobile Router and the Home Agent exchange routes > > > through routing protocol updates, the Home Agent MUST NOT > > > create routes to the Mobile network when the Binding Update > > > from the Mobile Router is received. The Mobile Router also > > > MUST NOT include any prefix information in the Binding Update. > > > Any routes to the Mobile Network are created at the Home > > > Agent through routing protocol updates. > > > > this was proposed a few days back. the latest > > discussion is at http://people.nokia.net/vijayd/nemo/issue6.txt. > > > > > >I disagree characterising this as an "config/operation" issue. > > > > > > > >I would agree if the Binding Updates and Routing Protocol > > > >updates carry different prefixes, i.e. if the MR uses a > > > >Binding Update to have the HA create routes for a certain > > > >perfix and it uses a routing protocol update for creating > > > >routes for a different prefix. > > > > > > Yes, the original text was exclusive in which method was used to > > > update the HA. Still I don't agree there needs to be any additional > > > checks. Again, what is the harm? > > > > what is the need? I dont see any. > > > > > The result is still traffic to MNP > > > are tunneled to the MR. > > > > *extra* traffic. > > > > > What about inter-mixing statically configured MNP with BU extensions > > > or IGP? > > > > > > This is something that multi-protocol routers deal with since they > were > > > invented. Why is this such a special case? > > > > didnt follow the argument. my question is why add to > > that? I see that you already have to deal with a lot > > of mechanisms for adding routes. why add yet another > > mechanism when it can used exclusive to the IGP over > > the bi-directional tunnel. > > > > Vijay From nemo-admin@ietf.org Tue Jul 22 17:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26962 for ; Tue, 22 Jul 2003 17:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4NY-0001Em-TA; Tue, 22 Jul 2003 17:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Mt-00018K-4r for nemo@optimus.ietf.org; Tue, 22 Jul 2003 17:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26938 for ; Tue, 22 Jul 2003 17:08:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4Mq-0007QI-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:08:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f4Mf-0007QB-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:08:06 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04515; Tue, 22 Jul 2003 14:07:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ML7U925212; Tue, 22 Jul 2003 14:07:30 -0700 X-mProtect: <200307222107> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWbTIaT; Tue, 22 Jul 2003 14:07:27 PDT Message-ID: <3F1DA78F.79B6143D@iprg.nokia.com> Date: Tue, 22 Jul 2003 14:07:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > Can't we just drop code 143 and accept the implicit whatever? > > There are at least 3 cases of implicit with different problems > associated: > > - static route: HA could check for a static route but it does not > control it. The admin may change it. Should we drop the binding then? > - prefix table: source of our recent discussion on how it compares with > other IGPs > - dynamic route: HA does not have the associated routes yet. No clue if > there will eventually be one? Should we drop the binding if none come > up? > > You see code 143 is tricky to use for not much added value. Sugestion, > get rid of the last paragraph and if the code. In implicit mode, the HA > does its best and that's it. I disagree. it is always good to have an error message if something goes wrong. the MR shouldnt assume the HA has setup forwarding for the Mobile Network, when the HA actually didnt. the MR has now way of figuring out whats wrong, if packets from the CN to MNNs are dropped at the HA. From exim@www1.ietf.org Tue Jul 22 17:09:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26977 for ; Tue, 22 Jul 2003 17:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Nf-0001Hs-KC for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 17:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ML97U1004943 for nemo-archive@odin.ietf.org; Tue, 22 Jul 2003 17:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Nf-0001He-GK for nemo-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 17:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26956 for ; Tue, 22 Jul 2003 17:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4Nd-0007QV-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 17:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f4NX-0007QS-00 for nemo-web-archive@ietf.org; Tue, 22 Jul 2003 17:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4NY-0001Em-TA; Tue, 22 Jul 2003 17:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f4Mt-00018K-4r for nemo@optimus.ietf.org; Tue, 22 Jul 2003 17:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26938 for ; Tue, 22 Jul 2003 17:08:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f4Mq-0007QI-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:08:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19f4Mf-0007QB-00 for nemo@ietf.org; Tue, 22 Jul 2003 17:08:06 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04515; Tue, 22 Jul 2003 14:07:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ML7U925212; Tue, 22 Jul 2003 14:07:30 -0700 X-mProtect: <200307222107> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWbTIaT; Tue, 22 Jul 2003 14:07:27 PDT Message-ID: <3F1DA78F.79B6143D@iprg.nokia.com> Date: Tue, 22 Jul 2003 14:07:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > Can't we just drop code 143 and accept the implicit whatever? > > There are at least 3 cases of implicit with different problems > associated: > > - static route: HA could check for a static route but it does not > control it. The admin may change it. Should we drop the binding then? > - prefix table: source of our recent discussion on how it compares with > other IGPs > - dynamic route: HA does not have the associated routes yet. No clue if > there will eventually be one? Should we drop the binding if none come > up? > > You see code 143 is tricky to use for not much added value. Sugestion, > get rid of the last paragraph and if the code. In implicit mode, the HA > does its best and that's it. I disagree. it is always good to have an error message if something goes wrong. the MR shouldnt assume the HA has setup forwarding for the Mobile Network, when the HA actually didnt. the MR has now way of figuring out whats wrong, if packets from the CN to MNNs are dropped at the HA. From nemo-admin@ietf.org Wed Jul 23 04:27:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05683 for ; Wed, 23 Jul 2003 04:27:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fExh-0007nr-D1; Wed, 23 Jul 2003 04:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fExD-0007nM-OM for nemo@optimus.ietf.org; Wed, 23 Jul 2003 04:26:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05656 for ; Wed, 23 Jul 2003 04:26:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fExA-00033K-00 for nemo@ietf.org; Wed, 23 Jul 2003 04:26:29 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fEx0-00032h-00 for nemo@ietf.org; Wed, 23 Jul 2003 04:26:18 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6N8La39018275; Wed, 23 Jul 2003 10:21:37 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 10:23:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Wed, 23 Jul 2003 09:23:32 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQlYJlaCSi+hksQm+pSRZ+WMKnrwAXUdaQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 23 Jul 2003 08:23:32.0753 (UTC) FILETIME=[B43AC010:01C350F3] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 22 juillet 2003 23:07 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > Can't we just drop code 143 and accept the implicit whatever? > > > > There are at least 3 cases of implicit with different problems > > associated: > > > > - static route: HA could check for a static route but it does not > > control it. The admin may change it. Should we drop the binding then? > > - prefix table: source of our recent discussion on how it compares with > > other IGPs > > - dynamic route: HA does not have the associated routes yet. No clue if > > there will eventually be one? Should we drop the binding if none come > > up? > > > > You see code 143 is tricky to use for not much added value. Sugestion, > > get rid of the last paragraph and if the code. In implicit mode, the HA > > does its best and that's it. >=20 > I disagree. it is always good to have an error message > if something goes wrong. the MR shouldnt assume the HA > has setup forwarding for the Mobile Network, when the > HA actually didnt. the MR has now way of figuring out > whats wrong, if packets from the CN to MNNs are dropped > at the HA. Then you do not want implicit mode at all. Because even if the HA has some prefixes listed for that MR in its prefix table, the may not be correct, or complete. Unless the HA lists the prefixes it knows of in the B-Ack. Again I'm talking about the real implicit, the one with prefix table, as opposed to static routes or IGP over MRHA. Consequence, if you want full checking, you need implicit, plus the list of accepted prefixes in the B-Ack if not all. In the latter case, (IGP over MRHA) the HA can not know at B-Ack time whether it will ever get the right routes, or whether the MR will try anything. So the code 143 is straight infeasible. Pascal From exim@www1.ietf.org Wed Jul 23 04:27:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05701 for ; Wed, 23 Jul 2003 04:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEy3-0007qC-KB for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 04:27:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N8RNeM030134 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 04:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEy2-0007px-R2 for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 04:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05680 for ; Wed, 23 Jul 2003 04:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fEy0-00033z-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 04:27:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fExu-00033s-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 04:27:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fExh-0007nr-D1; Wed, 23 Jul 2003 04:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fExD-0007nM-OM for nemo@optimus.ietf.org; Wed, 23 Jul 2003 04:26:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05656 for ; Wed, 23 Jul 2003 04:26:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fExA-00033K-00 for nemo@ietf.org; Wed, 23 Jul 2003 04:26:29 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fEx0-00032h-00 for nemo@ietf.org; Wed, 23 Jul 2003 04:26:18 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6N8La39018275; Wed, 23 Jul 2003 10:21:37 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 10:23:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Wed, 23 Jul 2003 09:23:32 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQlYJlaCSi+hksQm+pSRZ+WMKnrwAXUdaQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 23 Jul 2003 08:23:32.0753 (UTC) FILETIME=[B43AC010:01C350F3] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 22 juillet 2003 23:07 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > Can't we just drop code 143 and accept the implicit whatever? > > > > There are at least 3 cases of implicit with different problems > > associated: > > > > - static route: HA could check for a static route but it does not > > control it. The admin may change it. Should we drop the binding then? > > - prefix table: source of our recent discussion on how it compares with > > other IGPs > > - dynamic route: HA does not have the associated routes yet. No clue if > > there will eventually be one? Should we drop the binding if none come > > up? > > > > You see code 143 is tricky to use for not much added value. Sugestion, > > get rid of the last paragraph and if the code. In implicit mode, the HA > > does its best and that's it. >=20 > I disagree. it is always good to have an error message > if something goes wrong. the MR shouldnt assume the HA > has setup forwarding for the Mobile Network, when the > HA actually didnt. the MR has now way of figuring out > whats wrong, if packets from the CN to MNNs are dropped > at the HA. Then you do not want implicit mode at all. Because even if the HA has some prefixes listed for that MR in its prefix table, the may not be correct, or complete. Unless the HA lists the prefixes it knows of in the B-Ack. Again I'm talking about the real implicit, the one with prefix table, as opposed to static routes or IGP over MRHA. Consequence, if you want full checking, you need implicit, plus the list of accepted prefixes in the B-Ack if not all. In the latter case, (IGP over MRHA) the HA can not know at B-Ack time whether it will ever get the right routes, or whether the MR will try anything. So the code 143 is straight infeasible. Pascal From nemo-admin@ietf.org Wed Jul 23 05:18:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06677 for ; Wed, 23 Jul 2003 05:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFl3-0001Sd-1N; Wed, 23 Jul 2003 05:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFkw-0001Ru-Lf for nemo@optimus.ietf.org; Wed, 23 Jul 2003 05:17:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06660 for ; Wed, 23 Jul 2003 05:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFkt-0003UF-00 for nemo@ietf.org; Wed, 23 Jul 2003 05:17:51 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fFki-0003U1-00 for nemo@ietf.org; Wed, 23 Jul 2003 05:17:40 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6N9EoPW029570 for ; Wed, 23 Jul 2003 11:14:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 11:16:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] RE: Issue 6 Date: Wed, 23 Jul 2003 10:16:56 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQlYJlaCSi+hksQm+pSRZ+WMKnrwAXUdaQAAILEMA= From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 23 Jul 2003 09:16:56.0477 (UTC) FILETIME=[29CC3CD0:01C350FB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Typo there: I meant=20 >=20 > Consequence, if you want full checking, you need EXplicit, plus the list > of accepted prefixes in the B-Ack if not all. Sorry Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mercredi 23 juillet 2003 10:24 > To: Vijay Devarapalli > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 >=20 >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: mardi 22 juillet 2003 23:07 > > To: Pascal Thubert (pthubert) > > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > Can't we just drop code 143 and accept the implicit whatever? > > > > > > There are at least 3 cases of implicit with different problems > > > associated: > > > > > > - static route: HA could check for a static route but it does not > > > control it. The admin may change it. Should we drop the binding > then? > > > - prefix table: source of our recent discussion on how it compares > with > > > other IGPs > > > - dynamic route: HA does not have the associated routes yet. No clue > if > > > there will eventually be one? Should we drop the binding if none > come > > > up? > > > > > > You see code 143 is tricky to use for not much added value. > Sugestion, > > > get rid of the last paragraph and if the code. In implicit mode, the > HA > > > does its best and that's it. > > > > I disagree. it is always good to have an error message > > if something goes wrong. the MR shouldnt assume the HA > > has setup forwarding for the Mobile Network, when the > > HA actually didnt. the MR has now way of figuring out > > whats wrong, if packets from the CN to MNNs are dropped > > at the HA. >=20 >=20 > Then you do not want implicit mode at all. Because even if the HA has > some prefixes listed for that MR in its prefix table, the may not be > correct, or complete. Unless the HA lists the prefixes it knows of in > the B-Ack. Again I'm talking about the real implicit, the one with > prefix table, as opposed to static routes or IGP over MRHA. >=20 > Consequence, if you want full checking, you need implicit, plus the list > of accepted prefixes in the B-Ack if not all. >=20 > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > whether it will ever get the right routes, or whether the MR will try > anything. So the code 143 is straight infeasible. >=20 > Pascal From exim@www1.ietf.org Wed Jul 23 05:18:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06693 for ; Wed, 23 Jul 2003 05:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFlB-0001Tc-Hh for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 05:18:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N9I9GM005675 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 05:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFlB-0001TS-9L for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 05:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06667 for ; Wed, 23 Jul 2003 05:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFl8-0003US-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 05:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fFl2-0003UP-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 05:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFl3-0001Sd-1N; Wed, 23 Jul 2003 05:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFkw-0001Ru-Lf for nemo@optimus.ietf.org; Wed, 23 Jul 2003 05:17:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06660 for ; Wed, 23 Jul 2003 05:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFkt-0003UF-00 for nemo@ietf.org; Wed, 23 Jul 2003 05:17:51 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fFki-0003U1-00 for nemo@ietf.org; Wed, 23 Jul 2003 05:17:40 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6N9EoPW029570 for ; Wed, 23 Jul 2003 11:14:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 11:16:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] RE: Issue 6 Date: Wed, 23 Jul 2003 10:16:56 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNQlYJlaCSi+hksQm+pSRZ+WMKnrwAXUdaQAAILEMA= From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 23 Jul 2003 09:16:56.0477 (UTC) FILETIME=[29CC3CD0:01C350FB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Typo there: I meant=20 >=20 > Consequence, if you want full checking, you need EXplicit, plus the list > of accepted prefixes in the B-Ack if not all. Sorry Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mercredi 23 juillet 2003 10:24 > To: Vijay Devarapalli > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: RE: [nemo] RE: Issue 6 >=20 >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: mardi 22 juillet 2003 23:07 > > To: Pascal Thubert (pthubert) > > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > > Subject: Re: [nemo] RE: Issue 6 > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > Can't we just drop code 143 and accept the implicit whatever? > > > > > > There are at least 3 cases of implicit with different problems > > > associated: > > > > > > - static route: HA could check for a static route but it does not > > > control it. The admin may change it. Should we drop the binding > then? > > > - prefix table: source of our recent discussion on how it compares > with > > > other IGPs > > > - dynamic route: HA does not have the associated routes yet. No clue > if > > > there will eventually be one? Should we drop the binding if none > come > > > up? > > > > > > You see code 143 is tricky to use for not much added value. > Sugestion, > > > get rid of the last paragraph and if the code. In implicit mode, the > HA > > > does its best and that's it. > > > > I disagree. it is always good to have an error message > > if something goes wrong. the MR shouldnt assume the HA > > has setup forwarding for the Mobile Network, when the > > HA actually didnt. the MR has now way of figuring out > > whats wrong, if packets from the CN to MNNs are dropped > > at the HA. >=20 >=20 > Then you do not want implicit mode at all. Because even if the HA has > some prefixes listed for that MR in its prefix table, the may not be > correct, or complete. Unless the HA lists the prefixes it knows of in > the B-Ack. Again I'm talking about the real implicit, the one with > prefix table, as opposed to static routes or IGP over MRHA. >=20 > Consequence, if you want full checking, you need implicit, plus the list > of accepted prefixes in the B-Ack if not all. >=20 > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > whether it will ever get the right routes, or whether the MR will try > anything. So the code 143 is straight infeasible. >=20 > Pascal From nemo-admin@ietf.org Wed Jul 23 06:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08040 for ; Wed, 23 Jul 2003 06:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH6H-00046e-4J; Wed, 23 Jul 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH5e-000445-3g for nemo@optimus.ietf.org; Wed, 23 Jul 2003 06:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08016 for ; Wed, 23 Jul 2003 06:43:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fH5a-0003oq-00 for nemo@ietf.org; Wed, 23 Jul 2003 06:43:18 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fH5O-0003oZ-00 for nemo@ietf.org; Wed, 23 Jul 2003 06:43:07 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6NAWs5B028906; Wed, 23 Jul 2003 18:32:54 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 4E03B10E94CF; Wed, 23 Jul 2003 18:38:46 +0800 (SGT) Subject: Re: [nemo] supported multihoming scenarios From: Chan-Wah Ng To: Erik Nordmark Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058956725.10186.24.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 23 Jul 2003 18:38:46 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Erik, Thank you for your insight. See response in-line. On Tue, 2003-07-22 at 16:43, Erik Nordmark wrote: > > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > > > - Do we support only the case where every HA belongs to the same > > administrative domain? > > I don't think it is the admin domain which is really pertinent but a more > general concept: The multiple HAs must be located so that the single prefix > is not part of an aggregated prefix where the aggregation occurs between the > HAs. > > For example if the HAs are in a single routing domain which uses OSPF or IS-IS > then either the HAs must be part of the same IGP area, or the prefix > assigned to the mobile network must not be aggregated at the area boundary. > Agreed, it is not specifically the admin domain that gives complexity, but the interactions with the routing protocols used. The question is then do we need to open up NEMO to such complexity? My recommendation is that the only requirement is for NEMO to support the case where a single prefix be registered to home agents belonging to the same routing domain such that there is no additional constraints impose on the way mobile network prefix is chosen other than it is aggregated from the said routing domain. Should implementors want to support beyond such case, they can do so by whatever legal means. However, it will not be taken into consideration when evaluating NEMO basic solution. > > - If HAs belong to different domains, it may interfere with global > > routing since different domains now advertise routes to the same > > prefix.. > > I think this statement is backwards since there tends to be filtering of > advertised prefixes at AS boundaries. Thus if this were to be done > it is likely that things would not work due to the routes for the > mobile network's prefix are likely to be filtered. > You are right. It still means that considerable effort will be needed so that NEMO can be used with a mobile network with mobile routers belonging to the different AS/admin/ruting/ICP domain/area. > > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > > > - Do we restrict ourselves to only the case where each prefix is only > > registered to HA within the same domain? > > - If the same prefix is registered to HAs from different domains, it may > > interfere with global routing since different domains now advertise > > routes to the same prefix.. > > same comment as above. > > But there is an addition point of view which is that in this case > the mobile network can be viewed as a multihomed site similar a home > being multihomed to both a DLS provider and a cable modem provider. > > I'm concerned that the categorization you use don't capture the important > distinction between the case when the MR(s) are independent of the HA(s) > (as is the case in the site multihoming view) and when the MR(s) are > operated by the same entity as the HA(s). > In either case there are existing techniques that can be applied > independently of Nemo, but the techniques would be quite different in > the two cases. > > When there are multiple prefixes assigned to the mobile network > this is most likely due to the MR(s) being independent of the HA(s) > i.e. the site multihoming view. > Would you care to elaborate more on the two different point of views? As far as I see, using the example of a home network with a DSL and a cable, the DSL-ISP will give your DSL modem an IP address, and cable ISP will give you another IP address for your cable modem. So, the IP addresses belongs to two different ISP of different domain. There is actually previous discussion on whether we should expand the axes and use the following: y = 0: single HA, y = 1: multiple HA from same domain y = 2: multiple HA from different domains Are you suggesting something along this line? /rgds /cwng From exim@www1.ietf.org Wed Jul 23 06:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08058 for ; Wed, 23 Jul 2003 06:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH6T-00047j-CL for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 06:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NAiD4U015846 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 06:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH6T-00047V-5x for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 06:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08023 for ; Wed, 23 Jul 2003 06:44:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fH6P-0003p8-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 06:44:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fH6J-0003p5-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 06:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH6H-00046e-4J; Wed, 23 Jul 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH5e-000445-3g for nemo@optimus.ietf.org; Wed, 23 Jul 2003 06:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08016 for ; Wed, 23 Jul 2003 06:43:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fH5a-0003oq-00 for nemo@ietf.org; Wed, 23 Jul 2003 06:43:18 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fH5O-0003oZ-00 for nemo@ietf.org; Wed, 23 Jul 2003 06:43:07 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6NAWs5B028906; Wed, 23 Jul 2003 18:32:54 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 4E03B10E94CF; Wed, 23 Jul 2003 18:38:46 +0800 (SGT) Subject: Re: [nemo] supported multihoming scenarios From: Chan-Wah Ng To: Erik Nordmark Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1058956725.10186.24.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 23 Jul 2003 18:38:46 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Erik, Thank you for your insight. See response in-line. On Tue, 2003-07-22 at 16:43, Erik Nordmark wrote: > > * (0,1,0): Single MR, Multiple HAs, Single Prefix > > > > - Do we support only the case where every HA belongs to the same > > administrative domain? > > I don't think it is the admin domain which is really pertinent but a more > general concept: The multiple HAs must be located so that the single prefix > is not part of an aggregated prefix where the aggregation occurs between the > HAs. > > For example if the HAs are in a single routing domain which uses OSPF or IS-IS > then either the HAs must be part of the same IGP area, or the prefix > assigned to the mobile network must not be aggregated at the area boundary. > Agreed, it is not specifically the admin domain that gives complexity, but the interactions with the routing protocols used. The question is then do we need to open up NEMO to such complexity? My recommendation is that the only requirement is for NEMO to support the case where a single prefix be registered to home agents belonging to the same routing domain such that there is no additional constraints impose on the way mobile network prefix is chosen other than it is aggregated from the said routing domain. Should implementors want to support beyond such case, they can do so by whatever legal means. However, it will not be taken into consideration when evaluating NEMO basic solution. > > - If HAs belong to different domains, it may interfere with global > > routing since different domains now advertise routes to the same > > prefix.. > > I think this statement is backwards since there tends to be filtering of > advertised prefixes at AS boundaries. Thus if this were to be done > it is likely that things would not work due to the routes for the > mobile network's prefix are likely to be filtered. > You are right. It still means that considerable effort will be needed so that NEMO can be used with a mobile network with mobile routers belonging to the different AS/admin/ruting/ICP domain/area. > > * (0,1,1): Single MR, Multiple HAs, Multiple Prefixes > > > > - Do we restrict ourselves to only the case where each prefix is only > > registered to HA within the same domain? > > - If the same prefix is registered to HAs from different domains, it may > > interfere with global routing since different domains now advertise > > routes to the same prefix.. > > same comment as above. > > But there is an addition point of view which is that in this case > the mobile network can be viewed as a multihomed site similar a home > being multihomed to both a DLS provider and a cable modem provider. > > I'm concerned that the categorization you use don't capture the important > distinction between the case when the MR(s) are independent of the HA(s) > (as is the case in the site multihoming view) and when the MR(s) are > operated by the same entity as the HA(s). > In either case there are existing techniques that can be applied > independently of Nemo, but the techniques would be quite different in > the two cases. > > When there are multiple prefixes assigned to the mobile network > this is most likely due to the MR(s) being independent of the HA(s) > i.e. the site multihoming view. > Would you care to elaborate more on the two different point of views? As far as I see, using the example of a home network with a DSL and a cable, the DSL-ISP will give your DSL modem an IP address, and cable ISP will give you another IP address for your cable modem. So, the IP addresses belongs to two different ISP of different domain. There is actually previous discussion on whether we should expand the axes and use the following: y = 0: single HA, y = 1: multiple HA from same domain y = 2: multiple HA from different domains Are you suggesting something along this line? /rgds /cwng From nemo-admin@ietf.org Wed Jul 23 08:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10257 for ; Wed, 23 Jul 2003 08:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCw-0007ti-3l; Wed, 23 Jul 2003 08:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCZ-0007tJ-B6 for nemo@optimus.ietf.org; Wed, 23 Jul 2003 08:58:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10239 for ; Wed, 23 Jul 2003 08:58:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJCX-0004La-00 for nemo@ietf.org; Wed, 23 Jul 2003 08:58:38 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fJCM-0004LK-00 for nemo@ietf.org; Wed, 23 Jul 2003 08:58:27 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6NCviK19988 for ; Wed, 23 Jul 2003 14:57:44 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: Date: Wed, 23 Jul 2003 14:57:43 +0200 Message-ID: <000101c3511a$01cbf850$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Subject: [nemo] WG: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable -----Urspr=FCngliche Nachricht----- Von: Koojana Kuladinithi [mailto:koo@comnets.uni-bremen.de]=20 Gesendet: Mittwoch, 23. Juli 2003 14:56 An: 'Nicolas Montavont'; 'mobileip' Betreff: AW: [mobile-ip] new I-D on HA filtering=20 Hi Nicolas, There are a lot of drafts related to multiple points of attachments and = flow distribution, especially for MIPv6. Followings are the list of drafts, (that I am aware of) MIPv4 ------- http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. MIPv6 ------- http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-03.t= xt http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa- To be listed at the IETF repository. http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobileip-= fi lters-00.txt http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filteri= ng- v6-00.txt Perhaps, we should initiate a discussion in mobile-ip or nemo WG to = discuss=20 about this topic. Kind regards Koojana -----Urspr=FCngliche Nachricht----- Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas Montavont Gesendet: Mittwoch, 23. Juli 2003 09:55 An: mobileip Betreff: [mobile-ip] new I-D on HA filtering=20 Hi all, We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 available at http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filteri= ng- v6-00.txt It will be soon available in the IETF repertories. This I-D proposes a solution for the MN to set filters on its home=20 agent. Filters can be used to spread flows on different CoAs (and=20 potentially several network interfaces), and to forbid the redirection=20 of certain flows from the home agent. Here is the abstract: Mobile IPv6 allows a MN to receive incoming packets to its home address=20 while it is away from its home network. In a heterogeneous environment,=20 a MN may have multiple interfaces, each with different characteristics.=20 While a MN is in a visited network, due to the performance of the=20 interfaces or to the user preferences, the MN may want to forbid the=20 redirection from its home agent of a kind of flow, or to indicate a=20 target CoA for a kind of flow. In this draft, we propose new mobility options that allow a MN to=20 advertise filters to its home agent. A filter is associated with a CoA,=20 in such a way that the MN can register several CoA and can register=20 several filters for one CoA. A filter may indicate that a flow which map = to a filter must be dropped or must be redirected to the indicated CoA. Regards, Nicolas From exim@www1.ietf.org Wed Jul 23 09:00:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10380 for ; Wed, 23 Jul 2003 09:00:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJDm-0007xN-65 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 08:59:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NCxsLQ030584 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 08:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJDm-0007xD-1Y for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 08:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10298 for ; Wed, 23 Jul 2003 08:59:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJDk-0004Ma-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 08:59:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJDe-0004Lm-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 08:59:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCw-0007ti-3l; Wed, 23 Jul 2003 08:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCZ-0007tJ-B6 for nemo@optimus.ietf.org; Wed, 23 Jul 2003 08:58:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10239 for ; Wed, 23 Jul 2003 08:58:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJCX-0004La-00 for nemo@ietf.org; Wed, 23 Jul 2003 08:58:38 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fJCM-0004LK-00 for nemo@ietf.org; Wed, 23 Jul 2003 08:58:27 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6NCviK19988 for ; Wed, 23 Jul 2003 14:57:44 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: Date: Wed, 23 Jul 2003 14:57:43 +0200 Message-ID: <000101c3511a$01cbf850$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Subject: [nemo] WG: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Urspr=FCngliche Nachricht----- Von: Koojana Kuladinithi [mailto:koo@comnets.uni-bremen.de]=20 Gesendet: Mittwoch, 23. Juli 2003 14:56 An: 'Nicolas Montavont'; 'mobileip' Betreff: AW: [mobile-ip] new I-D on HA filtering=20 Hi Nicolas, There are a lot of drafts related to multiple points of attachments and = flow distribution, especially for MIPv6. Followings are the list of drafts, (that I am aware of) MIPv4 ------- http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-03.txt. MIPv6 ------- http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-03.t= xt http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa- To be listed at the IETF repository. http://www.comnets.uni-bremen.de/english/research/draft-nomadv6-mobileip-= fi lters-00.txt http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filteri= ng- v6-00.txt Perhaps, we should initiate a discussion in mobile-ip or nemo WG to = discuss=20 about this topic. Kind regards Koojana -----Urspr=FCngliche Nachricht----- Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas Montavont Gesendet: Mittwoch, 23. Juli 2003 09:55 An: mobileip Betreff: [mobile-ip] new I-D on HA filtering=20 Hi all, We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 available at http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filteri= ng- v6-00.txt It will be soon available in the IETF repertories. This I-D proposes a solution for the MN to set filters on its home=20 agent. Filters can be used to spread flows on different CoAs (and=20 potentially several network interfaces), and to forbid the redirection=20 of certain flows from the home agent. Here is the abstract: Mobile IPv6 allows a MN to receive incoming packets to its home address=20 while it is away from its home network. In a heterogeneous environment,=20 a MN may have multiple interfaces, each with different characteristics.=20 While a MN is in a visited network, due to the performance of the=20 interfaces or to the user preferences, the MN may want to forbid the=20 redirection from its home agent of a kind of flow, or to indicate a=20 target CoA for a kind of flow. In this draft, we propose new mobility options that allow a MN to=20 advertise filters to its home agent. A filter is associated with a CoA,=20 in such a way that the MN can register several CoA and can register=20 several filters for one CoA. A filter may indicate that a flow which map = to a filter must be dropped or must be redirected to the indicated CoA. Regards, Nicolas From nemo-admin@ietf.org Wed Jul 23 09:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11049 for ; Wed, 23 Jul 2003 09:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJQT-0000Xl-7X; Wed, 23 Jul 2003 09:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJPs-0000X0-OV for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10984 for ; Wed, 23 Jul 2003 09:12:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJPr-0004VG-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:12:23 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fJPg-0004Ur-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:12:12 -0400 Received: from dpt-info.u-strasbg.fr (localhost [127.0.0.1]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NDBbnX016861; Wed, 23 Jul 2003 15:11:37 +0200 Received: (from www-data@localhost) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) id h6NDBadt016860; Wed, 23 Jul 2003 15:11:36 +0200 X-Authentication-Warning: dpt-info.u-strasbg.fr: www-data set sender to Thomas.Noel@dpt-info.u-strasbg.fr using -f Received: from 81.56.165.253 ( [81.56.165.253]) as user noel@dpt-info.u-strasbg.fr by dpt-info.u-strasbg.fr with HTTP; Wed, 23 Jul 2003 15:11:36 +0200 Message-ID: <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> Date: Wed, 23 Jul 2003 15:11:36 +0200 From: Thomas Noel To: Koojana Kuladinithi Cc: nemo@ietf.org Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <000101c3511a$01cbf850$989b6686@scoobydoo> In-Reply-To: <000101c3511a$01cbf850$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 81.56.165.253 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h6NDBbnX016861 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Koojana, All, >=20 > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to dis= cuss >=20 > about this topic. >=20 I Agree with you, we have now several drafts and it will be interesting to converge towards an unique solution to solve this issue. Perhaps, Nemo is the ideal WG to discuss about this topic. Regards Thomas Noel LSIIT >=20 > Kind regards >=20 > Koojana >=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > Montavont > Gesendet: Mittwoch, 23. Juli 2003 09:55 > An: mobileip > Betreff: [mobile-ip] new I-D on HA filtering=20 >=20 > Hi all, >=20 > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 > available at >=20 > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filte= ring- > v6-00.txt >=20 > It will be soon available in the IETF repertories. >=20 > This I-D proposes a solution for the MN to set filters on its home=20 > agent. Filters can be used to spread flows on different CoAs (and=20 > potentially several network interfaces), and to forbid the redirection=20 > of certain flows from the home agent. >=20 > Here is the abstract: >=20 > Mobile IPv6 allows a MN to receive incoming packets to its home address= =20 > while it is away from its home network. In a heterogeneous environment,= =20 > a MN may have multiple interfaces, each with different characteristics.= =20 > While a MN is in a visited network, due to the performance of the=20 > interfaces or to the user preferences, the MN may want to forbid the=20 > redirection from its home agent of a kind of flow, or to indicate a=20 > target CoA for a kind of flow. > In this draft, we propose new mobility options that allow a MN to=20 > advertise filters to its home agent. A filter is associated with a CoA,= =20 > in such a way that the MN can register several CoA and can register=20 > several filters for one CoA. A filter may indicate that a flow which ma= p=20 > to a filter must be dropped or must be redirected to the indicated CoA. >=20 > Regards, > Nicolas >=20 >=20 >=20 From exim@www1.ietf.org Wed Jul 23 09:13:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11064 for ; Wed, 23 Jul 2003 09:13:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJQa-0000Yt-2t for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDD8US002155 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJQZ-0000Yg-Vk for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11031 for ; Wed, 23 Jul 2003 09:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJQY-0004WB-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJQS-0004W8-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJQT-0000Xl-7X; Wed, 23 Jul 2003 09:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJPs-0000X0-OV for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10984 for ; Wed, 23 Jul 2003 09:12:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJPr-0004VG-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:12:23 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fJPg-0004Ur-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:12:12 -0400 Received: from dpt-info.u-strasbg.fr (localhost [127.0.0.1]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NDBbnX016861; Wed, 23 Jul 2003 15:11:37 +0200 Received: (from www-data@localhost) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) id h6NDBadt016860; Wed, 23 Jul 2003 15:11:36 +0200 X-Authentication-Warning: dpt-info.u-strasbg.fr: www-data set sender to Thomas.Noel@dpt-info.u-strasbg.fr using -f Received: from 81.56.165.253 ( [81.56.165.253]) as user noel@dpt-info.u-strasbg.fr by dpt-info.u-strasbg.fr with HTTP; Wed, 23 Jul 2003 15:11:36 +0200 Message-ID: <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> Date: Wed, 23 Jul 2003 15:11:36 +0200 From: Thomas Noel To: Koojana Kuladinithi Cc: nemo@ietf.org Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <000101c3511a$01cbf850$989b6686@scoobydoo> In-Reply-To: <000101c3511a$01cbf850$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 81.56.165.253 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h6NDBbnX016861 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Koojana, All, >=20 > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to dis= cuss >=20 > about this topic. >=20 I Agree with you, we have now several drafts and it will be interesting to converge towards an unique solution to solve this issue. Perhaps, Nemo is the ideal WG to discuss about this topic. Regards Thomas Noel LSIIT >=20 > Kind regards >=20 > Koojana >=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > Montavont > Gesendet: Mittwoch, 23. Juli 2003 09:55 > An: mobileip > Betreff: [mobile-ip] new I-D on HA filtering=20 >=20 > Hi all, >=20 > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 > available at >=20 > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filte= ring- > v6-00.txt >=20 > It will be soon available in the IETF repertories. >=20 > This I-D proposes a solution for the MN to set filters on its home=20 > agent. Filters can be used to spread flows on different CoAs (and=20 > potentially several network interfaces), and to forbid the redirection=20 > of certain flows from the home agent. >=20 > Here is the abstract: >=20 > Mobile IPv6 allows a MN to receive incoming packets to its home address= =20 > while it is away from its home network. In a heterogeneous environment,= =20 > a MN may have multiple interfaces, each with different characteristics.= =20 > While a MN is in a visited network, due to the performance of the=20 > interfaces or to the user preferences, the MN may want to forbid the=20 > redirection from its home agent of a kind of flow, or to indicate a=20 > target CoA for a kind of flow. > In this draft, we propose new mobility options that allow a MN to=20 > advertise filters to its home agent. A filter is associated with a CoA,= =20 > in such a way that the MN can register several CoA and can register=20 > several filters for one CoA. A filter may indicate that a flow which ma= p=20 > to a filter must be dropped or must be redirected to the indicated CoA. >=20 > Regards, > Nicolas >=20 >=20 >=20 From nemo-admin@ietf.org Wed Jul 23 09:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11351 for ; Wed, 23 Jul 2003 09:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJVJ-0000l2-Em; Wed, 23 Jul 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJUh-0000j6-Rb for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:17:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11272 for ; Wed, 23 Jul 2003 09:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJUg-0004Z8-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:17:22 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fJUV-0004YY-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:17:11 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 23 Jul 2003 09:16:01 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thomas Noel'" , Koojana Kuladinithi Cc: nemo@ietf.org Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Wed, 23 Jul 2003 09:15:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > >=20 > > Perhaps, we should initiate a discussion in mobile-ip or=20 > nemo WG to discuss > >=20 > > about this topic. > >=20 > I Agree with you, we have now several drafts and it will be=20 > interesting > to converge towards an unique solution to solve this issue. >=20 > Perhaps, Nemo is the ideal WG to discuss about this topic. =3D> Definitely not the right WG for this. The right WG is MIP6 or if MIPSHOP had a more flexible name/charter it could go there as well. There is nothing NEMO specific for this problem. Hesham >=20 > Regards >=20 > Thomas Noel > LSIIT >=20 > >=20 > > Kind regards > >=20 > > Koojana > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von = Nicolas > > Montavont > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > An: mobileip > > Betreff: [mobile-ip] new I-D on HA filtering=20 > >=20 > > Hi all, > >=20 > > We just submitted a new I-D on Home Agent Filtering for=20 > Mobile IPv6,=20 > > available at > >=20 > >=20 http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filter= ing- > v6-00.txt >=20 > It will be soon available in the IETF repertories. >=20 > This I-D proposes a solution for the MN to set filters on its home=20 > agent. Filters can be used to spread flows on different CoAs (and=20 > potentially several network interfaces), and to forbid the = redirection=20 > of certain flows from the home agent. >=20 > Here is the abstract: >=20 > Mobile IPv6 allows a MN to receive incoming packets to its home = address=20 > while it is away from its home network. In a heterogeneous = environment,=20 > a MN may have multiple interfaces, each with different = characteristics.=20 > While a MN is in a visited network, due to the performance of the=20 > interfaces or to the user preferences, the MN may want to forbid the=20 > redirection from its home agent of a kind of flow, or to indicate a=20 > target CoA for a kind of flow. > In this draft, we propose new mobility options that allow a MN to=20 > advertise filters to its home agent. A filter is associated with a = CoA,=20 > in such a way that the MN can register several CoA and can register=20 > several filters for one CoA. A filter may indicate that a flow which = map=20 > to a filter must be dropped or must be redirected to the indicated = CoA. >=20 > Regards, > Nicolas >=20 >=20 >=20 From exim@www1.ietf.org Wed Jul 23 09:18:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11366 for ; Wed, 23 Jul 2003 09:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJVP-0000n9-Oj for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDI7eP003037 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJVP-0000mu-L0 for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11308 for ; Wed, 23 Jul 2003 09:18:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJVO-0004Zr-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJVI-0004Zo-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJVJ-0000l2-Em; Wed, 23 Jul 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJUh-0000j6-Rb for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:17:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11272 for ; Wed, 23 Jul 2003 09:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJUg-0004Z8-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:17:22 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fJUV-0004YY-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:17:11 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 23 Jul 2003 09:16:01 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thomas Noel'" , Koojana Kuladinithi Cc: nemo@ietf.org Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Wed, 23 Jul 2003 09:15:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >=20 > > Perhaps, we should initiate a discussion in mobile-ip or=20 > nemo WG to discuss > >=20 > > about this topic. > >=20 > I Agree with you, we have now several drafts and it will be=20 > interesting > to converge towards an unique solution to solve this issue. >=20 > Perhaps, Nemo is the ideal WG to discuss about this topic. =3D> Definitely not the right WG for this. The right WG is MIP6 or if MIPSHOP had a more flexible name/charter it could go there as well. There is nothing NEMO specific for this problem. Hesham >=20 > Regards >=20 > Thomas Noel > LSIIT >=20 > >=20 > > Kind regards > >=20 > > Koojana > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von = Nicolas > > Montavont > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > An: mobileip > > Betreff: [mobile-ip] new I-D on HA filtering=20 > >=20 > > Hi all, > >=20 > > We just submitted a new I-D on Home Agent Filtering for=20 > Mobile IPv6,=20 > > available at > >=20 > >=20 http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filter= ing- > v6-00.txt >=20 > It will be soon available in the IETF repertories. >=20 > This I-D proposes a solution for the MN to set filters on its home=20 > agent. Filters can be used to spread flows on different CoAs (and=20 > potentially several network interfaces), and to forbid the = redirection=20 > of certain flows from the home agent. >=20 > Here is the abstract: >=20 > Mobile IPv6 allows a MN to receive incoming packets to its home = address=20 > while it is away from its home network. In a heterogeneous = environment,=20 > a MN may have multiple interfaces, each with different = characteristics.=20 > While a MN is in a visited network, due to the performance of the=20 > interfaces or to the user preferences, the MN may want to forbid the=20 > redirection from its home agent of a kind of flow, or to indicate a=20 > target CoA for a kind of flow. > In this draft, we propose new mobility options that allow a MN to=20 > advertise filters to its home agent. A filter is associated with a = CoA,=20 > in such a way that the MN can register several CoA and can register=20 > several filters for one CoA. A filter may indicate that a flow which = map=20 > to a filter must be dropped or must be redirected to the indicated = CoA. >=20 > Regards, > Nicolas >=20 >=20 >=20 From nemo-admin@ietf.org Wed Jul 23 09:24:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11698 for ; Wed, 23 Jul 2003 09:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJb7-0000xM-1S; Wed, 23 Jul 2003 09:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJan-0000wQ-5s for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11672 for ; Wed, 23 Jul 2003 09:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJal-0004dh-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:23:39 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19fJaa-0004ct-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:23:28 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NDL6Ft006192; Wed, 23 Jul 2003 07:21:07 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6NDL5Q15556; Wed, 23 Jul 2003 15:21:06 +0200 (MEST) Date: Wed, 23 Jul 2003 15:19:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt To: =?iso-8859-1?Q?Pekka_P=E4=E4kk=F6nen?= Cc: nemo@ietf.org, narten@us.ibm.com, hinden@iprg.nokia.com, mrw@windriver.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20030722141236.00bf7cf0@elemail.ele.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > No document specifies to my knowledge how to configure link-local addresses > for tunnel-interfaces. This is a bug. Presumably it should be in the IPv6 WG charter to update RFC 2473 (IPv6 tunnels) with the information on how to form interface identifiers. Two of the methods in RFC 2472 (IPv6 over PPP) makes sense to me: If the node has an EUI-48 or EUI-64 on some other interface it can use it as the interface ID on any tunnel (and multiple tunnels). Otherwise form a random interface ID using a good source of randomness. Erik From exim@www1.ietf.org Wed Jul 23 09:25:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11728 for ; Wed, 23 Jul 2003 09:25:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJbc-00012N-94 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:24:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDOWAZ003981 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJbc-000128-3p for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:24:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11699 for ; Wed, 23 Jul 2003 09:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJb7-0000xM-1S; Wed, 23 Jul 2003 09:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJan-0000wQ-5s for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11672 for ; Wed, 23 Jul 2003 09:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJal-0004dh-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:23:39 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19fJaa-0004ct-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:23:28 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NDL6Ft006192; Wed, 23 Jul 2003 07:21:07 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6NDL5Q15556; Wed, 23 Jul 2003 15:21:06 +0200 (MEST) Date: Wed, 23 Jul 2003 15:19:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt To: =?iso-8859-1?Q?Pekka_P=E4=E4kk=F6nen?= Cc: nemo@ietf.org, narten@us.ibm.com, hinden@iprg.nokia.com, mrw@windriver.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20030722141236.00bf7cf0@elemail.ele.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > No document specifies to my knowledge how to configure link-local addresses > for tunnel-interfaces. This is a bug. Presumably it should be in the IPv6 WG charter to update RFC 2473 (IPv6 tunnels) with the information on how to form interface identifiers. Two of the methods in RFC 2472 (IPv6 over PPP) makes sense to me: If the node has an EUI-48 or EUI-64 on some other interface it can use it as the interface ID on any tunnel (and multiple tunnels). Otherwise form a random interface ID using a good source of randomness. Erik From nemo-admin@ietf.org Wed Jul 23 09:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12329 for ; Wed, 23 Jul 2003 09:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJmj-0001Sh-H4; Wed, 23 Jul 2003 09:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJmD-0001R3-9s for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:35:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12249 for ; Wed, 23 Jul 2003 09:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJmB-0004hx-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:35:27 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fJlv-0004hA-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:35:11 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6NDWZee015919; Wed, 23 Jul 2003 22:32:35 +0900 Date: Tue, 22 Jul 2003 19:18:06 +0900 Message-ID: From: Ryuji Wakikawa To: Thomas.Noel@dpt-info.u-strasbg.fr Cc: koo@comnets.uni-bremen.de, nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering In-Reply-To: <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> References: <000101c3511a$01cbf850$989b6686@scoobydoo> <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, At Wed, 23 Jul 2003 15:11:36 +0200, Thomas Noel wrote: >=20 > Hi Koojana, All, > >=20 > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to dis= cuss > >=20 > > about this topic. > >=20 > I Agree with you, we have now several drafts and it will be interesting > to converge towards an unique solution to solve this issue. Can we discuss filters/policies and multipleCoAs registration separately? Most of draft needs multiple CoAs registrations, but some of systems do not want to support filters/policies on the IP layer.=20 Our draft(multiplecoa) deals with only multiple CoAs registration. > Perhaps, Nemo is the ideal WG to discuss about this topic. It might be better to keep discussing it in MIP6/MIPSHOP WG, because NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters whatever, NEMO can have the same feature. If NEMO still needs further operations, then NEMO becomes the ideal WG. best regards, ryuji >=20 > Regards >=20 > Thomas Noel > LSIIT >=20 > >=20 > > Kind regards > >=20 > > Koojana > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > > Montavont > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > An: mobileip > > Betreff: [mobile-ip] new I-D on HA filtering=20 > >=20 > > Hi all, > >=20 > > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 > > available at > >=20 > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filte= ring- > > v6-00.txt > >=20 > > It will be soon available in the IETF repertories. > >=20 > > This I-D proposes a solution for the MN to set filters on its home=20 > > agent. Filters can be used to spread flows on different CoAs (and=20 > > potentially several network interfaces), and to forbid the redirection = > > of certain flows from the home agent. > >=20 > > Here is the abstract: > >=20 > > Mobile IPv6 allows a MN to receive incoming packets to its home address= =20 > > while it is away from its home network. In a heterogeneous environment,= =20 > > a MN may have multiple interfaces, each with different characteristics.= =20 > > While a MN is in a visited network, due to the performance of the=20 > > interfaces or to the user preferences, the MN may want to forbid the=20 > > redirection from its home agent of a kind of flow, or to indicate a=20 > > target CoA for a kind of flow. > > In this draft, we propose new mobility options that allow a MN to=20 > > advertise filters to its home agent. A filter is associated with a CoA,= =20 > > in such a way that the MN can register several CoA and can register=20 > > several filters for one CoA. A filter may indicate that a flow which ma= p=20 > > to a filter must be dropped or must be redirected to the indicated CoA. > >=20 > > Regards, > > Nicolas > >=20 > >=20 > >=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Jul 23 09:37:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12381 for ; Wed, 23 Jul 2003 09:37:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJnH-0001av-7b for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:36:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDaZPm006125 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJnF-0001aQ-KH for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:36:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12330 for ; Wed, 23 Jul 2003 09:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJmj-0001Sh-H4; Wed, 23 Jul 2003 09:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJmD-0001R3-9s for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:35:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12249 for ; Wed, 23 Jul 2003 09:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJmB-0004hx-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:35:27 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fJlv-0004hA-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:35:11 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6NDWZee015919; Wed, 23 Jul 2003 22:32:35 +0900 Date: Tue, 22 Jul 2003 19:18:06 +0900 Message-ID: From: Ryuji Wakikawa To: Thomas.Noel@dpt-info.u-strasbg.fr Cc: koo@comnets.uni-bremen.de, nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering In-Reply-To: <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> References: <000101c3511a$01cbf850$989b6686@scoobydoo> <1058965896.3f1e8988ac3f6@dpt-info.u-strasbg.fr> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, At Wed, 23 Jul 2003 15:11:36 +0200, Thomas Noel wrote: >=20 > Hi Koojana, All, > >=20 > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to dis= cuss > >=20 > > about this topic. > >=20 > I Agree with you, we have now several drafts and it will be interesting > to converge towards an unique solution to solve this issue. Can we discuss filters/policies and multipleCoAs registration separately? Most of draft needs multiple CoAs registrations, but some of systems do not want to support filters/policies on the IP layer.=20 Our draft(multiplecoa) deals with only multiple CoAs registration. > Perhaps, Nemo is the ideal WG to discuss about this topic. It might be better to keep discussing it in MIP6/MIPSHOP WG, because NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters whatever, NEMO can have the same feature. If NEMO still needs further operations, then NEMO becomes the ideal WG. best regards, ryuji >=20 > Regards >=20 > Thomas Noel > LSIIT >=20 > >=20 > > Kind regards > >=20 > > Koojana > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > > Montavont > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > An: mobileip > > Betreff: [mobile-ip] new I-D on HA filtering=20 > >=20 > > Hi all, > >=20 > > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6,=20 > > available at > >=20 > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha-filte= ring- > > v6-00.txt > >=20 > > It will be soon available in the IETF repertories. > >=20 > > This I-D proposes a solution for the MN to set filters on its home=20 > > agent. Filters can be used to spread flows on different CoAs (and=20 > > potentially several network interfaces), and to forbid the redirection = > > of certain flows from the home agent. > >=20 > > Here is the abstract: > >=20 > > Mobile IPv6 allows a MN to receive incoming packets to its home address= =20 > > while it is away from its home network. In a heterogeneous environment,= =20 > > a MN may have multiple interfaces, each with different characteristics.= =20 > > While a MN is in a visited network, due to the performance of the=20 > > interfaces or to the user preferences, the MN may want to forbid the=20 > > redirection from its home agent of a kind of flow, or to indicate a=20 > > target CoA for a kind of flow. > > In this draft, we propose new mobility options that allow a MN to=20 > > advertise filters to its home agent. A filter is associated with a CoA,= =20 > > in such a way that the MN can register several CoA and can register=20 > > several filters for one CoA. A filter may indicate that a flow which ma= p=20 > > to a filter must be dropped or must be redirected to the indicated CoA. > >=20 > > Regards, > > Nicolas > >=20 > >=20 > >=20 >=20 >=20 >=20 From nemo-admin@ietf.org Wed Jul 23 09:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12641 for ; Wed, 23 Jul 2003 09:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJvR-0002As-Ju; Wed, 23 Jul 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJuY-0002A6-4R for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12580 for ; Wed, 23 Jul 2003 09:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJuW-0004ly-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:44:04 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19fJuL-0004lV-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:43:53 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NDgxxk011513; Wed, 23 Jul 2003 06:43:00 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6NDgwQ19827; Wed, 23 Jul 2003 15:42:58 +0200 (MEST) Date: Wed, 23 Jul 2003 15:41:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Chan-Wah Ng Cc: Erik Nordmark , IETF NEMO WG In-Reply-To: "Your message with ID" <1058956725.10186.24.camel@beethoven> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Agreed, it is not specifically the admin domain that gives complexity, > but the interactions with the routing protocols used. The question is > then do we need to open up NEMO to such complexity? Doesn't cause any additional complexity in the Nemo protocol AFAIK; the ability to convey a prefix in the BU is one option and the other option is to run an IGP over the tunnel. That should be sufficient. My point is that if you want the draft on multihoming to clearly state the scenarios and issue, whether or not they effect the Nemo protocol, they I think you should capture this high level distinction. If you don't want to capture the scenarios and issue then I don't think the multihoming draft is needed since the protocol document will provide the building block (and how to run an IGP over the tunnels can be left as an exercise to the reader?) You seem to think adding explanator text and different categorization to the multihoming draft will somehow effect the Nemo protocol. I fail to understand why this would be the case. How and why would the Nemo protocol need to be different in your opinion? > Would you care to elaborate more on the two different point of views? As > far as I see, using the example of a home network with a DSL and a > cable, the DSL-ISP will give your DSL modem an IP address, and cable ISP > will give you another IP address for your cable modem. So, the IP > addresses belongs to two different ISP of different domain. > > There is actually previous discussion on whether we should expand the > axes and use the following: > y = 0: single HA, > y = 1: multiple HA from same domain > y = 2: multiple HA from different domains > Are you suggesting something along this line? First of all "domain" is not the best word, since it is the general issue whether the prefix is aggregated between the multiple HAs. But the more important point is that you are approaching the description from the bottom up and I am suggesting the top down approach which starts with the control and ownership of the HA(s) and MR(s). If the HA(s) and MR(s) are controlled by the same entity (for instance an ISP) then the ISP can decide whether it wants to assign one or multiple prefixes to the mobile network just like it can make that decision for any other link in its network. In any case the ISP will make routing work i.e. not introduce any aggregation between the HA(s) which will filter out the routing announcements for the mobile prefix(es). The tools the ISP has for making routing work is to - run their IGP over the tunnels, or - use static routing of the tunnels (the prefix in the BUs) perhaps combined with some liveness testing protocol applied to the tunnels The ISP might be less likely to use prefix delegation since the MR(s) can presumably be configured with the proper prefixes using whatever management system the ISP uses for the routers. If the HA(s) and MR(s) and controlled by different entities it might look a lot more like the HA(s) being controlled by (one or more) ISP and the MR(s) being controlled by a subscriber. (Presumably when there are multiple MR(s) on the same link they need to be controlled by the same subscriber otherwise there might be a lack of coordination of the control of the mobile link). From the top down there are two possible subcases: - The MR(s) establishing multiple tunnels to the same ISP (to get additional capacity, redundancy, etc) whether or not they are connected to the same HA in the ISP (having multiple HAs might improve availability though) - The MR(s) making the mobile network a multihomed site (see multi6) by connecting to different ISPs. When there is a subscriber/provider relationship at the MR-HA tunnels it is rather unlikely that an IGP would be used for routing (due to the possibility of the subscriber accidentally or intentionally messing up the IGP for everybody); it is much more likely that the prefix in BU will be used to provide static routing. An issue to consider is whether it makes sense to specify a tunnel liveness protocol so that the HA and MR can detect when one tunnel fails and cause the other tunnel(s) to be used. With the subscriber/provider relationship it is likely that prefix delegation would be used. Does that high-level description make sense to folks? Erik From exim@www1.ietf.org Wed Jul 23 09:45:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12659 for ; Wed, 23 Jul 2003 09:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJvb-0002FS-VX for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:45:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDjB65008636 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 09:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJva-0002FD-Dx for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12635 for ; Wed, 23 Jul 2003 09:45:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJvY-0004n3-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:45:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJvT-0004n0-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 09:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJvR-0002As-Ju; Wed, 23 Jul 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJuY-0002A6-4R for nemo@optimus.ietf.org; Wed, 23 Jul 2003 09:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12580 for ; Wed, 23 Jul 2003 09:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJuW-0004ly-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:44:04 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19fJuL-0004lV-00 for nemo@ietf.org; Wed, 23 Jul 2003 09:43:53 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NDgxxk011513; Wed, 23 Jul 2003 06:43:00 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6NDgwQ19827; Wed, 23 Jul 2003 15:42:58 +0200 (MEST) Date: Wed, 23 Jul 2003 15:41:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Chan-Wah Ng Cc: Erik Nordmark , IETF NEMO WG In-Reply-To: "Your message with ID" <1058956725.10186.24.camel@beethoven> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Agreed, it is not specifically the admin domain that gives complexity, > but the interactions with the routing protocols used. The question is > then do we need to open up NEMO to such complexity? Doesn't cause any additional complexity in the Nemo protocol AFAIK; the ability to convey a prefix in the BU is one option and the other option is to run an IGP over the tunnel. That should be sufficient. My point is that if you want the draft on multihoming to clearly state the scenarios and issue, whether or not they effect the Nemo protocol, they I think you should capture this high level distinction. If you don't want to capture the scenarios and issue then I don't think the multihoming draft is needed since the protocol document will provide the building block (and how to run an IGP over the tunnels can be left as an exercise to the reader?) You seem to think adding explanator text and different categorization to the multihoming draft will somehow effect the Nemo protocol. I fail to understand why this would be the case. How and why would the Nemo protocol need to be different in your opinion? > Would you care to elaborate more on the two different point of views? As > far as I see, using the example of a home network with a DSL and a > cable, the DSL-ISP will give your DSL modem an IP address, and cable ISP > will give you another IP address for your cable modem. So, the IP > addresses belongs to two different ISP of different domain. > > There is actually previous discussion on whether we should expand the > axes and use the following: > y = 0: single HA, > y = 1: multiple HA from same domain > y = 2: multiple HA from different domains > Are you suggesting something along this line? First of all "domain" is not the best word, since it is the general issue whether the prefix is aggregated between the multiple HAs. But the more important point is that you are approaching the description from the bottom up and I am suggesting the top down approach which starts with the control and ownership of the HA(s) and MR(s). If the HA(s) and MR(s) are controlled by the same entity (for instance an ISP) then the ISP can decide whether it wants to assign one or multiple prefixes to the mobile network just like it can make that decision for any other link in its network. In any case the ISP will make routing work i.e. not introduce any aggregation between the HA(s) which will filter out the routing announcements for the mobile prefix(es). The tools the ISP has for making routing work is to - run their IGP over the tunnels, or - use static routing of the tunnels (the prefix in the BUs) perhaps combined with some liveness testing protocol applied to the tunnels The ISP might be less likely to use prefix delegation since the MR(s) can presumably be configured with the proper prefixes using whatever management system the ISP uses for the routers. If the HA(s) and MR(s) and controlled by different entities it might look a lot more like the HA(s) being controlled by (one or more) ISP and the MR(s) being controlled by a subscriber. (Presumably when there are multiple MR(s) on the same link they need to be controlled by the same subscriber otherwise there might be a lack of coordination of the control of the mobile link). From the top down there are two possible subcases: - The MR(s) establishing multiple tunnels to the same ISP (to get additional capacity, redundancy, etc) whether or not they are connected to the same HA in the ISP (having multiple HAs might improve availability though) - The MR(s) making the mobile network a multihomed site (see multi6) by connecting to different ISPs. When there is a subscriber/provider relationship at the MR-HA tunnels it is rather unlikely that an IGP would be used for routing (due to the possibility of the subscriber accidentally or intentionally messing up the IGP for everybody); it is much more likely that the prefix in BU will be used to provide static routing. An issue to consider is whether it makes sense to specify a tunnel liveness protocol so that the HA and MR can detect when one tunnel fails and cause the other tunnel(s) to be used. With the subscriber/provider relationship it is likely that prefix delegation would be used. Does that high-level description make sense to folks? Erik From nemo-admin@ietf.org Wed Jul 23 10:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14864 for ; Wed, 23 Jul 2003 10:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKZ8-0004HZ-8R; Wed, 23 Jul 2003 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKYZ-0004GR-Lg for nemo@optimus.ietf.org; Wed, 23 Jul 2003 10:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14843 for ; Wed, 23 Jul 2003 10:25:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKYX-00052u-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:25:25 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fKYM-00052j-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:25:14 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6NEOaK21691; Wed, 23 Jul 2003 16:24:36 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Ryuji Wakikawa'" , , "'Soliman Hesham'" Cc: , Subject: AW: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Wed, 23 Jul 2003 16:24:35 +0200 Message-ID: <000001c35126$243cfe50$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ryuji and all > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] Im Auftrag von Ryuji Wakikawa > Gesendet: Dienstag, 22. Juli 2003 12:18 > An: Thomas.Noel@dpt-info.u-strasbg.fr > Cc: koo@comnets.uni-bremen.de; nemo@ietf.org; mobile- > ip@sunroof.eng.sun.com > Betreff: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering >=20 > Hello, >=20 > At Wed, 23 Jul 2003 15:11:36 +0200, > Thomas Noel wrote: > > > > Hi Koojana, All, > > > > > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG = to > discuss > > > > > > about this topic. > > > > > I Agree with you, we have now several drafts and it will be = interesting > > to converge towards an unique solution to solve this issue. >=20 > Can we discuss filters/policies and multipleCoAs registration = separately? IMHO, Multiple CoAs and Flow Distributions should be discussed together. = The reason is because once multiple CoAs are available, the natural = requirement=20 that follows would be to use these points of attachments efficiently. >=20 > Most of draft needs multiple CoAs registrations, but some of systems > do not want to support filters/policies on the IP layer. >=20 > Our draft(multiplecoa) deals with only multiple CoAs registration. >=20 > > Perhaps, Nemo is the ideal WG to discuss about this topic. >=20 > It might be better to keep discussing it in MIP6/MIPSHOP WG, because > NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters > whatever, NEMO can have the same feature. As Hesham suggested, I too believe that mip6 or mipshop would be the = best=20 place to discuss as it should be a extension to the MIPv6 base specification, which is not considered simultaneous bindings as in the = MIPv4 RFC. Kind Regards Koojana > If NEMO still needs further operations, then NEMO becomes the ideal = WG. >=20 > best regards, > ryuji >=20 > > > > Regards > > > > Thomas Noel > > LSIIT > > > > > > > > Kind regards > > > > > > Koojana > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: owner-mobile-ip@sunroof.eng.sun.com > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von = Nicolas > > > Montavont > > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > > An: mobileip > > > Betreff: [mobile-ip] new I-D on HA filtering > > > > > > Hi all, > > > > > > We just submitted a new I-D on Home Agent Filtering for Mobile = IPv6, > > > available at > > > > > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha- > filtering- > > > v6-00.txt > > > > > > It will be soon available in the IETF repertories. > > > > > > This I-D proposes a solution for the MN to set filters on its home > > > agent. Filters can be used to spread flows on different CoAs (and > > > potentially several network interfaces), and to forbid the = redirection > > > of certain flows from the home agent. > > > > > > Here is the abstract: > > > > > > Mobile IPv6 allows a MN to receive incoming packets to its home > address > > > while it is away from its home network. In a heterogeneous > environment, > > > a MN may have multiple interfaces, each with different > characteristics. > > > While a MN is in a visited network, due to the performance of the > > > interfaces or to the user preferences, the MN may want to forbid = the > > > redirection from its home agent of a kind of flow, or to indicate = a > > > target CoA for a kind of flow. > > > In this draft, we propose new mobility options that allow a MN to > > > advertise filters to its home agent. A filter is associated with a > CoA, > > > in such a way that the MN can register several CoA and can = register > > > several filters for one CoA. A filter may indicate that a flow = which > map > > > to a filter must be dropped or must be redirected to the indicated > CoA. > > > > > > Regards, > > > Nicolas > > > > > > > > > > > > > > > From exim@www1.ietf.org Wed Jul 23 10:26:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14887 for ; Wed, 23 Jul 2003 10:26:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKZJ-0004Kk-5A for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 10:26:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEQDB1016655 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 10:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKZJ-0004KY-09 for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 10:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14850 for ; Wed, 23 Jul 2003 10:26:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKZG-000537-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 10:26:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fKZB-000534-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 10:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKZ8-0004HZ-8R; Wed, 23 Jul 2003 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKYZ-0004GR-Lg for nemo@optimus.ietf.org; Wed, 23 Jul 2003 10:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14843 for ; Wed, 23 Jul 2003 10:25:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKYX-00052u-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:25:25 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fKYM-00052j-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:25:14 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6NEOaK21691; Wed, 23 Jul 2003 16:24:36 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Ryuji Wakikawa'" , , "'Soliman Hesham'" Cc: , Subject: AW: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Wed, 23 Jul 2003 16:24:35 +0200 Message-ID: <000001c35126$243cfe50$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ryuji and all > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] Im Auftrag von Ryuji Wakikawa > Gesendet: Dienstag, 22. Juli 2003 12:18 > An: Thomas.Noel@dpt-info.u-strasbg.fr > Cc: koo@comnets.uni-bremen.de; nemo@ietf.org; mobile- > ip@sunroof.eng.sun.com > Betreff: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering >=20 > Hello, >=20 > At Wed, 23 Jul 2003 15:11:36 +0200, > Thomas Noel wrote: > > > > Hi Koojana, All, > > > > > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG = to > discuss > > > > > > about this topic. > > > > > I Agree with you, we have now several drafts and it will be = interesting > > to converge towards an unique solution to solve this issue. >=20 > Can we discuss filters/policies and multipleCoAs registration = separately? IMHO, Multiple CoAs and Flow Distributions should be discussed together. = The reason is because once multiple CoAs are available, the natural = requirement=20 that follows would be to use these points of attachments efficiently. >=20 > Most of draft needs multiple CoAs registrations, but some of systems > do not want to support filters/policies on the IP layer. >=20 > Our draft(multiplecoa) deals with only multiple CoAs registration. >=20 > > Perhaps, Nemo is the ideal WG to discuss about this topic. >=20 > It might be better to keep discussing it in MIP6/MIPSHOP WG, because > NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters > whatever, NEMO can have the same feature. As Hesham suggested, I too believe that mip6 or mipshop would be the = best=20 place to discuss as it should be a extension to the MIPv6 base specification, which is not considered simultaneous bindings as in the = MIPv4 RFC. Kind Regards Koojana > If NEMO still needs further operations, then NEMO becomes the ideal = WG. >=20 > best regards, > ryuji >=20 > > > > Regards > > > > Thomas Noel > > LSIIT > > > > > > > > Kind regards > > > > > > Koojana > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: owner-mobile-ip@sunroof.eng.sun.com > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von = Nicolas > > > Montavont > > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > > An: mobileip > > > Betreff: [mobile-ip] new I-D on HA filtering > > > > > > Hi all, > > > > > > We just submitted a new I-D on Home Agent Filtering for Mobile = IPv6, > > > available at > > > > > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha- > filtering- > > > v6-00.txt > > > > > > It will be soon available in the IETF repertories. > > > > > > This I-D proposes a solution for the MN to set filters on its home > > > agent. Filters can be used to spread flows on different CoAs (and > > > potentially several network interfaces), and to forbid the = redirection > > > of certain flows from the home agent. > > > > > > Here is the abstract: > > > > > > Mobile IPv6 allows a MN to receive incoming packets to its home > address > > > while it is away from its home network. In a heterogeneous > environment, > > > a MN may have multiple interfaces, each with different > characteristics. > > > While a MN is in a visited network, due to the performance of the > > > interfaces or to the user preferences, the MN may want to forbid = the > > > redirection from its home agent of a kind of flow, or to indicate = a > > > target CoA for a kind of flow. > > > In this draft, we propose new mobility options that allow a MN to > > > advertise filters to its home agent. A filter is associated with a > CoA, > > > in such a way that the MN can register several CoA and can = register > > > several filters for one CoA. A filter may indicate that a flow = which > map > > > to a filter must be dropped or must be redirected to the indicated > CoA. > > > > > > Regards, > > > Nicolas > > > > > > > > > > > > > > > From nemo-admin@ietf.org Wed Jul 23 10:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15229 for ; Wed, 23 Jul 2003 10:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKio-0004ZG-Il; Wed, 23 Jul 2003 10:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKhp-0004Yb-Uh for nemo@optimus.ietf.org; Wed, 23 Jul 2003 10:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15127 for ; Wed, 23 Jul 2003 10:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKhn-00055A-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:34:59 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fKhX-00054y-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:34:43 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6NEXeee016684; Wed, 23 Jul 2003 23:33:40 +0900 Date: Wed, 23 Jul 2003 23:34:44 +0900 Message-ID: From: Ryuji Wakikawa To: koo@comnets.uni-bremen.de Cc: ryuji@sfc.wide.ad.jp, Thomas.Noel@dpt-info.u-strasbg.fr, H.Soliman@flarion.com, nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: AW: [nemo] WG: [mobile-ip] new I-D on HA filtering In-Reply-To: <000001c35126$243cfe50$989b6686@scoobydoo> References: <000001c35126$243cfe50$989b6686@scoobydoo> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] Im Auftrag von Ryuji Wakikawa > > Gesendet: Dienstag, 22. Juli 2003 12:18 > > An: Thomas.Noel@dpt-info.u-strasbg.fr > > Cc: koo@comnets.uni-bremen.de; nemo@ietf.org; mobile- > > ip@sunroof.eng.sun.com > > Betreff: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering > >=20 > > Hello, > >=20 > > At Wed, 23 Jul 2003 15:11:36 +0200, > > Thomas Noel wrote: > > > > > > Hi Koojana, All, > > > > > > > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to > > discuss > > > > > > > > about this topic. > > > > > > > I Agree with you, we have now several drafts and it will be interesti= ng > > > to converge towards an unique solution to solve this issue. > >=20 > > Can we discuss filters/policies and multipleCoAs registration separatel= y? >=20 > IMHO, Multiple CoAs and Flow Distributions should be discussed together. = The > reason is because once multiple CoAs are available, the natural requireme= nt=20 > that follows would be to use these points of attachments efficiently. I understand there is a way to manage filters at the IP level, but there are also other ways to manage them. If a user wants to manage filters information statically, does she/he still need to support filters management at IP layer?=20 regards ryuji > >=20 > > Most of draft needs multiple CoAs registrations, but some of systems > > do not want to support filters/policies on the IP layer. > >=20 > > Our draft(multiplecoa) deals with only multiple CoAs registration. > >=20 > > > Perhaps, Nemo is the ideal WG to discuss about this topic. > >=20 > > It might be better to keep discussing it in MIP6/MIPSHOP WG, because > > NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters > > whatever, NEMO can have the same feature. >=20 > As Hesham suggested, I too believe that mip6 or mipshop would be the best= =20 > place to discuss as it should be a extension to the MIPv6 base > specification, which is not considered simultaneous bindings as in the MI= Pv4 > RFC. >=20 > Kind Regards > Koojana >=20 > > If NEMO still needs further operations, then NEMO becomes the ideal WG. > >=20 > > best regards, > > ryuji > >=20 > > > > > > Regards > > > > > > Thomas Noel > > > LSIIT > > > > > > > > > > > Kind regards > > > > > > > > Koojana > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: owner-mobile-ip@sunroof.eng.sun.com > > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > > > > Montavont > > > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > > > An: mobileip > > > > Betreff: [mobile-ip] new I-D on HA filtering > > > > > > > > Hi all, > > > > > > > > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6, > > > > available at > > > > > > > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha- > > filtering- > > > > v6-00.txt > > > > > > > > It will be soon available in the IETF repertories. > > > > > > > > This I-D proposes a solution for the MN to set filters on its home > > > > agent. Filters can be used to spread flows on different CoAs (and > > > > potentially several network interfaces), and to forbid the redirect= ion > > > > of certain flows from the home agent. > > > > > > > > Here is the abstract: > > > > > > > > Mobile IPv6 allows a MN to receive incoming packets to its home > > address > > > > while it is away from its home network. In a heterogeneous > > environment, > > > > a MN may have multiple interfaces, each with different > > characteristics. > > > > While a MN is in a visited network, due to the performance of the > > > > interfaces or to the user preferences, the MN may want to forbid the > > > > redirection from its home agent of a kind of flow, or to indicate a > > > > target CoA for a kind of flow. > > > > In this draft, we propose new mobility options that allow a MN to > > > > advertise filters to its home agent. A filter is associated with a > > CoA, > > > > in such a way that the MN can register several CoA and can register > > > > several filters for one CoA. A filter may indicate that a flow which > > map > > > > to a filter must be dropped or must be redirected to the indicated > > CoA. > > > > > > > > Regards, > > > > Nicolas > > > > > > > > > > > > > > > > > > > > > >=20 From exim@www1.ietf.org Wed Jul 23 10:36:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15247 for ; Wed, 23 Jul 2003 10:36:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKiv-0004cr-4Q for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 10:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEa9xi017782 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 10:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKiu-0004cj-WA for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 10:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15216 for ; Wed, 23 Jul 2003 10:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKis-00055r-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 10:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fKim-00055o-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 10:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKio-0004ZG-Il; Wed, 23 Jul 2003 10:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKhp-0004Yb-Uh for nemo@optimus.ietf.org; Wed, 23 Jul 2003 10:35:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15127 for ; Wed, 23 Jul 2003 10:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKhn-00055A-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:34:59 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fKhX-00054y-00 for nemo@ietf.org; Wed, 23 Jul 2003 10:34:43 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6NEXeee016684; Wed, 23 Jul 2003 23:33:40 +0900 Date: Wed, 23 Jul 2003 23:34:44 +0900 Message-ID: From: Ryuji Wakikawa To: koo@comnets.uni-bremen.de Cc: ryuji@sfc.wide.ad.jp, Thomas.Noel@dpt-info.u-strasbg.fr, H.Soliman@flarion.com, nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: AW: [nemo] WG: [mobile-ip] new I-D on HA filtering In-Reply-To: <000001c35126$243cfe50$989b6686@scoobydoo> References: <000001c35126$243cfe50$989b6686@scoobydoo> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] Im Auftrag von Ryuji Wakikawa > > Gesendet: Dienstag, 22. Juli 2003 12:18 > > An: Thomas.Noel@dpt-info.u-strasbg.fr > > Cc: koo@comnets.uni-bremen.de; nemo@ietf.org; mobile- > > ip@sunroof.eng.sun.com > > Betreff: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering > >=20 > > Hello, > >=20 > > At Wed, 23 Jul 2003 15:11:36 +0200, > > Thomas Noel wrote: > > > > > > Hi Koojana, All, > > > > > > > > Perhaps, we should initiate a discussion in mobile-ip or nemo WG to > > discuss > > > > > > > > about this topic. > > > > > > > I Agree with you, we have now several drafts and it will be interesti= ng > > > to converge towards an unique solution to solve this issue. > >=20 > > Can we discuss filters/policies and multipleCoAs registration separatel= y? >=20 > IMHO, Multiple CoAs and Flow Distributions should be discussed together. = The > reason is because once multiple CoAs are available, the natural requireme= nt=20 > that follows would be to use these points of attachments efficiently. I understand there is a way to manage filters at the IP level, but there are also other ways to manage them. If a user wants to manage filters information statically, does she/he still need to support filters management at IP layer?=20 regards ryuji > >=20 > > Most of draft needs multiple CoAs registrations, but some of systems > > do not want to support filters/policies on the IP layer. > >=20 > > Our draft(multiplecoa) deals with only multiple CoAs registration. > >=20 > > > Perhaps, Nemo is the ideal WG to discuss about this topic. > >=20 > > It might be better to keep discussing it in MIP6/MIPSHOP WG, because > > NEMO is based on Mobile IPv6. Once MIP supports multiplecoa, filters > > whatever, NEMO can have the same feature. >=20 > As Hesham suggested, I too believe that mip6 or mipshop would be the best= =20 > place to discuss as it should be a extension to the MIPv6 base > specification, which is not considered simultaneous bindings as in the MI= Pv4 > RFC. >=20 > Kind Regards > Koojana >=20 > > If NEMO still needs further operations, then NEMO becomes the ideal WG. > >=20 > > best regards, > > ryuji > >=20 > > > > > > Regards > > > > > > Thomas Noel > > > LSIIT > > > > > > > > > > > Kind regards > > > > > > > > Koojana > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: owner-mobile-ip@sunroof.eng.sun.com > > > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] Im Auftrag von Nicolas > > > > Montavont > > > > Gesendet: Mittwoch, 23. Juli 2003 09:55 > > > > An: mobileip > > > > Betreff: [mobile-ip] new I-D on HA filtering > > > > > > > > Hi all, > > > > > > > > We just submitted a new I-D on Home Agent Filtering for Mobile IPv6, > > > > available at > > > > > > > > http://www-r2.u-strasbg.fr/~montavont/draft-montavont-mobileip-ha- > > filtering- > > > > v6-00.txt > > > > > > > > It will be soon available in the IETF repertories. > > > > > > > > This I-D proposes a solution for the MN to set filters on its home > > > > agent. Filters can be used to spread flows on different CoAs (and > > > > potentially several network interfaces), and to forbid the redirect= ion > > > > of certain flows from the home agent. > > > > > > > > Here is the abstract: > > > > > > > > Mobile IPv6 allows a MN to receive incoming packets to its home > > address > > > > while it is away from its home network. In a heterogeneous > > environment, > > > > a MN may have multiple interfaces, each with different > > characteristics. > > > > While a MN is in a visited network, due to the performance of the > > > > interfaces or to the user preferences, the MN may want to forbid the > > > > redirection from its home agent of a kind of flow, or to indicate a > > > > target CoA for a kind of flow. > > > > In this draft, we propose new mobility options that allow a MN to > > > > advertise filters to its home agent. A filter is associated with a > > CoA, > > > > in such a way that the MN can register several CoA and can register > > > > several filters for one CoA. A filter may indicate that a flow which > > map > > > > to a filter must be dropped or must be redirected to the indicated > > CoA. > > > > > > > > Regards, > > > > Nicolas > > > > > > > > > > > > > > > > > > > > > >=20 From nemo-admin@ietf.org Wed Jul 23 13:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20668 for ; Wed, 23 Jul 2003 13:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNW1-0004pZ-Jy; Wed, 23 Jul 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNVX-0004p6-Ii for nemo@optimus.ietf.org; Wed, 23 Jul 2003 13:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20636 for ; Wed, 23 Jul 2003 13:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNVV-0006Lo-00 for nemo@ietf.org; Wed, 23 Jul 2003 13:34:29 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fNVK-0006Li-00 for nemo@ietf.org; Wed, 23 Jul 2003 13:34:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05529; Wed, 23 Jul 2003 10:33:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6NHXPZ29803; Wed, 23 Jul 2003 10:33:25 -0700 X-mProtect: <200307231733> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2cx5ya; Wed, 23 Jul 2003 10:33:23 PDT Message-ID: <3F1EC6E4.FF59F3F8@iprg.nokia.com> Date: Wed, 23 Jul 2003 10:33:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > > I disagree. it is always good to have an error message > > if something goes wrong. the MR shouldnt assume the HA > > has setup forwarding for the Mobile Network, when the > > HA actually didnt. the MR has now way of figuring out > > whats wrong, if packets from the CN to MNNs are dropped > > at the HA. > > Then you do not want implicit mode at all. Pascal, please read the text under implicit mode again. Implicit: In this mode, the Mobile Router does not include either a Mobile Network Prefix Option or a Mobile Network Prefix Length Option in the Binding Update (but it does include the Home Address Option in the Destination Options header, as all Mobile Hosts do). The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned the Mobile Router. One of the possible mechanisms is where the Home Agent maintains a Pre-configured Prefix Table listing all the Mobile Network prefixes owned by a particular Mobile Router. This table is keyed on the Home Address of the Mobile Router. it says the Home Agent can use any mechanism. we suggest Prefix Table as one of the mechanisms. static routes (as you call them) is another mechanism. otherwise static routes are not really mentioned anywhere in the spec. > Because even if the HA has > some prefixes listed for that MR in its prefix table, the may not be > correct, or complete. Unless the HA lists the prefixes it knows of in > the B-Ack. Again I'm talking about the real implicit, the one with > prefix table, as opposed to static routes or IGP over MRHA. > > Consequence, if you want full checking, you need implicit, plus the list > of accepted prefixes in the B-Ack if not all. > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > whether it will ever get the right routes, it doesnt have to. all it needs to do is lookup local configuration to figure out if it is running a IGP with the mobile rputer. if the HA realizes it is not running an IGP, neither there is any information in the prefix table, then it sends 143 status code in the Binding Update if the MR sends a Binding Update using implicit mode. Vijay > or whether the MR will try > anything. So the code 143 is straight infeasible. From exim@www1.ietf.org Wed Jul 23 13:35:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20685 for ; Wed, 23 Jul 2003 13:35:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNWB-0004qT-NU for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 13:35:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHZBbZ018624 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 13:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNWB-0004qJ-G1 for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 13:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20646 for ; Wed, 23 Jul 2003 13:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNW9-0006M4-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 13:35:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fNW3-0006M1-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 13:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNW1-0004pZ-Jy; Wed, 23 Jul 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNVX-0004p6-Ii for nemo@optimus.ietf.org; Wed, 23 Jul 2003 13:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20636 for ; Wed, 23 Jul 2003 13:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNVV-0006Lo-00 for nemo@ietf.org; Wed, 23 Jul 2003 13:34:29 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fNVK-0006Li-00 for nemo@ietf.org; Wed, 23 Jul 2003 13:34:18 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05529; Wed, 23 Jul 2003 10:33:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6NHXPZ29803; Wed, 23 Jul 2003 10:33:25 -0700 X-mProtect: <200307231733> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2cx5ya; Wed, 23 Jul 2003 10:33:23 PDT Message-ID: <3F1EC6E4.FF59F3F8@iprg.nokia.com> Date: Wed, 23 Jul 2003 10:33:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > > I disagree. it is always good to have an error message > > if something goes wrong. the MR shouldnt assume the HA > > has setup forwarding for the Mobile Network, when the > > HA actually didnt. the MR has now way of figuring out > > whats wrong, if packets from the CN to MNNs are dropped > > at the HA. > > Then you do not want implicit mode at all. Pascal, please read the text under implicit mode again. Implicit: In this mode, the Mobile Router does not include either a Mobile Network Prefix Option or a Mobile Network Prefix Length Option in the Binding Update (but it does include the Home Address Option in the Destination Options header, as all Mobile Hosts do). The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned the Mobile Router. One of the possible mechanisms is where the Home Agent maintains a Pre-configured Prefix Table listing all the Mobile Network prefixes owned by a particular Mobile Router. This table is keyed on the Home Address of the Mobile Router. it says the Home Agent can use any mechanism. we suggest Prefix Table as one of the mechanisms. static routes (as you call them) is another mechanism. otherwise static routes are not really mentioned anywhere in the spec. > Because even if the HA has > some prefixes listed for that MR in its prefix table, the may not be > correct, or complete. Unless the HA lists the prefixes it knows of in > the B-Ack. Again I'm talking about the real implicit, the one with > prefix table, as opposed to static routes or IGP over MRHA. > > Consequence, if you want full checking, you need implicit, plus the list > of accepted prefixes in the B-Ack if not all. > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > whether it will ever get the right routes, it doesnt have to. all it needs to do is lookup local configuration to figure out if it is running a IGP with the mobile rputer. if the HA realizes it is not running an IGP, neither there is any information in the prefix table, then it sends 143 status code in the Binding Update if the MR sends a Binding Update using implicit mode. Vijay > or whether the MR will try > anything. So the code 143 is straight infeasible. From nemo-admin@ietf.org Wed Jul 23 17:34:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03820 for ; Wed, 23 Jul 2003 17:34:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFK-0008DE-4x; Wed, 23 Jul 2003 17:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRF3-00088M-Ei for nemo@optimus.ietf.org; Wed, 23 Jul 2003 17:33:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03761 for ; Wed, 23 Jul 2003 17:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRF1-00011q-00 for nemo@ietf.org; Wed, 23 Jul 2003 17:33:43 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19fREq-00011V-00 for nemo@ietf.org; Wed, 23 Jul 2003 17:33:32 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6NLWrMx024967; Wed, 23 Jul 2003 14:32:53 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NLWIAG019303; Wed, 23 Jul 2003 16:32:24 -0500 Message-ID: <3F1F1A84.1010403@motorola.com> Date: Thu, 24 Jul 2003 01:30:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> In-Reply-To: <3F1EC6E4.FF59F3F8@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > In this mode, the Mobile Router does not include either a > Mobile Network Prefix Option or a Mobile Network Prefix Length > Option in the Binding Update (but it does include the Home > Address Option in the Destination Options header, as all Mobile > Hosts do). The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned the Mobile Router. One of the possible mechanisms is ^by > where the Home Agent maintains a Pre-configured Prefix Table pre > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. Couldn't this table in fact be the kernel routing table? It is true that the kernel routing table is not keyed by the Home Address, and existing lookup functions will compare with the prefix (not with the gw address); but new functions can be written such as to search the routing table by the gw address instead (i.e. the MR Home Address). So, either (1) the prefix table can be filled from the existing routing table at bootup (it's 'pre-configured') or (2) the prefix table is not used at all in implicit mode, the routing table is used instead: lookup the Home Address of the Mobile Router and subsequently the associated MNP and finally match the dst address of an incoming packet to MNP. (Keeping in mind that the routing table entries to MNP through MR HoA MUST exist in the routing table when MR is at home.) (The other suggestion against elimination of Prefix Table from implicit mode is that the Prefix Table gives a sense of higher protection against attacks, in that a Prefix Table gives the HA explicit knowledge of which MNP is owned by which MR. Still, the very existence of routing table entries towards MNP through MR HoA when MR is at home might already constitute a sort of 'proof' for that ownership. I mean, if one doubts the means by which that MNP entry got in the routing table in the first place, one notices that it could have been by static routing; then it's manual configuration: highest security. With dynamic routing, they have their own security mechanisms, one of them being sharing keys (again high security), others are dynamic keying (for which standards exist) and also involve manual configuration of files. So, I would suggest that existing means to configure the routing table with MNP and MR HoA is already secure enough not to make one care about the need of a new Prefix Table for implicit mode.) > it says the Home Agent can use any mechanism. we suggest > Prefix Table as one of the mechanisms. static routes (as > you call them) is another mechanism. Ok that. So maybe end of paragraph might be(?): Another possible mechanism is where the Home Agent uses existing secure forwarding information [entries in the kernel routing table that are valid when the Mobile Router is at home] to find the association of the Mobile Network Prefix to the corresponding Home Address. I don't mean to interfere with your discussion, I'm just supporting implicit mode without prefix table. Alex GBU From nemo-admin@ietf.org Wed Jul 23 18:06:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04913 for ; Wed, 23 Jul 2003 18:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRkH-0001PY-44; Wed, 23 Jul 2003 18:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRjs-0001Kg-GN for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04810 for ; Wed, 23 Jul 2003 18:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRjp-0001Dv-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:05:33 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fRje-0001DZ-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:05:23 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA20685; Wed, 23 Jul 2003 15:04:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6NM4S409057; Wed, 23 Jul 2003 15:04:28 -0700 X-mProtect: <200307232204> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ3D8xF; Wed, 23 Jul 2003 15:04:26 PDT Message-ID: <3F1F066B.6381D4DA@iprg.nokia.com> Date: Wed, 23 Jul 2003 15:04:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1F1A84.1010403@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > In this mode, the Mobile Router does not include either a > > Mobile Network Prefix Option or a Mobile Network Prefix Length > > Option in the Binding Update (but it does include the Home > > Address Option in the Destination Options header, as all Mobile > > Hosts do). The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network Prefix(es) > > owned the Mobile Router. One of the possible mechanisms is > ^by > > > where the Home Agent maintains a Pre-configured Prefix Table > pre > > > listing all the Mobile Network prefixes owned by a particular > > Mobile Router. This table is keyed on the Home Address of the > > Mobile Router. > > Couldn't this table in fact be the kernel routing table? It is true that > the kernel routing table is not keyed by the Home Address, and existing > lookup functions will compare with the prefix (not with the gw > address); but new functions can be written such as to search the routing > table by the gw address instead (i.e. the MR Home Address). > > So, either (1) the prefix table can be filled from the existing routing > table at bootup (it's 'pre-configured') or (2) the prefix table is not > used at all in implicit mode, the routing table is used instead: lookup > the Home Address of the Mobile Router and subsequently the associated > MNP and finally match the dst address of an incoming packet to MNP. > > (Keeping in mind that the routing table entries to MNP through MR HoA > MUST exist in the routing table when MR is at home.) > > (The other suggestion against elimination of Prefix Table from implicit > mode is that the Prefix Table gives a sense of higher protection against > attacks, in that a Prefix Table gives the HA explicit knowledge of which > MNP is owned by which MR. actually it does. dynamic routing protocols dont have explicit authorization built in. most are run using shared keys. these shared keys implicitly provide authentication and authorization. Prefix table goes a step ahead and enables the HA to explicity check if a mobile router owns a particular prefix it is claiming. > Still, the very existence of routing table > entries towards MNP through MR HoA when MR is at home might already > constitute a sort of 'proof' for that ownership. I mean, if one doubts > the means by which that MNP entry got in the routing table in the first > place, one notices that it could have been by static routing; then it's > manual configuration: highest security. agree. > With dynamic routing, they have > their own security mechanisms, one of them being sharing keys (again > high security), others are dynamic keying (for which standards exist) > and also involve manual configuration of files. So, I would suggest that > existing means to configure the routing table with MNP and MR HoA is > already secure enough not to make one care about the need of a new > Prefix Table for implicit mode.) :) there is some confusion again here. Prefix Table when used with implicit mode is not used for authorization. only in explicit mode it is used by the HA for the authorization check. infact the mobile router is not claiming any prefix in the implicit mode. it is only a mechanism by which the HA, in implicit mode, can use the entries in the prefix table to create routes at the HA. it *is* an alternative to creating static routes. > > it says the Home Agent can use any mechanism. we suggest > > Prefix Table as one of the mechanisms. static routes (as > > you call them) is another mechanism. > > Ok that. So maybe end of paragraph might be(?): > > Another possible mechanism is where the Home Agent uses existing secure > forwarding information [entries in the kernel routing table that are > valid when the Mobile Router is at home] to find the association of > the Mobile Network Prefix to the corresponding Home Address. I am fine with adding this text. but note that this is possible even with the existing text. Vijay From exim@www1.ietf.org Wed Jul 23 18:06:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04941 for ; Wed, 23 Jul 2003 18:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRkR-0001QZ-J3 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NM6BF3005482 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRkQ-0001QI-0f for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 18:06:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04865 for ; Wed, 23 Jul 2003 18:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRkN-0001E2-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:06:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRkH-0001Dz-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRkH-0001PY-44; Wed, 23 Jul 2003 18:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRjs-0001Kg-GN for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04810 for ; Wed, 23 Jul 2003 18:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRjp-0001Dv-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:05:33 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fRje-0001DZ-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:05:23 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA20685; Wed, 23 Jul 2003 15:04:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6NM4S409057; Wed, 23 Jul 2003 15:04:28 -0700 X-mProtect: <200307232204> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ3D8xF; Wed, 23 Jul 2003 15:04:26 PDT Message-ID: <3F1F066B.6381D4DA@iprg.nokia.com> Date: Wed, 23 Jul 2003 15:04:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1F1A84.1010403@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > In this mode, the Mobile Router does not include either a > > Mobile Network Prefix Option or a Mobile Network Prefix Length > > Option in the Binding Update (but it does include the Home > > Address Option in the Destination Options header, as all Mobile > > Hosts do). The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network Prefix(es) > > owned the Mobile Router. One of the possible mechanisms is > ^by > > > where the Home Agent maintains a Pre-configured Prefix Table > pre > > > listing all the Mobile Network prefixes owned by a particular > > Mobile Router. This table is keyed on the Home Address of the > > Mobile Router. > > Couldn't this table in fact be the kernel routing table? It is true that > the kernel routing table is not keyed by the Home Address, and existing > lookup functions will compare with the prefix (not with the gw > address); but new functions can be written such as to search the routing > table by the gw address instead (i.e. the MR Home Address). > > So, either (1) the prefix table can be filled from the existing routing > table at bootup (it's 'pre-configured') or (2) the prefix table is not > used at all in implicit mode, the routing table is used instead: lookup > the Home Address of the Mobile Router and subsequently the associated > MNP and finally match the dst address of an incoming packet to MNP. > > (Keeping in mind that the routing table entries to MNP through MR HoA > MUST exist in the routing table when MR is at home.) > > (The other suggestion against elimination of Prefix Table from implicit > mode is that the Prefix Table gives a sense of higher protection against > attacks, in that a Prefix Table gives the HA explicit knowledge of which > MNP is owned by which MR. actually it does. dynamic routing protocols dont have explicit authorization built in. most are run using shared keys. these shared keys implicitly provide authentication and authorization. Prefix table goes a step ahead and enables the HA to explicity check if a mobile router owns a particular prefix it is claiming. > Still, the very existence of routing table > entries towards MNP through MR HoA when MR is at home might already > constitute a sort of 'proof' for that ownership. I mean, if one doubts > the means by which that MNP entry got in the routing table in the first > place, one notices that it could have been by static routing; then it's > manual configuration: highest security. agree. > With dynamic routing, they have > their own security mechanisms, one of them being sharing keys (again > high security), others are dynamic keying (for which standards exist) > and also involve manual configuration of files. So, I would suggest that > existing means to configure the routing table with MNP and MR HoA is > already secure enough not to make one care about the need of a new > Prefix Table for implicit mode.) :) there is some confusion again here. Prefix Table when used with implicit mode is not used for authorization. only in explicit mode it is used by the HA for the authorization check. infact the mobile router is not claiming any prefix in the implicit mode. it is only a mechanism by which the HA, in implicit mode, can use the entries in the prefix table to create routes at the HA. it *is* an alternative to creating static routes. > > it says the Home Agent can use any mechanism. we suggest > > Prefix Table as one of the mechanisms. static routes (as > > you call them) is another mechanism. > > Ok that. So maybe end of paragraph might be(?): > > Another possible mechanism is where the Home Agent uses existing secure > forwarding information [entries in the kernel routing table that are > valid when the Mobile Router is at home] to find the association of > the Mobile Network Prefix to the corresponding Home Address. I am fine with adding this text. but note that this is possible even with the existing text. Vijay From nemo-admin@ietf.org Wed Jul 23 18:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05946 for ; Wed, 23 Jul 2003 18:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRuu-00029B-UO; Wed, 23 Jul 2003 18:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRue-00028w-KT for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05928 for ; Wed, 23 Jul 2003 18:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRub-0001Hc-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:16:41 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19fRuQ-0001HP-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:16:30 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6NMG9B0007568; Wed, 23 Jul 2003 15:16:09 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NMFgAG012794; Wed, 23 Jul 2003 17:15:46 -0500 Message-ID: <3F1F24B0.3000101@motorola.com> Date: Thu, 24 Jul 2003 02:13:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Chan-Wah Ng , IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [in all my oppinions expressed below, sorry if lack of knowledge.] Erik Nordmark wrote: >> Agreed, it is not specifically the admin domain that gives >> complexity, but the interactions with the routing protocols used. >> The question is then do we need to open up NEMO to such complexity? >> >> > > Doesn't cause any additional complexity in the Nemo protocol AFAIK; > the ability to convey a prefix in the BU is one option and the other > option is to run an IGP over the tunnel. That should be sufficient. > > My point is that if you want the draft on multihoming to clearly > state the scenarios and issue, whether or not they effect the Nemo > protocol, they I think you should capture this high level > distinction. I tend to agree. > If you don't want to capture the scenarios and issue then I don't > think the multihoming draft is needed since the protocol document > will provide the building block (and how to run an IGP over the > tunnels can be left as an exercise to the reader?) Yes, exercise, with a deadline. > If the HA(s) and MR(s) are controlled by the same entity (for > instance an ISP) [...] > The ISP might be less likely to use prefix delegation since the MR(s) > can presumably be configured with the proper prefixes using whatever > management system the ISP uses for the routers. A-ha. But I see prefix delegation in that case too, for same reasons that DHCP is used today by an ISP that gives an IP address at home. > When there is a subscriber/provider relationship at the MR-HA tunnels > it is rather unlikely that an IGP would be used for routing (due to > the possibility of the subscriber accidentally or intentionally > messing up the IGP for everybody); it is much more likely that the > prefix in BU will be used to provide static routing. As if providing prefix in the BU would prevent a subscriber to accidentally or intentionally messing the Prefix Table at HA and thus the other MNP entries of the other subscribers. (if mechanisms exist for this prevention, and only for BU's and not for IGP, then sorry). Doesn't an IGP already have means to avoid that messing up, by the way of keys for authenticated route updates? > An issue to consider is whether it makes sense to specify a tunnel > liveness protocol so that the HA and MR can detect when one tunnel > fails and cause the other tunnel(s) to be used. Which is the domain not of NEMO IMHO. I mean it also applies to a Mobile Host that has two tunnel interfaces up, so it might better be MIP6? It's good to have tunnel liveliness reliably maintained by heartbeat checks, but maybe Mobile IPv6 has already started on that direction with Binding Cache entries expiration(?). What Mobile IPv6 hasn't is heartbeats. Anyways, yes, it's good to have this detection capability specified and leave open how it's used. > With the subscriber/provider relationship it is likely that prefix > delegation would be used. Yes. > Does that high-level description make sense to folks? Yes, mostly with respect to multi-homing. One queestion about the subscriber/provider model, is it possible to have MR at home? If yes, by what means will the HA add real entries in its real routing table when that "alien" Mobile Router is at home? Is it assumed that the HA will use information in the Prefix Table in order to pre-configure an initial routing table (because I thought it was vice-versa). Alex GBU From exim@www1.ietf.org Wed Jul 23 18:17:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05963 for ; Wed, 23 Jul 2003 18:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRv4-0002AQ-Jp for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NMHAmU008326 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRv3-0002AD-3K for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 18:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05943 for ; Wed, 23 Jul 2003 18:17:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRv0-0001Hk-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:17:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRuu-0001Hh-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRuu-00029B-UO; Wed, 23 Jul 2003 18:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRue-00028w-KT for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05928 for ; Wed, 23 Jul 2003 18:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRub-0001Hc-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:16:41 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19fRuQ-0001HP-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:16:30 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h6NMG9B0007568; Wed, 23 Jul 2003 15:16:09 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NMFgAG012794; Wed, 23 Jul 2003 17:15:46 -0500 Message-ID: <3F1F24B0.3000101@motorola.com> Date: Thu, 24 Jul 2003 02:13:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Chan-Wah Ng , IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [in all my oppinions expressed below, sorry if lack of knowledge.] Erik Nordmark wrote: >> Agreed, it is not specifically the admin domain that gives >> complexity, but the interactions with the routing protocols used. >> The question is then do we need to open up NEMO to such complexity? >> >> > > Doesn't cause any additional complexity in the Nemo protocol AFAIK; > the ability to convey a prefix in the BU is one option and the other > option is to run an IGP over the tunnel. That should be sufficient. > > My point is that if you want the draft on multihoming to clearly > state the scenarios and issue, whether or not they effect the Nemo > protocol, they I think you should capture this high level > distinction. I tend to agree. > If you don't want to capture the scenarios and issue then I don't > think the multihoming draft is needed since the protocol document > will provide the building block (and how to run an IGP over the > tunnels can be left as an exercise to the reader?) Yes, exercise, with a deadline. > If the HA(s) and MR(s) are controlled by the same entity (for > instance an ISP) [...] > The ISP might be less likely to use prefix delegation since the MR(s) > can presumably be configured with the proper prefixes using whatever > management system the ISP uses for the routers. A-ha. But I see prefix delegation in that case too, for same reasons that DHCP is used today by an ISP that gives an IP address at home. > When there is a subscriber/provider relationship at the MR-HA tunnels > it is rather unlikely that an IGP would be used for routing (due to > the possibility of the subscriber accidentally or intentionally > messing up the IGP for everybody); it is much more likely that the > prefix in BU will be used to provide static routing. As if providing prefix in the BU would prevent a subscriber to accidentally or intentionally messing the Prefix Table at HA and thus the other MNP entries of the other subscribers. (if mechanisms exist for this prevention, and only for BU's and not for IGP, then sorry). Doesn't an IGP already have means to avoid that messing up, by the way of keys for authenticated route updates? > An issue to consider is whether it makes sense to specify a tunnel > liveness protocol so that the HA and MR can detect when one tunnel > fails and cause the other tunnel(s) to be used. Which is the domain not of NEMO IMHO. I mean it also applies to a Mobile Host that has two tunnel interfaces up, so it might better be MIP6? It's good to have tunnel liveliness reliably maintained by heartbeat checks, but maybe Mobile IPv6 has already started on that direction with Binding Cache entries expiration(?). What Mobile IPv6 hasn't is heartbeats. Anyways, yes, it's good to have this detection capability specified and leave open how it's used. > With the subscriber/provider relationship it is likely that prefix > delegation would be used. Yes. > Does that high-level description make sense to folks? Yes, mostly with respect to multi-homing. One queestion about the subscriber/provider model, is it possible to have MR at home? If yes, by what means will the HA add real entries in its real routing table when that "alien" Mobile Router is at home? Is it assumed that the HA will use information in the Prefix Table in order to pre-configure an initial routing table (because I thought it was vice-versa). Alex GBU From exim@www1.ietf.org Wed Jul 23 18:23:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03819 for ; Wed, 23 Jul 2003 17:34:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFV-0008F9-Cu for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 17:34:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLYDfe031681 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 17:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFT-0008Et-Pe for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03770 for ; Wed, 23 Jul 2003 17:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRFR-000121-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 17:34:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRFL-00011y-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 17:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRFK-0008DE-4x; Wed, 23 Jul 2003 17:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRF3-00088M-Ei for nemo@optimus.ietf.org; Wed, 23 Jul 2003 17:33:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03761 for ; Wed, 23 Jul 2003 17:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRF1-00011q-00 for nemo@ietf.org; Wed, 23 Jul 2003 17:33:43 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19fREq-00011V-00 for nemo@ietf.org; Wed, 23 Jul 2003 17:33:32 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6NLWrMx024967; Wed, 23 Jul 2003 14:32:53 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NLWIAG019303; Wed, 23 Jul 2003 16:32:24 -0500 Message-ID: <3F1F1A84.1010403@motorola.com> Date: Thu, 24 Jul 2003 01:30:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> In-Reply-To: <3F1EC6E4.FF59F3F8@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > In this mode, the Mobile Router does not include either a > Mobile Network Prefix Option or a Mobile Network Prefix Length > Option in the Binding Update (but it does include the Home > Address Option in the Destination Options header, as all Mobile > Hosts do). The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned the Mobile Router. One of the possible mechanisms is ^by > where the Home Agent maintains a Pre-configured Prefix Table pre > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. Couldn't this table in fact be the kernel routing table? It is true that the kernel routing table is not keyed by the Home Address, and existing lookup functions will compare with the prefix (not with the gw address); but new functions can be written such as to search the routing table by the gw address instead (i.e. the MR Home Address). So, either (1) the prefix table can be filled from the existing routing table at bootup (it's 'pre-configured') or (2) the prefix table is not used at all in implicit mode, the routing table is used instead: lookup the Home Address of the Mobile Router and subsequently the associated MNP and finally match the dst address of an incoming packet to MNP. (Keeping in mind that the routing table entries to MNP through MR HoA MUST exist in the routing table when MR is at home.) (The other suggestion against elimination of Prefix Table from implicit mode is that the Prefix Table gives a sense of higher protection against attacks, in that a Prefix Table gives the HA explicit knowledge of which MNP is owned by which MR. Still, the very existence of routing table entries towards MNP through MR HoA when MR is at home might already constitute a sort of 'proof' for that ownership. I mean, if one doubts the means by which that MNP entry got in the routing table in the first place, one notices that it could have been by static routing; then it's manual configuration: highest security. With dynamic routing, they have their own security mechanisms, one of them being sharing keys (again high security), others are dynamic keying (for which standards exist) and also involve manual configuration of files. So, I would suggest that existing means to configure the routing table with MNP and MR HoA is already secure enough not to make one care about the need of a new Prefix Table for implicit mode.) > it says the Home Agent can use any mechanism. we suggest > Prefix Table as one of the mechanisms. static routes (as > you call them) is another mechanism. Ok that. So maybe end of paragraph might be(?): Another possible mechanism is where the Home Agent uses existing secure forwarding information [entries in the kernel routing table that are valid when the Mobile Router is at home] to find the association of the Mobile Network Prefix to the corresponding Home Address. I don't mean to interfere with your discussion, I'm just supporting implicit mode without prefix table. Alex GBU From nemo-admin@ietf.org Wed Jul 23 18:38:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06494 for ; Wed, 23 Jul 2003 18:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFF-0003Xb-0X; Wed, 23 Jul 2003 18:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFD-0003XQ-UQ for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:37:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06477 for ; Wed, 23 Jul 2003 18:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSFA-0001QA-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:37:57 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19fSF0-0001Q6-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:37:46 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6NMbHMx027979; Wed, 23 Jul 2003 15:37:17 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NMacAG024219; Wed, 23 Jul 2003 17:36:43 -0500 Message-ID: <3F1F2998.7000706@motorola.com> Date: Thu, 24 Jul 2003 02:34:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1F1A84.1010403@motorola.com> <3F1F066B.6381D4DA@iprg.nokia.com> In-Reply-To: <3F1F066B.6381D4DA@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> (The other suggestion against elimination of Prefix Table from >> implicit mode is that the Prefix Table gives a sense of higher >> protection against attacks, in that a Prefix Table gives the HA >> explicit knowledge of which MNP is owned by which MR. > > actually it does. dynamic routing protocols dont have explicit > authorization built in. most are run using shared keys. these shared > keys implicitly provide authentication and authorization. Prefix > table goes a step ahead and enables the HA to explicity check if a > mobile router owns a particular prefix it is claiming. A-ha. I wonder why they didn't do it for routing protocols to allow protection of which router can route update which prefix. >> With dynamic routing, they have their own security mechanisms, one >> of them being sharing keys (again high security), others are >> dynamic keying (for which standards exist) and also involve manual >> configuration of files. So, I would suggest that existing means to >> configure the routing table with MNP and MR HoA is already secure >> enough not to make one care about the need of a new Prefix Table >> for implicit mode.) > > :) there is some confusion again here. Prefix Table when used with > implicit mode is not used for authorization. only in explicit mode it > is used by the HA for the authorization check. infact the mobile > router is not claiming any prefix in the implicit mode. it is only a > mechanism by which the HA, in implicit mode, can use the entries in > the prefix table to create routes at the HA. it *is* an alternative > to creating static routes. Oh yes, I remember. It is that file. Sorry. Maybe we could call it Prefix File instead of Prefix Table. Prefix Table sounds too much like routing table. Or say somewhere that the Prefix Table is never dynamically updated by nobody, only manually configured at boot time. >> Another possible mechanism is where the Home Agent uses existing >> secure forwarding information [entries in the kernel routing table >> that are valid when the Mobile Router is at home] to find the >> association of the Mobile Network Prefix to the corresponding Home >> Address. > > I am fine with adding this text. but note that this is possible even > with the existing text. Ok, if in your reading that is possible, and supposedly in others' reading too, then I don't propose adding that text; shorter texts are better. Alex GBU From exim@www1.ietf.org Wed Jul 23 18:38:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06509 for ; Wed, 23 Jul 2003 18:38:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFM-0003aq-Q3 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:38:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NMc8LR013806 for nemo-archive@odin.ietf.org; Wed, 23 Jul 2003 18:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFM-0003ab-KK for nemo-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 18:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06483 for ; Wed, 23 Jul 2003 18:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSFJ-0001QG-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fSFE-0001QD-00 for nemo-web-archive@ietf.org; Wed, 23 Jul 2003 18:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFF-0003Xb-0X; Wed, 23 Jul 2003 18:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fSFD-0003XQ-UQ for nemo@optimus.ietf.org; Wed, 23 Jul 2003 18:37:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06477 for ; Wed, 23 Jul 2003 18:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fSFA-0001QA-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:37:57 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19fSF0-0001Q6-00 for nemo@ietf.org; Wed, 23 Jul 2003 18:37:46 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6NMbHMx027979; Wed, 23 Jul 2003 15:37:17 -0700 (MST) Received: from motorola.com ([163.14.20.26]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6NMacAG024219; Wed, 23 Jul 2003 17:36:43 -0500 Message-ID: <3F1F2998.7000706@motorola.com> Date: Thu, 24 Jul 2003 02:34:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "Pascal Thubert (pthubert)" , Jongkeun Na , "Kent Leung (kleung)" , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1F1A84.1010403@motorola.com> <3F1F066B.6381D4DA@iprg.nokia.com> In-Reply-To: <3F1F066B.6381D4DA@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> (The other suggestion against elimination of Prefix Table from >> implicit mode is that the Prefix Table gives a sense of higher >> protection against attacks, in that a Prefix Table gives the HA >> explicit knowledge of which MNP is owned by which MR. > > actually it does. dynamic routing protocols dont have explicit > authorization built in. most are run using shared keys. these shared > keys implicitly provide authentication and authorization. Prefix > table goes a step ahead and enables the HA to explicity check if a > mobile router owns a particular prefix it is claiming. A-ha. I wonder why they didn't do it for routing protocols to allow protection of which router can route update which prefix. >> With dynamic routing, they have their own security mechanisms, one >> of them being sharing keys (again high security), others are >> dynamic keying (for which standards exist) and also involve manual >> configuration of files. So, I would suggest that existing means to >> configure the routing table with MNP and MR HoA is already secure >> enough not to make one care about the need of a new Prefix Table >> for implicit mode.) > > :) there is some confusion again here. Prefix Table when used with > implicit mode is not used for authorization. only in explicit mode it > is used by the HA for the authorization check. infact the mobile > router is not claiming any prefix in the implicit mode. it is only a > mechanism by which the HA, in implicit mode, can use the entries in > the prefix table to create routes at the HA. it *is* an alternative > to creating static routes. Oh yes, I remember. It is that file. Sorry. Maybe we could call it Prefix File instead of Prefix Table. Prefix Table sounds too much like routing table. Or say somewhere that the Prefix Table is never dynamically updated by nobody, only manually configured at boot time. >> Another possible mechanism is where the Home Agent uses existing >> secure forwarding information [entries in the kernel routing table >> that are valid when the Mobile Router is at home] to find the >> association of the Mobile Network Prefix to the corresponding Home >> Address. > > I am fine with adding this text. but note that this is possible even > with the existing text. Ok, if in your reading that is possible, and supposedly in others' reading too, then I don't propose adding that text; shorter texts are better. Alex GBU From nemo-admin@ietf.org Thu Jul 24 00:24:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12729 for ; Thu, 24 Jul 2003 00:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXe9-0000Dy-0s; Thu, 24 Jul 2003 00:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXRI-0008Ep-3z for nemo@optimus.ietf.org; Thu, 24 Jul 2003 00:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12066 for ; Thu, 24 Jul 2003 00:10:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fXRF-000365-00 for nemo@ietf.org; Thu, 24 Jul 2003 00:10:45 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fXR4-00035h-00 for nemo@ietf.org; Thu, 24 Jul 2003 00:10:34 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6O42s5V011071; Thu, 24 Jul 2003 12:02:55 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 44BEA10E94CF; Thu, 24 Jul 2003 12:08:44 +0800 (SGT) Subject: Objectives of Multihoming Draft (was: Re: [nemo] supported multihoming scenarios) From: Chan-Wah Ng To: Erik Nordmark Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059019723.11529.12.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Jul 2003 12:08:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Erik, On Wed, 2003-07-23 at 21:41, Erik Nordmark wrote: > > Agreed, it is not specifically the admin domain that gives complexity, > > but the interactions with the routing protocols used. The question is > > then do we need to open up NEMO to such complexity? > > Doesn't cause any additional complexity in the Nemo protocol AFAIK; the > ability to convey a prefix in the BU is one option and the other > option is to run an IGP over the tunnel. That should be sufficient. > > My point is that if you want the draft on multihoming to clearly state the > scenarios and issue, whether or not they effect the Nemo protocol, > they I think you should capture this high level distinction. > Agree. The draft should capture such issue. However that does not means that the NEMO Basic solution must support. My point is: the multihoming draft is an informational document with the following two objectives: (1) to capture issues of deploying a multihomed mobile network (which definitely should include all insights the nemo WG can share, including the points you made above) (2) to identify which multihoming scenario NEMO basic solution would support. It dosen't mean that those not supported will not work with NEMO, just that it is up to the implementors to make it work (hopefully issues discussed in the document will be helpful to these implementors). Are these agreeable? > If you don't want to capture the scenarios and issue then I don't think the > multihoming draft is needed since the protocol document will provide the > building block (and how to run an IGP over the tunnels can be left as > an exercise to the reader?) > > You seem to think adding explanator text and different categorization to > the multihoming draft will somehow effect the Nemo protocol. I fail > to understand why this would be the case. > Nope, I don't think so. Again, my objectives are stated clearly above. /rgds /cwng From exim@www1.ietf.org Thu Jul 24 00:25:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12777 for ; Thu, 24 Jul 2003 00:25:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXek-0000J4-K0 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 00:24:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O4Og8i001174 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 00:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXek-0000Ij-En for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 00:24:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12730 for ; Thu, 24 Jul 2003 00:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXe9-0000Dy-0s; Thu, 24 Jul 2003 00:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fXRI-0008Ep-3z for nemo@optimus.ietf.org; Thu, 24 Jul 2003 00:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12066 for ; Thu, 24 Jul 2003 00:10:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fXRF-000365-00 for nemo@ietf.org; Thu, 24 Jul 2003 00:10:45 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fXR4-00035h-00 for nemo@ietf.org; Thu, 24 Jul 2003 00:10:34 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6O42s5V011071; Thu, 24 Jul 2003 12:02:55 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 44BEA10E94CF; Thu, 24 Jul 2003 12:08:44 +0800 (SGT) Subject: Objectives of Multihoming Draft (was: Re: [nemo] supported multihoming scenarios) From: Chan-Wah Ng To: Erik Nordmark Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059019723.11529.12.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Jul 2003 12:08:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Erik, On Wed, 2003-07-23 at 21:41, Erik Nordmark wrote: > > Agreed, it is not specifically the admin domain that gives complexity, > > but the interactions with the routing protocols used. The question is > > then do we need to open up NEMO to such complexity? > > Doesn't cause any additional complexity in the Nemo protocol AFAIK; the > ability to convey a prefix in the BU is one option and the other > option is to run an IGP over the tunnel. That should be sufficient. > > My point is that if you want the draft on multihoming to clearly state the > scenarios and issue, whether or not they effect the Nemo protocol, > they I think you should capture this high level distinction. > Agree. The draft should capture such issue. However that does not means that the NEMO Basic solution must support. My point is: the multihoming draft is an informational document with the following two objectives: (1) to capture issues of deploying a multihomed mobile network (which definitely should include all insights the nemo WG can share, including the points you made above) (2) to identify which multihoming scenario NEMO basic solution would support. It dosen't mean that those not supported will not work with NEMO, just that it is up to the implementors to make it work (hopefully issues discussed in the document will be helpful to these implementors). Are these agreeable? > If you don't want to capture the scenarios and issue then I don't think the > multihoming draft is needed since the protocol document will provide the > building block (and how to run an IGP over the tunnels can be left as > an exercise to the reader?) > > You seem to think adding explanator text and different categorization to > the multihoming draft will somehow effect the Nemo protocol. I fail > to understand why this would be the case. > Nope, I don't think so. Again, my objectives are stated clearly above. /rgds /cwng From nemo-admin@ietf.org Thu Jul 24 02:11:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25090 for ; Thu, 24 Jul 2003 02:11:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZIf-00056g-LL; Thu, 24 Jul 2003 02:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZHj-0004yp-7Y for nemo@optimus.ietf.org; Thu, 24 Jul 2003 02:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22875 for ; Thu, 24 Jul 2003 02:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fZHf-0003Xx-00 for nemo@ietf.org; Thu, 24 Jul 2003 02:08:59 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fZHT-0003Xk-00 for nemo@ietf.org; Thu, 24 Jul 2003 02:08:47 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6O60k5V013688; Thu, 24 Jul 2003 14:00:46 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 5F19110E94CF; Thu, 24 Jul 2003 14:06:35 +0800 (SGT) Subject: Re: [nemo] supported multihoming scenarios From: Chan-Wah Ng To: Alexandru Petrescu Cc: Erik Nordmark , IETF NEMO WG In-Reply-To: <3F1F24B0.3000101@motorola.com> References: <3F1F24B0.3000101@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059026794.11529.26.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Jul 2003 14:06:35 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Alex and Erik, On Thu, 2003-07-24 at 08:13, Alexandru Petrescu wrote: > > An issue to consider is whether it makes sense to specify a tunnel > > liveness protocol so that the HA and MR can detect when one tunnel > > fails and cause the other tunnel(s) to be used. > > Which is the domain not of NEMO IMHO. I mean it also applies to a > Mobile Host that has two tunnel interfaces up, so it might better be > MIP6? It's good to have tunnel liveliness reliably maintained by > heartbeat checks, but maybe Mobile IPv6 has already started on that > direction with Binding Cache entries expiration(?). What Mobile IPv6 > hasn't is heartbeats. > What can be done in place of heartbeats is to use a lifetime = period of intended heartbeat. Then the BU messages sent can by all effect be considered as heartbeats. /rgds /cwng From exim@www1.ietf.org Thu Jul 24 02:11:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25140 for ; Thu, 24 Jul 2003 02:11:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZJT-0005Di-H9 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 02:10:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O6Ap5g020048 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 02:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZJS-0005DH-DX for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 02:10:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24683 for ; Thu, 24 Jul 2003 02:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fZJO-0003YL-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 02:10:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fZJJ-0003YI-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 02:10:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZIf-00056g-LL; Thu, 24 Jul 2003 02:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fZHj-0004yp-7Y for nemo@optimus.ietf.org; Thu, 24 Jul 2003 02:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22875 for ; Thu, 24 Jul 2003 02:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fZHf-0003Xx-00 for nemo@ietf.org; Thu, 24 Jul 2003 02:08:59 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19fZHT-0003Xk-00 for nemo@ietf.org; Thu, 24 Jul 2003 02:08:47 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6O60k5V013688; Thu, 24 Jul 2003 14:00:46 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 5F19110E94CF; Thu, 24 Jul 2003 14:06:35 +0800 (SGT) Subject: Re: [nemo] supported multihoming scenarios From: Chan-Wah Ng To: Alexandru Petrescu Cc: Erik Nordmark , IETF NEMO WG In-Reply-To: <3F1F24B0.3000101@motorola.com> References: <3F1F24B0.3000101@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059026794.11529.26.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Jul 2003 14:06:35 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Alex and Erik, On Thu, 2003-07-24 at 08:13, Alexandru Petrescu wrote: > > An issue to consider is whether it makes sense to specify a tunnel > > liveness protocol so that the HA and MR can detect when one tunnel > > fails and cause the other tunnel(s) to be used. > > Which is the domain not of NEMO IMHO. I mean it also applies to a > Mobile Host that has two tunnel interfaces up, so it might better be > MIP6? It's good to have tunnel liveliness reliably maintained by > heartbeat checks, but maybe Mobile IPv6 has already started on that > direction with Binding Cache entries expiration(?). What Mobile IPv6 > hasn't is heartbeats. > What can be done in place of heartbeats is to use a lifetime = period of intended heartbeat. Then the BU messages sent can by all effect be considered as heartbeats. /rgds /cwng From nemo-admin@ietf.org Thu Jul 24 03:50:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27807 for ; Thu, 24 Jul 2003 03:50:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19faqS-000297-E9; Thu, 24 Jul 2003 03:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fapv-00028A-9g for nemo@optimus.ietf.org; Thu, 24 Jul 2003 03:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27747 for ; Thu, 24 Jul 2003 03:48:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19faps-00043p-00 for nemo@ietf.org; Thu, 24 Jul 2003 03:48:24 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19faph-00043K-00 for nemo@ietf.org; Thu, 24 Jul 2003 03:48:14 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 196AD5D120; Thu, 24 Jul 2003 16:46:31 +0900 (JST) Date: Thu, 24 Jul 2003 16:43:39 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724164339.57209d2b.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > > > Perhaps, we should initiate a discussion in mobile-ip or > > nemo WG to discuss > > > > > > about this topic. > > > > > I Agree with you, we have now several drafts and it will be > > interesting > > to converge towards an unique solution to solve this issue. > > > > Perhaps, Nemo is the ideal WG to discuss about this topic. > > => Definitely not the right WG for this. The right WG > is MIP6 or if MIPSHOP had a more flexible name/charter > it could go there as well. There is nothing NEMO specific > for this problem. Sorry, I tend to disagree. Ideally, the solution should work for both Mobile IPv6 and NEMO Basic Support. So, if design team there is, we should have people from both working groups, making sure it work for both protocol. This said, whether the report is actually done, during the IETF meeting, in the NEMO WG or another WG may not be important. Thierry From exim@www1.ietf.org Thu Jul 24 03:50:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27822 for ; Thu, 24 Jul 2003 03:50:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19farB-0002CC-0Q for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 03:49:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O7niJM008434 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 03:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19farA-0002Bx-Mj for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 03:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27796 for ; Thu, 24 Jul 2003 03:49:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19far8-00044a-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 03:49:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19far2-00044X-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 03:49:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19faqS-000297-E9; Thu, 24 Jul 2003 03:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fapv-00028A-9g for nemo@optimus.ietf.org; Thu, 24 Jul 2003 03:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27747 for ; Thu, 24 Jul 2003 03:48:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19faps-00043p-00 for nemo@ietf.org; Thu, 24 Jul 2003 03:48:24 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19faph-00043K-00 for nemo@ietf.org; Thu, 24 Jul 2003 03:48:14 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 196AD5D120; Thu, 24 Jul 2003 16:46:31 +0900 (JST) Date: Thu, 24 Jul 2003 16:43:39 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724164339.57209d2b.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BDF@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > > > Perhaps, we should initiate a discussion in mobile-ip or > > nemo WG to discuss > > > > > > about this topic. > > > > > I Agree with you, we have now several drafts and it will be > > interesting > > to converge towards an unique solution to solve this issue. > > > > Perhaps, Nemo is the ideal WG to discuss about this topic. > > => Definitely not the right WG for this. The right WG > is MIP6 or if MIPSHOP had a more flexible name/charter > it could go there as well. There is nothing NEMO specific > for this problem. Sorry, I tend to disagree. Ideally, the solution should work for both Mobile IPv6 and NEMO Basic Support. So, if design team there is, we should have people from both working groups, making sure it work for both protocol. This said, whether the report is actually done, during the IETF meeting, in the NEMO WG or another WG may not be important. Thierry From nemo-admin@ietf.org Thu Jul 24 04:11:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28339 for ; Thu, 24 Jul 2003 04:11:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbAq-0003kN-Ki; Thu, 24 Jul 2003 04:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbA3-0003cw-0t for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:09:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28306 for ; Thu, 24 Jul 2003 04:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbA0-0004CM-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:09:12 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fb9p-0004BF-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:09:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 24 Jul 2003 04:07:09 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Thu, 24 Jul 2003 04:07:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > => Definitely not the right WG for this. The right WG > > is MIP6 or if MIPSHOP had a more flexible name/charter > > it could go there as well. There is nothing NEMO specific > > for this problem. > > Sorry, I tend to disagree. Ideally, the solution should work for both > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > should have people from both working groups, making sure it work for > both protocol. This said, whether the report is actually done, during > the IETF meeting, in the NEMO WG or another WG may not be important. => Well, the problem is how to allow flow-based mobility, where the flow is a connection or more. To do this, there are 2 aspects to consider: - How to decide which flow goes where (policy) - How to manipulate a binding cache in the HA/CN to achieve this. Since we're talking about multiple CoAs, this does not apply to an MNN (node behind the MR) until an RO solution for NEMO comes up. It could certainly apply to an MR with more than one interface, but I fail to see why anything designed for a MN would not work for the MR. Having said all that, there is no WG membership in IETF :) So if the chairs decide to have a DT, which is not at all clear, then it is likely that people with interest in NEMO and MIP will be in it. ButI don't know if a DT is needed anyway. Hesham From exim@www1.ietf.org Thu Jul 24 04:11:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28354 for ; Thu, 24 Jul 2003 04:11:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbBb-0003oo-Dw for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:10:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8ApnW014672 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbBa-0003oZ-Rp for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:10:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28329 for ; Thu, 24 Jul 2003 04:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbBY-0004DE-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:10:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbBS-0004DB-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:10:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbAq-0003kN-Ki; Thu, 24 Jul 2003 04:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbA3-0003cw-0t for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:09:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28306 for ; Thu, 24 Jul 2003 04:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbA0-0004CM-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:09:12 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fb9p-0004BF-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:09:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 24 Jul 2003 04:07:09 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Thu, 24 Jul 2003 04:07:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > => Definitely not the right WG for this. The right WG > > is MIP6 or if MIPSHOP had a more flexible name/charter > > it could go there as well. There is nothing NEMO specific > > for this problem. > > Sorry, I tend to disagree. Ideally, the solution should work for both > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > should have people from both working groups, making sure it work for > both protocol. This said, whether the report is actually done, during > the IETF meeting, in the NEMO WG or another WG may not be important. => Well, the problem is how to allow flow-based mobility, where the flow is a connection or more. To do this, there are 2 aspects to consider: - How to decide which flow goes where (policy) - How to manipulate a binding cache in the HA/CN to achieve this. Since we're talking about multiple CoAs, this does not apply to an MNN (node behind the MR) until an RO solution for NEMO comes up. It could certainly apply to an MR with more than one interface, but I fail to see why anything designed for a MN would not work for the MR. Having said all that, there is no WG membership in IETF :) So if the chairs decide to have a DT, which is not at all clear, then it is likely that people with interest in NEMO and MIP will be in it. ButI don't know if a DT is needed anyway. Hesham From nemo-admin@ietf.org Thu Jul 24 04:20:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28488 for ; Thu, 24 Jul 2003 04:20:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbJV-0003y2-9A; Thu, 24 Jul 2003 04:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbIb-0003wf-Ey for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28424 for ; Thu, 24 Jul 2003 04:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbIY-0004Et-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:18:02 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbIN-0004Ep-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:17:52 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 5ED575D012; Thu, 24 Jul 2003 17:15:55 +0900 (JST) Date: Thu, 24 Jul 2003 17:13:03 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724171303.24fc0247.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > => Definitely not the right WG for this. The right WG > > > is MIP6 or if MIPSHOP had a more flexible name/charter > > > it could go there as well. There is nothing NEMO specific > > > for this problem. > > > > Sorry, I tend to disagree. Ideally, the solution should work for both > > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > > should have people from both working groups, making sure it work for > > both protocol. This said, whether the report is actually done, during > > the IETF meeting, in the NEMO WG or another WG may not be important. > > => Well, the problem is how to allow flow-based mobility, > where the flow is a connection or more. To do this, > there are 2 aspects to consider: > - How to decide which flow goes where (policy) > - How to manipulate a binding cache in the HA/CN to achieve > this. > > Since we're talking about multiple CoAs, this does not > apply to an MNN (node behind the MR) until an RO > solution for NEMO comes up. It could certainly apply to an > MR with more than one interface, but I fail to see > why anything designed for a MN would not work > for the MR. Hi Hesham, In NEMO Basic Support, one issue we already have is how to select the interface/CoA at the MR. It would probably be useful that the MNN kind of interact with the MR (to exchange policies, for instance), and this doesn't break the NEMO "Mobility Transparency to MNNs". Besides this, since NEMO Basic Support is clearly based on MIP, having the relevant extensions explicitly stating how it works at CN/HA/MR/MH is important. Let's have another BoF for interface switching and CoA selection ! :-) Just kidding - there are already so many WGs to follow :-( > Having said all that, there is no WG membership in IETF :) > So if the chairs decide to have a DT, which is not at all > clear, then it is likely that people with interest in > NEMO and MIP will be in it. ButI don't know if > a DT is needed anyway. Right. Thierry. From exim@www1.ietf.org Thu Jul 24 04:20:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28507 for ; Thu, 24 Jul 2003 04:20:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbKH-00042K-B2 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:19:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8JnRi015510 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbKH-000425-2F for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28478 for ; Thu, 24 Jul 2003 04:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbKE-0004Fg-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:19:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbK8-0004Fd-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbJV-0003y2-9A; Thu, 24 Jul 2003 04:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbIb-0003wf-Ey for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28424 for ; Thu, 24 Jul 2003 04:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbIY-0004Et-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:18:02 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbIN-0004Ep-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:17:52 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 5ED575D012; Thu, 24 Jul 2003 17:15:55 +0900 (JST) Date: Thu, 24 Jul 2003 17:13:03 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724171303.24fc0247.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > => Definitely not the right WG for this. The right WG > > > is MIP6 or if MIPSHOP had a more flexible name/charter > > > it could go there as well. There is nothing NEMO specific > > > for this problem. > > > > Sorry, I tend to disagree. Ideally, the solution should work for both > > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > > should have people from both working groups, making sure it work for > > both protocol. This said, whether the report is actually done, during > > the IETF meeting, in the NEMO WG or another WG may not be important. > > => Well, the problem is how to allow flow-based mobility, > where the flow is a connection or more. To do this, > there are 2 aspects to consider: > - How to decide which flow goes where (policy) > - How to manipulate a binding cache in the HA/CN to achieve > this. > > Since we're talking about multiple CoAs, this does not > apply to an MNN (node behind the MR) until an RO > solution for NEMO comes up. It could certainly apply to an > MR with more than one interface, but I fail to see > why anything designed for a MN would not work > for the MR. Hi Hesham, In NEMO Basic Support, one issue we already have is how to select the interface/CoA at the MR. It would probably be useful that the MNN kind of interact with the MR (to exchange policies, for instance), and this doesn't break the NEMO "Mobility Transparency to MNNs". Besides this, since NEMO Basic Support is clearly based on MIP, having the relevant extensions explicitly stating how it works at CN/HA/MR/MH is important. Let's have another BoF for interface switching and CoA selection ! :-) Just kidding - there are already so many WGs to follow :-( > Having said all that, there is no WG membership in IETF :) > So if the chairs decide to have a DT, which is not at all > clear, then it is likely that people with interest in > NEMO and MIP will be in it. ButI don't know if > a DT is needed anyway. Right. Thierry. From nemo-admin@ietf.org Thu Jul 24 04:28:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28734 for ; Thu, 24 Jul 2003 04:28:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbRG-0004Gi-9K; Thu, 24 Jul 2003 04:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbRB-0004GU-5W for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:26:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28683 for ; Thu, 24 Jul 2003 04:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbR8-0004Ir-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:26:54 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fbQx-0004Ih-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:26:43 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 24 Jul 2003 04:26:04 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Thu, 24 Jul 2003 04:25:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, > In NEMO Basic Support, one issue we already have is how to select the > interface/CoA at the MR. It would probably be useful that > the MNN kind > of interact with the MR (to exchange policies, for > instance), and this > doesn't break the NEMO "Mobility Transparency to MNNs". => I completely agree, but this seems to be quite a separate issue from the binding cache manipulation in the CN/HA. I thought about this problem for nemo but didn't think people would be interested in it. I think it's needed but basically it would belong to the "policy" bullet in my previous mail. So you could envision a MIP solution for binding cache manipulation which can be used by MNs and MRs. At the same time, NEMO could develop a solution that runs between nemo-aware MNNs and MRs to set specific policies for each nemo-aware MNN. > Let's have another BoF for interface switching and CoA > selection ! :-) => :) > Just kidding - there are already so many WGs to follow :-( => Too true! Hesham From exim@www1.ietf.org Thu Jul 24 04:28:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28754 for ; Thu, 24 Jul 2003 04:28:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbS6-0004M7-86 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:27:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8Rsk3016737 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbS6-0004Lr-0d for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:27:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28727 for ; Thu, 24 Jul 2003 04:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbS3-0004JR-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:27:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbRx-0004JM-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:27:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbRG-0004Gi-9K; Thu, 24 Jul 2003 04:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbRB-0004GU-5W for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:26:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28683 for ; Thu, 24 Jul 2003 04:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbR8-0004Ir-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:26:54 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fbQx-0004Ih-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:26:43 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 24 Jul 2003 04:26:04 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [nemo] WG: [mobile-ip] new I-D on HA filtering Date: Thu, 24 Jul 2003 04:25:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, > In NEMO Basic Support, one issue we already have is how to select the > interface/CoA at the MR. It would probably be useful that > the MNN kind > of interact with the MR (to exchange policies, for > instance), and this > doesn't break the NEMO "Mobility Transparency to MNNs". => I completely agree, but this seems to be quite a separate issue from the binding cache manipulation in the CN/HA. I thought about this problem for nemo but didn't think people would be interested in it. I think it's needed but basically it would belong to the "policy" bullet in my previous mail. So you could envision a MIP solution for binding cache manipulation which can be used by MNs and MRs. At the same time, NEMO could develop a solution that runs between nemo-aware MNNs and MRs to set specific policies for each nemo-aware MNN. > Let's have another BoF for interface switching and CoA > selection ! :-) => :) > Just kidding - there are already so many WGs to follow :-( => Too true! Hesham From nemo-admin@ietf.org Thu Jul 24 04:31:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28886 for ; Thu, 24 Jul 2003 04:31:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbUC-0004SL-1w; Thu, 24 Jul 2003 04:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbTd-0004Ps-UJ for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28808 for ; Thu, 24 Jul 2003 04:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbTb-0004Jt-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:29:27 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fbTQ-0004Ji-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:29:16 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O8SqnX026655; Thu, 24 Jul 2003 10:28:52 +0200 Message-ID: <3F1F96E2.5070804@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 10:20:50 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Soliman Hesham CC: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > => Definitely not the right WG for this. The right WG > > > is MIP6 or if MIPSHOP had a more flexible name/charter > > > it could go there as well. There is nothing NEMO specific > > > for this problem. > > > > Sorry, I tend to disagree. Ideally, the solution should work for both > > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > > should have people from both working groups, making sure it work for > > both protocol. This said, whether the report is actually done, during > > the IETF meeting, in the NEMO WG or another WG may not be important. > >=> Well, the problem is how to allow flow-based mobility, >where the flow is a connection or more. To do this, >there are 2 aspects to consider: >- How to decide which flow goes where (policy) >- How to manipulate a binding cache in the HA/CN to achieve > this. > We think that how to decide which flow goes where is out of scope of any specification. In the contrary, we clearly need to standardize how to manipulate binding cache and enventually signaling to perform flows spreading > >Since we're talking about multiple CoAs, this does not >apply to an MNN (node behind the MR) until an RO >solution for NEMO comes up. It could certainly apply to an >MR with more than one interface, but I fail to see >why anything designed for a MN would not work >for the MR. > Yes, but we have to check if the solution we will propose work in NEMO environment. > >Having said all that, there is no WG membership in IETF :) >So if the chairs decide to have a DT, which is not at all >clear, then it is likely that people with interest in >NEMO and MIP will be in it. ButI don't know if >a DT is needed anyway. > But now we have several drafts on this topic. It would be interesting to merge them in order to have a unique solution Nicolas Thomas > > >Hesham > > From exim@www1.ietf.org Thu Jul 24 04:31:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28905 for ; Thu, 24 Jul 2003 04:31:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbV0-0004X6-62 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:30:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8Usff017425 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbUy-0004Wy-Ow for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:30:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28870 for ; Thu, 24 Jul 2003 04:30:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbUv-0004Kc-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:30:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbUq-0004KZ-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:30:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbUC-0004SL-1w; Thu, 24 Jul 2003 04:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbTd-0004Ps-UJ for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28808 for ; Thu, 24 Jul 2003 04:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbTb-0004Jt-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:29:27 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fbTQ-0004Ji-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:29:16 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O8SqnX026655; Thu, 24 Jul 2003 10:28:52 +0200 Message-ID: <3F1F96E2.5070804@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 10:20:50 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Soliman Hesham CC: "'Thierry Ernst'" , nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <748C6D0A58C0F94CA63C198B6674697A01922BE8@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > => Definitely not the right WG for this. The right WG > > > is MIP6 or if MIPSHOP had a more flexible name/charter > > > it could go there as well. There is nothing NEMO specific > > > for this problem. > > > > Sorry, I tend to disagree. Ideally, the solution should work for both > > Mobile IPv6 and NEMO Basic Support. So, if design team there is, we > > should have people from both working groups, making sure it work for > > both protocol. This said, whether the report is actually done, during > > the IETF meeting, in the NEMO WG or another WG may not be important. > >=> Well, the problem is how to allow flow-based mobility, >where the flow is a connection or more. To do this, >there are 2 aspects to consider: >- How to decide which flow goes where (policy) >- How to manipulate a binding cache in the HA/CN to achieve > this. > We think that how to decide which flow goes where is out of scope of any specification. In the contrary, we clearly need to standardize how to manipulate binding cache and enventually signaling to perform flows spreading > >Since we're talking about multiple CoAs, this does not >apply to an MNN (node behind the MR) until an RO >solution for NEMO comes up. It could certainly apply to an >MR with more than one interface, but I fail to see >why anything designed for a MN would not work >for the MR. > Yes, but we have to check if the solution we will propose work in NEMO environment. > >Having said all that, there is no WG membership in IETF :) >So if the chairs decide to have a DT, which is not at all >clear, then it is likely that people with interest in >NEMO and MIP will be in it. ButI don't know if >a DT is needed anyway. > But now we have several drafts on this topic. It would be interesting to merge them in order to have a unique solution Nicolas Thomas > > >Hesham > > From nemo-admin@ietf.org Thu Jul 24 04:33:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28985 for ; Thu, 24 Jul 2003 04:33:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbW4-0004gs-Ui; Thu, 24 Jul 2003 04:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbVZ-0004gK-9L for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:31:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28902 for ; Thu, 24 Jul 2003 04:31:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbVR-0004Kh-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:31:21 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbVG-0004KW-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:31:11 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id C0EC95D211; Thu, 24 Jul 2003 17:30:36 +0900 (JST) Date: Thu, 24 Jul 2003 17:27:44 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724172744.6948a404.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > In NEMO Basic Support, one issue we already have is how to select the > > interface/CoA at the MR. It would probably be useful that > > the MNN kind > > of interact with the MR (to exchange policies, for > > instance), and this > > doesn't break the NEMO "Mobility Transparency to MNNs". > > => I completely agree, but this seems to be quite > a separate issue from the binding cache manipulation > in the CN/HA. I thought about this problem for nemo > but didn't think people would be interested in it. > I think it's needed but basically it would belong > to the "policy" bullet in my previous mail. > So you could envision a MIP solution for binding cache > manipulation which can be used by MNs and MRs. > At the same time, NEMO could develop a solution that > runs between nemo-aware MNNs and MRs to set specific > policies for each nemo-aware MNN. I perfectly agree. However, I tend to think the same people would be involved so it would make sense to do all at once, being in 2 separate documents. Let's see what other people say on the ML, including MIPv6 (or whatever) chairs. Thierry From exim@www1.ietf.org Thu Jul 24 04:33:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29003 for ; Thu, 24 Jul 2003 04:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbWp-0004lL-Gb for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8Wl1B018301 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbWp-0004l6-3M for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:32:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28957 for ; Thu, 24 Jul 2003 04:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbWm-0004LO-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:32:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbWg-0004LL-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbW4-0004gs-Ui; Thu, 24 Jul 2003 04:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbVZ-0004gK-9L for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:31:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28902 for ; Thu, 24 Jul 2003 04:31:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbVR-0004Kh-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:31:21 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbVG-0004KW-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:31:11 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id C0EC95D211; Thu, 24 Jul 2003 17:30:36 +0900 (JST) Date: Thu, 24 Jul 2003 17:27:44 +0900 From: Thierry Ernst To: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering Message-Id: <20030724172744.6948a404.ernst@sfc.wide.ad.jp> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > In NEMO Basic Support, one issue we already have is how to select the > > interface/CoA at the MR. It would probably be useful that > > the MNN kind > > of interact with the MR (to exchange policies, for > > instance), and this > > doesn't break the NEMO "Mobility Transparency to MNNs". > > => I completely agree, but this seems to be quite > a separate issue from the binding cache manipulation > in the CN/HA. I thought about this problem for nemo > but didn't think people would be interested in it. > I think it's needed but basically it would belong > to the "policy" bullet in my previous mail. > So you could envision a MIP solution for binding cache > manipulation which can be used by MNs and MRs. > At the same time, NEMO could develop a solution that > runs between nemo-aware MNNs and MRs to set specific > policies for each nemo-aware MNN. I perfectly agree. However, I tend to think the same people would be involved so it would make sense to do all at once, being in 2 separate documents. Let's see what other people say on the ML, including MIPv6 (or whatever) chairs. Thierry From nemo-admin@ietf.org Thu Jul 24 04:35:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29039 for ; Thu, 24 Jul 2003 04:35:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbY1-0004og-3x; Thu, 24 Jul 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbXI-0004md-HC for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:33:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29001 for ; Thu, 24 Jul 2003 04:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbXF-0004Lm-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:33:13 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbX4-0004LJ-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:33:03 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 89A745D224; Thu, 24 Jul 2003 17:32:28 +0900 (JST) Date: Thu, 24 Jul 2003 17:29:36 +0900 From: Thierry Ernst To: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Message-Id: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> In-Reply-To: <000901c351bc$8d589480$989b6686@scoobydoo> References: <3F1E92ED.7090906@dpt-info.u-strasbg.fr> <000901c351bc$8d589480$989b6686@scoobydoo> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Koojana Kuladinithi" wrote: > This seem like a good way to proceed, provided that others agree with this. > Additionally, I think IPv4 drafts too should be considered in this manner. I disagree. It has been decided to split Mobile IP WG in v4 and v6, so it's clearly a bad idea to consider both v4 and v6. Thierry From exim@www1.ietf.org Thu Jul 24 04:35:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29070 for ; Thu, 24 Jul 2003 04:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbYn-0004u0-TV for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:34:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8YnIj018796 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbYl-0004st-N7 for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:34:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29035 for ; Thu, 24 Jul 2003 04:34:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbYi-0004MM-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:34:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbYd-0004MJ-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:34:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbY1-0004og-3x; Thu, 24 Jul 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbXI-0004md-HC for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:33:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29001 for ; Thu, 24 Jul 2003 04:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbXF-0004Lm-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:33:13 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fbX4-0004LJ-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:33:03 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 89A745D224; Thu, 24 Jul 2003 17:32:28 +0900 (JST) Date: Thu, 24 Jul 2003 17:29:36 +0900 From: Thierry Ernst To: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Message-Id: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> In-Reply-To: <000901c351bc$8d589480$989b6686@scoobydoo> References: <3F1E92ED.7090906@dpt-info.u-strasbg.fr> <000901c351bc$8d589480$989b6686@scoobydoo> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Koojana Kuladinithi" wrote: > This seem like a good way to proceed, provided that others agree with this. > Additionally, I think IPv4 drafts too should be considered in this manner. I disagree. It has been decided to split Mobile IP WG in v4 and v6, so it's clearly a bad idea to consider both v4 and v6. Thierry From nemo-admin@ietf.org Thu Jul 24 04:37:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29126 for ; Thu, 24 Jul 2003 04:37:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbZx-0004yH-PH; Thu, 24 Jul 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbZm-0004vz-5Z for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29100 for ; Thu, 24 Jul 2003 04:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbZj-0004Mp-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:35:47 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fbZY-0004Mm-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:35:36 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O8ZTnX026764; Thu, 24 Jul 2003 10:35:29 +0200 Message-ID: <3F1F986F.4090307@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 10:27:27 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com, Soliman Hesham , Koojana Kuladinithi , Ryuji Wakikawa , Thomas.Noel@dpt-info.u-strasbg.fr Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> <20030724172744.6948a404.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >> > In NEMO Basic Support, one issue we already have is how to select the >> > interface/CoA at the MR. It would probably be useful that >> > the MNN kind >> > of interact with the MR (to exchange policies, for >> > instance), and this >> > doesn't break the NEMO "Mobility Transparency to MNNs". >> >>=> I completely agree, but this seems to be quite >>a separate issue from the binding cache manipulation >>in the CN/HA. I thought about this problem for nemo >>but didn't think people would be interested in it. >>I think it's needed but basically it would belong >>to the "policy" bullet in my previous mail. >>So you could envision a MIP solution for binding cache >>manipulation which can be used by MNs and MRs. >>At the same time, NEMO could develop a solution that >>runs between nemo-aware MNNs and MRs to set specific >>policies for each nemo-aware MNN. >> >> > >I perfectly agree. However, I tend to think the same people would be >involved so it would make sense to do all at once, being in 2 separate >documents. Let's see what other people say on the ML, including MIPv6 >(or whatever) chairs. > >Thierry > > Agree. Having a standard document in mipv6 and then write another one in NEMO if needed to describe how to use (or even enhance if necessary) multiple bindings from mipv6 Nicolas From exim@www1.ietf.org Thu Jul 24 04:37:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29144 for ; Thu, 24 Jul 2003 04:37:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbai-00054B-As for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:36:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8amrh019476 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbah-000543-WD for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:36:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29120 for ; Thu, 24 Jul 2003 04:36:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbaf-0004NS-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:36:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbaZ-0004NP-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbZx-0004yH-PH; Thu, 24 Jul 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbZm-0004vz-5Z for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29100 for ; Thu, 24 Jul 2003 04:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbZj-0004Mp-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:35:47 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fbZY-0004Mm-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:35:36 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O8ZTnX026764; Thu, 24 Jul 2003 10:35:29 +0200 Message-ID: <3F1F986F.4090307@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 10:27:27 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org, mobile-ip@sunroof.eng.sun.com, Soliman Hesham , Koojana Kuladinithi , Ryuji Wakikawa , Thomas.Noel@dpt-info.u-strasbg.fr Subject: Re: [nemo] WG: [mobile-ip] new I-D on HA filtering References: <748C6D0A58C0F94CA63C198B6674697A01922BEA@ftmail.lab.flarion.com> <20030724172744.6948a404.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >> > In NEMO Basic Support, one issue we already have is how to select the >> > interface/CoA at the MR. It would probably be useful that >> > the MNN kind >> > of interact with the MR (to exchange policies, for >> > instance), and this >> > doesn't break the NEMO "Mobility Transparency to MNNs". >> >>=> I completely agree, but this seems to be quite >>a separate issue from the binding cache manipulation >>in the CN/HA. I thought about this problem for nemo >>but didn't think people would be interested in it. >>I think it's needed but basically it would belong >>to the "policy" bullet in my previous mail. >>So you could envision a MIP solution for binding cache >>manipulation which can be used by MNs and MRs. >>At the same time, NEMO could develop a solution that >>runs between nemo-aware MNNs and MRs to set specific >>policies for each nemo-aware MNN. >> >> > >I perfectly agree. However, I tend to think the same people would be >involved so it would make sense to do all at once, being in 2 separate >documents. Let's see what other people say on the ML, including MIPv6 >(or whatever) chairs. > >Thierry > > Agree. Having a standard document in mipv6 and then write another one in NEMO if needed to describe how to use (or even enhance if necessary) multiple bindings from mipv6 Nicolas From nemo-admin@ietf.org Thu Jul 24 04:53:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29583 for ; Thu, 24 Jul 2003 04:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbpR-0005lQ-S5; Thu, 24 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbpL-0005kz-98 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29539 for ; Thu, 24 Jul 2003 04:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbpI-0004Uw-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:51:52 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fbp7-0004Ut-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:51:41 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6O8p4K08403; Thu, 24 Jul 2003 10:51:04 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Thierry Ernst'" , , Date: Thu, 24 Jul 2003 10:51:02 +0200 Message-ID: <001101c351c0$b6769020$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> Content-Transfer-Encoding: quoted-printable Subject: [nemo] AW: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Thierry What I meant was to discuss this issue for both versions, not in the = same list. But at the moment, only mobile-ip is acive (with some activity in mip6). Once mip4 is active, we can transfer mip4 discussions to that = list. Regards Koojana > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] Im Auftrag von Thierry Ernst > Gesendet: Donnerstag, 24. Juli 2003 10:30 > An: mobile-ip@sunroof.eng.sun.com; nemo@ietf.org > Betreff: Re: AW: AW: [mobile-ip] new I-D on HA filtering >=20 > "Koojana Kuladinithi" wrote: >=20 > > This seem like a good way to proceed, provided that others agree = with > this. > > Additionally, I think IPv4 drafts too should be considered in this > manner. >=20 > I disagree. It has been decided to split Mobile IP WG in v4 and v6, so > it's clearly a bad idea to consider both v4 and v6. >=20 > Thierry From exim@www1.ietf.org Thu Jul 24 04:53:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29599 for ; Thu, 24 Jul 2003 04:53:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbqG-0005pv-7t for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:52:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O8qqqO022436 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 04:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbqG-0005pn-0X for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 04:52:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29562 for ; Thu, 24 Jul 2003 04:52:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbqD-0004VN-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:52:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fbq7-0004VK-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 04:52:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbpR-0005lQ-S5; Thu, 24 Jul 2003 04:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fbpL-0005kz-98 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 04:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29539 for ; Thu, 24 Jul 2003 04:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fbpI-0004Uw-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:51:52 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fbp7-0004Ut-00 for nemo@ietf.org; Thu, 24 Jul 2003 04:51:41 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6O8p4K08403; Thu, 24 Jul 2003 10:51:04 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Thierry Ernst'" , , Date: Thu, 24 Jul 2003 10:51:02 +0200 Message-ID: <001101c351c0$b6769020$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> Content-Transfer-Encoding: quoted-printable Subject: [nemo] AW: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Thierry What I meant was to discuss this issue for both versions, not in the = same list. But at the moment, only mobile-ip is acive (with some activity in mip6). Once mip4 is active, we can transfer mip4 discussions to that = list. Regards Koojana > -----Urspr=FCngliche Nachricht----- > Von: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] Im Auftrag von Thierry Ernst > Gesendet: Donnerstag, 24. Juli 2003 10:30 > An: mobile-ip@sunroof.eng.sun.com; nemo@ietf.org > Betreff: Re: AW: AW: [mobile-ip] new I-D on HA filtering >=20 > "Koojana Kuladinithi" wrote: >=20 > > This seem like a good way to proceed, provided that others agree = with > this. > > Additionally, I think IPv4 drafts too should be considered in this > manner. >=20 > I disagree. It has been decided to split Mobile IP WG in v4 and v6, so > it's clearly a bad idea to consider both v4 and v6. >=20 > Thierry From nemo-admin@ietf.org Thu Jul 24 05:28:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00219 for ; Thu, 24 Jul 2003 05:28:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcNJ-0007C9-Nj; Thu, 24 Jul 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcMs-0007Bt-GW for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00183 for ; Thu, 24 Jul 2003 05:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcMp-0004gx-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:26:31 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fcMe-0004gk-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:26:20 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4AB915D0AB; Thu, 24 Jul 2003 18:25:33 +0900 (JST) Date: Thu, 24 Jul 2003 18:22:41 +0900 From: Thierry Ernst To: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Message-Id: <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> In-Reply-To: <001101c351c0$b6769020$989b6686@scoobydoo> References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > What I meant was to discuss this issue for both versions, not in the same > list. But at the moment, only mobile-ip is acive (with some activity in > mip6). Once mip4 is active, we can transfer mip4 discussions to that list. Well, personally, anything related to v4 is overhead. And I tend to think it's also the case for most of the other involved in this thread, so separate group of people would definitely be involved. Thierry From exim@www1.ietf.org Thu Jul 24 05:28:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00237 for ; Thu, 24 Jul 2003 05:28:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcO7-0007Lz-6w for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:27:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9RpaW028261 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:27:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcO7-0007Lk-2a for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 05:27:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00212 for ; Thu, 24 Jul 2003 05:27:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcO3-0004hm-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:27:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fcNy-0004hj-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:27:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcNJ-0007C9-Nj; Thu, 24 Jul 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcMs-0007Bt-GW for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00183 for ; Thu, 24 Jul 2003 05:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcMp-0004gx-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:26:31 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19fcMe-0004gk-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:26:20 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4AB915D0AB; Thu, 24 Jul 2003 18:25:33 +0900 (JST) Date: Thu, 24 Jul 2003 18:22:41 +0900 From: Thierry Ernst To: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Message-Id: <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> In-Reply-To: <001101c351c0$b6769020$989b6686@scoobydoo> References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > What I meant was to discuss this issue for both versions, not in the same > list. But at the moment, only mobile-ip is acive (with some activity in > mip6). Once mip4 is active, we can transfer mip4 discussions to that list. Well, personally, anything related to v4 is overhead. And I tend to think it's also the case for most of the other involved in this thread, so separate group of people would definitely be involved. Thierry From nemo-admin@ietf.org Thu Jul 24 05:38:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00521 for ; Thu, 24 Jul 2003 05:38:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcX0-0007vq-8B; Thu, 24 Jul 2003 05:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcWv-0007uh-D4 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:36:57 -0400 Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.44.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00475 for ; Thu, 24 Jul 2003 05:36:51 -0400 (EDT) Received: from dpt-info.u-strasbg.fr (nomadnet.u-strasbg.fr [130.79.90.134]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O9X6nX027467; Thu, 24 Jul 2003 11:33:06 +0200 Message-ID: <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 11:33:12 +0200 From: Thomas Noel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> In-Reply-To: <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >Well, personally, anything related to v4 is overhead. And I tend to >think it's also the case for most of the other involved in this thread, >so separate group of people would definitely be involved. > >Thierry > Agree, Thomas, Nicolas From exim@www1.ietf.org Thu Jul 24 05:38:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00537 for ; Thu, 24 Jul 2003 05:38:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcXl-0008FC-1g for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:37:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9bnrO031684 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcXk-0008Eu-R1 for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 05:37:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00510 for ; Thu, 24 Jul 2003 05:37:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcXh-0004ml-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:37:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fcXb-0004mi-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:37:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcX0-0007vq-8B; Thu, 24 Jul 2003 05:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcWv-0007uh-D4 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:36:57 -0400 Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.44.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00475 for ; Thu, 24 Jul 2003 05:36:51 -0400 (EDT) Received: from dpt-info.u-strasbg.fr (nomadnet.u-strasbg.fr [130.79.90.134]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O9X6nX027467; Thu, 24 Jul 2003 11:33:06 +0200 Message-ID: <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> Date: Thu, 24 Jul 2003 11:33:12 +0200 From: Thomas Noel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> In-Reply-To: <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >Well, personally, anything related to v4 is overhead. And I tend to >think it's also the case for most of the other involved in this thread, >so separate group of people would definitely be involved. > >Thierry > Agree, Thomas, Nicolas From nemo-admin@ietf.org Thu Jul 24 05:49:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00815 for ; Thu, 24 Jul 2003 05:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fchd-0000Fx-GL; Thu, 24 Jul 2003 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fch6-0000Fa-Ia for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00792 for ; Thu, 24 Jul 2003 05:47:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fch3-0004rL-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:47:25 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19fcgs-0004rA-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:47:14 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6O9kq6q013876; Thu, 24 Jul 2003 02:46:52 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h6O9kmPM018122; Thu, 24 Jul 2003 04:46:49 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BA3782EC86; Thu, 24 Jul 2003 11:46:47 +0200 (CEST) Message-ID: <3F1FAA7C.4070605@motorola.com> Date: Thu, 24 Jul 2003 11:44:28 +0200 From: Alexandru Petrescu Organization: Motorola Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Noel Cc: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> In-Reply-To: <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Anyone wondering what AW stands for, it's 'antwort', German for 'answer'.] > Thierry Ernst wrote: > >> Well, personally, anything related to v4 is overhead. Personally, I feel like we have left v4 behind for too long and we should have a v4 network mobility doc before engaging in multi-x efforts, for x in homes and bindings. Alex GBU From exim@www1.ietf.org Thu Jul 24 05:49:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00830 for ; Thu, 24 Jul 2003 05:49:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fciP-0000Kp-Mi for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:48:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9mnlO001280 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 05:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fciO-0000KZ-Uu for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 05:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00812 for ; Thu, 24 Jul 2003 05:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fciL-0004sE-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:48:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fciF-0004sB-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 05:48:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fchd-0000Fx-GL; Thu, 24 Jul 2003 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fch6-0000Fa-Ia for nemo@optimus.ietf.org; Thu, 24 Jul 2003 05:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00792 for ; Thu, 24 Jul 2003 05:47:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fch3-0004rL-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:47:25 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19fcgs-0004rA-00 for nemo@ietf.org; Thu, 24 Jul 2003 05:47:14 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h6O9kq6q013876; Thu, 24 Jul 2003 02:46:52 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h6O9kmPM018122; Thu, 24 Jul 2003 04:46:49 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BA3782EC86; Thu, 24 Jul 2003 11:46:47 +0200 (CEST) Message-ID: <3F1FAA7C.4070605@motorola.com> Date: Thu, 24 Jul 2003 11:44:28 +0200 From: Alexandru Petrescu Organization: Motorola Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Noel Cc: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Re: AW: AW: AW: [mobile-ip] new I-D on HA filtering References: <20030724172936.2a6421a1.ernst@sfc.wide.ad.jp> <001101c351c0$b6769020$989b6686@scoobydoo> <20030724182241.78b88f1e.ernst@sfc.wide.ad.jp> <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> In-Reply-To: <3F1FA7D8.8060502@dpt-info.u-strasbg.fr> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Anyone wondering what AW stands for, it's 'antwort', German for 'answer'.] > Thierry Ernst wrote: > >> Well, personally, anything related to v4 is overhead. Personally, I feel like we have left v4 behind for too long and we should have a v4 network mobility doc before engaging in multi-x efforts, for x in homes and bindings. Alex GBU From nemo-admin@ietf.org Thu Jul 24 09:10:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04971 for ; Thu, 24 Jul 2003 09:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffq8-00032h-Py; Thu, 24 Jul 2003 09:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffpP-00030X-Ct for nemo@optimus.ietf.org; Thu, 24 Jul 2003 09:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04882 for ; Thu, 24 Jul 2003 09:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ffpN-0005rA-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:08:13 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ffpC-0005pe-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:08:03 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6OD3Z3V027808; Thu, 24 Jul 2003 15:03:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 15:05:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Thu, 24 Jul 2003 14:05:44 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNRQLcuzsDuhL9GSTWmaLqWj/Q9hAAoX/5g From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 24 Jul 2003 13:05:46.0597 (UTC) FILETIME=[4C000950:01C351E4] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 23 juillet 2003 19:33 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > > I disagree. it is always good to have an error message > > > if something goes wrong. the MR shouldnt assume the HA > > > has setup forwarding for the Mobile Network, when the > > > HA actually didnt. the MR has now way of figuring out > > > whats wrong, if packets from the CN to MNNs are dropped > > > at the HA. > > > > Then you do not want implicit mode at all. >=20 > Pascal, >=20 > please read the text under implicit mode again. >=20 > Implicit: >=20 > In this mode, the Mobile Router does not include either a > Mobile Network Prefix Option or a Mobile Network Prefix Length > Option in the Binding Update (but it does include the Home > Address Option in the Destination Options header, as all Mobile > Hosts do). The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned the Mobile Router. One of the possible mechanisms is > where the Home Agent maintains a Pre-configured Prefix Table > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. >=20 > it says the Home Agent can use any mechanism. we suggest > Prefix Table as one of the mechanisms. static routes (as > you call them) is another mechanism. otherwise static > routes are not really mentioned anywhere in the spec. I love this text. Never asked to change it :) Just pointed out that we may find useful to differentiate implicit source (static route, prefix table and routing protocol over MRHA, the latter opening to unauthorized cases) by maybe a more precise naming? >=20 > > Because even if the HA has > > some prefixes listed for that MR in its prefix table, the may not be > > correct, or complete. Unless the HA lists the prefixes it knows of in > > the B-Ack. Again I'm talking about the real implicit, the one with > > prefix table, as opposed to static routes or IGP over MRHA. > > > > Consequence, if you want full checking, you need implicit, plus the list > > of accepted prefixes in the B-Ack if not all. > > > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > > whether it will ever get the right routes, >=20 > it doesnt have to. all it needs to do is lookup local > configuration to figure out if it is running a IGP > with the mobile rputer. if the HA realizes it is not > running an IGP, neither there is any information in > the prefix table, then it sends 143 status code in > the Binding Update if the MR sends a Binding Update > using implicit mode. >=20 You do not know if both ends are configured correctly and whether the exchange will work??? So a lot of bother for little value. Again, you need explicit to make sure of full agreement. And there's still room for a config error that would forget a prefix in the BU depending on the implementation.=20 So code 143 is a lot of effort for no big result. I'm still for removing that small text... > Vijay >=20 > > or whether the MR will try > > anything. So the code 143 is straight infeasible. From exim@www1.ietf.org Thu Jul 24 09:10:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04988 for ; Thu, 24 Jul 2003 09:10:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffqt-00038z-CJ for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 09:09:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OD9lLC012081 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 09:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffqt-00038m-8Z for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 09:09:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04958 for ; Thu, 24 Jul 2003 09:09:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ffqr-0005sP-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 09:09:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ffqm-0005sM-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 09:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffq8-00032h-Py; Thu, 24 Jul 2003 09:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ffpP-00030X-Ct for nemo@optimus.ietf.org; Thu, 24 Jul 2003 09:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04882 for ; Thu, 24 Jul 2003 09:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ffpN-0005rA-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:08:13 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19ffpC-0005pe-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:08:03 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6OD3Z3V027808; Thu, 24 Jul 2003 15:03:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 15:05:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Issue 6 Date: Thu, 24 Jul 2003 14:05:44 +0100 Message-ID: Thread-Topic: [nemo] RE: Issue 6 Thread-Index: AcNRQLcuzsDuhL9GSTWmaLqWj/Q9hAAoX/5g From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , "Kent Leung (kleung)" , "S. Felix Wu" , X-OriginalArrivalTime: 24 Jul 2003 13:05:46.0597 (UTC) FILETIME=[4C000950:01C351E4] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 23 juillet 2003 19:33 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; nemo@ietf.org > Subject: Re: [nemo] RE: Issue 6 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > > I disagree. it is always good to have an error message > > > if something goes wrong. the MR shouldnt assume the HA > > > has setup forwarding for the Mobile Network, when the > > > HA actually didnt. the MR has now way of figuring out > > > whats wrong, if packets from the CN to MNNs are dropped > > > at the HA. > > > > Then you do not want implicit mode at all. >=20 > Pascal, >=20 > please read the text under implicit mode again. >=20 > Implicit: >=20 > In this mode, the Mobile Router does not include either a > Mobile Network Prefix Option or a Mobile Network Prefix Length > Option in the Binding Update (but it does include the Home > Address Option in the Destination Options header, as all Mobile > Hosts do). The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned the Mobile Router. One of the possible mechanisms is > where the Home Agent maintains a Pre-configured Prefix Table > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. >=20 > it says the Home Agent can use any mechanism. we suggest > Prefix Table as one of the mechanisms. static routes (as > you call them) is another mechanism. otherwise static > routes are not really mentioned anywhere in the spec. I love this text. Never asked to change it :) Just pointed out that we may find useful to differentiate implicit source (static route, prefix table and routing protocol over MRHA, the latter opening to unauthorized cases) by maybe a more precise naming? >=20 > > Because even if the HA has > > some prefixes listed for that MR in its prefix table, the may not be > > correct, or complete. Unless the HA lists the prefixes it knows of in > > the B-Ack. Again I'm talking about the real implicit, the one with > > prefix table, as opposed to static routes or IGP over MRHA. > > > > Consequence, if you want full checking, you need implicit, plus the list > > of accepted prefixes in the B-Ack if not all. > > > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack time > > whether it will ever get the right routes, >=20 > it doesnt have to. all it needs to do is lookup local > configuration to figure out if it is running a IGP > with the mobile rputer. if the HA realizes it is not > running an IGP, neither there is any information in > the prefix table, then it sends 143 status code in > the Binding Update if the MR sends a Binding Update > using implicit mode. >=20 You do not know if both ends are configured correctly and whether the exchange will work??? So a lot of bother for little value. Again, you need explicit to make sure of full agreement. And there's still room for a config error that would forget a prefix in the BU depending on the implementation.=20 So code 143 is a lot of effort for no big result. I'm still for removing that small text... > Vijay >=20 > > or whether the MR will try > > anything. So the code 143 is straight infeasible. From nemo-admin@ietf.org Thu Jul 24 09:54:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06417 for ; Thu, 24 Jul 2003 09:54:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWj-0005nk-Rl; Thu, 24 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWP-0005n9-Px for nemo@optimus.ietf.org; Thu, 24 Jul 2003 09:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06320 for ; Thu, 24 Jul 2003 09:52:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgWN-0006AZ-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:52:39 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19fgWD-0006AQ-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:52:29 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6ODpaGg019658; Thu, 24 Jul 2003 06:51:36 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6ODpZQ14561; Thu, 24 Jul 2003 15:51:35 +0200 (MEST) Date: Thu, 24 Jul 2003 13:58:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Alexandru Petrescu Cc: Erik Nordmark , Chan-Wah Ng , IETF NEMO WG In-Reply-To: "Your message with ID" <3F1F24B0.3000101@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > The ISP might be less likely to use prefix delegation since the MR(s) > > can presumably be configured with the proper prefixes using whatever > > management system the ISP uses for the routers. > > A-ha. But I see prefix delegation in that case too, for same reasons > that DHCP is used today by an ISP that gives an IP address at home. If an ISP has a router (that the ISP controls) at the customer's premises than prefix delegation might make sense. But it probably makes less sense if an ISP runs a bunch of routers - some located in fixed places and others located on trains and plains. I said "less likely" trying to compare with the case with a provider/subscriber boundary between the HA(s) and MR(s) - in that case I suspect that prefix delegation would always be used. > As if providing prefix in the BU would prevent a subscriber to > accidentally or intentionally messing the Prefix Table at HA and thus > the other MNP entries of the other subscribers. (if mechanisms exist > for this prevention, and only for BU's and not for IGP, then sorry). I can't quite parse the paragraph. My point is that a mechanism for authorizing what prefixes can be "advertised" can be added as part of the BU mechanism, but might not exist in an IGP implementation. > Doesn't an IGP already have means to avoid that messing up, by the way > of keys for authenticated route updates? AFAIK this is a single key for the whole routing domain i.e. provides for authentication and authorization at the "I'm a router in the IGP" level, but that there isn't any existing mechanism to authorize particular routers to only advertise particular prefixes. But I could be wrong on this. > One queestion about the subscriber/provider model, is it possible to > have MR at home? Seems a bit odd in that case because the HA(s) will be operated by the ISP and the MR(s) by the subscriber, thus it seems unlikely that the MR will actually be on its home link. The only case I can think of is when the home link is e.g. the DSL link between a household and the ISP and the whole house goes mobile. Erik > If yes, by what means will the HA add real entries in > its real routing table when that "alien" Mobile Router is at home? Is it > assumed that the HA will use information in the Prefix Table in order to > pre-configure an initial routing table (because I thought it was > vice-versa). From exim@www1.ietf.org Thu Jul 24 09:54:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06433 for ; Thu, 24 Jul 2003 09:54:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgY3-00063f-R8 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 09:54:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ODsNrP023281 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 09:54:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgY3-00063Q-Lc for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 09:54:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06392 for ; Thu, 24 Jul 2003 09:54:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgY1-0006BI-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 09:54:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fgXw-0006BF-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 09:54:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWj-0005nk-Rl; Thu, 24 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fgWP-0005n9-Px for nemo@optimus.ietf.org; Thu, 24 Jul 2003 09:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06320 for ; Thu, 24 Jul 2003 09:52:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fgWN-0006AZ-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:52:39 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19fgWD-0006AQ-00 for nemo@ietf.org; Thu, 24 Jul 2003 09:52:29 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6ODpaGg019658; Thu, 24 Jul 2003 06:51:36 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6ODpZQ14561; Thu, 24 Jul 2003 15:51:35 +0200 (MEST) Date: Thu, 24 Jul 2003 13:58:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] supported multihoming scenarios To: Alexandru Petrescu Cc: Erik Nordmark , Chan-Wah Ng , IETF NEMO WG In-Reply-To: "Your message with ID" <3F1F24B0.3000101@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > The ISP might be less likely to use prefix delegation since the MR(s) > > can presumably be configured with the proper prefixes using whatever > > management system the ISP uses for the routers. > > A-ha. But I see prefix delegation in that case too, for same reasons > that DHCP is used today by an ISP that gives an IP address at home. If an ISP has a router (that the ISP controls) at the customer's premises than prefix delegation might make sense. But it probably makes less sense if an ISP runs a bunch of routers - some located in fixed places and others located on trains and plains. I said "less likely" trying to compare with the case with a provider/subscriber boundary between the HA(s) and MR(s) - in that case I suspect that prefix delegation would always be used. > As if providing prefix in the BU would prevent a subscriber to > accidentally or intentionally messing the Prefix Table at HA and thus > the other MNP entries of the other subscribers. (if mechanisms exist > for this prevention, and only for BU's and not for IGP, then sorry). I can't quite parse the paragraph. My point is that a mechanism for authorizing what prefixes can be "advertised" can be added as part of the BU mechanism, but might not exist in an IGP implementation. > Doesn't an IGP already have means to avoid that messing up, by the way > of keys for authenticated route updates? AFAIK this is a single key for the whole routing domain i.e. provides for authentication and authorization at the "I'm a router in the IGP" level, but that there isn't any existing mechanism to authorize particular routers to only advertise particular prefixes. But I could be wrong on this. > One queestion about the subscriber/provider model, is it possible to > have MR at home? Seems a bit odd in that case because the HA(s) will be operated by the ISP and the MR(s) by the subscriber, thus it seems unlikely that the MR will actually be on its home link. The only case I can think of is when the home link is e.g. the DSL link between a household and the ISP and the whole house goes mobile. Erik > If yes, by what means will the HA add real entries in > its real routing table when that "alien" Mobile Router is at home? Is it > assumed that the HA will use information in the Prefix Table in order to > pre-configure an initial routing table (because I thought it was > vice-versa). From nemo-admin@ietf.org Thu Jul 24 13:37:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17243 for ; Thu, 24 Jul 2003 13:37:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk0W-0001qT-NX; Thu, 24 Jul 2003 13:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk0H-0001qC-11 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 13:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17229 for ; Thu, 24 Jul 2003 13:35:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fk06-0000F2-00 for nemo@ietf.org; Thu, 24 Jul 2003 13:35:34 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fjzv-0000E9-00 for nemo@ietf.org; Thu, 24 Jul 2003 13:35:23 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA17254; Thu, 24 Jul 2003 10:32:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OHWkc01745; Thu, 24 Jul 2003 10:32:46 -0700 X-mProtect: <200307241732> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4P6lsd; Thu, 24 Jul 2003 10:32:45 PDT Message-ID: <3F20183D.5081AC11@iprg.nokia.com> Date: Thu, 24 Jul 2003 10:32:45 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Issue 10 (was Re: [nemo] RE: Issue 6) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I created a new issue 10 because we have digressed from the original issue 6. please lookup http://people.nokia.net/vijayd/nemo/issues.html for the current list of issues. "Pascal Thubert (pthubert)" wrote: > > > > > it says the Home Agent can use any mechanism. we suggest > > Prefix Table as one of the mechanisms. static routes (as > > you call them) is another mechanism. otherwise static > > routes are not really mentioned anywhere in the spec. > > I love this text. Never asked to change it :) Just pointed out that we > may find useful to differentiate implicit source (static route, prefix > table and routing protocol over MRHA, the latter opening to unauthorized > cases) by maybe a more precise naming? I am not sure. I want to keep the IGP over MR-HA tunnel separate from the rest of specification. I am not too sure that we have taken care of all the issues related to running IGP over the tunnel. if later there are any problems with it, it would be easy to deal with it. if you notice, running IGP over the MR-HA tunnel is described in section 8 and is not mentioned anywhere else in the draft. I think it is sensible to keep it that way. > > > Because even if the HA has > > > some prefixes listed for that MR in its prefix table, the may not be > > > correct, or complete. Unless the HA lists the prefixes it knows of > in > > > the B-Ack. Again I'm talking about the real implicit, the one with > > > prefix table, as opposed to static routes or IGP over MRHA. > > > > > > Consequence, if you want full checking, you need implicit, plus the > list > > > of accepted prefixes in the B-Ack if not all. > > > > > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack > time > > > whether it will ever get the right routes, > > > > it doesnt have to. all it needs to do is lookup local > > configuration to figure out if it is running a IGP > > with the mobile rputer. if the HA realizes it is not > > running an IGP, neither there is any information in > > the prefix table, then it sends 143 status code in > > the Binding Update if the MR sends a Binding Update > > using implicit mode. > > > > You do not know if both ends are configured correctly and whether the > exchange will work??? agree, you can never be sure about that. > So a lot of bother for little value. ??? since we can never be sure if things at both end are configured correctly, we need an explicit error status in the Binding Ack (in the implicit mode) so that the MR does not assume everything is fine at the HA, when the HA couldnt actually figure out the prefix corresponding to the MR. > Again, you need explicit to make sure of full agreement. And there's > still room for a config error that would forget a prefix in the BU > depending on the implementation. > > So code 143 is a lot of effort for no big result. could be. but I think it shouldnt be removed. Vijay From exim@www1.ietf.org Thu Jul 24 13:39:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17300 for ; Thu, 24 Jul 2003 13:39:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk3E-0002Ba-KR for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 13:38:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OHcmDl008398 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 13:38:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk3D-0002BN-3o for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 13:38:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17292 for ; Thu, 24 Jul 2003 13:38:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fk3B-0000Fs-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 13:38:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fk35-0000FH-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 13:38:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk0W-0001qT-NX; Thu, 24 Jul 2003 13:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk0H-0001qC-11 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 13:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17229 for ; Thu, 24 Jul 2003 13:35:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fk06-0000F2-00 for nemo@ietf.org; Thu, 24 Jul 2003 13:35:34 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fjzv-0000E9-00 for nemo@ietf.org; Thu, 24 Jul 2003 13:35:23 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA17254; Thu, 24 Jul 2003 10:32:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OHWkc01745; Thu, 24 Jul 2003 10:32:46 -0700 X-mProtect: <200307241732> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4P6lsd; Thu, 24 Jul 2003 10:32:45 PDT Message-ID: <3F20183D.5081AC11@iprg.nokia.com> Date: Thu, 24 Jul 2003 10:32:45 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Issue 10 (was Re: [nemo] RE: Issue 6) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I created a new issue 10 because we have digressed from the original issue 6. please lookup http://people.nokia.net/vijayd/nemo/issues.html for the current list of issues. "Pascal Thubert (pthubert)" wrote: > > > > > it says the Home Agent can use any mechanism. we suggest > > Prefix Table as one of the mechanisms. static routes (as > > you call them) is another mechanism. otherwise static > > routes are not really mentioned anywhere in the spec. > > I love this text. Never asked to change it :) Just pointed out that we > may find useful to differentiate implicit source (static route, prefix > table and routing protocol over MRHA, the latter opening to unauthorized > cases) by maybe a more precise naming? I am not sure. I want to keep the IGP over MR-HA tunnel separate from the rest of specification. I am not too sure that we have taken care of all the issues related to running IGP over the tunnel. if later there are any problems with it, it would be easy to deal with it. if you notice, running IGP over the MR-HA tunnel is described in section 8 and is not mentioned anywhere else in the draft. I think it is sensible to keep it that way. > > > Because even if the HA has > > > some prefixes listed for that MR in its prefix table, the may not be > > > correct, or complete. Unless the HA lists the prefixes it knows of > in > > > the B-Ack. Again I'm talking about the real implicit, the one with > > > prefix table, as opposed to static routes or IGP over MRHA. > > > > > > Consequence, if you want full checking, you need implicit, plus the > list > > > of accepted prefixes in the B-Ack if not all. > > > > > > In the latter case, (IGP over MRHA) the HA can not know at B-Ack > time > > > whether it will ever get the right routes, > > > > it doesnt have to. all it needs to do is lookup local > > configuration to figure out if it is running a IGP > > with the mobile rputer. if the HA realizes it is not > > running an IGP, neither there is any information in > > the prefix table, then it sends 143 status code in > > the Binding Update if the MR sends a Binding Update > > using implicit mode. > > > > You do not know if both ends are configured correctly and whether the > exchange will work??? agree, you can never be sure about that. > So a lot of bother for little value. ??? since we can never be sure if things at both end are configured correctly, we need an explicit error status in the Binding Ack (in the implicit mode) so that the MR does not assume everything is fine at the HA, when the HA couldnt actually figure out the prefix corresponding to the MR. > Again, you need explicit to make sure of full agreement. And there's > still room for a config error that would forget a prefix in the BU > depending on the implementation. > > So code 143 is a lot of effort for no big result. could be. but I think it shouldnt be removed. Vijay From nemo-admin@ietf.org Thu Jul 24 13:52:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18308 for ; Thu, 24 Jul 2003 13:52:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkF2-0002qk-Vu; Thu, 24 Jul 2003 13:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkEd-0002pA-Gu for nemo@optimus.ietf.org; Thu, 24 Jul 2003 13:50:35 -0400 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18215 for ; Thu, 24 Jul 2003 13:50:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA18038; Thu, 24 Jul 2003 10:49:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OHnpW23485; Thu, 24 Jul 2003 10:49:51 -0700 X-mProtect: <200307241749> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEgCBc6; Thu, 24 Jul 2003 10:49:49 PDT Message-ID: <3F201C3E.591DB3D6@iprg.nokia.com> Date: Thu, 24 Jul 2003 10:49:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: pthubert@cisco.com, ernst@sfc.wide.ad.jp, tj@kniveton.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 6 - moving forward. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I had proposed the following text when Jongkeun first raised the issue. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. Ryuji later modified this so that the same prefix is not conveyed both through the Binding Update and an IGP update. you can do route updates through both mechanisms at the same time, but for different mobile network prefixes. When the Mobile Router and the Home Agent exchange routes of specific mobile network prefixes through routing protocol updates, the Home Agent MUST NOT create the routes of the mobile network prefixes to the Mobile Router when the Binding Update from the Mobile Router is received. The Mobile Router also SHOULD NOT include the mobile network prefixes exchanged by routing protocol in the Binding Update. The routes of the mobile network prefixes to the Mobile Router SHOULD be created at the Home Agent through routing protocol updates. I think this is a good compromise. I am fine with it. but Pascal has an objection > It is (and it should stay) up to the admin of the router to decide, in > case of a same prefix advertised by multiple IGPs, to select which > source is preferred. The way this is done is implementation dependent. > Because it is a router setting, not something in a protocol. MIP does > not have to be any different. Pascal favors not having any text at all. any opinions on how to proceed? Vijay From exim@www1.ietf.org Thu Jul 24 13:52:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18343 for ; Thu, 24 Jul 2003 13:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkGB-0002vZ-OW for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 13:52:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OHqBbA011247 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 13:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkGB-0002vK-Jq for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 13:52:11 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18309 for ; Thu, 24 Jul 2003 13:52:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkF2-0002qk-Vu; Thu, 24 Jul 2003 13:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkEd-0002pA-Gu for nemo@optimus.ietf.org; Thu, 24 Jul 2003 13:50:35 -0400 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18215 for ; Thu, 24 Jul 2003 13:50:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA18038; Thu, 24 Jul 2003 10:49:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OHnpW23485; Thu, 24 Jul 2003 10:49:51 -0700 X-mProtect: <200307241749> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEgCBc6; Thu, 24 Jul 2003 10:49:49 PDT Message-ID: <3F201C3E.591DB3D6@iprg.nokia.com> Date: Thu, 24 Jul 2003 10:49:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: pthubert@cisco.com, ernst@sfc.wide.ad.jp, tj@kniveton.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 6 - moving forward. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I had proposed the following text when Jongkeun first raised the issue. When the Mobile Router and the Home Agent exchange routes through routing protocol updates, the Home Agent MUST NOT create routes to the Mobile network when the Binding Update from the Mobile Router is received. The Mobile Router also MUST NOT include any prefix information in the Binding Update. Any routes to the Mobile Network are created at the Home Agent through routing protocol updates. Ryuji later modified this so that the same prefix is not conveyed both through the Binding Update and an IGP update. you can do route updates through both mechanisms at the same time, but for different mobile network prefixes. When the Mobile Router and the Home Agent exchange routes of specific mobile network prefixes through routing protocol updates, the Home Agent MUST NOT create the routes of the mobile network prefixes to the Mobile Router when the Binding Update from the Mobile Router is received. The Mobile Router also SHOULD NOT include the mobile network prefixes exchanged by routing protocol in the Binding Update. The routes of the mobile network prefixes to the Mobile Router SHOULD be created at the Home Agent through routing protocol updates. I think this is a good compromise. I am fine with it. but Pascal has an objection > It is (and it should stay) up to the admin of the router to decide, in > case of a same prefix advertised by multiple IGPs, to select which > source is preferred. The way this is done is implementation dependent. > Because it is a router setting, not something in a protocol. MIP does > not have to be any different. Pascal favors not having any text at all. any opinions on how to proceed? Vijay From nemo-admin@ietf.org Thu Jul 24 14:11:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19256 for ; Thu, 24 Jul 2003 14:11:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkXR-0003a8-Gx; Thu, 24 Jul 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkWZ-0003YZ-IO for nemo@optimus.ietf.org; Thu, 24 Jul 2003 14:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19176 for ; Thu, 24 Jul 2003 14:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkWX-0000Z4-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:09:05 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fkWM-0000Yp-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:08:54 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18713; Thu, 24 Jul 2003 11:08:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OI8FO09969; Thu, 24 Jul 2003 11:08:15 -0700 X-mProtect: <200307241808> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdESCavT; Thu, 24 Jul 2003 11:08:13 PDT Message-ID: <3F20208E.B362BEE1@iprg.nokia.com> Date: Thu, 24 Jul 2003 11:08:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Alexandru Petrescu , Chan-Wah Ng , IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > > Doesn't an IGP already have means to avoid that messing up, by the way > > of keys for authenticated route updates? > > AFAIK this is a single key for the whole routing domain i.e. provides for > authentication and authorization at the "I'm a router in the IGP" level, > but that there isn't any existing mechanism to authorize particular routers > to only advertise particular prefixes. > But I could be wrong on this. this is my understanding too. and for the NEMO protocol (when not using IGP over the MR-HA tunnel), we have defined something called the Prefix Table at the HA. the HA checks the Prefix Table to see if a particular MR is authorized for the prefixes it claims. this is necessary to prevent a misbehaving MR from claiming prefixes that belong to another MR. Vijay From exim@www1.ietf.org Thu Jul 24 14:11:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19273 for ; Thu, 24 Jul 2003 14:11:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkYF-0003cp-St for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 14:10:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIApO5013929 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 14:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkYF-0003ca-Nt for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 14:10:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19243 for ; Thu, 24 Jul 2003 14:10:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkYD-0000aH-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 14:10:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fkY7-0000aE-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 14:10:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkXR-0003a8-Gx; Thu, 24 Jul 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkWZ-0003YZ-IO for nemo@optimus.ietf.org; Thu, 24 Jul 2003 14:09:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19176 for ; Thu, 24 Jul 2003 14:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkWX-0000Z4-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:09:05 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fkWM-0000Yp-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:08:54 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18713; Thu, 24 Jul 2003 11:08:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OI8FO09969; Thu, 24 Jul 2003 11:08:15 -0700 X-mProtect: <200307241808> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdESCavT; Thu, 24 Jul 2003 11:08:13 PDT Message-ID: <3F20208E.B362BEE1@iprg.nokia.com> Date: Thu, 24 Jul 2003 11:08:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Alexandru Petrescu , Chan-Wah Ng , IETF NEMO WG Subject: Re: [nemo] supported multihoming scenarios References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > > Doesn't an IGP already have means to avoid that messing up, by the way > > of keys for authenticated route updates? > > AFAIK this is a single key for the whole routing domain i.e. provides for > authentication and authorization at the "I'm a router in the IGP" level, > but that there isn't any existing mechanism to authorize particular routers > to only advertise particular prefixes. > But I could be wrong on this. this is my understanding too. and for the NEMO protocol (when not using IGP over the MR-HA tunnel), we have defined something called the Prefix Table at the HA. the HA checks the Prefix Table to see if a particular MR is authorized for the prefixes it claims. this is necessary to prevent a misbehaving MR from claiming prefixes that belong to another MR. Vijay From nemo-admin@ietf.org Thu Jul 24 14:13:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19364 for ; Thu, 24 Jul 2003 14:13:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkZN-0003jx-DI; Thu, 24 Jul 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkYP-0003f9-P3 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 14:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19248 for ; Thu, 24 Jul 2003 14:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkYN-0000aM-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:10:59 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fkYC-0000a4-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:10:48 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA19310; Thu, 24 Jul 2003 11:10:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OIABR12606; Thu, 24 Jul 2003 11:10:11 -0700 X-mProtect: <200307241810> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5A5Soe; Thu, 24 Jul 2003 11:10:09 PDT Message-ID: <3F202102.E1ADED05@iprg.nokia.com> Date: Thu, 24 Jul 2003 11:10:10 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: Erik Nordmark , IETF NEMO WG References: <1059019723.11529.12.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Objectives of Multihoming Draft (was: Re: [nemo] supportedmultihoming scenarios) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Agree. The draft should capture such issue. However that does not > means that the NEMO Basic solution must support. My point is: the > multihoming draft is an informational document with the following two > objectives: > > (1) to capture issues of deploying a multihomed mobile network (which > definitely should include all insights the nemo WG can share, including > the points you made above) > > (2) to identify which multihoming scenario NEMO basic solution would > support. It dosen't mean that those not supported will not work with > NEMO, just that it is up to the implementors to make it work (hopefully > issues discussed in the document will be helpful to these implementors). > > Are these agreeable? this sounds good. Vijay From exim@www1.ietf.org Thu Jul 24 14:13:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19380 for ; Thu, 24 Jul 2003 14:13:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fka7-0003uR-Lk for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 14:12:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIClkr015021 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 14:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fka7-0003uC-H4 for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 14:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19353 for ; Thu, 24 Jul 2003 14:12:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fka5-0000br-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 14:12:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fkZz-0000bo-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 14:12:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkZN-0003jx-DI; Thu, 24 Jul 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkYP-0003f9-P3 for nemo@optimus.ietf.org; Thu, 24 Jul 2003 14:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19248 for ; Thu, 24 Jul 2003 14:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkYN-0000aM-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:10:59 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fkYC-0000a4-00 for nemo@ietf.org; Thu, 24 Jul 2003 14:10:48 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA19310; Thu, 24 Jul 2003 11:10:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6OIABR12606; Thu, 24 Jul 2003 11:10:11 -0700 X-mProtect: <200307241810> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5A5Soe; Thu, 24 Jul 2003 11:10:09 PDT Message-ID: <3F202102.E1ADED05@iprg.nokia.com> Date: Thu, 24 Jul 2003 11:10:10 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: Erik Nordmark , IETF NEMO WG References: <1059019723.11529.12.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Objectives of Multihoming Draft (was: Re: [nemo] supportedmultihoming scenarios) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > > Agree. The draft should capture such issue. However that does not > means that the NEMO Basic solution must support. My point is: the > multihoming draft is an informational document with the following two > objectives: > > (1) to capture issues of deploying a multihomed mobile network (which > definitely should include all insights the nemo WG can share, including > the points you made above) > > (2) to identify which multihoming scenario NEMO basic solution would > support. It dosen't mean that those not supported will not work with > NEMO, just that it is up to the implementors to make it work (hopefully > issues discussed in the document will be helpful to these implementors). > > Are these agreeable? this sounds good. Vijay From nemo-admin@ietf.org Thu Jul 24 17:42:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02227 for ; Thu, 24 Jul 2003 17:42:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnpe-00084E-4J; Thu, 24 Jul 2003 17:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnp3-00083r-LE for nemo@optimus.ietf.org; Thu, 24 Jul 2003 17:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02165 for ; Thu, 24 Jul 2003 17:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnp1-0002ZA-00 for nemo@ietf.org; Thu, 24 Jul 2003 17:40:23 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19fnoq-0002Ym-00 for nemo@ietf.org; Thu, 24 Jul 2003 17:40:12 -0400 Received: from [64.36.73.246] (home6.kniveton.com [64.36.73.246]) by multihop.net (8.12.9/8.12.9) with ESMTP id h6OLeSql035792 for ; Thu, 24 Jul 2003 14:40:28 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Jul 2003 14:39:02 -0700 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] New NEMO Web Page URL Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, The supplementary web page has been relocated. Thanks to our friends on the Motorola team for keeping it running until now! The new URL is: http://www.mobilenetworks.org/nemo/ I have tried to update the links to the latest drafts from the IETF repository. I was also able to fish some of the text documents out of the Google cache and convert them from their weird HTML back into text. The rest of the documents should be there soon. As for the videos, I am trying to arrange to put them on a faster server that is closer to the backbone so they won't demolish our poor T1... Thanks... and have fun TJ From exim@www1.ietf.org Thu Jul 24 17:42:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02243 for ; Thu, 24 Jul 2003 17:42:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnqU-0008AT-Rf for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 17:41:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLfsS6031391 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 17:41:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnqU-0008AE-N8 for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 17:41:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02219 for ; Thu, 24 Jul 2003 17:41:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnqS-0002Zu-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 17:41:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fnqM-0002Zr-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 17:41:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnpe-00084E-4J; Thu, 24 Jul 2003 17:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnp3-00083r-LE for nemo@optimus.ietf.org; Thu, 24 Jul 2003 17:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02165 for ; Thu, 24 Jul 2003 17:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnp1-0002ZA-00 for nemo@ietf.org; Thu, 24 Jul 2003 17:40:23 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19fnoq-0002Ym-00 for nemo@ietf.org; Thu, 24 Jul 2003 17:40:12 -0400 Received: from [64.36.73.246] (home6.kniveton.com [64.36.73.246]) by multihop.net (8.12.9/8.12.9) with ESMTP id h6OLeSql035792 for ; Thu, 24 Jul 2003 14:40:28 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Jul 2003 14:39:02 -0700 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] New NEMO Web Page URL Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, The supplementary web page has been relocated. Thanks to our friends on the Motorola team for keeping it running until now! The new URL is: http://www.mobilenetworks.org/nemo/ I have tried to update the links to the latest drafts from the IETF repository. I was also able to fish some of the text documents out of the Google cache and convert them from their weird HTML back into text. The rest of the documents should be there soon. As for the videos, I am trying to arrange to put them on a faster server that is closer to the backbone so they won't demolish our poor T1... Thanks... and have fun TJ From nemo-admin@ietf.org Thu Jul 24 18:26:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04669 for ; Thu, 24 Jul 2003 18:26:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foWD-00020U-Cr; Thu, 24 Jul 2003 18:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foVe-0001zi-6J for nemo@optimus.ietf.org; Thu, 24 Jul 2003 18:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04639 for ; Thu, 24 Jul 2003 18:24:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foVb-0002s8-00 for nemo@ietf.org; Thu, 24 Jul 2003 18:24:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19foVQ-0002s0-00 for nemo@ietf.org; Thu, 24 Jul 2003 18:24:12 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2003 15:23:38 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6OMNZQk015950; Thu, 24 Jul 2003 15:23:35 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJO73999; Thu, 24 Jul 2003 15:19:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jul 2003 15:23:22 -0700 To: Alexandru Petrescu From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org In-Reply-To: <3F1F1A84.1010403@motorola.com> References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The Prefix Table seems to be overloaded functionally. Let me see if I got this right? In Implicit Mode, MNPs are preconfigured in Prefix Table for HA to inject routes during BU. Also Prefix Table is used to authorize IGP routing updates to prevent incorrect routes from being propagated by HA. In Explicit Network Mode, Prefix Table is used to authorized MNPs in options. In Explicit Prefix Length Mode, Prefix Table is not used. Wondering if we can try this? Define the functional role of the table or database, such as MNP Injection DB and MNP Authorization DB. It may be implemented as one table or not should not matter. In Implicit Mode, HA will insert routes from the MNP Injection DB. I don't think the MNP Authorization DB is needed for IGP in the base protocol. Folks can implement this if desired. But this is really beyond current router to router behavior as been pointed out. In Explicit Prefix Mode, the MNP Authorization DB is used to validate MNPs in BU option. This may help clarify some confusions in the discussions. And hope it doesn't add to it. :) Kent At 01:30 AM 7/24/2003 +0200, Alexandru Petrescu wrote: >Vijay Devarapalli wrote: >> In this mode, the Mobile Router does not include either a >> Mobile Network Prefix Option or a Mobile Network Prefix Length >> Option in the Binding Update (but it does include the Home >> Address Option in the Destination Options header, as all Mobile >> Hosts do). The Home Agent can use any mechanism (not defined >> in this document) to determine the Mobile Network Prefix(es) >> owned the Mobile Router. One of the possible mechanisms is > ^by > >> where the Home Agent maintains a Pre-configured Prefix Table > pre > >> listing all the Mobile Network prefixes owned by a particular >> Mobile Router. This table is keyed on the Home Address of the >> Mobile Router. > >Couldn't this table in fact be the kernel routing table? It is true that >the kernel routing table is not keyed by the Home Address, and existing >lookup functions will compare with the prefix (not with the gw >address); but new functions can be written such as to search the routing >table by the gw address instead (i.e. the MR Home Address). > >So, either (1) the prefix table can be filled from the existing routing >table at bootup (it's 'pre-configured') or (2) the prefix table is not >used at all in implicit mode, the routing table is used instead: lookup >the Home Address of the Mobile Router and subsequently the associated >MNP and finally match the dst address of an incoming packet to MNP. > >(Keeping in mind that the routing table entries to MNP through MR HoA > MUST exist in the routing table when MR is at home.) > >(The other suggestion against elimination of Prefix Table from implicit >mode is that the Prefix Table gives a sense of higher protection against >attacks, in that a Prefix Table gives the HA explicit knowledge of which >MNP is owned by which MR. Still, the very existence of routing table >entries towards MNP through MR HoA when MR is at home might already >constitute a sort of 'proof' for that ownership. I mean, if one doubts >the means by which that MNP entry got in the routing table in the first >place, one notices that it could have been by static routing; then it's >manual configuration: highest security. With dynamic routing, they have >their own security mechanisms, one of them being sharing keys (again >high security), others are dynamic keying (for which standards exist) >and also involve manual configuration of files. So, I would suggest that >existing means to configure the routing table with MNP and MR HoA is >already secure enough not to make one care about the need of a new >Prefix Table for implicit mode.) > >>it says the Home Agent can use any mechanism. we suggest >>Prefix Table as one of the mechanisms. static routes (as >>you call them) is another mechanism. > >Ok that. So maybe end of paragraph might be(?): > >Another possible mechanism is where the Home Agent uses existing secure >forwarding information [entries in the kernel routing table that are >valid when the Mobile Router is at home] to find the association of >the Mobile Network Prefix to the corresponding Home Address. > >I don't mean to interfere with your discussion, I'm just supporting >implicit mode without prefix table. > >Alex >GBU From exim@www1.ietf.org Thu Jul 24 18:26:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04688 for ; Thu, 24 Jul 2003 18:26:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foWz-00027O-R5 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 18:25:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OMPnHU008136 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 18:25:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foWz-000279-Mk for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:25:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04661 for ; Thu, 24 Jul 2003 18:25:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foWw-0002sU-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 18:25:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19foWr-0002sR-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 18:25:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foWD-00020U-Cr; Thu, 24 Jul 2003 18:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foVe-0001zi-6J for nemo@optimus.ietf.org; Thu, 24 Jul 2003 18:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04639 for ; Thu, 24 Jul 2003 18:24:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foVb-0002s8-00 for nemo@ietf.org; Thu, 24 Jul 2003 18:24:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19foVQ-0002s0-00 for nemo@ietf.org; Thu, 24 Jul 2003 18:24:12 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2003 15:23:38 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6OMNZQk015950; Thu, 24 Jul 2003 15:23:35 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJO73999; Thu, 24 Jul 2003 15:19:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jul 2003 15:23:22 -0700 To: Alexandru Petrescu From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org In-Reply-To: <3F1F1A84.1010403@motorola.com> References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The Prefix Table seems to be overloaded functionally. Let me see if I got this right? In Implicit Mode, MNPs are preconfigured in Prefix Table for HA to inject routes during BU. Also Prefix Table is used to authorize IGP routing updates to prevent incorrect routes from being propagated by HA. In Explicit Network Mode, Prefix Table is used to authorized MNPs in options. In Explicit Prefix Length Mode, Prefix Table is not used. Wondering if we can try this? Define the functional role of the table or database, such as MNP Injection DB and MNP Authorization DB. It may be implemented as one table or not should not matter. In Implicit Mode, HA will insert routes from the MNP Injection DB. I don't think the MNP Authorization DB is needed for IGP in the base protocol. Folks can implement this if desired. But this is really beyond current router to router behavior as been pointed out. In Explicit Prefix Mode, the MNP Authorization DB is used to validate MNPs in BU option. This may help clarify some confusions in the discussions. And hope it doesn't add to it. :) Kent At 01:30 AM 7/24/2003 +0200, Alexandru Petrescu wrote: >Vijay Devarapalli wrote: >> In this mode, the Mobile Router does not include either a >> Mobile Network Prefix Option or a Mobile Network Prefix Length >> Option in the Binding Update (but it does include the Home >> Address Option in the Destination Options header, as all Mobile >> Hosts do). The Home Agent can use any mechanism (not defined >> in this document) to determine the Mobile Network Prefix(es) >> owned the Mobile Router. One of the possible mechanisms is > ^by > >> where the Home Agent maintains a Pre-configured Prefix Table > pre > >> listing all the Mobile Network prefixes owned by a particular >> Mobile Router. This table is keyed on the Home Address of the >> Mobile Router. > >Couldn't this table in fact be the kernel routing table? It is true that >the kernel routing table is not keyed by the Home Address, and existing >lookup functions will compare with the prefix (not with the gw >address); but new functions can be written such as to search the routing >table by the gw address instead (i.e. the MR Home Address). > >So, either (1) the prefix table can be filled from the existing routing >table at bootup (it's 'pre-configured') or (2) the prefix table is not >used at all in implicit mode, the routing table is used instead: lookup >the Home Address of the Mobile Router and subsequently the associated >MNP and finally match the dst address of an incoming packet to MNP. > >(Keeping in mind that the routing table entries to MNP through MR HoA > MUST exist in the routing table when MR is at home.) > >(The other suggestion against elimination of Prefix Table from implicit >mode is that the Prefix Table gives a sense of higher protection against >attacks, in that a Prefix Table gives the HA explicit knowledge of which >MNP is owned by which MR. Still, the very existence of routing table >entries towards MNP through MR HoA when MR is at home might already >constitute a sort of 'proof' for that ownership. I mean, if one doubts >the means by which that MNP entry got in the routing table in the first >place, one notices that it could have been by static routing; then it's >manual configuration: highest security. With dynamic routing, they have >their own security mechanisms, one of them being sharing keys (again >high security), others are dynamic keying (for which standards exist) >and also involve manual configuration of files. So, I would suggest that >existing means to configure the routing table with MNP and MR HoA is >already secure enough not to make one care about the need of a new >Prefix Table for implicit mode.) > >>it says the Home Agent can use any mechanism. we suggest >>Prefix Table as one of the mechanisms. static routes (as >>you call them) is another mechanism. > >Ok that. So maybe end of paragraph might be(?): > >Another possible mechanism is where the Home Agent uses existing secure >forwarding information [entries in the kernel routing table that are >valid when the Mobile Router is at home] to find the association of >the Mobile Network Prefix to the corresponding Home Address. > >I don't mean to interfere with your discussion, I'm just supporting >implicit mode without prefix table. > >Alex >GBU From nemo-admin@ietf.org Thu Jul 24 19:11:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05543 for ; Thu, 24 Jul 2003 19:11:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpDk-0003nd-V5; Thu, 24 Jul 2003 19:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpDR-0003nE-9p for nemo@optimus.ietf.org; Thu, 24 Jul 2003 19:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05512 for ; Thu, 24 Jul 2003 19:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fpDN-00034Q-00 for nemo@ietf.org; Thu, 24 Jul 2003 19:09:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fpDD-00034E-00 for nemo@ietf.org; Thu, 24 Jul 2003 19:09:27 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA05084; Thu, 24 Jul 2003 16:07:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ON7jb10327; Thu, 24 Jul 2003 16:07:45 -0700 X-mProtect: <200307242307> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVXTAmf; Thu, 24 Jul 2003 16:07:44 PDT Message-ID: <3F2066C0.22FBEC4@iprg.nokia.com> Date: Thu, 24 Jul 2003 16:07:44 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kent Leung wrote: > > The Prefix Table seems to be overloaded functionally. it is an optional data structure. > > Let me see if I got this right? > > In Implicit Mode, MNPs are preconfigured in Prefix Table for HA to inject > routes > during BU. yes. > Also Prefix Table is used to authorize IGP routing updates to > prevent > incorrect routes from being propagated by HA. no. > > In Explicit Network Mode, Prefix Table is used to authorized MNPs in options. > > In Explicit Prefix Length Mode, Prefix Table is not used. it is used in both, if needed. if the MR and HA have a subscription relationship, you dont normally expect the MR to misbehave. but if in a certain deployment scenario, you expect misbehaving MRs, then you need this authorization check through the prefix table. if you have some other way of doing this authorization check, you dont need the prefix table. > > Wondering if we can try this? > > Define the functional role of the table or database, such as MNP Injection DB > and MNP Authorization DB. It may be implemented as one table or not should > not matter. > > In Implicit Mode, HA will insert routes from the MNP Injection DB. I don't > think > the MNP Authorization DB is needed for IGP in the base protocol. Folks can > implement this if desired. But this is really beyond current router to router > behavior as been pointed out. > > In Explicit Prefix Mode, the MNP Authorization DB is used to validate > MNPs in BU option. sounds okay. but the MNP injection DB would be used only in implicit mode. I dont think you need a new DB for that. thats why the prefix table is used for both. in explicit mode for MNP authorization and in implicit mode for MNP injection. > This may help clarify some confusions in the discussions. And hope it doesn't > add to it. :) there is a lot of confusion. we should probably add more text while describing the prefix table. Vijay From exim@www1.ietf.org Thu Jul 24 19:11:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05558 for ; Thu, 24 Jul 2003 19:11:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpEX-0003rw-7j for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 19:10:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ONAnus014866 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 19:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpEX-0003rh-3I for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 19:10:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05525 for ; Thu, 24 Jul 2003 19:10:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fpET-00035G-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 19:10:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fpEO-00035D-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 19:10:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpDk-0003nd-V5; Thu, 24 Jul 2003 19:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fpDR-0003nE-9p for nemo@optimus.ietf.org; Thu, 24 Jul 2003 19:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05512 for ; Thu, 24 Jul 2003 19:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fpDN-00034Q-00 for nemo@ietf.org; Thu, 24 Jul 2003 19:09:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19fpDD-00034E-00 for nemo@ietf.org; Thu, 24 Jul 2003 19:09:27 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA05084; Thu, 24 Jul 2003 16:07:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6ON7jb10327; Thu, 24 Jul 2003 16:07:45 -0700 X-mProtect: <200307242307> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVXTAmf; Thu, 24 Jul 2003 16:07:44 PDT Message-ID: <3F2066C0.22FBEC4@iprg.nokia.com> Date: Thu, 24 Jul 2003 16:07:44 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org Subject: Re: [nemo] RE: Issue 6 References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > > The Prefix Table seems to be overloaded functionally. it is an optional data structure. > > Let me see if I got this right? > > In Implicit Mode, MNPs are preconfigured in Prefix Table for HA to inject > routes > during BU. yes. > Also Prefix Table is used to authorize IGP routing updates to > prevent > incorrect routes from being propagated by HA. no. > > In Explicit Network Mode, Prefix Table is used to authorized MNPs in options. > > In Explicit Prefix Length Mode, Prefix Table is not used. it is used in both, if needed. if the MR and HA have a subscription relationship, you dont normally expect the MR to misbehave. but if in a certain deployment scenario, you expect misbehaving MRs, then you need this authorization check through the prefix table. if you have some other way of doing this authorization check, you dont need the prefix table. > > Wondering if we can try this? > > Define the functional role of the table or database, such as MNP Injection DB > and MNP Authorization DB. It may be implemented as one table or not should > not matter. > > In Implicit Mode, HA will insert routes from the MNP Injection DB. I don't > think > the MNP Authorization DB is needed for IGP in the base protocol. Folks can > implement this if desired. But this is really beyond current router to router > behavior as been pointed out. > > In Explicit Prefix Mode, the MNP Authorization DB is used to validate > MNPs in BU option. sounds okay. but the MNP injection DB would be used only in implicit mode. I dont think you need a new DB for that. thats why the prefix table is used for both. in explicit mode for MNP authorization and in implicit mode for MNP injection. > This may help clarify some confusions in the discussions. And hope it doesn't > add to it. :) there is a lot of confusion. we should probably add more text while describing the prefix table. Vijay From nemo-admin@ietf.org Thu Jul 24 21:41:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08177 for ; Thu, 24 Jul 2003 21:41:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frYv-0001aD-Dv; Thu, 24 Jul 2003 21:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frYu-0001ZU-9V for nemo@optimus.ietf.org; Thu, 24 Jul 2003 21:40:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08155 for ; Thu, 24 Jul 2003 21:39:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frYr-0003lv-00 for nemo@ietf.org; Thu, 24 Jul 2003 21:39:57 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19frYg-0003ln-00 for nemo@ietf.org; Thu, 24 Jul 2003 21:39:46 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6P1cwpp018565; Thu, 24 Jul 2003 18:38:59 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJO95848; Thu, 24 Jul 2003 18:34:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20030724182458.02caced8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jul 2003 18:38:45 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org In-Reply-To: <3F2066C0.22FBEC4@iprg.nokia.com> References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 04:07 PM 7/24/2003 -0700, Vijay Devarapalli wrote: > > Also Prefix Table is used to authorize IGP routing updates to > > prevent > > incorrect routes from being propagated by HA. > >no. That's good. But I got this impression from your comments here. I may have misread that you said prefix table is used to explicitly check if MR claims a prefix via IGP in implicit mode. >Vijay Devarapalli wrote: >>>(The other suggestion against elimination of Prefix Table from implicit >>>mode is that the Prefix Table gives a sense of higher protection against >>>attacks, in that a Prefix Table gives the HA explicit knowledge of which >>>MNP is owned by which MR. >>actually it does. dynamic routing protocols dont have explicit >>authorization built in. most are run using shared keys. these shared >> keys implicitly provide authentication and authorization. Prefix table >> goes a step ahead and enables the HA to explicity check if a mobile >> router owns a particular prefix it is claiming. > >A-ha. I wonder why they didn't do it for routing protocols to allow >protection of which router can route update which prefix. > > > > In Explicit Network Mode, Prefix Table is used to authorized MNPs in > options. > > > > In Explicit Prefix Length Mode, Prefix Table is not used. > >it is used in both, if needed. if the MR and HA have >a subscription relationship, you dont normally expect >the MR to misbehave. but if in a certain deployment >scenario, you expect misbehaving MRs, then you need >this authorization check through the prefix table. if >you have some other way of doing this authorization >check, you dont need the prefix table. OK. I'm not hung up on the "Prefix Table" name. Trying to say that there's a function needed to authorize MNPs that's different than injection function. >there is a lot of confusion. we should probably add >more text while describing the prefix table. It's clearer now that I know Authorization function is not applied in the Implicit Mode. Kent From exim@www1.ietf.org Thu Jul 24 21:41:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08192 for ; Thu, 24 Jul 2003 21:41:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frZl-0001ej-Lh for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 21:40:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1erHP006361 for nemo-archive@odin.ietf.org; Thu, 24 Jul 2003 21:40:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frZl-0001eW-Fa for nemo-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:40:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08159 for ; Thu, 24 Jul 2003 21:40:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frZi-0003mM-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 21:40:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frZd-0003mJ-00 for nemo-web-archive@ietf.org; Thu, 24 Jul 2003 21:40:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frYv-0001aD-Dv; Thu, 24 Jul 2003 21:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frYu-0001ZU-9V for nemo@optimus.ietf.org; Thu, 24 Jul 2003 21:40:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08155 for ; Thu, 24 Jul 2003 21:39:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frYr-0003lv-00 for nemo@ietf.org; Thu, 24 Jul 2003 21:39:57 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19frYg-0003ln-00 for nemo@ietf.org; Thu, 24 Jul 2003 21:39:46 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6P1cwpp018565; Thu, 24 Jul 2003 18:38:59 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJO95848; Thu, 24 Jul 2003 18:34:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20030724182458.02caced8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jul 2003 18:38:45 -0700 To: Vijay Devarapalli From: Kent Leung Subject: Re: [nemo] RE: Issue 6 Cc: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , "S. Felix Wu" , nemo@ietf.org In-Reply-To: <3F2066C0.22FBEC4@iprg.nokia.com> References: <3F1EC6E4.FF59F3F8@iprg.nokia.com> <3F1EC6E4.FF59F3F8@iprg.nokia.com> <4.3.2.7.2.20030723155250.02b397c8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At 04:07 PM 7/24/2003 -0700, Vijay Devarapalli wrote: > > Also Prefix Table is used to authorize IGP routing updates to > > prevent > > incorrect routes from being propagated by HA. > >no. That's good. But I got this impression from your comments here. I may have misread that you said prefix table is used to explicitly check if MR claims a prefix via IGP in implicit mode. >Vijay Devarapalli wrote: >>>(The other suggestion against elimination of Prefix Table from implicit >>>mode is that the Prefix Table gives a sense of higher protection against >>>attacks, in that a Prefix Table gives the HA explicit knowledge of which >>>MNP is owned by which MR. >>actually it does. dynamic routing protocols dont have explicit >>authorization built in. most are run using shared keys. these shared >> keys implicitly provide authentication and authorization. Prefix table >> goes a step ahead and enables the HA to explicity check if a mobile >> router owns a particular prefix it is claiming. > >A-ha. I wonder why they didn't do it for routing protocols to allow >protection of which router can route update which prefix. > > > > In Explicit Network Mode, Prefix Table is used to authorized MNPs in > options. > > > > In Explicit Prefix Length Mode, Prefix Table is not used. > >it is used in both, if needed. if the MR and HA have >a subscription relationship, you dont normally expect >the MR to misbehave. but if in a certain deployment >scenario, you expect misbehaving MRs, then you need >this authorization check through the prefix table. if >you have some other way of doing this authorization >check, you dont need the prefix table. OK. I'm not hung up on the "Prefix Table" name. Trying to say that there's a function needed to authorize MNPs that's different than injection function. >there is a lot of confusion. we should probably add >more text while describing the prefix table. It's clearer now that I know Authorization function is not applied in the Implicit Mode. Kent From nemo-admin@ietf.org Fri Jul 25 00:44:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11570 for ; Fri, 25 Jul 2003 00:44:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuQ1-0006zr-7G; Fri, 25 Jul 2003 00:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuPp-0006zf-3w for nemo@optimus.ietf.org; Fri, 25 Jul 2003 00:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11517 for ; Fri, 25 Jul 2003 00:42:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fuPm-0004qi-00 for nemo@ietf.org; Fri, 25 Jul 2003 00:42:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fuPb-0004qS-00 for nemo@ietf.org; Fri, 25 Jul 2003 00:42:35 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P4fZee004067; Fri, 25 Jul 2003 13:41:35 +0900 Date: Thu, 24 Jul 2003 03:12:19 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Pascal, Pascal Thubert (pthubert) wrote: > > > >> > > >> - Why do you introduce the interface identification (IFID) ? It > could > > >>be sufficient to only register a CoA with the associated priority. > > >>Therefore, when the MN has to choose the destination address for a > HoA, > > >>it can take the most preferred CoA, which is bound to the most > preferred > > >>interface of the MN. > > >> > > >> > > > > > >Priority can be changed by some reason during communication, but IFID > > >can not be changed until MN want to change it. > > > > > Ok, I understand that. But what I mean is that I don't see the > > requirement to have the IFID... In the Binding Cache, an entry could > be > > identified by both the Home address and the CoA. It is sufficient to > > distinguish tow different entries. The priority field is then used to > > choose the CoA, i.e. the interface. No need to have the IFID I guess. > > I believe we talked about that a lot already; there seems to be a > consensus on using the home address to identify uniquely a registration, > for checking and cleanup purposes. The IFID should not be used to that > purpose, and a registration should be able to migrate interface on the > MR side. If we do not find a valid usage for ifid (I have none in mind > at the moment) then it should be dropped, shouldn't it? I don't think we have consensus on using the HoA to identify a binding. There are advantages to use single HoA per MN and MR. Multiple HoAs allow nodes inside a mobile network to use multiple interfaces, but not MR. MR also wants to use multiple interfaces for its communication, then we need some other scheme like IFID. regards, ryuji From exim@www1.ietf.org Fri Jul 25 00:44:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11589 for ; Fri, 25 Jul 2003 00:44:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuRU-00074k-MP for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 00:44:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P4iWYs027194 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 00:44:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuRU-00074X-HO for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 00:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11552 for ; Fri, 25 Jul 2003 00:44:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fuRR-0004ra-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 00:44:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fuRM-0004rX-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 00:44:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuQ1-0006zr-7G; Fri, 25 Jul 2003 00:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fuPp-0006zf-3w for nemo@optimus.ietf.org; Fri, 25 Jul 2003 00:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11517 for ; Fri, 25 Jul 2003 00:42:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fuPm-0004qi-00 for nemo@ietf.org; Fri, 25 Jul 2003 00:42:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fuPb-0004qS-00 for nemo@ietf.org; Fri, 25 Jul 2003 00:42:35 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P4fZee004067; Fri, 25 Jul 2003 13:41:35 +0900 Date: Thu, 24 Jul 2003 03:12:19 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Pascal, Pascal Thubert (pthubert) wrote: > > > >> > > >> - Why do you introduce the interface identification (IFID) ? It > could > > >>be sufficient to only register a CoA with the associated priority. > > >>Therefore, when the MN has to choose the destination address for a > HoA, > > >>it can take the most preferred CoA, which is bound to the most > preferred > > >>interface of the MN. > > >> > > >> > > > > > >Priority can be changed by some reason during communication, but IFID > > >can not be changed until MN want to change it. > > > > > Ok, I understand that. But what I mean is that I don't see the > > requirement to have the IFID... In the Binding Cache, an entry could > be > > identified by both the Home address and the CoA. It is sufficient to > > distinguish tow different entries. The priority field is then used to > > choose the CoA, i.e. the interface. No need to have the IFID I guess. > > I believe we talked about that a lot already; there seems to be a > consensus on using the home address to identify uniquely a registration, > for checking and cleanup purposes. The IFID should not be used to that > purpose, and a registration should be able to migrate interface on the > MR side. If we do not find a valid usage for ifid (I have none in mind > at the moment) then it should be dropped, shouldn't it? I don't think we have consensus on using the HoA to identify a binding. There are advantages to use single HoA per MN and MR. Multiple HoAs allow nodes inside a mobile network to use multiple interfaces, but not MR. MR also wants to use multiple interfaces for its communication, then we need some other scheme like IFID. regards, ryuji From nemo-admin@ietf.org Fri Jul 25 03:33:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27147 for ; Fri, 25 Jul 2003 03:33:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx3Z-0006E3-Vy; Fri, 25 Jul 2003 03:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx2r-0006DO-1R for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27042 for ; Fri, 25 Jul 2003 03:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx2o-00062O-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:31:14 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fx2e-00061N-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:31:04 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 03:30:14 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 03:30:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > I don't think we have consensus on using the HoA to identify > a binding. => We have a MIPv6 (RFC now!) that says that the HoA is used to identify a binding in the binding cache. So I'd say we have concensus on that. > There are advantages to use single HoA per MN and MR. > Multiple HoAs allow nodes inside a mobile network to use > multiple interfaces, but not MR. => Why not MR? Hesham From exim@www1.ietf.org Fri Jul 25 03:33:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27170 for ; Fri, 25 Jul 2003 03:33:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx4P-0006Ik-9O for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:32:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7WrIt024216 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:32:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx4O-0006IV-FJ for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 03:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27124 for ; Fri, 25 Jul 2003 03:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx4M-000640-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:32:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fx4G-00063x-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx3Z-0006E3-Vy; Fri, 25 Jul 2003 03:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx2r-0006DO-1R for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27042 for ; Fri, 25 Jul 2003 03:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx2o-00062O-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:31:14 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fx2e-00061N-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:31:04 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 03:30:14 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 03:30:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > I don't think we have consensus on using the HoA to identify > a binding. => We have a MIPv6 (RFC now!) that says that the HoA is used to identify a binding in the binding cache. So I'd say we have concensus on that. > There are advantages to use single HoA per MN and MR. > Multiple HoAs allow nodes inside a mobile network to use > multiple interfaces, but not MR. => Why not MR? Hesham From nemo-admin@ietf.org Fri Jul 25 03:43:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27525 for ; Fri, 25 Jul 2003 03:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxDF-0006nl-Sq; Fri, 25 Jul 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxD5-0006nW-Tq for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:41:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27512 for ; Fri, 25 Jul 2003 03:41:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxD3-00068E-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:41:49 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fxCr-00067p-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:41:38 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P7eaee005805; Fri, 25 Jul 2003 16:40:36 +0900 Date: Thu, 24 Jul 2003 06:09:31 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Fri, 25 Jul 2003 03:30:09 -0400, Soliman Hesham wrote: > > > > I don't think we have consensus on using the HoA to identify > > a binding. > > => We have a MIPv6 (RFC now!) that says that the HoA > is used to identify a binding in the binding cache. > So I'd say we have concensus on that. I am talking about the case when multiple CoAs are bounded to a HoA. When two bindings have same HoA, how do you identify each binding with same HoA? regards, ryuji > > There are advantages to use single HoA per MN and MR. > > Multiple HoAs allow nodes inside a mobile network to use > > multiple interfaces, but not MR. > > => Why not MR? From exim@www1.ietf.org Fri Jul 25 03:43:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27540 for ; Fri, 25 Jul 2003 03:43:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxE0-0006sj-DF for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:42:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7gmNV026447 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxE0-0006sU-6c for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 03:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27519 for ; Fri, 25 Jul 2003 03:42:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxDx-00068e-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:42:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fxDs-00068b-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:42:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxDF-0006nl-Sq; Fri, 25 Jul 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxD5-0006nW-Tq for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:41:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27512 for ; Fri, 25 Jul 2003 03:41:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxD3-00068E-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:41:49 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fxCr-00067p-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:41:38 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P7eaee005805; Fri, 25 Jul 2003 16:40:36 +0900 Date: Thu, 24 Jul 2003 06:09:31 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922BFE@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Fri, 25 Jul 2003 03:30:09 -0400, Soliman Hesham wrote: > > > > I don't think we have consensus on using the HoA to identify > > a binding. > > => We have a MIPv6 (RFC now!) that says that the HoA > is used to identify a binding in the binding cache. > So I'd say we have concensus on that. I am talking about the case when multiple CoAs are bounded to a HoA. When two bindings have same HoA, how do you identify each binding with same HoA? regards, ryuji > > There are advantages to use single HoA per MN and MR. > > Multiple HoAs allow nodes inside a mobile network to use > > multiple interfaces, but not MR. > > => Why not MR? From nemo-admin@ietf.org Fri Jul 25 03:46:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27644 for ; Fri, 25 Jul 2003 03:46:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxG9-00076c-Mc; Fri, 25 Jul 2003 03:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxFL-00074N-SG for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27575 for ; Fri, 25 Jul 2003 03:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxFJ-00068z-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:44:09 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fxF8-00068n-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:43:58 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 03:43:24 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , Soliman Hesham Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 03:43:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > I don't think we have consensus on using the HoA to identify > > > a binding. > > > > => We have a MIPv6 (RFC now!) that says that the HoA > > is used to identify a binding in the binding cache. > > So I'd say we have concensus on that. > > I am talking about the case when multiple CoAs are bounded to a HoA. > When two bindings have same HoA, how do you identify each > binding with same HoA? => By other attributes of that binding: CoA, CN's address, port nos, flow label ...etc Hesham From exim@www1.ietf.org Fri Jul 25 03:46:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27659 for ; Fri, 25 Jul 2003 03:46:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxGq-0007II-F8 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:45:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7ji5T028032 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxGq-0007I3-59 for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 03:45:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27638 for ; Fri, 25 Jul 2003 03:45:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxGn-0006A2-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:45:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fxGi-00069z-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:45:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxG9-00076c-Mc; Fri, 25 Jul 2003 03:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxFL-00074N-SG for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27575 for ; Fri, 25 Jul 2003 03:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxFJ-00068z-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:44:09 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fxF8-00068n-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:43:58 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 03:43:24 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , Soliman Hesham Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 03:43:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > I don't think we have consensus on using the HoA to identify > > > a binding. > > > > => We have a MIPv6 (RFC now!) that says that the HoA > > is used to identify a binding in the binding cache. > > So I'd say we have concensus on that. > > I am talking about the case when multiple CoAs are bounded to a HoA. > When two bindings have same HoA, how do you identify each > binding with same HoA? => By other attributes of that binding: CoA, CN's address, port nos, flow label ...etc Hesham From nemo-admin@ietf.org Fri Jul 25 04:00:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27944 for ; Fri, 25 Jul 2003 04:00:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxTh-0007gM-0q; Fri, 25 Jul 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxTG-0007fe-PP for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:58:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27893 for ; Fri, 25 Jul 2003 03:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxTE-0006Dt-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:58:32 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fxT3-0006Dc-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:58:21 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P7vaee006006; Fri, 25 Jul 2003 16:57:36 +0900 Date: Thu, 24 Jul 2003 06:25:16 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Hesham, At Fri, 25 Jul 2003 03:43:11 -0400, Soliman Hesham wrote: > > > > I don't think we have consensus on using the HoA to identify > > > > a binding. > > > > > > => We have a MIPv6 (RFC now!) that says that the HoA > > > is used to identify a binding in the binding cache. > > > So I'd say we have concensus on that. > > > > I am talking about the case when multiple CoAs are bounded to a HoA. > > When two bindings have same HoA, how do you identify each > > binding with same HoA? > > => By other attributes of that binding: CoA, CN's address, port nos, > flow label ...etc CoA can not be used to identify binding, because it is changed. I wrote some comments before (I replied to Nicolas) maybe by filter information, but you can not identify two bindings if MN does not have filter information. Filter information is not always mandatory information. There are several approaches to maintain filter information. I prefer using ID to identify bindings and may associate filter information with the IFID somewhere (maybe binding cache, maybe not). This approach gives space for policy management and its implementation. regards, ryuji From exim@www1.ietf.org Fri Jul 25 04:00:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27960 for ; Fri, 25 Jul 2003 04:00:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxUR-0007og-UL for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:59:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7xlNT030042 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 03:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxUR-0007oT-M7 for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 03:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27915 for ; Fri, 25 Jul 2003 03:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxUP-0006Ee-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:59:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fxUJ-0006Eb-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 03:59:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxTh-0007gM-0q; Fri, 25 Jul 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxTG-0007fe-PP for nemo@optimus.ietf.org; Fri, 25 Jul 2003 03:58:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27893 for ; Fri, 25 Jul 2003 03:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxTE-0006Dt-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:58:32 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19fxT3-0006Dc-00 for nemo@ietf.org; Fri, 25 Jul 2003 03:58:21 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-78.sfc.wide.ad.jp [203.178.143.78]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h6P7vaee006006; Fri, 25 Jul 2003 16:57:36 +0900 Date: Thu, 24 Jul 2003 06:25:16 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Hesham, At Fri, 25 Jul 2003 03:43:11 -0400, Soliman Hesham wrote: > > > > I don't think we have consensus on using the HoA to identify > > > > a binding. > > > > > > => We have a MIPv6 (RFC now!) that says that the HoA > > > is used to identify a binding in the binding cache. > > > So I'd say we have concensus on that. > > > > I am talking about the case when multiple CoAs are bounded to a HoA. > > When two bindings have same HoA, how do you identify each > > binding with same HoA? > > => By other attributes of that binding: CoA, CN's address, port nos, > flow label ...etc CoA can not be used to identify binding, because it is changed. I wrote some comments before (I replied to Nicolas) maybe by filter information, but you can not identify two bindings if MN does not have filter information. Filter information is not always mandatory information. There are several approaches to maintain filter information. I prefer using ID to identify bindings and may associate filter information with the IFID somewhere (maybe binding cache, maybe not). This approach gives space for policy management and its implementation. regards, ryuji From nemo-admin@ietf.org Fri Jul 25 04:10:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28174 for ; Fri, 25 Jul 2003 04:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxdN-0000AO-FH; Fri, 25 Jul 2003 04:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxck-00005u-Ef for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:08:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28149 for ; Fri, 25 Jul 2003 04:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxch-0006It-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:08:19 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fxcX-0006Ic-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:08:09 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 04:07:34 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C02@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , Soliman Hesham Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 04:07:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > > I am talking about the case when multiple CoAs are > bounded to a HoA. > > > When two bindings have same HoA, how do you identify each > > > binding with same HoA? > > > > => By other attributes of that binding: CoA, CN's address, > port nos, > > flow label ...etc > > CoA can not be used to identify binding, because it is changed. => That's why you need to send a new BU when you change CoA. Just to be clear, we're talking about a sub-binding here. So whenever the attributes change, just like a normal binding, you send a new BU. You have to do that anyway when your address changes. > I wrote some comments before (I replied to Nicolas) > > maybe by filter information, but you can not identify two bindings if > MN does not have filter information. Filter information is not always > mandatory information. There are several approaches to maintain > filter information. => What do you mean by "filter information"? You mean flow identifiers? I don't understand the problem you're trying to solve I guess. The problem _I think_ we're solving here is how to direct one or more connections to a particular interface. So, to me, the obvious approach would be to map the connection identifiers to a CoA which is directly mapped to an interface. This is good because all the information is contained in the packet, so a HA/CN can directly tunnel to the right CoA. If you are discussing how the HA looks up that filtering information and map it to the packet that is about to be tunnelled to the MN, then this is an implementation issue and is already done in routers today that do flow-based traffic engineering. One way of doing this is to hash the filter information and compare it with the information in the received packet. > > I prefer using ID to identify bindings and may associate filter > information with the IFID somewhere (maybe binding cache, maybe not). > This approach gives space for policy management and its > implementation. => The id can be used locally within the MN to allow applications to pick an interface according to the interface's attributes, instead of picking it based on a meaningless address. But I'm not sure I see the value of exchanging that over the wire. Hesham From exim@www1.ietf.org Fri Jul 25 04:10:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28190 for ; Fri, 25 Jul 2003 04:10:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxeA-0000FU-Cg for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:09:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P89on2000957 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxe9-0000FM-S7 for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 04:09:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28170 for ; Fri, 25 Jul 2003 04:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxe6-0006JX-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 04:09:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fxe1-0006JU-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 04:09:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxdN-0000AO-FH; Fri, 25 Jul 2003 04:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxck-00005u-Ef for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:08:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28149 for ; Fri, 25 Jul 2003 04:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxch-0006It-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:08:19 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19fxcX-0006Ic-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:08:09 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Jul 2003 04:07:34 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C02@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ryuji Wakikawa'" , Soliman Hesham Cc: pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: RE: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 04:07:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > > I am talking about the case when multiple CoAs are > bounded to a HoA. > > > When two bindings have same HoA, how do you identify each > > > binding with same HoA? > > > > => By other attributes of that binding: CoA, CN's address, > port nos, > > flow label ...etc > > CoA can not be used to identify binding, because it is changed. => That's why you need to send a new BU when you change CoA. Just to be clear, we're talking about a sub-binding here. So whenever the attributes change, just like a normal binding, you send a new BU. You have to do that anyway when your address changes. > I wrote some comments before (I replied to Nicolas) > > maybe by filter information, but you can not identify two bindings if > MN does not have filter information. Filter information is not always > mandatory information. There are several approaches to maintain > filter information. => What do you mean by "filter information"? You mean flow identifiers? I don't understand the problem you're trying to solve I guess. The problem _I think_ we're solving here is how to direct one or more connections to a particular interface. So, to me, the obvious approach would be to map the connection identifiers to a CoA which is directly mapped to an interface. This is good because all the information is contained in the packet, so a HA/CN can directly tunnel to the right CoA. If you are discussing how the HA looks up that filtering information and map it to the packet that is about to be tunnelled to the MN, then this is an implementation issue and is already done in routers today that do flow-based traffic engineering. One way of doing this is to hash the filter information and compare it with the information in the received packet. > > I prefer using ID to identify bindings and may associate filter > information with the IFID somewhere (maybe binding cache, maybe not). > This approach gives space for policy management and its > implementation. => The id can be used locally within the MN to allow applications to pick an interface according to the interface's attributes, instead of picking it based on a meaningless address. But I'm not sure I see the value of exchanging that over the wire. Hesham From nemo-admin@ietf.org Fri Jul 25 04:18:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28373 for ; Fri, 25 Jul 2003 04:18:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxl7-0000ZC-HY; Fri, 25 Jul 2003 04:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxkl-0000Yl-2c for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28347 for ; Fri, 25 Jul 2003 04:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxki-0006Mi-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:16:36 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fxkX-0006MV-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:16:25 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6P8GHK00317; Fri, 25 Jul 2003 10:16:17 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Ryuji Wakikawa'" , Cc: , , Subject: AW: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 10:16:15 +0200 Message-ID: <000901c35285$046c72d0$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ryuji, > > =3D> We have a MIPv6 (RFC now!) that says that the HoA > > is used to identify a binding in the binding cache. > > So I'd say we have concensus on that. >=20 > I am talking about the case when multiple CoAs are bounded to a HoA. > When two bindings have same HoA, how do you identify each binding with > same HoA? We have a solution in our draft (refer, nomadv6 draft). It introduces a = new bit, similar to S bit in Mobile IPv4 Registration request. It allows = keeping simultaneous binding, without duplicating traffic to each active point = of attachment.=20 Regards Koojana From exim@www1.ietf.org Fri Jul 25 04:18:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28409 for ; Fri, 25 Jul 2003 04:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxmH-0000gi-EM for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:18:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P8IDq1002638 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxmH-0000gT-6H for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 04:18:13 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28374 for ; Fri, 25 Jul 2003 04:18:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxl7-0000ZC-HY; Fri, 25 Jul 2003 04:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxkl-0000Yl-2c for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28347 for ; Fri, 25 Jul 2003 04:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxki-0006Mi-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:16:36 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19fxkX-0006MV-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:16:25 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h6P8GHK00317; Fri, 25 Jul 2003 10:16:17 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Ryuji Wakikawa'" , Cc: , , Subject: AW: [mobile-ip] RE: [nemo] multiple CoAs registration Date: Fri, 25 Jul 2003 10:16:15 +0200 Message-ID: <000901c35285$046c72d0$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ryuji, > > =3D> We have a MIPv6 (RFC now!) that says that the HoA > > is used to identify a binding in the binding cache. > > So I'd say we have concensus on that. >=20 > I am talking about the case when multiple CoAs are bounded to a HoA. > When two bindings have same HoA, how do you identify each binding with > same HoA? We have a solution in our draft (refer, nomadv6 draft). It introduces a = new bit, similar to S bit in Mobile IPv4 Registration request. It allows = keeping simultaneous binding, without duplicating traffic to each active point = of attachment.=20 Regards Koojana From nemo-admin@ietf.org Fri Jul 25 04:56:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29304 for ; Fri, 25 Jul 2003 04:56:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyLt-0001vk-DV; Fri, 25 Jul 2003 04:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyLX-0001sZ-9B for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29198 for ; Fri, 25 Jul 2003 04:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyLU-0006Yz-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:54:36 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fyLJ-0006Yn-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:54:25 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6P8renX006477; Fri, 25 Jul 2003 10:53:40 +0200 Message-ID: <3F20EE29.7050007@dpt-info.u-strasbg.fr> Date: Fri, 25 Jul 2003 10:45:29 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Soliman Hesham CC: "'Ryuji Wakikawa'" , pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration References: <748C6D0A58C0F94CA63C198B6674697A01922C02@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > I am talking about the case when multiple CoAs are > > bounded to a HoA. > > > > When two bindings have same HoA, how do you identify each > > > > binding with same HoA? > > > > > > => By other attributes of that binding: CoA, CN's address, > > port nos, > > > flow label ...etc > > > > CoA can not be used to identify binding, because it is changed. > >=> That's why you need to send a new BU when you change CoA. >Just to be clear, we're talking about a sub-binding here. >So whenever the attributes change, just like a normal binding, >you send a new BU. You have to do that anyway when your >address changes. > > > I wrote some comments before (I replied to Nicolas) > > > > maybe by filter information, but you can not identify two bindings if > > MN does not have filter information. Filter information is not always > > mandatory information. There are several approaches to maintain > > filter information. > >=> What do you mean by "filter information"? You mean >flow identifiers? >I don't understand the problem you're trying to solve >I guess. The problem _I think_ we're solving here is how >to direct one or more connections to a particular interface. >So, to me, the obvious approach would be to map the connection >identifiers to a CoA which is directly mapped to an interface. >This is good because all the information is contained in the >packet, so a HA/CN can directly tunnel to the right >CoA. >If you are discussing how the HA looks up that filtering >information and map it to the packet that is about to be >tunnelled to the MN, then this is an implementation issue >and is already done in routers today that do flow-based >traffic engineering. One way of doing this is to hash >the filter information and compare it with the information >in the received packet. > This is what we use in our draft. An entry is identified by the HoA plus the associated filter of the flow (which is a port number and/or CN address) This entry gives the CoA to use. No need to have an interface ID. By this way, we can either filter flows or perform redirection between interfaces. Nicolas > > > > > I prefer using ID to identify bindings and may associate filter > > information with the IFID somewhere (maybe binding cache, maybe not). > > This approach gives space for policy management and its > > implementation. > >=> The id can be used locally within the MN to allow >applications to pick an interface according to the >interface's attributes, instead of picking it based on >a meaningless address. But I'm not sure I see the value >of exchanging that over the wire. > >Hesham > > From exim@www1.ietf.org Fri Jul 25 04:56:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29319 for ; Fri, 25 Jul 2003 04:56:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyMm-0001yd-VU for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:55:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P8tuRk007598 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 04:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyMm-0001yL-OD for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 04:55:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29286 for ; Fri, 25 Jul 2003 04:55:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyMj-0006aF-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 04:55:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fyMe-0006a9-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 04:55:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyLt-0001vk-DV; Fri, 25 Jul 2003 04:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyLX-0001sZ-9B for nemo@optimus.ietf.org; Fri, 25 Jul 2003 04:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29198 for ; Fri, 25 Jul 2003 04:54:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyLU-0006Yz-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:54:36 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fyLJ-0006Yn-00 for nemo@ietf.org; Fri, 25 Jul 2003 04:54:25 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6P8renX006477; Fri, 25 Jul 2003 10:53:40 +0200 Message-ID: <3F20EE29.7050007@dpt-info.u-strasbg.fr> Date: Fri, 25 Jul 2003 10:45:29 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Soliman Hesham CC: "'Ryuji Wakikawa'" , pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration References: <748C6D0A58C0F94CA63C198B6674697A01922C02@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > I am talking about the case when multiple CoAs are > > bounded to a HoA. > > > > When two bindings have same HoA, how do you identify each > > > > binding with same HoA? > > > > > > => By other attributes of that binding: CoA, CN's address, > > port nos, > > > flow label ...etc > > > > CoA can not be used to identify binding, because it is changed. > >=> That's why you need to send a new BU when you change CoA. >Just to be clear, we're talking about a sub-binding here. >So whenever the attributes change, just like a normal binding, >you send a new BU. You have to do that anyway when your >address changes. > > > I wrote some comments before (I replied to Nicolas) > > > > maybe by filter information, but you can not identify two bindings if > > MN does not have filter information. Filter information is not always > > mandatory information. There are several approaches to maintain > > filter information. > >=> What do you mean by "filter information"? You mean >flow identifiers? >I don't understand the problem you're trying to solve >I guess. The problem _I think_ we're solving here is how >to direct one or more connections to a particular interface. >So, to me, the obvious approach would be to map the connection >identifiers to a CoA which is directly mapped to an interface. >This is good because all the information is contained in the >packet, so a HA/CN can directly tunnel to the right >CoA. >If you are discussing how the HA looks up that filtering >information and map it to the packet that is about to be >tunnelled to the MN, then this is an implementation issue >and is already done in routers today that do flow-based >traffic engineering. One way of doing this is to hash >the filter information and compare it with the information >in the received packet. > This is what we use in our draft. An entry is identified by the HoA plus the associated filter of the flow (which is a port number and/or CN address) This entry gives the CoA to use. No need to have an interface ID. By this way, we can either filter flows or perform redirection between interfaces. Nicolas > > > > > I prefer using ID to identify bindings and may associate filter > > information with the IFID somewhere (maybe binding cache, maybe not). > > This approach gives space for policy management and its > > implementation. > >=> The id can be used locally within the MN to allow >applications to pick an interface according to the >interface's attributes, instead of picking it based on >a meaningless address. But I'm not sure I see the value >of exchanging that over the wire. > >Hesham > > From nemo-admin@ietf.org Fri Jul 25 05:11:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29775 for ; Fri, 25 Jul 2003 05:11:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyaO-0002Yn-TW; Fri, 25 Jul 2003 05:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyZo-0002Xx-AQ for nemo@optimus.ietf.org; Fri, 25 Jul 2003 05:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29674 for ; Fri, 25 Jul 2003 05:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyZl-0006g4-00 for nemo@ietf.org; Fri, 25 Jul 2003 05:09:21 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fyZa-0006fx-00 for nemo@ietf.org; Fri, 25 Jul 2003 05:09:10 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6P991nX007109; Fri, 25 Jul 2003 11:09:01 +0200 Message-ID: <3F20F1C2.4050201@dpt-info.u-strasbg.fr> Date: Fri, 25 Jul 2003 11:00:50 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: H.Soliman@flarion.com, pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration References: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >Hi Hesham, > >At Fri, 25 Jul 2003 03:43:11 -0400, >Soliman Hesham wrote: > > >> > > I don't think we have consensus on using the HoA to identify >> > > > a binding. >> > > >> > > => We have a MIPv6 (RFC now!) that says that the HoA >> > > is used to identify a binding in the binding cache. >> > > So I'd say we have concensus on that. >> > >> > I am talking about the case when multiple CoAs are bounded to a HoA. >> > When two bindings have same HoA, how do you identify each >> > binding with same HoA? >> >>=> By other attributes of that binding: CoA, CN's address, port nos, >>flow label ...etc >> >> > >CoA can not be used to identify binding, because it is changed. >I wrote some comments before (I replied to Nicolas) > >maybe by filter information, but you can not identify two bindings if >MN does not have filter information. Filter information is not always >mandatory information. There are several approaches to maintain >filter information. > >I prefer using ID to identify bindings and may associate filter >information with the IFID somewhere (maybe binding cache, maybe not). >This approach gives space for policy management and its >implementation. > Yes but I am not sure that an Interface ID is the better way to have a unique identifier of a binding... Nicolas > >regards, >ryuji > > From exim@www1.ietf.org Fri Jul 25 05:11:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29792 for ; Fri, 25 Jul 2003 05:11:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyb9-0002d8-Ks for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 05:10:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P9Al9H010104 for nemo-archive@odin.ietf.org; Fri, 25 Jul 2003 05:10:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyb9-0002ct-Gd for nemo-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 05:10:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29754 for ; Fri, 25 Jul 2003 05:10:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyb6-0006hC-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 05:10:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fyb0-0006h9-00 for nemo-web-archive@ietf.org; Fri, 25 Jul 2003 05:10:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyaO-0002Yn-TW; Fri, 25 Jul 2003 05:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fyZo-0002Xx-AQ for nemo@optimus.ietf.org; Fri, 25 Jul 2003 05:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29674 for ; Fri, 25 Jul 2003 05:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fyZl-0006g4-00 for nemo@ietf.org; Fri, 25 Jul 2003 05:09:21 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 19fyZa-0006fx-00 for nemo@ietf.org; Fri, 25 Jul 2003 05:09:10 -0400 Received: from dpt-info.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6P991nX007109; Fri, 25 Jul 2003 11:09:01 +0200 Message-ID: <3F20F1C2.4050201@dpt-info.u-strasbg.fr> Date: Fri, 25 Jul 2003 11:00:50 +0200 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ryuji Wakikawa CC: H.Soliman@flarion.com, pthubert@cisco.com, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org Subject: Re: [mobile-ip] RE: [nemo] multiple CoAs registration References: <748C6D0A58C0F94CA63C198B6674697A01922C00@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >Hi Hesham, > >At Fri, 25 Jul 2003 03:43:11 -0400, >Soliman Hesham wrote: > > >> > > I don't think we have consensus on using the HoA to identify >> > > > a binding. >> > > >> > > => We have a MIPv6 (RFC now!) that says that the HoA >> > > is used to identify a binding in the binding cache. >> > > So I'd say we have concensus on that. >> > >> > I am talking about the case when multiple CoAs are bounded to a HoA. >> > When two bindings have same HoA, how do you identify each >> > binding with same HoA? >> >>=> By other attributes of that binding: CoA, CN's address, port nos, >>flow label ...etc >> >> > >CoA can not be used to identify binding, because it is changed. >I wrote some comments before (I replied to Nicolas) > >maybe by filter information, but you can not identify two bindings if >MN does not have filter information. Filter information is not always >mandatory information. There are several approaches to maintain >filter information. > >I prefer using ID to identify bindings and may associate filter >information with the IFID somewhere (maybe binding cache, maybe not). >This approach gives space for policy management and its >implementation. > Yes but I am not sure that an Interface ID is the better way to have a unique identifier of a binding... Nicolas > >regards, >ryuji > > From nemo-admin@ietf.org Mon Jul 28 21:35:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26763 for ; Mon, 28 Jul 2003 21:35:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJNJ-0004mp-45; Mon, 28 Jul 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJMZ-0004mP-4r for nemo@optimus.ietf.org; Mon, 28 Jul 2003 21:33:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26747 for ; Mon, 28 Jul 2003 21:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hJMW-0001oH-00 for nemo@ietf.org; Mon, 28 Jul 2003 21:33:12 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hJMV-0001o7-00 for nemo@ietf.org; Mon, 28 Jul 2003 21:33:11 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA18669; Mon, 28 Jul 2003 18:32:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6T1Wf427300; Mon, 28 Jul 2003 18:32:41 -0700 X-mProtect: <200307290132> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLzE6Pw; Mon, 28 Jul 2003 18:32:39 PDT Message-ID: <3F25CEB7.60E355FD@iprg.nokia.com> Date: Mon, 28 Jul 2003 18:32:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wu@cs.ucdavis.edu, kleung@cisco.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Felix, I have added some text to make it clear that the Prefix Table is used for verifying whether the mobile router owns the MNP it claims only if the HA receives a Binding Update in explicit mode. hope this addresses your concern (and also Kent's). In some deployment scenarios, it is necessary for Home Agent to prevent a misbehaving Mobile Router from claiming mobile network prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains the Prefix Table and verifies the Prefix Information provided by the Mobile Router against the entries in the Prefix Table. However, this verification is done only if the Binding Update contained explicit prefix information in the form of either the Mobile Network Prefix Option or the Mobile Network Prefix Length Option. Vijay From exim@www1.ietf.org Mon Jul 28 21:37:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26815 for ; Mon, 28 Jul 2003 21:37:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJPr-0004rt-Qq for nemo-archive@odin.ietf.org; Mon, 28 Jul 2003 21:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T1adi8018707 for nemo-archive@odin.ietf.org; Mon, 28 Jul 2003 21:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJPr-0004rd-LV for nemo-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 21:36:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26785 for ; Mon, 28 Jul 2003 21:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hJOR-0001ok-00 for nemo-web-archive@ietf.org; Mon, 28 Jul 2003 21:35:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hJOG-0001og-00 for nemo-web-archive@ietf.org; Mon, 28 Jul 2003 21:35:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJNJ-0004mp-45; Mon, 28 Jul 2003 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hJMZ-0004mP-4r for nemo@optimus.ietf.org; Mon, 28 Jul 2003 21:33:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26747 for ; Mon, 28 Jul 2003 21:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hJMW-0001oH-00 for nemo@ietf.org; Mon, 28 Jul 2003 21:33:12 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hJMV-0001o7-00 for nemo@ietf.org; Mon, 28 Jul 2003 21:33:11 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA18669; Mon, 28 Jul 2003 18:32:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6T1Wf427300; Mon, 28 Jul 2003 18:32:41 -0700 X-mProtect: <200307290132> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLzE6Pw; Mon, 28 Jul 2003 18:32:39 PDT Message-ID: <3F25CEB7.60E355FD@iprg.nokia.com> Date: Mon, 28 Jul 2003 18:32:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wu@cs.ucdavis.edu, kleung@cisco.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Felix, I have added some text to make it clear that the Prefix Table is used for verifying whether the mobile router owns the MNP it claims only if the HA receives a Binding Update in explicit mode. hope this addresses your concern (and also Kent's). In some deployment scenarios, it is necessary for Home Agent to prevent a misbehaving Mobile Router from claiming mobile network prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains the Prefix Table and verifies the Prefix Information provided by the Mobile Router against the entries in the Prefix Table. However, this verification is done only if the Binding Update contained explicit prefix information in the form of either the Mobile Network Prefix Option or the Mobile Network Prefix Length Option. Vijay From nemo-admin@ietf.org Tue Jul 29 02:50:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14167 for ; Tue, 29 Jul 2003 02:50:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOJ7-0007Uo-J1; Tue, 29 Jul 2003 02:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOIB-0007TJ-R7 for nemo@optimus.ietf.org; Tue, 29 Jul 2003 02:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14147 for ; Tue, 29 Jul 2003 02:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hOI8-00037A-00 for nemo@ietf.org; Tue, 29 Jul 2003 02:49:00 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hOI6-00036o-00 for nemo@ietf.org; Tue, 29 Jul 2003 02:48:59 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6T6fDkK011675 for ; Tue, 29 Jul 2003 14:41:13 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 0E74F10E94CF; Tue, 29 Jul 2003 14:46:46 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: <3F25A8C2.92532F17@iprg.nokia.com> References: <3F1C5150.BB054A68@iprg.nokia.com> <3F25A8C2.92532F17@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059461205.1435.4.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 14:46:45 +0800 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Closing Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all, we will have to reach consensus on this ... may I propose the following text (its a shameless combination of the two, but I hope it can be one step towards consensus): The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the Home Agent MAY store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information can later be used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. Any comments? /rgds /cwng On Tue, 2003-07-29 at 06:50, Vijay Devarapalli wrote: > TJ, Thierry, should I close this issue? any suggestions > on how to proceed? > > Vijay Devarapalli wrote: > > > > Pascal and Kent, > > > > I want to close Issue 3. The issue we are discussing is > > too trivial to warrant so many mails. > > > > the original text that was proposed by me was > > > > The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted. > > > > Pascal objected by saying > > > > > Vijay, can you please be less specific about the data in the BCE? Any > > > handle to the route info is enough; it does not have to take the form of > > > a list of prefixes. For instance it can be pointers to the prefix table. > > > Also, In the case of real static routes, the HA does not install or > > > clear them, so there's no need to keep them in BCE... > > > > I prefer specific text because alteast one person had a > > question about this. I prefer a tight specification. > > I dont see any technical reason not to include the text. > > the only thing I have seen from you is that it is too > > implementation specific. > > > > you prefer something like > > > > The Home Agent MUST keep all necessary information to be able > > to add or delete routes associated with the Mobile Router at > > the time. > > > > I think this sentence is very vague. what information? > > where do you store this information? which data structure? > > > > nobody else seems to be interested in this issue. I am > > not sure how to close this issue. > > > > Vijay > > > > ps: TJ, Thierry, the entire discussion is at > > http://people.nokia.net/vijayd/nemo/issue3.txt -- Chan-Wah Ng Panasonic Singapore Laboratories From exim@www1.ietf.org Tue Jul 29 02:50:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14182 for ; Tue, 29 Jul 2003 02:50:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOJR-0007XG-03 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 02:50:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T6oK2Z028961 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 02:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOJP-0007X2-Pf for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 02:50:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14164 for ; Tue, 29 Jul 2003 02:50:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hOJM-00037Y-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 02:50:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hOJL-00037U-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 02:50:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOJ7-0007Uo-J1; Tue, 29 Jul 2003 02:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hOIB-0007TJ-R7 for nemo@optimus.ietf.org; Tue, 29 Jul 2003 02:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14147 for ; Tue, 29 Jul 2003 02:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hOI8-00037A-00 for nemo@ietf.org; Tue, 29 Jul 2003 02:49:00 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hOI6-00036o-00 for nemo@ietf.org; Tue, 29 Jul 2003 02:48:59 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6T6fDkK011675 for ; Tue, 29 Jul 2003 14:41:13 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 0E74F10E94CF; Tue, 29 Jul 2003 14:46:46 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: <3F25A8C2.92532F17@iprg.nokia.com> References: <3F1C5150.BB054A68@iprg.nokia.com> <3F25A8C2.92532F17@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059461205.1435.4.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 14:46:45 +0800 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Closing Issue 3 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, we will have to reach consensus on this ... may I propose the following text (its a shameless combination of the two, but I hope it can be one step towards consensus): The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the Home Agent MAY store the list of Mobile Network Prefixes owned by a Mobile Router in the corresponding Binding Cache entry. However this is done only when the Mobile Router has included prefix information in the Binding Update. This list of prefixes should include only those for which the Home Agent currently has routes pointing to the Mobile Router's current Care-of address. This information can later be used to delete the routes when the Binding Cache entry for the Mobile Router is deleted. Any comments? /rgds /cwng On Tue, 2003-07-29 at 06:50, Vijay Devarapalli wrote: > TJ, Thierry, should I close this issue? any suggestions > on how to proceed? > > Vijay Devarapalli wrote: > > > > Pascal and Kent, > > > > I want to close Issue 3. The issue we are discussing is > > too trivial to warrant so many mails. > > > > the original text that was proposed by me was > > > > The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted. > > > > Pascal objected by saying > > > > > Vijay, can you please be less specific about the data in the BCE? Any > > > handle to the route info is enough; it does not have to take the form of > > > a list of prefixes. For instance it can be pointers to the prefix table. > > > Also, In the case of real static routes, the HA does not install or > > > clear them, so there's no need to keep them in BCE... > > > > I prefer specific text because alteast one person had a > > question about this. I prefer a tight specification. > > I dont see any technical reason not to include the text. > > the only thing I have seen from you is that it is too > > implementation specific. > > > > you prefer something like > > > > The Home Agent MUST keep all necessary information to be able > > to add or delete routes associated with the Mobile Router at > > the time. > > > > I think this sentence is very vague. what information? > > where do you store this information? which data structure? > > > > nobody else seems to be interested in this issue. I am > > not sure how to close this issue. > > > > Vijay > > > > ps: TJ, Thierry, the entire discussion is at > > http://people.nokia.net/vijayd/nemo/issue3.txt -- Chan-Wah Ng Panasonic Singapore Laboratories From nemo-admin@ietf.org Tue Jul 29 04:34:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15604 for ; Tue, 29 Jul 2003 04:34:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPvm-0002BZ-FM; Tue, 29 Jul 2003 04:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPv7-0002BE-IN for nemo@optimus.ietf.org; Tue, 29 Jul 2003 04:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15593 for ; Tue, 29 Jul 2003 04:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hPv4-0003VB-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:33:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19hPv4-0003V6-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:33:18 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2003 10:32:29 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6T8UJBX013165; Tue, 29 Jul 2003 10:30:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 10:32:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [nemo] Re: Closing Issue 3 Date: Tue, 29 Jul 2003 09:32:39 +0100 Message-ID: Thread-Topic: [nemo] Re: Closing Issue 3 Thread-Index: AcM8PFKiufdwcdE1S/mszwLKx6KuRAPM3V4wAo6cTDA= From: "Pascal Thubert (pthubert)" To: "Pascal Thubert (pthubert)" , "Vijay Devarapalli" , , "Chan-Wah Ng" Cc: X-OriginalArrivalTime: 29 Jul 2003 08:32:39.0894 (UTC) FILETIME=[F8D45760:01C355AB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable My original take on July 16 was (REALLY) as follows: > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefixES in BCE, whether they come from > implicit or explicit source". I still think it's sufficient and that it goes with the spirit TJ proposed. Kent found that this text doesn't cover the case when routes need to be re-injected into the routing table. Kent answered with the text that Vijay's assigning to me:=20 "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." But this was not fully correct because the BCE data is transient. Now Chan Wah is reusing Some of Kent's text (maybe thinking it's mine from Vijay's note). Note that I took great care to cover static routes where the HA does NOT inject or remove the routes. This is lost in Kent and Chan Wah's proposal. Chan Wah, we may be closing in but please try again (if you do not like my original take) Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mercredi 16 juillet 2003 10:04 > To: Vijay Devarapalli > Cc: nemo@ietf.org > Subject: [nemo] Issue 3 >=20 >=20 >=20 > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." >=20 > > is this okay? >=20 > If the info is to be used to delete the routes, then you need to know > which prefixes you actually created routes for, so maybe you need more > info associated to the prefixes, like pointers to the adjacencies that > were instantiated. This is deep into implementation, a bit to much to my > taste. >=20 > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefix in BCE, whether they come from > implicit or explicit source". Vijay, please do not tell people how to > implement things (even if your proposal seems perfectly proper). >=20 > Pascal >=20 From exim@www1.ietf.org Tue Jul 29 04:34:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15620 for ; Tue, 29 Jul 2003 04:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPw2-0002Db-Rf for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 04:34:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T8YInV008526 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 04:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPw1-0002DR-HB for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 04:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15598 for ; Tue, 29 Jul 2003 04:34:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hPvy-0003VI-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 04:34:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hPvy-0003VF-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 04:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPvm-0002BZ-FM; Tue, 29 Jul 2003 04:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hPv7-0002BE-IN for nemo@optimus.ietf.org; Tue, 29 Jul 2003 04:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15593 for ; Tue, 29 Jul 2003 04:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hPv4-0003VB-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:33:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19hPv4-0003V6-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:33:18 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2003 10:32:29 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6T8UJBX013165; Tue, 29 Jul 2003 10:30:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 10:32:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [nemo] Re: Closing Issue 3 Date: Tue, 29 Jul 2003 09:32:39 +0100 Message-ID: Thread-Topic: [nemo] Re: Closing Issue 3 Thread-Index: AcM8PFKiufdwcdE1S/mszwLKx6KuRAPM3V4wAo6cTDA= From: "Pascal Thubert (pthubert)" To: "Pascal Thubert (pthubert)" , "Vijay Devarapalli" , , "Chan-Wah Ng" Cc: X-OriginalArrivalTime: 29 Jul 2003 08:32:39.0894 (UTC) FILETIME=[F8D45760:01C355AB] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My original take on July 16 was (REALLY) as follows: > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefixES in BCE, whether they come from > implicit or explicit source". I still think it's sufficient and that it goes with the spirit TJ proposed. Kent found that this text doesn't cover the case when routes need to be re-injected into the routing table. Kent answered with the text that Vijay's assigning to me:=20 "The Home Agent MUST keep all necessary information to be able to add or delete routes associated with the Mobile Router at the time. For instance, the list of Mobile Network Prefixes may be stored in the Binding Cache entry." But this was not fully correct because the BCE data is transient. Now Chan Wah is reusing Some of Kent's text (maybe thinking it's mine from Vijay's note). Note that I took great care to cover static routes where the HA does NOT inject or remove the routes. This is lost in Kent and Chan Wah's proposal. Chan Wah, we may be closing in but please try again (if you do not like my original take) Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mercredi 16 juillet 2003 10:04 > To: Vijay Devarapalli > Cc: nemo@ietf.org > Subject: [nemo] Issue 3 >=20 >=20 >=20 > "The Home Agent SHOULD store the list of Mobile Network Prefixes > owned by a Mobile Router in the corresponding Binding Cache > entry. However this is done only when the Mobile Router has > included prefix information in the Binding Update. This list > of prefixes should include only those for which the Home Agent > currently has routes pointing to the Mobile Router's current > Care-of address. This information can later be used to delete > the routes when the Binding Cache entry for the Mobile Router > is deleted." >=20 > > is this okay? >=20 > If the info is to be used to delete the routes, then you need to know > which prefixes you actually created routes for, so maybe you need more > info associated to the prefixes, like pointers to the adjacencies that > were instantiated. This is deep into implementation, a bit to much to my > taste. >=20 > I would have preferred a text saying that "the MR MUST keep all > necessary information to clean up whichever routes it installed, for > instance by keeping the list of prefix in BCE, whether they come from > implicit or explicit source". Vijay, please do not tell people how to > implement things (even if your proposal seems perfectly proper). >=20 > Pascal >=20 From nemo-admin@ietf.org Tue Jul 29 04:51:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15945 for ; Tue, 29 Jul 2003 04:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCE-0002pY-48; Tue, 29 Jul 2003 04:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCA-0002pB-PO for nemo@optimus.ietf.org; Tue, 29 Jul 2003 04:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15928 for ; Tue, 29 Jul 2003 04:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQC7-0003Zk-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:50:55 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hQC5-0003ZU-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:50:54 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6T8gvkK014970; Tue, 29 Jul 2003 16:42:57 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 9A0BF10E94CF; Tue, 29 Jul 2003 16:48:29 +0800 (SGT) Subject: Re: [nemo] Re: Closing Issue 3 From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , "T.J. Kniveton" , IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059468509.1435.47.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 16:48:29 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry for the mixed up, Pascal. I will try harder ;), but not before the following doubts are answered. On Tue, 2003-07-29 at 16:32, Pascal Thubert (pthubert) wrote: > My original take on July 16 was (REALLY) as follows: > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefixES in BCE, whether they come > from > > implicit or explicit source". > Is that "the MR MUST... " or "the HA MUST..."? > I still think it's sufficient and that it goes with the spirit TJ > proposed. > > Kent found that this text doesn't cover the case when routes need to be > re-injected into the routing table. Kent answered with the text that > Vijay's assigning to me: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For > instance, the list of Mobile Network Prefixes may be stored in the > Binding Cache entry." > > But this was not fully correct because the BCE data is transient. > By BCE is transient, I presume you meant that BCE entry will expire according to lifetime field in the BU or BA message. Why should this be a problem? If the MR is alive and still attached to the global network, it would have sent a refresh or updated BU containing the prefix (assuming that is how it injected routes) before the BCE expires. If the HA does not receive the BU by the time the corresponding BCE expires, the HA would have to assume that the MR is no longer reacheable, and should delete the dynamic routes anyway, > Now Chan Wah is reusing Some of Kent's text (maybe thinking it's mine > from Vijay's note). yep right, my mistake, I apologize. > Note that I took great care to cover static routes > where the HA does NOT inject or remove the routes. This is lost in Kent > and Chan Wah's proposal. > Chan Wah, we may be closing in but please try again (if you do not like > my original take) > > Pascal > > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: mercredi 16 juillet 2003 10:04 > > To: Vijay Devarapalli > > Cc: nemo@ietf.org > > Subject: [nemo] Issue 3 > > > > > > > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted." > > > > > is this okay? > > > > If the info is to be used to delete the routes, then you need to know > > which prefixes you actually created routes for, so maybe you need more > > info associated to the prefixes, like pointers to the adjacencies that > > were instantiated. This is deep into implementation, a bit to much to > my > > taste. > > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). > > > > Pascal > > > From exim@www1.ietf.org Tue Jul 29 04:51:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15960 for ; Tue, 29 Jul 2003 04:51:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCQ-0002th-Qn for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 04:51:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T8pETR011137 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 04:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCQ-0002tY-Kx for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 04:51:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15935 for ; Tue, 29 Jul 2003 04:51:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQCN-0003Zy-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 04:51:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hQCN-0003Zv-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 04:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCE-0002pY-48; Tue, 29 Jul 2003 04:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQCA-0002pB-PO for nemo@optimus.ietf.org; Tue, 29 Jul 2003 04:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15928 for ; Tue, 29 Jul 2003 04:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQC7-0003Zk-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:50:55 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hQC5-0003ZU-00 for nemo@ietf.org; Tue, 29 Jul 2003 04:50:54 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6T8gvkK014970; Tue, 29 Jul 2003 16:42:57 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 9A0BF10E94CF; Tue, 29 Jul 2003 16:48:29 +0800 (SGT) Subject: Re: [nemo] Re: Closing Issue 3 From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , "T.J. Kniveton" , IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059468509.1435.47.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 16:48:29 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the mixed up, Pascal. I will try harder ;), but not before the following doubts are answered. On Tue, 2003-07-29 at 16:32, Pascal Thubert (pthubert) wrote: > My original take on July 16 was (REALLY) as follows: > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefixES in BCE, whether they come > from > > implicit or explicit source". > Is that "the MR MUST... " or "the HA MUST..."? > I still think it's sufficient and that it goes with the spirit TJ > proposed. > > Kent found that this text doesn't cover the case when routes need to be > re-injected into the routing table. Kent answered with the text that > Vijay's assigning to me: > > "The Home Agent MUST keep all necessary information to be able to add or > delete routes associated with the Mobile Router at the time. For > instance, the list of Mobile Network Prefixes may be stored in the > Binding Cache entry." > > But this was not fully correct because the BCE data is transient. > By BCE is transient, I presume you meant that BCE entry will expire according to lifetime field in the BU or BA message. Why should this be a problem? If the MR is alive and still attached to the global network, it would have sent a refresh or updated BU containing the prefix (assuming that is how it injected routes) before the BCE expires. If the HA does not receive the BU by the time the corresponding BCE expires, the HA would have to assume that the MR is no longer reacheable, and should delete the dynamic routes anyway, > Now Chan Wah is reusing Some of Kent's text (maybe thinking it's mine > from Vijay's note). yep right, my mistake, I apologize. > Note that I took great care to cover static routes > where the HA does NOT inject or remove the routes. This is lost in Kent > and Chan Wah's proposal. > Chan Wah, we may be closing in but please try again (if you do not like > my original take) > > Pascal > > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: mercredi 16 juillet 2003 10:04 > > To: Vijay Devarapalli > > Cc: nemo@ietf.org > > Subject: [nemo] Issue 3 > > > > > > > > "The Home Agent SHOULD store the list of Mobile Network Prefixes > > owned by a Mobile Router in the corresponding Binding Cache > > entry. However this is done only when the Mobile Router has > > included prefix information in the Binding Update. This list > > of prefixes should include only those for which the Home Agent > > currently has routes pointing to the Mobile Router's current > > Care-of address. This information can later be used to delete > > the routes when the Binding Cache entry for the Mobile Router > > is deleted." > > > > > is this okay? > > > > If the info is to be used to delete the routes, then you need to know > > which prefixes you actually created routes for, so maybe you need more > > info associated to the prefixes, like pointers to the adjacencies that > > were instantiated. This is deep into implementation, a bit to much to > my > > taste. > > > > I would have preferred a text saying that "the MR MUST keep all > > necessary information to clean up whichever routes it installed, for > > instance by keeping the list of prefix in BCE, whether they come from > > implicit or explicit source". Vijay, please do not tell people how to > > implement things (even if your proposal seems perfectly proper). > > > > Pascal > > > From nemo-admin@ietf.org Tue Jul 29 05:23:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16539 for ; Tue, 29 Jul 2003 05:23:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQhA-0003mv-Kc; Tue, 29 Jul 2003 05:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQge-0003mf-4B for nemo@optimus.ietf.org; Tue, 29 Jul 2003 05:22:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16523 for ; Tue, 29 Jul 2003 05:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQga-0003iv-00 for nemo@ietf.org; Tue, 29 Jul 2003 05:22:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19hQga-0003il-00 for nemo@ietf.org; Tue, 29 Jul 2003 05:22:24 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2003 11:21:35 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6T9JY5j024605; Tue, 29 Jul 2003 11:19:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 11:21:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Closing Issue 3 Date: Tue, 29 Jul 2003 10:21:48 +0100 Message-ID: Thread-Topic: [nemo] Re: Closing Issue 3 Thread-Index: AcNVrn7hGRafM1IeQwiUXL7RttYh7gAA7tBg From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "Vijay Devarapalli" , "T.J. Kniveton" , "IETF NEMO WG" , "Kent Leung (kleung)" X-OriginalArrivalTime: 29 Jul 2003 09:21:49.0210 (UTC) FILETIME=[D6C23FA0:01C355B2] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Chan-Wah Ng [mailto:cwng@psl.com.sg] > Sent: mardi 29 juillet 2003 10:48 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; T.J. Kniveton; IETF NEMO WG > Subject: Re: [nemo] Re: Closing Issue 3 >=20 > Sorry for the mixed up, Pascal. I will try harder ;), but not before > the following doubts are answered. >=20 > On Tue, 2003-07-29 at 16:32, Pascal Thubert (pthubert) wrote: > > My original take on July 16 was (REALLY) as follows: > > > > > I would have preferred a text saying that "the MR MUST keep all > > > necessary information to clean up whichever routes it installed, for > > > instance by keeping the list of prefixES in BCE, whether they come > > from > > > implicit or explicit source". > > >=20 > Is that "the MR MUST... " or "the HA MUST..."? >=20 Sure, sorry for the typo >=20 > > I still think it's sufficient and that it goes with the spirit TJ > > proposed. > > > > Kent found that this text doesn't cover the case when routes need to be > > re-injected into the routing table. Kent answered with the text that > > Vijay's assigning to me: > > > > "The Home Agent MUST keep all necessary information to be able to add or > > delete routes associated with the Mobile Router at the time. For > > instance, the list of Mobile Network Prefixes may be stored in the > > Binding Cache entry." > > > > But this was not fully correct because the BCE data is transient. > > > By BCE is transient, I presume you meant that BCE entry will expire > according to lifetime field in the BU or BA message. Why should this be > a problem? If the MR is alive and still attached to the global network, > it would have sent a refresh or updated BU containing the prefix > (assuming that is how it injected routes) before the BCE expires. If > the HA does not receive the BU by the time the corresponding BCE > expires, the HA would have to assume that the MR is no longer > reacheable, and should delete the dynamic routes anyway, Agreed Kent wanted to make sure that when the routes are removed (say lifetime expires) then the HA will be able to reinstall them upon a new binding from that MR. As you say, this is not a real problem. An oter wording for the same answer is that whatever the HA used the first time can be used again (implicit with prefix table or explicit) Pascal From exim@www1.ietf.org Tue Jul 29 05:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16554 for ; Tue, 29 Jul 2003 05:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQhO-0003r8-GI for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 05:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T9NEUG014819 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 05:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQhN-0003qw-SX for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 05:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16536 for ; Tue, 29 Jul 2003 05:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQhK-0003j8-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 05:23:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hQhK-0003j5-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 05:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQhA-0003mv-Kc; Tue, 29 Jul 2003 05:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hQge-0003mf-4B for nemo@optimus.ietf.org; Tue, 29 Jul 2003 05:22:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16523 for ; Tue, 29 Jul 2003 05:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hQga-0003iv-00 for nemo@ietf.org; Tue, 29 Jul 2003 05:22:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19hQga-0003il-00 for nemo@ietf.org; Tue, 29 Jul 2003 05:22:24 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2003 11:21:35 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6T9JY5j024605; Tue, 29 Jul 2003 11:19:39 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 11:21:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.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: Closing Issue 3 Date: Tue, 29 Jul 2003 10:21:48 +0100 Message-ID: Thread-Topic: [nemo] Re: Closing Issue 3 Thread-Index: AcNVrn7hGRafM1IeQwiUXL7RttYh7gAA7tBg From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "Vijay Devarapalli" , "T.J. Kniveton" , "IETF NEMO WG" , "Kent Leung (kleung)" X-OriginalArrivalTime: 29 Jul 2003 09:21:49.0210 (UTC) FILETIME=[D6C23FA0:01C355B2] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Chan-Wah Ng [mailto:cwng@psl.com.sg] > Sent: mardi 29 juillet 2003 10:48 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; T.J. Kniveton; IETF NEMO WG > Subject: Re: [nemo] Re: Closing Issue 3 >=20 > Sorry for the mixed up, Pascal. I will try harder ;), but not before > the following doubts are answered. >=20 > On Tue, 2003-07-29 at 16:32, Pascal Thubert (pthubert) wrote: > > My original take on July 16 was (REALLY) as follows: > > > > > I would have preferred a text saying that "the MR MUST keep all > > > necessary information to clean up whichever routes it installed, for > > > instance by keeping the list of prefixES in BCE, whether they come > > from > > > implicit or explicit source". > > >=20 > Is that "the MR MUST... " or "the HA MUST..."? >=20 Sure, sorry for the typo >=20 > > I still think it's sufficient and that it goes with the spirit TJ > > proposed. > > > > Kent found that this text doesn't cover the case when routes need to be > > re-injected into the routing table. Kent answered with the text that > > Vijay's assigning to me: > > > > "The Home Agent MUST keep all necessary information to be able to add or > > delete routes associated with the Mobile Router at the time. For > > instance, the list of Mobile Network Prefixes may be stored in the > > Binding Cache entry." > > > > But this was not fully correct because the BCE data is transient. > > > By BCE is transient, I presume you meant that BCE entry will expire > according to lifetime field in the BU or BA message. Why should this be > a problem? If the MR is alive and still attached to the global network, > it would have sent a refresh or updated BU containing the prefix > (assuming that is how it injected routes) before the BCE expires. If > the HA does not receive the BU by the time the corresponding BCE > expires, the HA would have to assume that the MR is no longer > reacheable, and should delete the dynamic routes anyway, Agreed Kent wanted to make sure that when the routes are removed (say lifetime expires) then the HA will be able to reinstall them upon a new binding from that MR. As you say, this is not a real problem. An oter wording for the same answer is that whatever the HA used the first time can be used again (implicit with prefix table or explicit) Pascal From nemo-admin@ietf.org Tue Jul 29 07:21:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18796 for ; Tue, 29 Jul 2003 07:21:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSXM-00078a-Vy; Tue, 29 Jul 2003 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSX2-00076o-K1 for nemo@optimus.ietf.org; Tue, 29 Jul 2003 07:20:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18767 for ; Tue, 29 Jul 2003 07:20:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hSX1-0004TR-00 for nemo@ietf.org; Tue, 29 Jul 2003 07:20:39 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hSX0-0004TA-00 for nemo@ietf.org; Tue, 29 Jul 2003 07:20:38 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6TBCZkK018034; Tue, 29 Jul 2003 19:12:35 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 670C610E94CF; Tue, 29 Jul 2003 19:18:07 +0800 (SGT) Subject: RE: [nemo] Re: Closing Issue 3 From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , "T.J. Kniveton" , IETF NEMO WG , "Kent Leung (kleung)" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059477487.1435.135.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 19:18:07 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, let me try this again. Objective is: (1) to state that HA MUST maintain all information necessary for it to clean up routes that are injected by the MR through the bi-directional tunnel, or through a binding update (be it implicit or explicit), when parameters of the bi-directional tunnel is changed. (2) not be too vague: Quoting Vijay: "what information? where do you store this information? which data structure?" This is what I come up with: The home agent MUST maintain all information necessary for it to clean up routes that are injected by the MR through the bi-directional tunnel, or through a binding update, when the bi-directional tunnel is tore down or the end-point(s) of the bi-directional tunnel has changed. For instance, For instance, the home agent MAY keep the list of prefixes in BCE, whether they come from implicit or explicit source, so that routes corresponding to these prefixes can be deleted when the BCE expires or is deleted. How about this? /rgds /cwng From exim@www1.ietf.org Tue Jul 29 07:21:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18811 for ; Tue, 29 Jul 2003 07:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSXd-00079S-W7 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 07:21:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TBLHn7027490 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 07:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSXd-00079J-Oy for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 07:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18789 for ; Tue, 29 Jul 2003 07:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hSXd-0004Tm-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 07:21:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hSXc-0004Tj-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 07:21:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSXM-00078a-Vy; Tue, 29 Jul 2003 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hSX2-00076o-K1 for nemo@optimus.ietf.org; Tue, 29 Jul 2003 07:20:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18767 for ; Tue, 29 Jul 2003 07:20:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hSX1-0004TR-00 for nemo@ietf.org; Tue, 29 Jul 2003 07:20:39 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19hSX0-0004TA-00 for nemo@ietf.org; Tue, 29 Jul 2003 07:20:38 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6TBCZkK018034; Tue, 29 Jul 2003 19:12:35 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 670C610E94CF; Tue, 29 Jul 2003 19:18:07 +0800 (SGT) Subject: RE: [nemo] Re: Closing Issue 3 From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , "T.J. Kniveton" , IETF NEMO WG , "Kent Leung (kleung)" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1059477487.1435.135.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 19:18:07 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, let me try this again. Objective is: (1) to state that HA MUST maintain all information necessary for it to clean up routes that are injected by the MR through the bi-directional tunnel, or through a binding update (be it implicit or explicit), when parameters of the bi-directional tunnel is changed. (2) not be too vague: Quoting Vijay: "what information? where do you store this information? which data structure?" This is what I come up with: The home agent MUST maintain all information necessary for it to clean up routes that are injected by the MR through the bi-directional tunnel, or through a binding update, when the bi-directional tunnel is tore down or the end-point(s) of the bi-directional tunnel has changed. For instance, For instance, the home agent MAY keep the list of prefixes in BCE, whether they come from implicit or explicit source, so that routes corresponding to these prefixes can be deleted when the BCE expires or is deleted. How about this? /rgds /cwng From nemo-admin@ietf.org Tue Jul 29 12:20:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28092 for ; Tue, 29 Jul 2003 12:20:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXCj-0001Sn-W3; Tue, 29 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXCK-0001S1-Kk for nemo@optimus.ietf.org; Tue, 29 Jul 2003 12:19:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28039; Tue, 29 Jul 2003 12:19:30 -0400 (EDT) Message-Id: <200307291619.MAA28039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 29 Jul 2003 12:19:30 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-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-perera-nemo-extended-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: <2003-7-29122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jul 29 12:20:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28107 for ; Tue, 29 Jul 2003 12:20:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXD0-0001VL-5T for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 12:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TGKI5K005779 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 12:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXD0-0001V8-2K for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 12:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28074 for ; Tue, 29 Jul 2003 12:20:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hXCy-000714-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 12:20:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hXCy-000711-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 12:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXCj-0001Sn-W3; Tue, 29 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hXCK-0001S1-Kk for nemo@optimus.ietf.org; Tue, 29 Jul 2003 12:19:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28039; Tue, 29 Jul 2003 12:19:30 -0400 (EDT) Message-Id: <200307291619.MAA28039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 29 Jul 2003 12:19:30 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-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-perera-nemo-extended-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: <2003-7-29122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Tue Jul 29 13:41:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02046 for ; Tue, 29 Jul 2003 13:41:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYT8-0004dj-Bn; Tue, 29 Jul 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYSP-0004cj-4Q for nemo@optimus.ietf.org; Tue, 29 Jul 2003 13:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02019 for ; Tue, 29 Jul 2003 13:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYSM-0000LL-00 for nemo@ietf.org; Tue, 29 Jul 2003 13:40:15 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hYSM-0000Km-00 for nemo@ietf.org; Tue, 29 Jul 2003 13:40:14 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03383; Tue, 29 Jul 2003 10:39:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6THdKC08624; Tue, 29 Jul 2003 10:39:20 -0700 X-mProtect: <200307291739> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjCWAZD; Tue, 29 Jul 2003 10:39:19 PDT Message-ID: <3F26B147.11DBCA0F@iprg.nokia.com> Date: Tue, 29 Jul 2003 10:39:19 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: "Pascal Thubert (pthubert)" , "T.J. Kniveton" , IETF NEMO WG , "Kent Leung (kleung)" Subject: Re: [nemo] Re: Closing Issue 3 References: <1059477487.1435.135.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I probably forgot to tell you that the text I proposed was going into section 6.1.1 of the latest spec http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre01.txt. binding cache as a conceptual data structure is described in the MIPv6 spec. I just wanted to mention how NEMO extends it. the prefix information needs to stored in it in case the Binding Update (which created this BCE) contained prefix information in explicit mode. so the following text really doesnt fit under that section. also remember that under section 6.7 (Mobile Network Prefix De-Registration) we have the following text. In addition, the Home Agent also removes the bi-directional tunnel and stops forwarding packets to the mobile network. Vijay Chan-Wah Ng wrote: > > Ok, let me try this again. > > Objective is: > > (1) to state that HA MUST maintain all information necessary for it to > clean up routes that are injected by the MR through the bi-directional > tunnel, or through a binding update (be it implicit or explicit), when > parameters of the bi-directional tunnel is changed. > > (2) not be too vague: Quoting Vijay: "what information? where do you > store this information? which data structure?" > > This is what I come up with: > > The home agent MUST maintain all information necessary for it to > clean up routes that are injected by the MR through the > bi-directional tunnel, or through a binding update, when the > bi-directional tunnel is tore down or the end-point(s) of the > bi-directional tunnel has changed. For instance, For instance, > the home agent MAY keep the list of prefixes in BCE, whether > they come from implicit or explicit source, so that routes > corresponding to these prefixes can be deleted when the BCE > expires or is deleted. > > How about this? > > /rgds > /cwng From exim@www1.ietf.org Tue Jul 29 13:41:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02061 for ; Tue, 29 Jul 2003 13:41:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYTP-0004fy-4l for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 13:41:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THfJMh017968 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 13:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYTP-0004fj-0s for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 13:41:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02037 for ; Tue, 29 Jul 2003 13:41:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYTM-0000Lx-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 13:41:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hYTM-0000Lu-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 13:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYT8-0004dj-Bn; Tue, 29 Jul 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYSP-0004cj-4Q for nemo@optimus.ietf.org; Tue, 29 Jul 2003 13:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02019 for ; Tue, 29 Jul 2003 13:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYSM-0000LL-00 for nemo@ietf.org; Tue, 29 Jul 2003 13:40:15 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hYSM-0000Km-00 for nemo@ietf.org; Tue, 29 Jul 2003 13:40:14 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03383; Tue, 29 Jul 2003 10:39:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6THdKC08624; Tue, 29 Jul 2003 10:39:20 -0700 X-mProtect: <200307291739> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjCWAZD; Tue, 29 Jul 2003 10:39:19 PDT Message-ID: <3F26B147.11DBCA0F@iprg.nokia.com> Date: Tue, 29 Jul 2003 10:39:19 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chan-Wah Ng CC: "Pascal Thubert (pthubert)" , "T.J. Kniveton" , IETF NEMO WG , "Kent Leung (kleung)" Subject: Re: [nemo] Re: Closing Issue 3 References: <1059477487.1435.135.camel@beethoven> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I probably forgot to tell you that the text I proposed was going into section 6.1.1 of the latest spec http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre01.txt. binding cache as a conceptual data structure is described in the MIPv6 spec. I just wanted to mention how NEMO extends it. the prefix information needs to stored in it in case the Binding Update (which created this BCE) contained prefix information in explicit mode. so the following text really doesnt fit under that section. also remember that under section 6.7 (Mobile Network Prefix De-Registration) we have the following text. In addition, the Home Agent also removes the bi-directional tunnel and stops forwarding packets to the mobile network. Vijay Chan-Wah Ng wrote: > > Ok, let me try this again. > > Objective is: > > (1) to state that HA MUST maintain all information necessary for it to > clean up routes that are injected by the MR through the bi-directional > tunnel, or through a binding update (be it implicit or explicit), when > parameters of the bi-directional tunnel is changed. > > (2) not be too vague: Quoting Vijay: "what information? where do you > store this information? which data structure?" > > This is what I come up with: > > The home agent MUST maintain all information necessary for it to > clean up routes that are injected by the MR through the > bi-directional tunnel, or through a binding update, when the > bi-directional tunnel is tore down or the end-point(s) of the > bi-directional tunnel has changed. For instance, For instance, > the home agent MAY keep the list of prefixes in BCE, whether > they come from implicit or explicit source, so that routes > corresponding to these prefixes can be deleted when the BCE > expires or is deleted. > > How about this? > > /rgds > /cwng From nemo-admin@ietf.org Tue Jul 29 13:51:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02276 for ; Tue, 29 Jul 2003 13:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYco-0004wn-5K; Tue, 29 Jul 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYcO-0004wN-3V for nemo@optimus.ietf.org; Tue, 29 Jul 2003 13:50:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02249; Tue, 29 Jul 2003 13:50:30 -0400 (EDT) Message-Id: <200307291750.NAA02249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 29 Jul 2003 13:50:30 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-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-perera-nemo-extended-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: <2003-7-29122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jul 29 13:51:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02291 for ; Tue, 29 Jul 2003 13:51:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYcz-000512-VW for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 13:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THpDos019274 for nemo-archive@odin.ietf.org; Tue, 29 Jul 2003 13:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYcz-00050n-Qd for nemo-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 13:51:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02270 for ; Tue, 29 Jul 2003 13:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYcx-0000Q5-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 13:51:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hYcx-0000Q2-00 for nemo-web-archive@ietf.org; Tue, 29 Jul 2003 13:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYco-0004wn-5K; Tue, 29 Jul 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYcO-0004wN-3V for nemo@optimus.ietf.org; Tue, 29 Jul 2003 13:50:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02249; Tue, 29 Jul 2003 13:50:30 -0400 (EDT) Message-Id: <200307291750.NAA02249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 29 Jul 2003 13:50:30 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-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-perera-nemo-extended-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: <2003-7-29122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Jul 30 05:24:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24805 for ; Wed, 30 Jul 2003 05:24:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnAj-0001mX-4B; Wed, 30 Jul 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn9n-0001mG-BM for nemo@optimus.ietf.org; Wed, 30 Jul 2003 05:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24774 for ; Wed, 30 Jul 2003 05:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hn9i-0006G4-00 for nemo@ietf.org; Wed, 30 Jul 2003 05:21:58 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19hn9h-0006Fo-00 for nemo@ietf.org; Wed, 30 Jul 2003 05:21:58 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 7EA655D107; Wed, 30 Jul 2003 18:21:28 +0900 (JST) Date: Wed, 30 Jul 2003 18:18:21 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Missing minutes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, Our minutes-taker went out of battery during the NEMO meeting. As a result, part of his notes are corrupted. So, is there anyone out there who could provide his notes for the first 4 parts below so that we can merge and publish ? 1) Agenda Bashing - Chairs 2) NEMO status and milestones - Chairs 3) NEMO Basic Support - Ryuji Wakikawa 4) Multihoming This would be highly appreciated. The most important is questions and answers. Thanks in advance, Thierry. From exim@www1.ietf.org Wed Jul 30 05:24:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24820 for ; Wed, 30 Jul 2003 05:24:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnBd-0001qz-Lc for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 05:23:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U9NvHM007119 for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 05:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnBd-0001qk-GT for nemo-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 05:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24794 for ; Wed, 30 Jul 2003 05:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hnBZ-0006GW-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 05:23:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hnBY-0006GS-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 05:23:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnAj-0001mX-4B; Wed, 30 Jul 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn9n-0001mG-BM for nemo@optimus.ietf.org; Wed, 30 Jul 2003 05:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24774 for ; Wed, 30 Jul 2003 05:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hn9i-0006G4-00 for nemo@ietf.org; Wed, 30 Jul 2003 05:21:58 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19hn9h-0006Fo-00 for nemo@ietf.org; Wed, 30 Jul 2003 05:21:58 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 7EA655D107; Wed, 30 Jul 2003 18:21:28 +0900 (JST) Date: Wed, 30 Jul 2003 18:18:21 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Missing minutes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Our minutes-taker went out of battery during the NEMO meeting. As a result, part of his notes are corrupted. So, is there anyone out there who could provide his notes for the first 4 parts below so that we can merge and publish ? 1) Agenda Bashing - Chairs 2) NEMO status and milestones - Chairs 3) NEMO Basic Support - Ryuji Wakikawa 4) Multihoming This would be highly appreciated. The most important is questions and answers. Thanks in advance, Thierry. From nemo-admin@ietf.org Wed Jul 30 14:29:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11969 for ; Wed, 30 Jul 2003 14:29:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvg9-00069g-6q; Wed, 30 Jul 2003 14:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvfo-00069N-BJ for nemo@optimus.ietf.org; Wed, 30 Jul 2003 14:27:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11902 for ; Wed, 30 Jul 2003 14:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvfl-0002Yz-00 for nemo@ietf.org; Wed, 30 Jul 2003 14:27:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hvfk-0002Yr-00 for nemo@ietf.org; Wed, 30 Jul 2003 14:27:36 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA14723; Wed, 30 Jul 2003 11:26:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6UIQeb05270; Wed, 30 Jul 2003 11:26:40 -0700 X-mProtect: <200307301826> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.43, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCViKH2; Wed, 30 Jul 2003 11:26:38 PDT Message-ID: <3F280DDE.7090201@iprg.nokia.com> Date: Wed, 30 Jul 2003 11:26:38 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pthubert@cisco.com, Kent Leung CC: Jongkeun , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal, Kent here is another attempt to close Issue 6. When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router should be careful in including the same mobile network prefixes in the Binding Update to the HA and in the routing protocol updates. The HA depending on its configuration might not add routes based on the prefix information in the Binding Updates at all, and might use only the routing protocol updates. Moreover, including the same prefix information in both the Binding Update and the routing protocol update is redundant. this text does not prohibit the MR from running an IGP and Binding Updates in explicit mode at the same time. but it does give a warning on what might go wrong. let me know what you think about this text. Vijay From exim@www1.ietf.org Wed Jul 30 14:29:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11984 for ; Wed, 30 Jul 2003 14:29:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvgq-0006Ek-Rm for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 14:28:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UISinO023968 for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 14:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvgq-0006EV-Mj for nemo-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 14:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11944 for ; Wed, 30 Jul 2003 14:28:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvgo-0002Zf-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 14:28:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hvgn-0002Zc-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 14:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvg9-00069g-6q; Wed, 30 Jul 2003 14:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvfo-00069N-BJ for nemo@optimus.ietf.org; Wed, 30 Jul 2003 14:27:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11902 for ; Wed, 30 Jul 2003 14:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvfl-0002Yz-00 for nemo@ietf.org; Wed, 30 Jul 2003 14:27:37 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19hvfk-0002Yr-00 for nemo@ietf.org; Wed, 30 Jul 2003 14:27:36 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA14723; Wed, 30 Jul 2003 11:26:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6UIQeb05270; Wed, 30 Jul 2003 11:26:40 -0700 X-mProtect: <200307301826> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.43, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCViKH2; Wed, 30 Jul 2003 11:26:38 PDT Message-ID: <3F280DDE.7090201@iprg.nokia.com> Date: Wed, 30 Jul 2003 11:26:38 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pthubert@cisco.com, Kent Leung CC: Jongkeun , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal, Kent here is another attempt to close Issue 6. When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router should be careful in including the same mobile network prefixes in the Binding Update to the HA and in the routing protocol updates. The HA depending on its configuration might not add routes based on the prefix information in the Binding Updates at all, and might use only the routing protocol updates. Moreover, including the same prefix information in both the Binding Update and the routing protocol update is redundant. this text does not prohibit the MR from running an IGP and Binding Updates in explicit mode at the same time. but it does give a warning on what might go wrong. let me know what you think about this text. Vijay From nemo-admin@ietf.org Wed Jul 30 22:21:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26943 for ; Wed, 30 Jul 2003 22:21:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i32v-0007TD-KI; Wed, 30 Jul 2003 22:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i326-0007SV-Va for nemo@optimus.ietf.org; Wed, 30 Jul 2003 22:19:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26917 for ; Wed, 30 Jul 2003 22:19:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i323-0006QK-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:19:07 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19i322-0006QH-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:19:06 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Thu, 31 Jul 2003 12:19:04 +1000 From: "Muhammad Ali Malik" To: Date: Thu, 31 Jul 2003 12:19:14 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C3575D.F4F86380" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] NEMO basic protocol question !!!! Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C3575D.F4F86380 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA26918 Content-Transfer-Encoding: quoted-printable Hi I will be grateful if someone can answer these questions related to NEMO basic protocol. 1. Why it is not possible for mobile network node to obtains the CoA in foreign location. As NEMO basic protocol states that only MR obtains the care-of-address. 2. What do the protocol means that mobility is transparent to mobile netw= ork nodes =85.. how can we achieved transparency. Regards, Muhammad Ali Malik ------=_NextPart_000_0000_01C3575D.F4F86380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I will be grateful if someone can answer these questions related = to NEMO basic protocol.

 

  1. Wh= y it is not possible for mobile network node to obtains the CoA in = foreign location. As NEMO basic protocol states that only MR obtains the = care-of-address.
  2. Wh= at do the protocol means that mobility is transparent to mobile = network nodes ….. how can we achieved = transparency.

 

Regards,

 

Muhammad Ali Malik

 

 

 

------=_NextPart_000_0000_01C3575D.F4F86380-- From exim@www1.ietf.org Wed Jul 30 22:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26958 for ; Wed, 30 Jul 2003 22:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i33t-0007Xc-1Y for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 22:21:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V2L1s8028983 for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 22:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i33s-0007XO-Ef for nemo-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 22:21:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26935 for ; Wed, 30 Jul 2003 22:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i33p-0006Qp-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 22:20:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i33o-0006Qm-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 22:20:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i32v-0007TD-KI; Wed, 30 Jul 2003 22:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i326-0007SV-Va for nemo@optimus.ietf.org; Wed, 30 Jul 2003 22:19:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26917 for ; Wed, 30 Jul 2003 22:19:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i323-0006QK-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:19:07 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19i322-0006QH-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:19:06 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Thu, 31 Jul 2003 12:19:04 +1000 From: "Muhammad Ali Malik" To: Date: Thu, 31 Jul 2003 12:19:14 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C3575D.F4F86380" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [nemo] NEMO basic protocol question !!!! Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C3575D.F4F86380 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA26918 Content-Transfer-Encoding: quoted-printable Hi I will be grateful if someone can answer these questions related to NEMO basic protocol. 1. Why it is not possible for mobile network node to obtains the CoA in foreign location. As NEMO basic protocol states that only MR obtains the care-of-address. 2. What do the protocol means that mobility is transparent to mobile netw= ork nodes =85.. how can we achieved transparency. Regards, Muhammad Ali Malik ------=_NextPart_000_0000_01C3575D.F4F86380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I will be grateful if someone can answer these questions related = to NEMO basic protocol.

 

  1. Wh= y it is not possible for mobile network node to obtains the CoA in = foreign location. As NEMO basic protocol states that only MR obtains the = care-of-address.
  2. Wh= at do the protocol means that mobility is transparent to mobile = network nodes ….. how can we achieved = transparency.

 

Regards,

 

Muhammad Ali Malik

 

 

 

------=_NextPart_000_0000_01C3575D.F4F86380-- From nemo-admin@ietf.org Wed Jul 30 22:49:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27308 for ; Wed, 30 Jul 2003 22:49:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3U1-0008BI-IE; Wed, 30 Jul 2003 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3T7-0008A5-93 for nemo@optimus.ietf.org; Wed, 30 Jul 2003 22:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27262 for ; Wed, 30 Jul 2003 22:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i3T3-0006V4-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:47:01 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19i3T2-0006V0-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:47:00 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6V2dBkK016828; Thu, 31 Jul 2003 10:39:11 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B860910E94CF; Thu, 31 Jul 2003 10:44:39 +0800 (SGT) Subject: Re: [nemo] NEMO basic protocol question !!!! From: Chan-Wah Ng To: Muhammad Ali Malik Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Organization: Panasonic Singapore Laboratories Message-Id: <1059619479.1437.24.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 31 Jul 2003 10:44:39 +0800 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, Muhammad, Let me try to answer. I am sure others will fill in any gaps in my answer. (1) It is possible, but not necessary. As stated in your question 2, objective is to achieve mobility transparency for the mobile network nodes (MNNs). Since they do not know anything about mobility, there is no concept of CoA. (2) It means that the MNNs do not need to know that the MR has changed its point of attachment. They do not need to have special protocol other than those found in any normal IPv6 node. Specifically, they do not need to have MIPv6. They continue to use the address configured from the network prefix announced by MR, and continue to use MR as the default router. They will continue to be able to reach, and be reach by, the Internet. /rgds /cwng On Thu, 2003-07-31 at 10:19, Muhammad Ali Malik wrote: > Hi >=20 > =20 >=20 > I will be grateful if someone can answer these questions related to > NEMO basic protocol. >=20 > =20 >=20 > 1. Why it is not possible for mobile network node to obtains the > CoA in foreign location. As NEMO basic protocol states that > only MR obtains the care-of-address. > 2. What do the protocol means that mobility is transparent to > mobile network nodes =85.. how can we achieved transparency. >=20 >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Muhammad Ali Malik >=20 > =20 >=20 > =20 >=20 > =20 From exim@www1.ietf.org Wed Jul 30 22:49:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27323 for ; Wed, 30 Jul 2003 22:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3Uu-0008HM-4y for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 22:48:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V2muvS031818 for nemo-archive@odin.ietf.org; Wed, 30 Jul 2003 22:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3Ut-0008H7-W6 for nemo-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 22:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27305 for ; Wed, 30 Jul 2003 22:48:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i3Uq-0006Vp-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 22:48:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i3Uq-0006Vm-00 for nemo-web-archive@ietf.org; Wed, 30 Jul 2003 22:48:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3U1-0008BI-IE; Wed, 30 Jul 2003 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i3T7-0008A5-93 for nemo@optimus.ietf.org; Wed, 30 Jul 2003 22:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27262 for ; Wed, 30 Jul 2003 22:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i3T3-0006V4-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:47:01 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19i3T2-0006V0-00 for nemo@ietf.org; Wed, 30 Jul 2003 22:47:00 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h6V2dBkK016828; Thu, 31 Jul 2003 10:39:11 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B860910E94CF; Thu, 31 Jul 2003 10:44:39 +0800 (SGT) Subject: Re: [nemo] NEMO basic protocol question !!!! From: Chan-Wah Ng To: Muhammad Ali Malik Cc: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Organization: Panasonic Singapore Laboratories Message-Id: <1059619479.1437.24.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 31 Jul 2003 10:44:39 +0800 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Muhammad, Let me try to answer. I am sure others will fill in any gaps in my answer. (1) It is possible, but not necessary. As stated in your question 2, objective is to achieve mobility transparency for the mobile network nodes (MNNs). Since they do not know anything about mobility, there is no concept of CoA. (2) It means that the MNNs do not need to know that the MR has changed its point of attachment. They do not need to have special protocol other than those found in any normal IPv6 node. Specifically, they do not need to have MIPv6. They continue to use the address configured from the network prefix announced by MR, and continue to use MR as the default router. They will continue to be able to reach, and be reach by, the Internet. /rgds /cwng On Thu, 2003-07-31 at 10:19, Muhammad Ali Malik wrote: > Hi >=20 > =20 >=20 > I will be grateful if someone can answer these questions related to > NEMO basic protocol. >=20 > =20 >=20 > 1. Why it is not possible for mobile network node to obtains the > CoA in foreign location. As NEMO basic protocol states that > only MR obtains the care-of-address. > 2. What do the protocol means that mobility is transparent to > mobile network nodes =85.. how can we achieved transparency. >=20 >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Muhammad Ali Malik >=20 > =20 >=20 > =20 >=20 > =20 From nemo-admin@ietf.org Thu Jul 31 03:22:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14299 for ; Thu, 31 Jul 2003 03:22:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7lB-0001Cf-GH; Thu, 31 Jul 2003 03:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7kU-00018R-VH for nemo@optimus.ietf.org; Thu, 31 Jul 2003 03:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14264 for ; Thu, 31 Jul 2003 03:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7kS-0000It-00 for nemo@ietf.org; Thu, 31 Jul 2003 03:21:16 -0400 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 19i7kR-0000Ii-00 for nemo@ietf.org; Thu, 31 Jul 2003 03:21:16 -0400 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.9/8.12.9) with ESMTP id h6V7Koo1026219; Thu, 31 Jul 2003 00:20:52 -0700 (PDT) Message-ID: <3F28C352.20701@cs.ucdavis.edu> Date: Thu, 31 Jul 2003 00:20:50 -0700 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: kleung@cisco.com, nemo@ietf.org References: <3F25CEB7.60E355FD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Vijay, The paragraph you provide below looks great to me. Thanks. -Felix Vijay Devarapalli wrote: > hi Felix, > > I have added some text to make it clear that the Prefix Table > is used for verifying whether the mobile router owns the MNP > it claims only if the HA receives a Binding Update in explicit > mode. hope this addresses your concern (and also Kent's). > > In some deployment scenarios, it is necessary for Home Agent to > prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Vijay -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Thu Jul 31 03:22:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14314 for ; Thu, 31 Jul 2003 03:22:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7lU-0001Ew-AF for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 03:22:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7MKkM004765 for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 03:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7lU-0001El-2X for nemo-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 03:22:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14293 for ; Thu, 31 Jul 2003 03:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7lR-0000Jg-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 03:22:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i7lR-0000Jd-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 03:22:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7lB-0001Cf-GH; Thu, 31 Jul 2003 03:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7kU-00018R-VH for nemo@optimus.ietf.org; Thu, 31 Jul 2003 03:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14264 for ; Thu, 31 Jul 2003 03:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7kS-0000It-00 for nemo@ietf.org; Thu, 31 Jul 2003 03:21:16 -0400 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 19i7kR-0000Ii-00 for nemo@ietf.org; Thu, 31 Jul 2003 03:21:16 -0400 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.9/8.12.9) with ESMTP id h6V7Koo1026219; Thu, 31 Jul 2003 00:20:52 -0700 (PDT) Message-ID: <3F28C352.20701@cs.ucdavis.edu> Date: Thu, 31 Jul 2003 00:20:50 -0700 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: kleung@cisco.com, nemo@ietf.org References: <3F25CEB7.60E355FD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Issue 7 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Vijay, The paragraph you provide below looks great to me. Thanks. -Felix Vijay Devarapalli wrote: > hi Felix, > > I have added some text to make it clear that the Prefix Table > is used for verifying whether the mobile router owns the MNP > it claims only if the HA receives a Binding Update in explicit > mode. hope this addresses your concern (and also Kent's). > > In some deployment scenarios, it is necessary for Home Agent to > prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Vijay -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Thu Jul 31 04:02:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15504 for ; Thu, 31 Jul 2003 04:02:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Nu-0003rn-4b; Thu, 31 Jul 2003 04:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8ND-0003ou-Il for nemo@optimus.ietf.org; Thu, 31 Jul 2003 04:01:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15447 for ; Thu, 31 Jul 2003 04:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8NB-0000ZF-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:01:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19i8NA-0000Z4-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:01:16 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2003 10:00:30 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6V7wRHO021364; Thu, 31 Jul 2003 09:58:35 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 10:00:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Jul 2003 09:00:42 +0100 Message-ID: Thread-Topic: another attempt at Issue 6 Thread-Index: AcNWyFME1wPKitVXRU6KIF8wmyuw9AAcWTzg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Kent Leung (kleung)" Cc: "Jongkeun" , X-OriginalArrivalTime: 31 Jul 2003 08:00:42.0980 (UTC) FILETIME=[D715FA40:01C35739] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Fine with me :) > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 30 juillet 2003 20:27 > To: Pascal Thubert (pthubert); Kent Leung (kleung) > Cc: Jongkeun; nemo@ietf.org > Subject: another attempt at Issue 6 >=20 > Pascal, Kent >=20 > here is another attempt to close Issue 6. >=20 > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router should be > careful in including the same mobile network prefixes in the > Binding Update to the HA and in the routing protocol updates. > The HA depending on its configuration might not add routes > based on the prefix information in the Binding Updates at all, > and might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. >=20 > this text does not prohibit the MR from running an IGP and > Binding Updates in explicit mode at the same time. but it does > give a warning on what might go wrong. >=20 > let me know what you think about this text. >=20 > Vijay From exim@www1.ietf.org Thu Jul 31 04:02:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15519 for ; Thu, 31 Jul 2003 04:02:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8O7-0003yW-LD for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 04:02:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V82Fkf015280 for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 04:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8O7-0003yK-8M for nemo-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 04:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15493 for ; Thu, 31 Jul 2003 04:02:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8O4-0000aW-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 04:02:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i8O4-0000aT-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 04:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Nu-0003rn-4b; Thu, 31 Jul 2003 04:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8ND-0003ou-Il for nemo@optimus.ietf.org; Thu, 31 Jul 2003 04:01:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15447 for ; Thu, 31 Jul 2003 04:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8NB-0000ZF-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:01:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19i8NA-0000Z4-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:01:16 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2003 10:00:30 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6V7wRHO021364; Thu, 31 Jul 2003 09:58:35 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 10:00:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Jul 2003 09:00:42 +0100 Message-ID: Thread-Topic: another attempt at Issue 6 Thread-Index: AcNWyFME1wPKitVXRU6KIF8wmyuw9AAcWTzg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Kent Leung (kleung)" Cc: "Jongkeun" , X-OriginalArrivalTime: 31 Jul 2003 08:00:42.0980 (UTC) FILETIME=[D715FA40:01C35739] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fine with me :) > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 30 juillet 2003 20:27 > To: Pascal Thubert (pthubert); Kent Leung (kleung) > Cc: Jongkeun; nemo@ietf.org > Subject: another attempt at Issue 6 >=20 > Pascal, Kent >=20 > here is another attempt to close Issue 6. >=20 > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router should be > careful in including the same mobile network prefixes in the > Binding Update to the HA and in the routing protocol updates. > The HA depending on its configuration might not add routes > based on the prefix information in the Binding Updates at all, > and might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. >=20 > this text does not prohibit the MR from running an IGP and > Binding Updates in explicit mode at the same time. but it does > give a warning on what might go wrong. >=20 > let me know what you think about this text. >=20 > Vijay From nemo-admin@ietf.org Thu Jul 31 04:57:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16781 for ; Thu, 31 Jul 2003 04:57:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9F7-0005ym-4s; Thu, 31 Jul 2003 04:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9F2-0005ya-NV for nemo@optimus.ietf.org; Thu, 31 Jul 2003 04:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16757 for ; Thu, 31 Jul 2003 04:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i9Ez-0000vq-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:56:53 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19i9Ey-0000vm-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:56:52 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h6V8ujG7003785; Thu, 31 Jul 2003 01:56:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6V8uSKl016731; Thu, 31 Jul 2003 03:56:29 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CB1BB2EC86; Thu, 31 Jul 2003 10:56:39 +0200 (CEST) Message-ID: <3F28D9C7.6050805@motorola.com> Date: Thu, 31 Jul 2003 10:56:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] NEMO basic protocol question !!!! References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate6.mot.com id h6V8ujG7003785 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Muhammad Ali Malik wrote: > 2. What do the protocol means that mobility is transparent to mobile=20 > network nodes =85.. how can we achieved transparency. Abuses of language. I believe "transparency" was initially proposed to express that, in a mobile host, layers above IP will communicate with the unchanged endpoint names of its peer even if some intermediary addresses will change: those latter changes are transparent, app data beams hardly bounce on them, mobility is invisible, or transparent, to applications. In the context of mobile network nodes, the use of word "transparency" is somehow pushed to its limits and "invisible" would be better. LFN's do not see nor process any message exchanges related to mobility. RA's don'get through MR, LFN's don't send BU's, don't maintain caches and so on. With MN's that visit the mobile network, the first use of transparency applies. "Transparency" is a nice word with plenty of positive interpretations from physics, politics and corporate speak; so having it as a requirement can only be good. Is this for a homework? Alex GBU From exim@www1.ietf.org Thu Jul 31 04:57:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16800 for ; Thu, 31 Jul 2003 04:57:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9FP-00063A-UW for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 04:57:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V8vJWs023124 for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 04:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9FP-00060t-6p for nemo-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 04:57:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16777 for ; Thu, 31 Jul 2003 04:57:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i9FM-0000wI-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 04:57:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i9FL-0000wF-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 04:57:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9F7-0005ym-4s; Thu, 31 Jul 2003 04:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i9F2-0005ya-NV for nemo@optimus.ietf.org; Thu, 31 Jul 2003 04:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16757 for ; Thu, 31 Jul 2003 04:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i9Ez-0000vq-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:56:53 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19i9Ey-0000vm-00 for nemo@ietf.org; Thu, 31 Jul 2003 04:56:52 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h6V8ujG7003785; Thu, 31 Jul 2003 01:56:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h6V8uSKl016731; Thu, 31 Jul 2003 03:56:29 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CB1BB2EC86; Thu, 31 Jul 2003 10:56:39 +0200 (CEST) Message-ID: <3F28D9C7.6050805@motorola.com> Date: Thu, 31 Jul 2003 10:56:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] NEMO basic protocol question !!!! References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate6.mot.com id h6V8ujG7003785 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Muhammad Ali Malik wrote: > 2. What do the protocol means that mobility is transparent to mobile=20 > network nodes =85.. how can we achieved transparency. Abuses of language. I believe "transparency" was initially proposed to express that, in a mobile host, layers above IP will communicate with the unchanged endpoint names of its peer even if some intermediary addresses will change: those latter changes are transparent, app data beams hardly bounce on them, mobility is invisible, or transparent, to applications. In the context of mobile network nodes, the use of word "transparency" is somehow pushed to its limits and "invisible" would be better. LFN's do not see nor process any message exchanges related to mobility. RA's don'get through MR, LFN's don't send BU's, don't maintain caches and so on. With MN's that visit the mobile network, the first use of transparency applies. "Transparency" is a nice word with plenty of positive interpretations from physics, politics and corporate speak; so having it as a requirement can only be good. Is this for a homework? Alex GBU From nemo-admin@ietf.org Thu Jul 31 12:53:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04018 for ; Thu, 31 Jul 2003 12:53:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGen-0002Le-0T; Thu, 31 Jul 2003 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGeg-0002LO-3N for nemo@optimus.ietf.org; Thu, 31 Jul 2003 12:51:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03955 for ; Thu, 31 Jul 2003 12:51:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGee-0005er-00 for nemo@ietf.org; Thu, 31 Jul 2003 12:51:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGed-0005eg-00 for nemo@ietf.org; Thu, 31 Jul 2003 12:51:51 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 09:54:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGpJLH023626; Thu, 31 Jul 2003 09:51:19 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV41590; Thu, 31 Jul 2003 09:46:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20030731095029.02d7ee10@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jul 2003 09:51:17 -0700 To: Vijay Devarapalli From: Kent Leung Cc: pthubert@cisco.com, Jongkeun , nemo@ietf.org In-Reply-To: <3F280DDE.7090201@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Looks good. Thanks. Kent At 11:26 AM 7/30/2003 -0700, Vijay Devarapalli wrote: >Pascal, Kent > >here is another attempt to close Issue 6. > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router should be > careful in including the same mobile network prefixes in the > Binding Update to the HA and in the routing protocol updates. > The HA depending on its configuration might not add routes > based on the prefix information in the Binding Updates at all, > and might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > >this text does not prohibit the MR from running an IGP and >Binding Updates in explicit mode at the same time. but it does >give a warning on what might go wrong. > >let me know what you think about this text. > >Vijay From exim@www1.ietf.org Thu Jul 31 12:53:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04033 for ; Thu, 31 Jul 2003 12:53:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGfU-0002Th-7U for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 12:52:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGqiaT009519 for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 12:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGfU-0002TS-2e for nemo-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 12:52:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03975 for ; Thu, 31 Jul 2003 12:52:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGfS-0005fB-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 12:52:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iGfR-0005f7-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 12:52:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGen-0002Le-0T; Thu, 31 Jul 2003 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGeg-0002LO-3N for nemo@optimus.ietf.org; Thu, 31 Jul 2003 12:51:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03955 for ; Thu, 31 Jul 2003 12:51:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGee-0005er-00 for nemo@ietf.org; Thu, 31 Jul 2003 12:51:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGed-0005eg-00 for nemo@ietf.org; Thu, 31 Jul 2003 12:51:51 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 09:54:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGpJLH023626; Thu, 31 Jul 2003 09:51:19 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV41590; Thu, 31 Jul 2003 09:46:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20030731095029.02d7ee10@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jul 2003 09:51:17 -0700 To: Vijay Devarapalli From: Kent Leung Cc: pthubert@cisco.com, Jongkeun , nemo@ietf.org In-Reply-To: <3F280DDE.7090201@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: another attempt at Issue 6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Looks good. Thanks. Kent At 11:26 AM 7/30/2003 -0700, Vijay Devarapalli wrote: >Pascal, Kent > >here is another attempt to close Issue 6. > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router should be > careful in including the same mobile network prefixes in the > Binding Update to the HA and in the routing protocol updates. > The HA depending on its configuration might not add routes > based on the prefix information in the Binding Updates at all, > and might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > >this text does not prohibit the MR from running an IGP and >Binding Updates in explicit mode at the same time. but it does >give a warning on what might go wrong. > >let me know what you think about this text. > >Vijay From exim@www1.ietf.org Thu Jul 31 14:52:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08130 for ; Thu, 31 Jul 2003 14:52:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIWb-0008Lj-Af for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 14:51:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIpff4032091 for nemo-archive@odin.ietf.org; Thu, 31 Jul 2003 14:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIWb-0008LW-7N for nemo-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 14:51:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08112 for ; Thu, 31 Jul 2003 14:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIWY-0006ZD-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 14:51:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iIWX-0006ZA-00 for nemo-web-archive@ietf.org; Thu, 31 Jul 2003 14:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIVx-0008HE-E2; Thu, 31 Jul 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIVr-0008Gy-Bi for nemo@optimus.ietf.org; Thu, 31 Jul 2003 14:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08074 for ; Thu, 31 Jul 2003 14:50:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIVo-0006Yl-00 for nemo@ietf.org; Thu, 31 Jul 2003 14:50:52 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19iIVn-0006Y5-00 for nemo@ietf.org; Thu, 31 Jul 2003 14:50:51 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA25297; Thu, 31 Jul 2003 11:50:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6VIoJH11014; Thu, 31 Jul 2003 11:50:19 -0700 X-mProtect: <200307311850> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXOo0P1; Thu, 31 Jul 2003 11:50:17 PDT Message-ID: <3F2964EA.D01F466E@iprg.nokia.com> Date: Thu, 31 Jul 2003 11:50:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Pascal and all, I want to see if we can close issue 10. Binding Ack status 143 is supposed to be used when the HA cant figure out which MNP belongs to the MR in the implicit mode. it is every essential to have this error status because we dont want the MR assuming that the HA has set up forwarding for the MNP when it actually didnt. it doesnt matter which mechanism (Prefix Table being one) is used by the HA in the implicit mode. status code 143 is not supposed to be used when an IGP is being run over the MR-HA tunnel. when an IGP is being used, the HA just waits for the routing protocol updates from the MR and does not attempt to create any routes if the BU did not contain any prefix information. there are basically three different mechanisms by which the MR propagates routes to the HA. 1. explicit mode. the Binding Update contains the prefix information in the mobility options (Mobile Network Prefix option or Mobile Network Prefix Length option) 2. implicit mode. the HA figures out the MNP through mechanisms not defined in the draft. a pre-configured Prefix Table is one such mechanism that you can use. a static route configuration (manually added) is another one. 3. IGP over the MR-HA tunnel. I dont want to mix up (3) with (2). I would like to keep the IGP part separate from the rest of the specification. I am not too sure we have taken care of all the issues related to running an IGP over the tunnel. does this make sense? Vijay From nemo-admin@ietf.org Thu Jul 31 14:52:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08128 for ; Thu, 31 Jul 2003 14:52:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIVx-0008HE-E2; Thu, 31 Jul 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIVr-0008Gy-Bi for nemo@optimus.ietf.org; Thu, 31 Jul 2003 14:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08074 for ; Thu, 31 Jul 2003 14:50:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIVo-0006Yl-00 for nemo@ietf.org; Thu, 31 Jul 2003 14:50:52 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19iIVn-0006Y5-00 for nemo@ietf.org; Thu, 31 Jul 2003 14:50:51 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA25297; Thu, 31 Jul 2003 11:50:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6VIoJH11014; Thu, 31 Jul 2003 11:50:19 -0700 X-mProtect: <200307311850> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXOo0P1; Thu, 31 Jul 2003 11:50:17 PDT Message-ID: <3F2964EA.D01F466E@iprg.nokia.com> Date: Thu, 31 Jul 2003 11:50:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: pthubert@cisco.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Pascal and all, I want to see if we can close issue 10. Binding Ack status 143 is supposed to be used when the HA cant figure out which MNP belongs to the MR in the implicit mode. it is every essential to have this error status because we dont want the MR assuming that the HA has set up forwarding for the MNP when it actually didnt. it doesnt matter which mechanism (Prefix Table being one) is used by the HA in the implicit mode. status code 143 is not supposed to be used when an IGP is being run over the MR-HA tunnel. when an IGP is being used, the HA just waits for the routing protocol updates from the MR and does not attempt to create any routes if the BU did not contain any prefix information. there are basically three different mechanisms by which the MR propagates routes to the HA. 1. explicit mode. the Binding Update contains the prefix information in the mobility options (Mobile Network Prefix option or Mobile Network Prefix Length option) 2. implicit mode. the HA figures out the MNP through mechanisms not defined in the draft. a pre-configured Prefix Table is one such mechanism that you can use. a static route configuration (manually added) is another one. 3. IGP over the MR-HA tunnel. I dont want to mix up (3) with (2). I would like to keep the IGP part separate from the rest of the specification. I am not too sure we have taken care of all the issues related to running an IGP over the tunnel. does this make sense? Vijay