From nemo-bounces@ietf.org Sun Oct 02 21:04:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMEkM-0008BP-GK; Sun, 02 Oct 2005 21:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMEkK-0008BG-9T for nemo@megatron.ietf.org; Sun, 02 Oct 2005 21:04:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12006 for ; Sun, 2 Oct 2005 21:03:58 -0400 (EDT) Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMEse-00077H-Sf for nemo@ietf.org; Sun, 02 Oct 2005 21:12:40 -0400 Received: from ryuji-no-powerbook-g4-15.local.sfc.wide.ad.jp (n128-61.sfc.wide.ad.jp [203.178.128.61]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id j9313P64019264; Mon, 3 Oct 2005 10:03:25 +0900 Date: Mon, 03 Oct 2005 10:03:25 +0900 Message-ID: From: Ryuji Wakikawa To: Ralph Droms Subject: Re: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt In-Reply-To: <1127911736.16351.108.camel@localhost.localdomain> References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> <4314A955.5050906@iprg.nokia.com> <77B28091-FE92-4D33-964C-3D0D6D57F6C7@sfc.wide.ad.jp> <1127911736.16351.108.camel@localhost.localdomain> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, Vijay Devarapalli , "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi At Wed, 28 Sep 2005 08:48:55 -0400, Ralph Droms wrote: > > (picking up an old thread; I'm revising draft-ietf-nemo-dhcpv6-pd-00.txt > based on these comments) > > On Tue, 2005-09-06 at 01:56 +0900, Ryuji Wakikawa wrote: > > Hello Pascal and Vijay > > > > I read the draft and feel the same impression with Vijay. I agree > > with Vijay. > > The section 3.2 is not directly related to the NEMO PD. > > We had the consensus not to include local mobility management in > > DHCPv6PD > > at the Minneapolis meeting (forget maybe somewhere else). > > > > Here are more comments. > > > > Can MR can skip DHCP server discovery sending message to FF02::1:2 ? > > If MR knows the HA, MR can send request message to the HA without DR > > discovery. > > I'm leery of making this fundamental change to the specification in RFC > 3315 without dhc WG review. I did not propose to make some changes to 3315. I would suggest to make the NEMO PD specification clearer. At least, it is better to state what are the required operations and the omissible operations for the NEMO PD. > Uf the goal is to reduce the number of messages exchanged, the Rapid > Commit option allows a 2 message exchange for PD. I am fine with this, too regards, ryuji From nemo-bounces@ietf.org Mon Oct 03 11:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRu6-0001TO-MB; Mon, 03 Oct 2005 11:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRu5-0001TD-2q for nemo@megatron.ietf.org; Mon, 03 Oct 2005 11:06:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10787 for ; Mon, 3 Oct 2005 11:06:55 -0400 (EDT) Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMS2Z-0002Ba-QD for nemo@ietf.org; Mon, 03 Oct 2005 11:15:44 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 7FABB38014; Mon, 3 Oct 2005 17:06:47 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6AC7237F00; Mon, 3 Oct 2005 17:06:47 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 5768237E45; Mon, 3 Oct 2005 17:06:47 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EMRtv-0002Tt-6q; Mon, 03 Oct 2005 17:06:47 +0200 Message-ID: <43414906.5050503@levkowetz.com> Date: Mon, 03 Oct 2005 17:06:46 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC0151AE71@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0151AE71@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, on 2005-09-30 11:06 Pascal Thubert (pthubert) said the following: >>>>>>Section 1., para. 2: [...] >>>>Slightly, but not enough, I think. After trying out various formulations, >>>>I actually think it would be better to reduce the paragraph to this: >>>> >>>> In order to read this document properly, it is important to realise >>>> there is a distinction between the concepts of Home Link and Home >>>> Network, and in a NEMO context these may not at all be equivalent. >>>> How the two concepts relate in a given deployment depend on the >>>> organization of the Home Network, as described below. >>>> >>> >>> [] What about: >>> >>> In order to read this document properly, it is important to realize >>> that in a NEMO context, the Home Network is not bounded by the Home Link. >>> How the two concepts relate in a given deployment depends on the >>> organization of the Home Network, as described below. >> >>No - remember, this is at the very beginning of the document. Reading this >>would still leave me wondering - what is meant here - bounded? Physically? >>logically? prefix-wise? what?? >> >>My earlier suggestion still seems to me like a good one - would you consider >>it again? > > [] The problem that I tried to change was in the comparison of a > Link (usually a L2 term) and a Network (usually a L3 term). I wanted to > say that in MIP, the Network overlaps with - is congruent to, whatever - > the Link. But in NEMO, the network is much wider as it spans the Home > Link and all the Links that the MRs carry with them. > > Could you then reword a bit? Hmm. A first try - I'm not sure if this is good language, but at least I would be able to understand it...: In order to read this document properly, it is important to realise there is a distinction between the concepts of Home Link and Home Network. In a NEMO context these may not at all be equivalent - quite to the contrary: in NEMO, the Home Network can encompass much more than the Home Link, as it spans the Home Link and all the Links that the Mobile Routers carry with them. Exactly how the two concepts relate in a given deployment depend on the organization of the Home Network, as described below. [...] > [] Or we can change the figures to reflect the fact that one is > config and the other arrangement? > [] I guess that would be ok. Although for now I think the simplest would be to just refer back to Fig. 2... >>> Note that this is a hierarchy in terms of configuration, which may not >>> be reflected in the actual arrangement of nodes at a given point of time. >>> For instance in the Cab Co case, some Cabs might roam to a different city, >>> or even attach to the Headquarters. >>> " >> >>Ahh! *That* I can understand. >> >>Of course, I then wonder if that will actually work - what happens if a Cab >>attaches to a HA in a different city which doesn't have a matching prefix? > > [] Attaching is building a CoA, not binding. The CoA is formed from > a prefix that is exposed by another city, and globally reachable, so it > works. In terms of tunnels, it is an interesting story :) > I have deployed the whole thing using my implementation to check the > configuration. It works, cabs can be attached to other cabs, etc... When > you add RRH to the picture, you can even have SFO attach to one of its > cabs :) Hmm ,,,;-) Maybe some more words are needed to make this clear - could you have a look at adding some? Henrik From nemo-bounces@ietf.org Mon Oct 03 11:57:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMShE-0004fj-Kr; Mon, 03 Oct 2005 11:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMShD-0004fF-9P for nemo@megatron.ietf.org; Mon, 03 Oct 2005 11:57:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14588 for ; Mon, 3 Oct 2005 11:57:41 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMSpg-00040w-DO for nemo@ietf.org; Mon, 03 Oct 2005 12:06:30 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2005 17:57:33 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93FvRVP005069; Mon, 3 Oct 2005 17:57:29 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 17:57:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Mon, 3 Oct 2005 17:57:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01568383@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXILCGjbuvVJQDFSbeOEie7bE5f7AAAcM8A From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" , "Ryuji Wakikawa" , "Vijay Devarapalli" X-OriginalArrivalTime: 03 Oct 2005 15:57:27.0380 (UTC) FILETIME=[270A4940:01C5C833] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >Sent: Monday, October 03, 2005 5:07 PM >To: Pascal Thubert (pthubert) >Cc: nemo@ietf.org >Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt > >Hi Pascal, > >on 2005-09-30 11:06 Pascal Thubert (pthubert) said the following: >>>>>>>Section 1., para. 2: >[...] >>>>>Slightly, but not enough, I think. After trying out various formulations, >>>>>I actually think it would be better to reduce the paragraph to this: >>>>> >>>>> In order to read this document properly, it is important to realise >>>>> there is a distinction between the concepts of Home Link and Home >>>>> Network, and in a NEMO context these may not at all be equivalent. >>>>> How the two concepts relate in a given deployment depend on the >>>>> organization of the Home Network, as described below. >>>>> >>>> >>>> [] What about: >>>> >>>> In order to read this document properly, it is important to realize >>>> that in a NEMO context, the Home Network is not bounded by the Home Link. >>>> How the two concepts relate in a given deployment depends on the >>>> organization of the Home Network, as described below. >>> >>>No - remember, this is at the very beginning of the document. Reading this >>>would still leave me wondering - what is meant here - bounded? Physically? >>>logically? prefix-wise? what?? >>> >>>My earlier suggestion still seems to me like a good one - would you consider >>>it again? >> >> [] The problem that I tried to change was in the comparison of a >> Link (usually a L2 term) and a Network (usually a L3 term). I wanted to >> say that in MIP, the Network overlaps with - is congruent to, whatever - >> the Link. But in NEMO, the network is much wider as it spans the Home >> Link and all the Links that the MRs carry with them. >> >> Could you then reword a bit? > >Hmm. A first try - I'm not sure if this is good language, but at least >I would be able to understand it...: > > In order to read this document properly, it is important to realise > there is a distinction between the concepts of Home Link and Home > Network. In a NEMO context these may not at all be equivalent - > quite to the contrary: in NEMO, the Home Network can encompass much > more than the Home Link, as it spans the Home Link and all the Links > that the Mobile Routers carry with them. Exactly how the two concepts > relate in a given deployment depend on the organization of the Home > Network, as described below. > > []=20 What about: In order to read this document properly, it is important to realize That the Home Link and Home Network are not necessarily congruent - quite to the contrary: in NEMO, the Home Network can encompass much more than the Home Link, as it spans the Home Link and all the Links that the Mobile Routers carry with them. Exactly how the two concepts relate in a given deployment depend on the organization of the Home Network, as described below. >[...] > >> [] Or we can change the figures to reflect the fact that one is >> config and the other arrangement? >> [] > >I guess that would be ok. Although for now I think the simplest would >be to just refer back to Fig. 2... > [] I do not have strong feelings on this. If anyone is still listening, can you please provide advice here? Copying Vijay and Ryuji... >>>> Note that this is a hierarchy in terms of configuration, which may not >>>> be reflected in the actual arrangement of nodes at a given point of time. >>>> For instance in the Cab Co case, some Cabs might roam to a different city, >>>> or even attach to the Headquarters. >>>> " >>> >>>Ahh! *That* I can understand. >>> >>>Of course, I then wonder if that will actually work - what happens if a Cab >>>attaches to a HA in a different city which doesn't have a matching prefix? >> >> [] Attaching is building a CoA, not binding. The CoA is formed from >> a prefix that is exposed by another city, and globally reachable, so it >> works. In terms of tunnels, it is an interesting story :) >> I have deployed the whole thing using my implementation to check the >> configuration. It works, cabs can be attached to other cabs, etc... When >> you add RRH to the picture, you can even have SFO attach to one of its >> cabs :) > >Hmm ,,,;-) > >Maybe some more words are needed to make this clear - could you have a look >at adding some? []=20 [] What about: Note that this is a hierarchy in terms of MR-HA relationship, which may not be reflected in the physical arrangement of nodes at a given point of time. For instance, in the Cab Co case, some SFO Cabs might attach to any hot spot or Cab Co office in a different city, and the SFO office might be at Home if it is collocated with the Headquarters. But note that SFO might never attach to one of its own Cabs. This would create a deadlock issue, as documented in the NEMO RO problem statement. []=20 What do you think? Pascal From nemo-bounces@ietf.org Mon Oct 03 12:14:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSxk-00006P-IO; Mon, 03 Oct 2005 12:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSxj-00005E-0A for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:14:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15494 for ; Mon, 3 Oct 2005 12:14:44 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMT6D-0004V0-UP for nemo@ietf.org; Mon, 03 Oct 2005 12:23:34 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2005 18:14:37 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93GEWVR010321; Mon, 3 Oct 2005 18:14:35 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 18:14:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C835.8B3E4A0F" Subject: RE: [nemo] solving Home Network models issue 8 Date: Mon, 3 Oct 2005 18:14:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] solving Home Network models issue 8 Thread-Index: AcXFGNxE0kj++Qx6Ts6trJ3wjS2TJwDHHcIA From: "Pascal Thubert \(pthubert\)" To: "Jari Arkko" X-OriginalArrivalTime: 03 Oct 2005 16:14:34.0829 (UTC) FILETIME=[8B728FD0:01C5C835] X-Spam-Score: 0.2 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C835.8B3E4A0F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jari: =20 Here is a proposed change to fix issue 8: =20 5.5 Applicability =20 The Extended Home Network keeps the MIP6 concept of a Home Network for both Mobile Nodes and Mobile Routers to take their Home Address from. Since there is no overlap between the prefixes that are assigned to MNPs and prefix(es) that are dedicated to the Home Link, it is possible for MNs and Mobile Routers to coexist with that model. =20 Also, when the Home Address is derived from the prefix on the Home Link, the Home Agent behavior on the link trivially extends that of MIP and the support for that configuration should be available with all implementations. =20 On the other hand, there are a number of issues with the support of a Home Address that is derived from the MNP, as detailed in Section 5.3. Though it is feasible, this configuration is not recommended for deployment. =20 =20 =20 What do you think? =20 Pascal ________________________________ From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Thursday, September 29, 2005 7:12 PM To: nemo@ietf.org Subject: [nemo] solving Home Network models issue 8 =20 Hi: =20 I'm trying to get a consensus to solve issue 8: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mode= ls-issue8.txt=20 =20 The idea is to add some text to say that we do not recommend forming a = home address from MNP in extended Home Network case. Thoughts anyone? =20 =20 =20 =20 =20 Pascal Thubert software engineer=20 Cisco Systems Village d'Entreprises GREEN SIDE 400, Avenue Roumanille B=E2timent T3 06410 BIOT - Sophia-Antipolis=20 pthubert@cisco.com =20 tel:=20 mobile:=20 +33 4 97 23 26 34 +33 6 19 98 29 85=20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5C835.8B3E4A0F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Jari:

 

Here is a proposed change to fix = issue 8:

 

5.5=A0 = Applicability

 

=A0=A0 The Extended Home Network = keeps the MIP6 concept of a Home Network

=A0=A0 for both Mobile Nodes and = Mobile Routers to take their Home Address

=A0=A0 from.=A0 Since there is no = overlap between the prefixes that are

=A0=A0 assigned to MNPs and = prefix(es) that are dedicated to the Home Link,

=A0=A0 it is possible for MNs and = Mobile Routers to coexist with that model.

 

=A0=A0 Also, when the Home Address = is derived from the prefix on the Home

=A0=A0 Link, the Home Agent = behavior on the link trivially extends that of

=A0=A0 MIP and the support for that configuration should be available with

=A0=A0 all = implementations.

 

=A0=A0 On the other hand, there are = a number of issues with the support of a

=A0=A0 Home Address that is derived = from the MNP, as detailed in

=A0=A0 Section 5.3.=A0 Though it is = feasible, this configuration is not

=A0=A0 recommended for = deployment.

 

 

 

What do you = think?

 

Pascal

From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, September = 29, 2005 7:12 PM
To: nemo@ietf.org
Subject: [nemo] solving = Home Network models issue 8

 

Hi:

 

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

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

 

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

 

 

 

 

 

Pascal Thubert
software = engineer

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

pthubert@cisco.com

tel:
mobile:

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

 

 

 

 

 

------_=_NextPart_001_01C5C835.8B3E4A0F-- From nemo-bounces@ietf.org Mon Oct 03 12:26:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMT96-00027i-7D; Mon, 03 Oct 2005 12:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMT93-00027b-Lq for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:26:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16030 for ; Mon, 3 Oct 2005 12:26:27 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTHW-0004oC-Pc for nemo@ietf.org; Mon, 03 Oct 2005 12:35:17 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2005 18:26:18 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93GPkVp013836; Mon, 3 Oct 2005 18:26:15 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 18:26:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C837.2AB39566" Subject: RE: [nemo] solving Home Network models issue 7 Date: Mon, 3 Oct 2005 18:26:05 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] solving Home Network models issue 7 Thread-Index: AcXFGHq4QRiZsohjT5qi0UyQ1S/SDQDHnWvA From: "Pascal Thubert \(pthubert\)" To: "Jari Arkko" X-OriginalArrivalTime: 03 Oct 2005 16:26:11.0908 (UTC) FILETIME=[2AF06040:01C5C837] X-Spam-Score: 0.2 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C837.2AB39566 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jari: =20 Proposed fix issue 7: remove the appendix and replace the text as = discussed: =20 There are also some drawbacks to the Virtual Home Link approach: =20 RFC 3775 [7] and RFC 3963 [8] do not provide the specific support for a Mobile Node to emulate returning Home on a Virtual Home Network. In particular, in the case of NEMO, the routing information from the Mobile Router being injected on the IGP might adversely affect IPv6 route aggregation on the Home Network. =20 =20 Is that text OK with you? =20 Pascal ________________________________ From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Thursday, September 29, 2005 7:09 PM To: nemo@ietf.org Subject: [nemo] solving Home Network models issue 7 =20 Hi: =20 I'm trying to get a consensus to solve issue 7: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mode= ls-issue7.txt=20 =20 The idea is to remove the text around going home in a virtual Home = network. This includes some text in the main document and the related = appendix. Thoughts anyone? =20 =20 =20 =20 Pascal Thubert software engineer=20 Cisco Systems Village d'Entreprises GREEN SIDE 400, Avenue Roumanille B=E2timent T3 06410 BIOT - Sophia-Antipolis=20 pthubert@cisco.com =20 tel:=20 mobile:=20 +33 4 97 23 26 34 +33 6 19 98 29 85=20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5C837.2AB39566 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Jari:

 

Proposed fix issue 7: remove the = appendix and replace the text as discussed:

 

There are also some drawbacks to = the Virtual Home Link approach:

 

=A0=A0=A0=A0=A0 RFC 3775 [7] and = RFC 3963 [8] do not provide the specific support

=A0=A0=A0=A0=A0 for a Mobile Node = to emulate returning Home on a Virtual Home

=A0=A0=A0=A0=A0 Network.=A0 In = particular, in the case of NEMO, the routing

=A0=A0=A0=A0=A0 information from = the Mobile Router being injected on the IGP might

=A0=A0=A0=A0=A0 adversely affect = IPv6 route aggregation on the Home Network.

 

 

Is that text OK with = you?

 

Pascal

From: = nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On = Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, September = 29, 2005 7:09 PM
To: nemo@ietf.org
Subject: [nemo] solving = Home Network models issue 7

 

Hi:

 

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

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

 

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

 

 

 

 

Pascal Thubert
software = engineer

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

pthubert@cisco.com

tel:
mobile:

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

 

 

 

 

 

------_=_NextPart_001_01C5C837.2AB39566-- From nemo-bounces@ietf.org Mon Oct 03 12:29:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTCJ-0002SV-P2; Mon, 03 Oct 2005 12:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTCJ-0002SQ-0g for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:29:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16151 for ; Mon, 3 Oct 2005 12:29:48 -0400 (EDT) Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTKn-0004tb-GA for nemo@ietf.org; Mon, 03 Oct 2005 12:38:38 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 0B9D7380E3; Mon, 3 Oct 2005 18:23:43 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D4B5737E4F; Mon, 3 Oct 2005 18:23:42 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2D40737E46; Mon, 3 Oct 2005 18:29:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EMTC4-0008C9-Eq; Mon, 03 Oct 2005 18:29:36 +0200 Message-ID: <43415C70.2040402@levkowetz.com> Date: Mon, 03 Oct 2005 18:29:36 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC01568383@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01568383@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org on 2005-10-03 17:57 Pascal Thubert (pthubert) said the following: >>> [] The problem that I tried to change was in the comparison of a >>> Link (usually a L2 term) and a Network (usually a L3 term). I wanted to >>> say that in MIP, the Network overlaps with - is congruent to, whatever - >>> the Link. But in NEMO, the network is much wider as it spans the Home >>> Link and all the Links that the MRs carry with them. >>> >>> Could you then reword a bit? >> >>Hmm. A first try - I'm not sure if this is good language, but at least >>I would be able to understand it...: >> >> In order to read this document properly, it is important to realise >> there is a distinction between the concepts of Home Link and Home >> Network. In a NEMO context these may not at all be equivalent - >> quite to the contrary: in NEMO, the Home Network can encompass much >> more than the Home Link, as it spans the Home Link and all the Links >> that the Mobile Routers carry with them. Exactly how the two concepts >> relate in a given deployment depend on the organization of the Home >> Network, as described below. >> >> > [] > What about: > > In order to read this document properly, it is important to realize > That the Home Link and Home Network are not necessarily congruent - > quite to the contrary: in NEMO, the Home Network can encompass much > more than the Home Link, as it spans the Home Link and all the Links > that the Mobile Routers carry with them. Exactly how the two concepts > relate in a given deployment depend on the organization of the Home > Network, as described below. Congruence is clear to me for triangles, but not for networks. I'd rather not inflict that upon a reader this early in the text ... >>[...] >> >>> [] Or we can change the figures to reflect the fact that one is >>> config and the other arrangement? >>> [] >> >>I guess that would be ok. Although for now I think the simplest would >>be to just refer back to Fig. 2... >> > [] I do not have strong feelings on this. If anyone is still > listening, can you please provide advice here? Copying Vijay and > Ryuji... > [...] >> >>Maybe some more words are needed to make this clear - could you have a > look >>at adding some? > [] > [] What about: > > Note that this is a hierarchy in terms of MR-HA relationship, which may > not > be reflected in the physical arrangement of nodes at a given point of > time. > For instance, in the Cab Co case, some SFO Cabs might attach to any hot > spot or > Cab Co office in a different city, and the SFO office might be at Home > if it is collocated with the Headquarters. But note that SFO might never > attach to > one of its own Cabs. This would create a deadlock issue, as documented > in > the NEMO RO problem statement. > [] > > What do you think? That is basically in the text already - but pointing out the difference between attaching with a new CoA and binding, and possibly how this would work might be helpful. The suggested text above didn't give me any additional clarity... Henrik From nemo-bounces@ietf.org Mon Oct 03 12:40:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTMU-0004m7-VS; Mon, 03 Oct 2005 12:40:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTMU-0004ld-38 for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:40:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16795 for ; Mon, 3 Oct 2005 12:40:19 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTUz-0005F6-OC for nemo@ietf.org; Mon, 03 Oct 2005 12:49:10 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2005 18:40:13 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93GdqVf018009; Mon, 3 Oct 2005 18:40:10 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 18:40:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Mon, 3 Oct 2005 18:39:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXIN7Fx2Q5aErdFSnuB7PN7cVeZowAAD+4Q From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 03 Oct 2005 16:40:05.0487 (UTC) FILETIME=[1BCA6FF0:01C5C839] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >Sent: Monday, October 03, 2005 6:30 PM >To: Pascal Thubert (pthubert) >Cc: Ryuji Wakikawa; Vijay Devarapalli; nemo@ietf.org >Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt > > > >on 2005-10-03 17:57 Pascal Thubert (pthubert) said the following: >>>> [] The problem that I tried to change was in the comparison of a >>>> Link (usually a L2 term) and a Network (usually a L3 term). I wanted to >>>> say that in MIP, the Network overlaps with - is congruent to, whatever - >>>> the Link. But in NEMO, the network is much wider as it spans the Home >>>> Link and all the Links that the MRs carry with them. >>>> >>>> Could you then reword a bit? >>> >>>Hmm. A first try - I'm not sure if this is good language, but at least >>>I would be able to understand it...: >>> >>> In order to read this document properly, it is important to realise >>> there is a distinction between the concepts of Home Link and Home >>> Network. In a NEMO context these may not at all be equivalent - >>> quite to the contrary: in NEMO, the Home Network can encompass much >>> more than the Home Link, as it spans the Home Link and all the Links >>> that the Mobile Routers carry with them. Exactly how the two concepts >>> relate in a given deployment depend on the organization of the Home >>> Network, as described below. >>> >>> >> [] >> What about: >> >> In order to read this document properly, it is important to realize >> That the Home Link and Home Network are not necessarily congruent - >> quite to the contrary: in NEMO, the Home Network can encompass much >> more than the Home Link, as it spans the Home Link and all the Links >> that the Mobile Routers carry with them. Exactly how the two concepts >> relate in a given deployment depend on the organization of the Home >> Network, as described below. > >Congruence is clear to me for triangles, but not for networks. I'd >rather not inflict that upon a reader this early in the text ... [] We use it in networks, usually when Ipv4 and IPv6 topologies are exactly overlapping.=20 I'm surprised you did not see it already. Any alternate suggestion? > >>>[...] >>> >>>> [] Or we can change the figures to reflect the fact that one is >>>> config and the other arrangement? >>>> [] >>> >>>I guess that would be ok. Although for now I think the simplest would >>>be to just refer back to Fig. 2... >>> >> [] I do not have strong feelings on this. If anyone is still >> listening, can you please provide advice here? Copying Vijay and >> Ryuji... >> > > [] For the time being I removed the picture. I can easily put it back if the coauthors disagree with the move. > >>> >>>Maybe some more words are needed to make this clear - could you have a >> look >>>at adding some? >> [] >> [] What about: >> >> Note that this is a hierarchy in terms of MR-HA relationship, which may >> not >> be reflected in the physical arrangement of nodes at a given point of >> time. >> For instance, in the Cab Co case, some SFO Cabs might attach to any hot >> spot or >> Cab Co office in a different city, and the SFO office might be at Home >> if it is collocated with the Headquarters. But note that SFO might never >> attach to >> one of its own Cabs. This would create a deadlock issue, as documented >> in >> the NEMO RO problem statement. >> [] >> >> What do you think? > >That is basically in the text already - but pointing out the difference >between attaching with a new CoA and binding, and possibly how this >would work might be helpful. The suggested text above didn't give me >any additional clarity... [] Seems I did not understand the question the first time... And in fact I still fail to see the problem you point out. There's nothing special in the way the CoA is obtained??? Pascal=20 From nemo-bounces@ietf.org Mon Oct 03 12:52:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTYA-0007J3-80; Mon, 03 Oct 2005 12:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTY9-0007Iu-3C for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17772 for ; Mon, 3 Oct 2005 12:52:21 -0400 (EDT) Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTgd-0005fw-V5 for nemo@ietf.org; Mon, 03 Oct 2005 13:01:12 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id B0CE037FA2; Mon, 3 Oct 2005 18:52:14 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 988C637E6B; Mon, 3 Oct 2005 18:52:14 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 7CE3B37E44; Mon, 3 Oct 2005 18:52:14 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EMTXy-0000L3-2i; Mon, 03 Oct 2005 18:52:14 +0200 Message-ID: <434161BD.40608@levkowetz.com> Date: Mon, 03 Oct 2005 18:52:13 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org on 2005-10-03 18:39 Pascal Thubert (pthubert) said the following: >>>> >>>>Hmm. A first try - I'm not sure if this is good language, but at least >>>>I would be able to understand it...: >>>> >>>> In order to read this document properly, it is important to realise >>>> there is a distinction between the concepts of Home Link and Home >>>> Network. In a NEMO context these may not at all be equivalent - >>>> quite to the contrary: in NEMO, the Home Network can encompass much >>>> more than the Home Link, as it spans the Home Link and all the Links >>>> that the Mobile Routers carry with them. Exactly how the two concepts >>>> relate in a given deployment depend on the organization of the Home >>>> Network, as described below. >>>> >>>> >>> [] >>> What about: >>> >>> In order to read this document properly, it is important to realize >>> That the Home Link and Home Network are not necessarily congruent - >>> quite to the contrary: in NEMO, the Home Network can encompass much >>> more than the Home Link, as it spans the Home Link and all the Links >>> that the Mobile Routers carry with them. Exactly how the two concepts >>> relate in a given deployment depend on the organization of the Home >>> Network, as described below. >> >>Congruence is clear to me for triangles, but not for networks. I'd >>rather not inflict that upon a reader this early in the text ... > > [] We use it in networks, usually when Ipv4 and IPv6 topologies are > exactly overlapping. > I'm surprised you did not see it already. Any alternate suggestion? What about my suggested text above ? >> >>>>[...] >>>> >>>>> [] Or we can change the figures to reflect the fact that one is >>>>> config and the other arrangement? >>>>> [] >>>> >>>>I guess that would be ok. Although for now I think the simplest > would >>>>be to just refer back to Fig. 2... >>>> >>> [] I do not have strong feelings on this. If anyone is still >>> listening, can you please provide advice here? Copying Vijay and >>> Ryuji... >>> >> >> > > [] For the time being I removed the picture. I can easily put it > back if the coauthors disagree with the move. Right. >> >>>> >>>>Maybe some more words are needed to make this clear - could you have > a >>> look >>>>at adding some? >>> [] >>> [] What about: >>> >>> Note that this is a hierarchy in terms of MR-HA relationship, which > may >>> not >>> be reflected in the physical arrangement of nodes at a given point of >>> time. >>> For instance, in the Cab Co case, some SFO Cabs might attach to any > hot >>> spot or >>> Cab Co office in a different city, and the SFO office might be at > Home >>> if it is collocated with the Headquarters. But note that SFO might > never >>> attach to >>> one of its own Cabs. This would create a deadlock issue, as > documented >>> in >>> the NEMO RO problem statement. >>> [] >>> >>> What do you think? >> >>That is basically in the text already - but pointing out the difference >>between attaching with a new CoA and binding, and possibly how this >>would work might be helpful. The suggested text above didn't give me >>any additional clarity... > > [] Seems I did not understand the question the first time... And in > fact I still fail to see the problem you point out. There's nothing > special in the way the CoA is obtained??? Hmm. Skip additional text for now, then - I'll read the revised draft and see if I can suggest something better when I have the whole text in front of me. Regards, Henrik From nemo-bounces@ietf.org Mon Oct 03 12:53:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTYx-0007RM-AK; Mon, 03 Oct 2005 12:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTYv-0007RC-Pe for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:53:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17898 for ; Mon, 3 Oct 2005 12:53:11 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMThQ-0005j8-Eh for nemo@ietf.org; Mon, 03 Oct 2005 13:02:01 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1D45189864; Mon, 3 Oct 2005 19:53:03 +0300 (EEST) Message-ID: <434161FA.3010502@piuha.net> Date: Mon, 03 Oct 2005 19:53:14 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] solving Home Network models issue 8 References: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Looks good. Thanks. Pascal Thubert (pthubert) wrote: > Hi Jari: > > Here is a proposed change to fix issue 8: > > 5.5 Applicability > > The Extended Home Network keeps the MIP6 concept of a Home Network > > for both Mobile Nodes and Mobile Routers to take their Home Address > > from. Since there is no overlap between the prefixes that are > > assigned to MNPs and prefix(es) that are dedicated to the Home Link, > > it is possible for MNs and Mobile Routers to coexist with that model. > > Also, when the Home Address is derived from the prefix on the Home > > Link, the Home Agent behavior on the link trivially extends that of > > MIP and the support for that configuration should be available with > > all implementations. > > On the other hand, there are a number of issues with the support of a > > Home Address that is derived from the MNP, as detailed in > > Section 5.3. Though it is feasible, this configuration is not > > recommended for deployment. > > What do you think? > > Pascal > > -----------------------------------------------------------------------= - > > *From:* nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] *On=20 > Behalf Of *Pascal Thubert (pthubert) > *Sent:* Thursday, September 29, 2005 7:12 PM > *To:* nemo@ietf.org > *Subject:* [nemo] solving Home Network models issue 8 > > Hi: > > I=92m trying to get a consensus to solve issue 8: > > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mo= dels-issue8.txt=20 > =20 > > > The idea is to add some text to say that we do not recommend forming a=20 > home address from MNP in extended Home Network case. Thoughts anyone? > > =09 > > =09 > > *Pascal Thubert* > /software engineer/ > > =09 > > *Cisco Systems* > Village d'Entreprises GREEN SIDE > 400, Avenue Roumanille > B=E2timent T3 > 06410 BIOT - Sophia-Antipolis > > pthubert@cisco.com > > =09 > > tel: > mobile: > > =09 > > +33 4 97 23 26 34 > +33 6 19 98 29 85 > > =09 > > =09 > From nemo-bounces@ietf.org Mon Oct 03 12:53:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTZG-0007TF-Qg; Mon, 03 Oct 2005 12:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTZG-0007T7-1I for nemo@megatron.ietf.org; Mon, 03 Oct 2005 12:53:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17941 for ; Mon, 3 Oct 2005 12:53:31 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMThk-0005kP-7x for nemo@ietf.org; Mon, 03 Oct 2005 13:02:21 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2001E89864; Mon, 3 Oct 2005 19:53:23 +0300 (EEST) Message-ID: <4341620E.7060504@piuha.net> Date: Mon, 03 Oct 2005 19:53:34 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] solving Home Network models issue 7 References: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org OK for me. --Jari Pascal Thubert (pthubert) wrote: > Hi Jari: > > Proposed fix issue 7: remove the appendix and replace the text as=20 > discussed: > > There are also some drawbacks to the Virtual Home Link approach: > > RFC 3775 [7] and RFC 3963 [8] do not provide the specific support > > for a Mobile Node to emulate returning Home on a Virtual Home > > Network. In particular, in the case of NEMO, the routing > > information from the Mobile Router being injected on the IGP might > > adversely affect IPv6 route aggregation on the Home Network. > > Is that text OK with you? > > Pascal > > -----------------------------------------------------------------------= - > > *From:* nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] *On=20 > Behalf Of *Pascal Thubert (pthubert) > *Sent:* Thursday, September 29, 2005 7:09 PM > *To:* nemo@ietf.org > *Subject:* [nemo] solving Home Network models issue 7 > > Hi: > > I=92m trying to get a consensus to solve issue 7: > > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mo= dels-issue7.txt=20 > =20 > > > The idea is to remove the text around going home in a virtual Home=20 > network. This includes some text in the main document and the related=20 > appendix. Thoughts anyone? > > =09 > > =09 > > *Pascal Thubert* > /software engineer/ > > =09 > > *Cisco Systems* > Village d'Entreprises GREEN SIDE > 400, Avenue Roumanille > B=E2timent T3 > 06410 BIOT - Sophia-Antipolis > > pthubert@cisco.com > > =09 > > tel: > mobile: > > =09 > > +33 4 97 23 26 34 > +33 6 19 98 29 85 > > =09 > > =09 > From nemo-bounces@ietf.org Mon Oct 03 13:01:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTgm-0000OC-6M; Mon, 03 Oct 2005 13:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTgl-0000O3-05 for nemo@megatron.ietf.org; Mon, 03 Oct 2005 13:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18385 for ; Mon, 3 Oct 2005 13:01:16 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTpG-0005yc-N4 for nemo@ietf.org; Mon, 03 Oct 2005 13:10:07 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2005 19:01:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93H15VP024168; Mon, 3 Oct 2005 19:01:05 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 19:01:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Mon, 3 Oct 2005 19:00:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC015683F0@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXIOtjAwE5/lxe+T5egh2PF7Ni8igAAPkJA From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 03 Oct 2005 17:01:04.0908 (UTC) FILETIME=[0A76D4C0:01C5C83C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > >on 2005-10-03 18:39 Pascal Thubert (pthubert) said the following: >>>>> >>>>>Hmm. A first try - I'm not sure if this is good language, but at least >>>>>I would be able to understand it...: >>>>> >>>>> In order to read this document properly, it is important to realise >>>>> there is a distinction between the concepts of Home Link and Home >>>>> Network. In a NEMO context these may not at all be equivalent - >>>>> quite to the contrary: in NEMO, the Home Network can encompass much >>>>> more than the Home Link, as it spans the Home Link and all the Links >>>>> that the Mobile Routers carry with them. Exactly how the two concepts >>>>> relate in a given deployment depend on the organization of the Home >>>>> Network, as described below. >>>>> >>>>> >>>> [] >>>> What about: >>>> >>>> In order to read this document properly, it is important to realize >>>> That the Home Link and Home Network are not necessarily congruent - >>>> quite to the contrary: in NEMO, the Home Network can encompass much >>>> more than the Home Link, as it spans the Home Link and all the Links >>>> that the Mobile Routers carry with them. Exactly how the two concepts >>>> relate in a given deployment depend on the organization of the Home >>>> Network, as described below. >>> >>>Congruence is clear to me for triangles, but not for networks. I'd >>>rather not inflict that upon a reader this early in the text ... >> >> [] We use it in networks, usually when Ipv4 and IPv6 topologies are >> exactly overlapping. >> I'm surprised you did not see it already. Any alternate suggestion? > >What about my suggested text above ? > [] Told you, the trouble is the layer violation. A L2 link is obviously distinct from an L3 network, even if the coincide... Pascal From nemo-bounces@ietf.org Mon Oct 03 13:23:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMU2C-00043z-H0; Mon, 03 Oct 2005 13:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMU2A-00043k-Hu for nemo@megatron.ietf.org; Mon, 03 Oct 2005 13:23:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19598 for ; Mon, 3 Oct 2005 13:23:23 -0400 (EDT) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMUAf-0006c8-Cv for nemo@ietf.org; Mon, 03 Oct 2005 13:32:15 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id A68D137E6B; Mon, 3 Oct 2005 19:17:19 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8E20F37E5B; Mon, 3 Oct 2005 19:17:19 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 983C537E49; Mon, 3 Oct 2005 19:23:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EMU1z-00033r-6A; Mon, 03 Oct 2005 19:23:15 +0200 Message-ID: <43416902.6050006@levkowetz.com> Date: Mon, 03 Oct 2005 19:23:14 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC015683F0@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC015683F0@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org on 2005-10-03 19:00 Pascal Thubert (pthubert) said the following: >> >> >>on 2005-10-03 18:39 Pascal Thubert (pthubert) said the following: >>>>>> >>>>>>Hmm. A first try - I'm not sure if this is good language, but at > least >>>>>>I would be able to understand it...: >>>>>> >>>>>> In order to read this document properly, it is important to > realise >>>>>> there is a distinction between the concepts of Home Link and > Home >>>>>> Network. In a NEMO context these may not at all be equivalent - >>>>>> quite to the contrary: in NEMO, the Home Network can encompass > much >>>>>> more than the Home Link, as it spans the Home Link and all the > Links >>>>>> that the Mobile Routers carry with them. Exactly how the two > concepts >>>>>> relate in a given deployment depend on the organization of the > Home >>>>>> Network, as described below. >>>>>> >>>>>> >>>>> [] >>>>> What about: >>>>> >>>>> In order to read this document properly, it is important to > realize >>>>> That the Home Link and Home Network are not necessarily > congruent - >>>>> quite to the contrary: in NEMO, the Home Network can encompass > much >>>>> more than the Home Link, as it spans the Home Link and all the > Links >>>>> that the Mobile Routers carry with them. Exactly how the two > concepts >>>>> relate in a given deployment depend on the organization of the > Home >>>>> Network, as described below. >>>> >>>>Congruence is clear to me for triangles, but not for networks. I'd >>>>rather not inflict that upon a reader this early in the text ... >>> >>> [] We use it in networks, usually when Ipv4 and IPv6 topologies > are >>> exactly overlapping. >>> I'm surprised you did not see it already. Any alternate suggestion? >> >>What about my suggested text above ? >> > [] Told you, the trouble is the layer violation. A L2 link is > obviously distinct from an L3 network, even if the coincide... Yes, agreed - but I don't see the problem? If the text had said 'the same', or 'equal', I might be worried, but I think 'equivalent' gives you the de-coupling needed? Henrik From nemo-bounces@ietf.org Mon Oct 03 15:10:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVhg-0004yd-QC; Mon, 03 Oct 2005 15:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVhe-0004yO-O7 for nemo@megatron.ietf.org; Mon, 03 Oct 2005 15:10:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25632 for ; Mon, 3 Oct 2005 15:10:21 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVqA-00019r-KY for nemo@ietf.org; Mon, 03 Oct 2005 15:19:12 -0400 Received: by xproxy.gmail.com with SMTP id t5so234761wxc for ; Mon, 03 Oct 2005 12:10:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FJ0XrsoBDFFewcN5E6hwIfeNAR6yf+0BP/62+UghaDSRa3hiGZL1zo1fOk6BrVQ0r++DtpWUKNqrFhndI622D0qlbIG9utd4v1MOmqAtfCuB2tF+yIi6sK53qjBsdOwQwNG3xu30ImLSwAHhet+r9Xl3xKkvuv7pgeiI5Ex5NCY= Received: by 10.70.71.7 with SMTP id t7mr179009wxa; Mon, 03 Oct 2005 12:10:11 -0700 (PDT) Received: by 10.70.28.18 with HTTP; Mon, 3 Oct 2005 12:10:11 -0700 (PDT) Message-ID: Date: Mon, 3 Oct 2005 12:10:11 -0700 From: Vijay Devarapallli To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] solving Home Network models issue 8 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19994_8707799.1128366611021" References: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vijay Devarapallli List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ------=_Part_19994_8707799.1128366611021 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > On the other hand, there are a number of issues with the support of a > > Home Address that is derived from the MNP, as detailed in > > Section 5.3. Though it is feasible, this configuration is not > > recommended for deployment. > this is a bit too strong. there are two issues. 1) the HA needs to do a special check to verify if the home address is from the home link prefix. in RFC 3775, the HA just compares the address to the prefix on the home link and rejects the BU if the home address is not from that prefix. we extended that in RFC 3963. Mobile IPv6 specification [1] requires that the Home Address in the Binding Update be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specification relaxes this requirement so that the Home Agent rejects the Binding Update only if the Home Address does not belong to the prefix that the Home Agent is configured to serve. 2) returning home. there are many issues in returning home. since we have already fixed 1) and 2) might not be applicable in many deployments, the above statement you propose is too strong. how about the following? There are a number of issues with returning home when a mobile router configures its home address from the MNP as described in section 5.3. Therefore we do not recommend this mechanism if the mobile routers attach to the home network. Vijay ------=_Part_19994_8707799.1128366611021 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

   On the other hand, there are a number of issues with the support of a

   Home Address that is = derived from the MNP, as detailed in

   Section 5.3.  Th= ough it is feasible, this configuration is not

   recommended for deplo= yment.

this is a bit too strong. t= here are two issues.

1) the HA needs to do a special check to verify if the home address
is from the home link prefix. in RFC 3775, the HA just compares
the address to the prefix on the home link and rejects the BU if
the home address is not from that prefix.  we extended that in
RFC 3963.

      Mobile IPv6 specification [1] requires that = the Home Address in
      the Binding Update be configured from a pref= ix advertised on the
      home link.  Otherwise the Binding Updat= e is rejected with status
      value 132 [1].  This specification rela= xes this requirement so
      that the Home Agent rejects the Binding Upda= te only if the Home
      Address does not belong to the prefix that t= he Home Agent is
      configured to serve.

2) returning home. there are many issues in returning home.

since we have already fixed 1) and 2) might not be applicable
in many deployments, the above statement you propose is
too strong.

how about the following?

There are a number of issues with returning home when a mobile
router configures its home address from the MNP as described
in section 5.3. Therefore we do not recommend this mechanism
if the mobile routers attach to the home network.

Vijay
------=_Part_19994_8707799.1128366611021-- From nemo-bounces@ietf.org Tue Oct 04 18:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvYE-0005P5-LB; Tue, 04 Oct 2005 18:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvYC-0005Os-OY for nemo@megatron.ietf.org; Tue, 04 Oct 2005 18:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14761 for ; Tue, 4 Oct 2005 18:46:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMvgx-0007By-1F for nemo@ietf.org; Tue, 04 Oct 2005 18:55:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j94MDjd08935; Tue, 4 Oct 2005 15:13:45 -0700 X-mProtect: <200510042213> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdUO92SD; Tue, 04 Oct 2005 15:13:43 PDT Message-ID: <43430617.9000605@iprg.nokia.com> Date: Tue, 04 Oct 2005 15:45:43 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] solving Home Network models issue 7 References: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org okay. I changed my mind. I started writing up some stuff on this, but realised there are too many details that need to be explained to make returning home work for virtual home links. so lets remove the appendix from this document. Vijay Pascal Thubert (pthubert) wrote: > Hi Jari: > > > > Proposed fix issue 7: remove the appendix and replace the text as discussed: > > > > There are also some drawbacks to the Virtual Home Link approach: > > > > RFC 3775 [7] and RFC 3963 [8] do not provide the specific support > > for a Mobile Node to emulate returning Home on a Virtual Home > > Network. In particular, in the case of NEMO, the routing > > information from the Mobile Router being injected on the IGP might > > adversely affect IPv6 route aggregation on the Home Network. > > > > > > Is that text OK with you? > > > > Pascal > > ------------------------------------------------------------------------ > > *From:* nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] *On Behalf > Of *Pascal Thubert (pthubert) > *Sent:* Thursday, September 29, 2005 7:09 PM > *To:* nemo@ietf.org > *Subject:* [nemo] solving Home Network models issue 7 > > > > Hi: > > > > Im trying to get a consensus to solve issue 7: > > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issue7.txt > > > > > The idea is to remove the text around going home in a virtual Home > network. This includes some text in the main document and the related > appendix. Thoughts anyone? > > > > > > > > > > > > > > *Pascal Thubert* > /software engineer/ > > > > *Cisco Systems* > Village d'Entreprises GREEN SIDE > 400, Avenue Roumanille > Bbtiment T3 > 06410 BIOT - Sophia-Antipolis > > pthubert@cisco.com > > > > tel: > mobile: > > > > +33 4 97 23 26 34 > +33 6 19 98 29 85 > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Tue Oct 04 18:47:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvYy-0005ZG-JV; Tue, 04 Oct 2005 18:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvYw-0005ZB-Aq for nemo@megatron.ietf.org; Tue, 04 Oct 2005 18:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14823 for ; Tue, 4 Oct 2005 18:47:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMvhg-0007Cn-O2 for nemo@ietf.org; Tue, 04 Oct 2005 18:56:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j94MD9X08000; Tue, 4 Oct 2005 15:13:09 -0700 X-mProtect: <200510042213> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdh5rM2e; Tue, 04 Oct 2005 15:13:08 PDT Message-ID: <434305F3.3040602@iprg.nokia.com> Date: Tue, 04 Oct 2005 15:45:07 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Ryuji Wakikawa , Henrik Levkowetz X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: >>>>>[] Or we can change the figures to reflect the fact that one is >>>>>config and the other arrangement? >>>>>[] >>>> >>>>I guess that would be ok. Although for now I think the simplest > > would > >>>>be to just refer back to Fig. 2... >>>> >>> >>>[] I do not have strong feelings on this. If anyone is still >>>listening, can you please provide advice here? Copying Vijay and >>>Ryuji... IMO, having the picture in there does not cause any harm. if not anything it makes it easier to understand what is being said in section 6.2.1. Vijay From nemo-bounces@ietf.org Tue Oct 04 23:15:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMzkH-0007aZ-V8; Tue, 04 Oct 2005 23:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMzkG-0007aH-ME for nemo@megatron.ietf.org; Tue, 04 Oct 2005 23:15:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24412 for ; Tue, 4 Oct 2005 23:15:01 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMzt2-00048m-42 for nemo@ietf.org; Tue, 04 Oct 2005 23:24:10 -0400 Received: from [192.168.0.4] (p3086-ipbf409marunouchi.tokyo.ocn.ne.jp [218.43.37.86]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 43A464C8AC; Wed, 5 Oct 2005 12:14:32 +0900 (JST) In-Reply-To: <43430617.9000605@iprg.nokia.com> References: <7892795E1A87F04CADFCCF41FADD00FC015683B5@xmb-ams-337.emea.cisco.com> <43430617.9000605@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ryuji Wakikawa Subject: Re: [nemo] solving Home Network models issue 7 Date: Wed, 5 Oct 2005 12:14:30 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi pascal and jari I am fine with the changes. ryuji On 2005/10/05, at 7:45, Vijay Devarapalli wrote: > okay. I changed my mind. I started writing up some stuff on > this, but realised there are too many details that need to > be explained to make returning home work for virtual home > links. so lets remove the appendix from this document. > > Vijay > > Pascal Thubert (pthubert) wrote: > >> Hi Jari: >> Proposed fix issue 7: remove the appendix and replace the text as =20= >> discussed: >> There are also some drawbacks to the Virtual Home Link approach: >> RFC 3775 [7] and RFC 3963 [8] do not provide the specific =20 >> support >> for a Mobile Node to emulate returning Home on a Virtual Home >> Network. In particular, in the case of NEMO, the routing >> information from the Mobile Router being injected on the IGP =20= >> might >> adversely affect IPv6 route aggregation on the Home Network. >> Is that text OK with you? >> Pascal >> ---------------------------------------------------------------------=20= >> --- >> *From:* nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] *On =20 >> Behalf Of *Pascal Thubert (pthubert) >> *Sent:* Thursday, September 29, 2005 7:09 PM >> *To:* nemo@ietf.org >> *Subject:* [nemo] solving Home Network models issue 7 >> Hi: >> I=12m trying to get a consensus to solve issue 7: >> http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-=20 >> network-models-issue7.txt The idea is to remove the text around =20 >> going home in a virtual Home network. This includes some text in =20 >> the main document and the related appendix. Thoughts anyone? >> >> >> *Pascal Thubert* >> /software engineer/ >> >> *Cisco Systems* >> Village d'Entreprises GREEN SIDE >> 400, Avenue Roumanille >> Bbtiment T3 >> 06410 BIOT - Sophia-Antipolis >> pthubert@cisco.com >> >> tel: >> mobile: >> >> +33 4 97 23 26 34 >> +33 6 19 98 29 85 >> >> >> >> > > From nemo-bounces@ietf.org Tue Oct 04 23:34:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN03S-0005yJ-CY; Tue, 04 Oct 2005 23:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN03Q-0005wG-NI for nemo@megatron.ietf.org; Tue, 04 Oct 2005 23:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25297 for ; Tue, 4 Oct 2005 23:34:49 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN0CE-0004bG-PG for nemo@ietf.org; Tue, 04 Oct 2005 23:43:59 -0400 Received: from [192.168.0.4] (p3086-ipbf409marunouchi.tokyo.ocn.ne.jp [218.43.37.86]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 416134C516; Wed, 5 Oct 2005 12:34:43 +0900 (JST) In-Reply-To: References: <7892795E1A87F04CADFCCF41FADD00FC0156839E@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51282D80-7128-41C6-BF88-2C85A9DE3A83@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] solving Home Network models issue 8 Date: Wed, 5 Oct 2005 12:34:41 +0900 To: Vijay Devarapallli X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay and Pascal Vijay's proposed text looks better. I also think we should state these two issues in the document. How about putting the vijay's texts(1 and 2) in section 5.3?! ryuji On 2005/10/04, at 4:10, Vijay Devarapallli wrote: > On the other hand, there are a number of issues with the support > of a > > Home Address that is derived from the MNP, as detailed in > > Section 5.3. Though it is feasible, this configuration is not > > recommended for deployment. > > this is a bit too strong. there are two issues. > > 1) the HA needs to do a special check to verify if the home address > is from the home link prefix. in RFC 3775, the HA just compares > the address to the prefix on the home link and rejects the BU if > the home address is not from that prefix. we extended that in > RFC 3963. > > Mobile IPv6 specification [1] requires that the Home Address in > the Binding Update be configured from a prefix advertised on the > home link. Otherwise the Binding Update is rejected with status > value 132 [1]. This specification relaxes this requirement so > that the Home Agent rejects the Binding Update only if the Home > Address does not belong to the prefix that the Home Agent is > configured to serve. > > 2) returning home. there are many issues in returning home. > > since we have already fixed 1) and 2) might not be applicable > in many deployments, the above statement you propose is > too strong. > > how about the following? > > There are a number of issues with returning home when a mobile > router configures its home address from the MNP as described > in section 5.3. Therefore we do not recommend this mechanism > if the mobile routers attach to the home network. > > Vijay From nemo-bounces@ietf.org Wed Oct 05 02:12:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2Vu-0001u9-6a; Wed, 05 Oct 2005 02:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2Vr-0001tk-Nx for nemo@megatron.ietf.org; Wed, 05 Oct 2005 02:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13082 for ; Wed, 5 Oct 2005 02:12:17 -0400 (EDT) Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN2eb-00083J-62 for nemo@ietf.org; Wed, 05 Oct 2005 02:21:26 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 71C4C383A9; Wed, 5 Oct 2005 08:11:57 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5BC0B37F12; Wed, 5 Oct 2005 08:11:57 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B0FA337E42; Wed, 5 Oct 2005 08:11:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EN2VP-00013Q-Ki; Wed, 05 Oct 2005 08:11:55 +0200 Message-ID: <43436EAA.90808@levkowetz.com> Date: Wed, 05 Oct 2005 08:11:54 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC015683D0@xmb-ams-337.emea.cisco.com> <434305F3.3040602@iprg.nokia.com> In-Reply-To: <434305F3.3040602@iprg.nokia.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Vijay, on 2005-10-05 00:45 Vijay Devarapalli said the following: >>>>[] I do not have strong feelings on this. If anyone is still >>>>listening, can you please provide advice here? Copying Vijay and >>>>Ryuji... > > IMO, having the picture in there does not cause any harm. > if not anything it makes it easier to understand what is > being said in section 6.2.1. My point was that picture 2 and picture 3 seems to be the same, and it confused me when reading the document - I wondered why the picture was there, what difference I was supposed to see. Henrik From nemo-bounces@ietf.org Wed Oct 05 02:47:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN33T-0007QH-IV; Wed, 05 Oct 2005 02:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN33R-0007QC-6e for nemo@megatron.ietf.org; Wed, 05 Oct 2005 02:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01218 for ; Wed, 5 Oct 2005 02:47:03 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN3CF-0000Y3-KB for nemo@ietf.org; Wed, 05 Oct 2005 02:56:12 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2005 23:46:53 -0700 X-IronPort-AV: i="3.97,175,1125903600"; d="scan'208"; a="217148997:sNHT24633416" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j956kHgq022797; Wed, 5 Oct 2005 14:46:37 +0800 (CST) Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 14:46:20 +0800 Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 08:22:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Wed, 5 Oct 2005 08:22:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01568A80@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXJdARf70UamKKETLylC6ufRIQrhgAAESWA From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" , "Vijay Devarapalli" X-OriginalArrivalTime: 05 Oct 2005 06:22:24.0912 (UTC) FILETIME=[26CAF900:01C5C975] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >Sent: Wednesday, October 05, 2005 8:12 AM >To: Vijay Devarapalli >Cc: Pascal Thubert (pthubert); nemo@ietf.org; Ryuji Wakikawa >Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt > >Vijay, > >on 2005-10-05 00:45 Vijay Devarapalli said the following: > >>>>>[] I do not have strong feelings on this. If anyone is still >>>>>listening, can you please provide advice here? Copying Vijay and >>>>>Ryuji... >> >> IMO, having the picture in there does not cause any harm. >> if not anything it makes it easier to understand what is >> being said in section 6.2.1. > >My point was that picture 2 and picture 3 seems to be the same, and >it confused me when reading the document - I wondered why the picture >was there, what difference I was supposed to see. > > [] I explained that one was a configuration thing, and the other an actual arrangement of boxes. Another way of fixing the issue is to draw only one MR at home: HA | /56=20 --+-----+--+- . -+- . -+-- Egress |=20 MR at Home =20 | ------ /64 =20 And then for the next figure HA | /56 =20 --+-----+--+- . -+- . -+-- | ------=20 | /64 MR at Home Egress | =20 What do you think? Pascal From nemo-bounces@ietf.org Wed Oct 05 03:16:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3Vw-0001HV-Fi; Wed, 05 Oct 2005 03:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3Vu-0001HQ-3w for nemo@megatron.ietf.org; Wed, 05 Oct 2005 03:16:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02700 for ; Wed, 5 Oct 2005 03:16:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN3ek-0001Fr-7g for nemo@ietf.org; Wed, 05 Oct 2005 03:25:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2005 00:16:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,175,1125903600"; d="scan'208"; a="12450151:sNHT32505504" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j957G1TE023532; Wed, 5 Oct 2005 03:16:12 -0400 (EDT) Received: from xbh-ams-332.emea.cisco.com ([144.254.231.87]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 03:16:07 -0400 Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 08:58:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] solving Home Network models issue 8 Date: Wed, 5 Oct 2005 08:58:07 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01568A94@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] solving Home Network models issue 8 Thread-Index: AcXITjHcDZIFzjkQRsCXFJUCWO/ntABKP1jg From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapallli" X-OriginalArrivalTime: 05 Oct 2005 06:58:07.0909 (UTC) FILETIME=[241E5D50:01C5C97A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ________________________________________ From: Vijay Devarapallli [mailto:dvijay@gmail.com]=20 Sent: Monday, October 03, 2005 9:10 PM To: Pascal Thubert (pthubert) Cc: Jari Arkko; nemo@ietf.org Subject: Re: [nemo] solving Home Network models issue 8 =A0=A0 On the other hand, there are a number of issues with the support = of a =A0=A0 Home Address that is derived from the MNP, as detailed in =A0=A0 Section 5.3.=A0 Though it is feasible, this configuration is not =A0=A0 recommended for deployment. this is a bit too strong. there are two issues.=20 1) the HA needs to do a special check to verify if the home address is from the home link prefix. in RFC 3775, the HA just compares the address to the prefix on the home link and rejects the BU if the home address is not from that prefix.=A0 we extended that in RFC 3963. =A0=A0=A0=A0=A0 Mobile IPv6 specification [1] requires that the Home = Address in =A0=A0=A0=A0=A0 the Binding Update be configured from a prefix = advertised on the =A0=A0=A0=A0=A0 home link.=A0 Otherwise the Binding Update is rejected = with status =A0=A0=A0=A0=A0 value 132 [1].=A0 This specification relaxes this = requirement so =A0=A0=A0=A0=A0 that the Home Agent rejects the Binding Update only if = the Home =A0=A0=A0=A0=A0 Address does not belong to the prefix that the Home = Agent is =A0=A0=A0=A0=A0 configured to serve. 2) returning home. there are many issues in returning home. since we have already fixed 1) and 2) might not be applicable in many deployments, the above statement you propose is too strong.=20 how about the following? There are a number of issues with returning home when a mobile router configures its home address from the MNP as described in section 5.3. Therefore we do not recommend this mechanism if the mobile routers attach to the home network. [] You're right, that's better Pascal From nemo-bounces@ietf.org Wed Oct 05 16:11:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFcI-0000yQ-Q4; Wed, 05 Oct 2005 16:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDSN-0004aL-SO for nemo@megatron.ietf.org; Wed, 05 Oct 2005 13:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06970 for ; Wed, 5 Oct 2005 13:53:30 -0400 (EDT) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENDbI-0002fU-8J for nemo@ietf.org; Wed, 05 Oct 2005 14:02:45 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 712443832D; Wed, 5 Oct 2005 19:53:15 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 58DF337FFD; Wed, 5 Oct 2005 19:53:15 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D65E337E43; Wed, 5 Oct 2005 19:53:14 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1ENDS5-0003jG-To; Wed, 05 Oct 2005 19:53:13 +0200 Message-ID: <43441309.6070607@levkowetz.com> Date: Wed, 05 Oct 2005 19:53:13 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC01568A80@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01568A80@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, on 2005-10-05 08:22 Pascal Thubert (pthubert) said the following: [...] >>My point was that picture 2 and picture 3 seems to be the same, and >>it confused me when reading the document - I wondered why the picture >>was there, what difference I was supposed to see. >> >> > [] I explained that one was a configuration thing, and the other an > actual arrangement of boxes. > Another way of fixing the issue is to draw only one MR at home: The figures below would be fig. 3 and fig. 4, right? If so, this would work for me. Maybe add another line so that "Egress" doesn't seem to be associated with the Home Link: HA | /56 --+-----+--+- . -+- . -+-- | Egress | MR at Home | ------ /64 > > HA > | /56 > --+-----+--+- . -+- . -+-- > Egress | > MR at Home > | > ------ > /64 > > > And then for the next figure > > HA > | /56 > --+-----+--+- . -+- . -+-- > | > ------ > | /64 > MR at Home > Egress | > > What do you think? I think we're getting there :-) Henrik From nemo-bounces@ietf.org Thu Oct 06 03:12:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPvV-0005Cv-7w; Thu, 06 Oct 2005 03:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPvT-0005Cn-FX for nemo@megatron.ietf.org; Thu, 06 Oct 2005 03:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12633 for ; Thu, 6 Oct 2005 03:12:21 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENQ4W-0000Bj-4w for nemo@ietf.org; Thu, 06 Oct 2005 03:21:44 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2005 09:12:14 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j967C4os025395; Thu, 6 Oct 2005 09:12:11 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Oct 2005 09:11:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Date: Thu, 6 Oct 2005 09:11:41 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01568ED2@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt Thread-Index: AcXJ1e+uoqqXFh6ZRdqyYegLWsNfbwAbxLyw From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 06 Oct 2005 07:11:47.0092 (UTC) FILETIME=[36CD8540:01C5CA45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >Sent: Wednesday, October 05, 2005 7:53 PM >To: Pascal Thubert (pthubert) >Cc: Vijay Devarapalli; nemo@ietf.org; Ryuji Wakikawa >Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt > >Hi Pascal, > >on 2005-10-05 08:22 Pascal Thubert (pthubert) said the following: >[...] >>>My point was that picture 2 and picture 3 seems to be the same, and >>>it confused me when reading the document - I wondered why the picture >>>was there, what difference I was supposed to see. >>> >>> >> [] I explained that one was a configuration thing, and the other an >> actual arrangement of boxes. >> Another way of fixing the issue is to draw only one MR at home: > >The figures below would be fig. 3 and fig. 4, right? If so, this would >work for me. Maybe add another line so that "Egress" doesn't seem to >be associated with the Home Link: > > > HA > | /56 > --+-----+--+- . -+- . -+-- > | > Egress | > MR at Home > | > ------ > /64 > > >> >> HA >> | /56 >> --+-----+--+- . -+- . -+-- >> Egress | >> MR at Home >> | >> ------ >> /64 >> >> >> And then for the next figure >> >> HA >> | /56 >> --+-----+--+- . -+- . -+-- >> | >> ------ >> | /64 >> MR at Home >> Egress | >> >> What do you think? > >I think we're getting there :-) > > > Henrik []=20 Yep :) fig3 Bridging between egress and ingress: HA | -------+--+--- /56 | Egress | MR at Home | --+--- /64 fig4 Merging the Home and the Mobile Networks: HA | -------+-+---- /56 | ---+-- /64 | MR at Home Egress | Pascal From nemo-bounces@ietf.org Thu Oct 06 03:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQGL-0002dl-6y; Thu, 06 Oct 2005 03:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQGJ-0002ad-B5 for nemo@megatron.ietf.org; Thu, 06 Oct 2005 03:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13901 for ; Thu, 6 Oct 2005 03:33:53 -0400 (EDT) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENQPJ-0001Bp-5A for nemo@ietf.org; Thu, 06 Oct 2005 03:43:16 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 8904C38405; Thu, 6 Oct 2005 09:27:07 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id F02EA383AD; Thu, 6 Oct 2005 09:27:06 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 270BE37E50; Thu, 6 Oct 2005 09:33:19 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1ENQFi-0007Qg-Is; Thu, 06 Oct 2005 09:33:18 +0200 Message-ID: <4344D33E.60701@levkowetz.com> Date: Thu, 06 Oct 2005 09:33:18 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt References: <7892795E1A87F04CADFCCF41FADD00FC01568ED2@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01568ED2@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, on 2005-10-06 09:11 Pascal Thubert (pthubert) said the following: > > [] > > Yep :) > > > fig3 Bridging between egress and ingress: > > HA > | > -------+--+--- /56 > | > Egress | > MR at Home > | > --+--- /64 > > > > fig4 Merging the Home and the Mobile Networks: > > HA > | > -------+-+---- /56 > | > ---+-- /64 > | > MR at Home > Egress | > Yes, this works for me. Henrik From nemo-bounces@ietf.org Thu Oct 06 06:18:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSq3-0006cp-2Q; Thu, 06 Oct 2005 06:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSq1-0006ck-T5 for nemo@megatron.ietf.org; Thu, 06 Oct 2005 06:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22488 for ; Thu, 6 Oct 2005 06:18:55 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENSz5-0008Gt-SU for nemo@ietf.org; Thu, 06 Oct 2005 06:28:20 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 08C504CAFA for ; Thu, 6 Oct 2005 19:18:33 +0900 (JST) Date: Thu, 6 Oct 2005 19:18:32 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051006191832.20b532be.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Subject: [nemo] cfp - NEMO Workshop (WONEMO) in Japan, January 2006. Papers by Oct.31, 2005 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Only 3 weeks left. CFP The First International WOrkshop on NEtwork MObility (WONEMO) January 19 2006, Sendai, Japan http://www.icoin.org/wonemo In conjunction with ICOIN http://www.icoin.org/ January 16-19 2006, Sendai, Japan Important Dates ~~~~~~~~~~~~~~~ All deadlines are 23:59:59 GMT. These are *firm* deadlines. Paper submission deadline: Oct 31, 2005 Notification of acceptance: Nov 30, 2005 Camera-ready versions due: Dec 31, 2005 Scope ~~~~~ Research in NEtwork MObility (NEMO) support mechanisms has been performed for some years. The purpose of network mobility support is to manage the change of the point of attachment of the mobile router connecting an entire network to the Internet topology. This would allow such a network, known as a "mobile network" (or a NEMO), to migrate in the IP topology. With such an approach to mobility management, anything could potentially be connected to the Internet, particularly PANs (Personal Area Networks, i.e. small networks attached to people and composed of Internet appliances like PDAs, mobile phones, digital cameras, etc.), networks of sensors deployed in vehicles (aircrafts, boats, buses, trains), and access networks deployed in public transportation (taxis, trains, aircrafts, trucks and personal cars) to provide Internet access to devices carried by their passengers (laptop, camera, mobile phone, and even PANs, therefore exhibiting what is referred to as a nested NEMO). The solution NEMO Basic Support (RFC 3963) specified for IPv6 by the IETF in the NEMO Working Group brings an answer to immediate needs, i.e. maintaining existing connections open, while optmization issues are left for later once research in this topic has reached maturity. The complexity of the configurations enabled by network mobility (nested mobility, multihomed NEMO, split NEMO) causes new issues, particularly on the routing optimization side. It does also challenge existing mechanisms for security, access control, multicast and quality of service applied to network mobility. The goal of the WONEMO workshop is to gather researchers in network mobility, to share the experience in implementations, experimentations, and to explore the deployment, usages, and research issues of NEMO-like networks. The workshop strongly encourages the submission of papers that challenge the research community with revolutionary new approaches, technologies, or usages in the field of NEMO. These "challenge papers" should provide stimulating ideas or visions that may open up exciting avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate. We solicit full-length papers presenting original and unpublished work including, but not limited to the following topics: - Routing optimization in nested and non-nested NEMO - NEMO multihomed issues (multiple MRs, multiple prefixes,multiple interfaces) - Performances issues - Security and Access control mechanisms for nested and non-nested NEMO - Applications and usages of NEMO Basic Support - Auto-configuration for NEMO - Interaction between NEMO and ad-hoc networks - Simulation of network mobility (protocols and usages) - Description of actual implementations/experimentations of NEMO - Multicast in nested and non-nested NEMO - Simulation models and tools for network mobility Submission ~~~~~~~~~~ Papers should not exceed 8 pages. For submission, please follow the guidelines as indicated on http://www.icoin.org/wonemo/submission.html General Chair ~~~~~~~~~~~~~ Prof. Jun Murai, WIDE Project, Keio University, Japan Program Co-chairs ~~~~~~~~~~~~~~~~~ - Dr. Thierry Ernst, Keio University, Japan - Dr. Ryuji Wakikawa, Keio University, Japan Technical Program Committee ~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Prof. Yang Hee Choi (Seoul National University, South Korea) - Dr. Gabriel Montenegro (Microsoft, USA) - Dr. Thomas Noel (ULP Strasbourg, France) - Prof. Fumio Teraoka (Keio University, Japan) - Prof. Chung-Ming Huang (National Cheng Kung University, Taiwan) - Vijay Devarapalli (Nokia, USA) - Takashi Aramaki (Panasonic, Japan) (More to be confirmed) [Last Modified: 2005/10/06] From nemo-bounces@ietf.org Sat Oct 08 02:53:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO8aB-0007K7-Lz; Sat, 08 Oct 2005 02:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO8a8-0007Jz-2l for nemo@megatron.ietf.org; Sat, 08 Oct 2005 02:53:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05579 for ; Sat, 8 Oct 2005 02:53:18 -0400 (EDT) Received: from locust.csie.ncku.edu.tw ([140.116.247.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO8jZ-0006BO-Cg for nemo@ietf.org; Sat, 08 Oct 2005 03:03:06 -0400 Received: from leechlab (leech.csie.ncku.edu.tw [140.116.247.122]) by locust.csie.ncku.edu.tw (8.12.10+Sun/8.12.10) with ESMTP id j986hdlg028887 for ; Sat, 8 Oct 2005 14:43:43 +0800 (CST) From: "Lee, Chao-Hsien" To: Subject: [nemo] New draft draft-ming-nemo-sipnemo-00.txt Date: Sat, 8 Oct 2005 14:53:19 +0800 Message-ID: <001f01c5cbd4$f7979960$7af7748c@leechlab> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C5CC18.05BAD960" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXL1Pd48axHUMk2QX6KyFK8mO6nSg== X-Spam-Score: 0.3 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C5CC18.05BAD960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all: We have submitted a new draft that extends SIP to support network mobility and to achieve RO. You can get this document from the following URL. http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt Abstract is as follows. The Network Mobility (NEMO) Basic Support protocol enables a mobile network to change its point of attachment and keeps nodes in the mobile network reachable when the mobile network moves in the Internet. However, using the NEMO Basic Support protocol, all traffic must pass through the bi-directional tunnel between a mobile router and its home agent when the mobile router leaves its home network. It results in sub-optimal routing and long transmission delay. This document describes the SIP-based Network Mobility (SIP- NEMO) Route Optimization (RO) that achieves optimal routing and reduces the limitation due to the bi-direction tunnel using Session Initiation Protocol (SIP). Any question or comment is welcome. best regards, Lee, Chao-Hsien Ph. D student, Lab of Multimedia Mobile Network, Dept. of Computer & Information Engineer, National Cheng Kung University, Tainan, Taiwan, R.O.C Lab's phone: +886-6-2080362 E-mail : leech@locust.csie.ncku.edu.tw ------=_NextPart_000_0020_01C5CC18.05BAD960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

We have submitted a new draft that extends SIP to support network mobility and = to achieve RO.

You can get this document from the following URL.

 

http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt

 

Abstract is as follows.

 

   The Network Mobility (NEMO) Basic Support protocol =
enables a mobile
   network to change its point of attachment and keeps =
nodes in the
   mobile network reachable when the mobile network =
moves in the
   Internet.  However, using the NEMO Basic =
Support protocol, all
   traffic must pass through the bi-directional tunnel =
between a mobile
   router and its home agent when the mobile router =
leaves its home
   network.  It results in sub-optimal routing =
and long transmission
   delay.  This document describes the SIP-based =
Network Mobility (SIP-
   NEMO) Route Optimization (RO) that achieves optimal =
routing and
   reduces the limitation due to the bi-direction =
tunnel using Session
   Initiation Protocol =
(SIP).

 

Any question or comment is welcome.

 

best regards,

 

Lee, Chao-Hsien
Ph. D student,
Lab of Multimedia Mobile Network,
Dept. of Computer & Information Engineer,
National Cheng Kung University, Tainan, = Taiwan, = R.O.C

 
Lab's phone: +886-6-2080362
E-mail : leech@locust.csie.ncku.edu= .tw=

 

------=_NextPart_000_0020_01C5CC18.05BAD960-- From nemo-bounces@ietf.org Tue Oct 11 10:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLSW-0003H8-KQ; Tue, 11 Oct 2005 10:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLS7-00037f-Ut; Tue, 11 Oct 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29267; Tue, 11 Oct 2005 10:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLcD-0002vz-TF; Tue, 11 Oct 2005 11:00:31 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPLS5-0005cQ-8y; Tue, 11 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-05.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-05.txt Pages : 22 Date : 2005-10-11 This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft [8]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-home-network-models-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-home-network-models-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-11100459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-11100459.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Oct 11 10:50:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLSd-0003Ih-VU; Tue, 11 Oct 2005 10:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLS8-00038E-LB; Tue, 11 Oct 2005 10:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29275; Tue, 11 Oct 2005 10:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLcE-0002wH-HZ; Tue, 11 Oct 2005 11:00:31 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPLS5-0005dW-MY; Tue, 11 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Problem Statement Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-problem-statement-01.txt Pages : 25 Date : 2005-10-11 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies, and provides for the motivation behind Route Optimization (RO) for NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-problem-statement-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-11103426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-problem-statement-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-11103426.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Oct 11 22:20:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPWDz-0007NB-4G; Tue, 11 Oct 2005 22:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPWDy-0007N0-Hh for nemo@megatron.ietf.org; Tue, 11 Oct 2005 22:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20223 for ; Tue, 11 Oct 2005 22:20:06 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPWOA-0001tJ-CC for nemo@ietf.org; Tue, 11 Oct 2005 22:30:43 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9C2JrBV020678 for ; Wed, 12 Oct 2005 11:19:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9C2Jt110493 for ; Wed, 12 Oct 2005 11:19:55 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j9C2Jqs16353 for ; Wed, 12 Oct 2005 11:19:53 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 10:17:17 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 44A6120AC00; Wed, 12 Oct 2005 10:22:48 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 12 Oct 2005 10:22:47 +0800 Message-Id: <1129083768.9252.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 12 Oct 2005 02:17:17.0213 (UTC) FILETIME=[113674D0:01C5CED3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, just a quick note on the changes from -00 to -01: * Added text on effect on TCP contributed by Carlos in Sect 2.1 - "Sub-Optimality with NEMO Basic Support" * Added text on VMN using CoA as source address in Appendix B.4.3 * Re-written Section 2.5 - "Security Policy Prohibiting Traffic From Visiting Nodes" * Replaced "deadlock" with "stalemate" in Section 2.7. * Minor typographical corrections /rgds /cwng On Tue, 2005-10-11 at 10:50 -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Network Mobility Route Optimization Problem Statement > Author(s) : C. Ng, et al. > Filename : draft-ietf-nemo-ro-problem-statement-01.txt > Pages : 25 > Date : 2005-10-11 > > With current Network Mobility (NEMO) Basic Support, all > communications to and from Mobile Network Nodes must go through the > bi-directional tunnel established between the Mobile Router and Home > Agent when the mobile network is away. This results in various > inefficiencies associated with packet delivery. This document > investigates such inefficiencies, and provides for the motivation > behind Route Optimization (RO) for NEMO. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-ro-problem-statement-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.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. > reference to remote file attachment > Content-Type: Message/External-body; access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2005-10-11103426.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From nemo-bounces@ietf.org Sat Oct 15 03:23:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQgO0-0001Xb-Qr; Sat, 15 Oct 2005 03:23:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQgNy-0001XQ-RB for nemo@megatron.ietf.org; Sat, 15 Oct 2005 03:23:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25838 for ; Sat, 15 Oct 2005 03:23:13 -0400 (EDT) Received: from web33508.mail.mud.yahoo.com ([68.142.206.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQgYq-0004QY-5D for nemo@ietf.org; Sat, 15 Oct 2005 03:34:33 -0400 Received: (qmail 48149 invoked by uid 60001); 15 Oct 2005 07:23:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MgahZmpVv7B+C+Bvriq9S2dcYzCklDEfjS9mvqUznfTwJKXKZjNMGAsDmIeaOoqI4ri9w3Qn1KeDpKknJ2H0t6eoHBsSRPaDGaYm0K6h3bnjddPbky/9yU3jrpDIeIzpfodC8c6epL4Xt6uVPyJgV5Uw2UCVwDh2Oov9RiJLBM8= ; Message-ID: <20051015072307.48147.qmail@web33508.mail.mud.yahoo.com> Received: from [66.21.211.138] by web33508.mail.mud.yahoo.com via HTTP; Sat, 15 Oct 2005 00:23:07 PDT Date: Sat, 15 Oct 2005 00:23:07 -0700 (PDT) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 8bit Cc: yangxiao@ieee.org Subject: [nemo] CFP-Final Call: Journal Special issue on Security Issues in Sensor Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org (Our apologies if you receive multiple copies) International Journal of Security and Networks (IJSN), Special Issue on Security Issues in Sensor Networks http://www.cs.memphis.edu/~yxiao/IJSN_Snesor_Security.html -----------------------------------------------------------------------Guest Editors Yang Xiao, The University of Memphis, USA E-mail: yangxiao@ieee.org Xiaohua Jia, City University of Hong Kong, Hong Kong E-mail: csjia@cityu.edu.hk Bo Sun, Lamar University, USA E-mail: bosun99@gmail.com Xiaojiang Du, North Dakota State University, USA E-mail: bsun@cs.lamar.edu -----------------------------------------------------------------------Security in Sensor networks differ from those in other traditional networks with many aspects such as limited memory space, limited computation capability, etc. Therefore, sensor network security has some unique features which do not exist in other networks. The need to address security issues, and provide timely, solid technical contributions of security solutions in sensor networks establishes the motivation behind this special issue. This special issue is dedicated to sensor network security. A paper should have security in sensor networks as the focus. Specific areas of interest include, but not limit to: . Key Managements in sensor networks . Secure Routing in secure networks . Light weight Encryption and authentication in Sensor networks . Attacks and solutions in Sensor networks . Other areas which are related to both security and sensor networks. The manuscripts should be submitted as an e-mail attachment in PDF format to Prof. Bo Sun at bosun99@gmail.com. If the file is larger than 1MB, the authors are encouraged to use WINZIP. Furthermore, each author is required to help the review process of the special issue. ----------------------------------------------------------------------- Schedule: Submission deadline: Oct. 15, 2005 Notification: Jan. 15, 2006 Final Paper Submission: Feb. 1, 2005 Publication of special issue: Middle 2006 ----------------------------------------------------------------------- From nemo-bounces@ietf.org Sun Oct 16 17:41:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERGFo-0007ne-4S; Sun, 16 Oct 2005 17:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERGFn-0007nZ-BP for nemo@megatron.ietf.org; Sun, 16 Oct 2005 17:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25982 for ; Sun, 16 Oct 2005 17:41:07 -0400 (EDT) Received: from web33508.mail.mud.yahoo.com ([68.142.206.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERGQx-0006tP-TA for nemo@ietf.org; Sun, 16 Oct 2005 17:52:50 -0400 Received: (qmail 32948 invoked by uid 60001); 16 Oct 2005 21:41:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z0iggAwPjb+47N5VjzKmmnOU5Pb9+RWyw1W8MOIXZ/xNMZzEL/v34FhkFkre1jj8osGLApm4n84oXDqzfmvIx1hWNw7R5Vwh5ba+jHBu9v9hCef5e4t7c41W+xlOEztIToNwLvk984zY5hP4djdd7z2iQo9LxEzP7H0G0HwcuHY= ; Message-ID: <20051016214101.32946.qmail@web33508.mail.mud.yahoo.com> Received: from [141.225.9.54] by web33508.mail.mud.yahoo.com via HTTP; Sun, 16 Oct 2005 14:41:01 PDT Date: Sun, 16 Oct 2005 14:41:01 -0700 (PDT) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 8bit Subject: [nemo] Deadline extended: Journal Special issue on Security Issues in Sensor Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Due to many requests, the submission deadline was extended to Oct. 25 2005 (Our apologies if you receive multiple copies) International Journal of Security and Networks (IJSN), Special Issue on Security Issues in Sensor Networks http://www.cs.memphis.edu/~yxiao/IJSN_Snesor_Security.html -----------------------------------------------------------------------Guest Editors Yang Xiao, The University of Memphis, USA E-mail: yangxiao@ieee.org Xiaohua Jia, City University of Hong Kong, Hong Kong E-mail: csjia@cityu.edu.hk Bo Sun, Lamar University, USA E-mail: bosun99@gmail.com Xiaojiang Du, North Dakota State University, USA E-mail: Xiaojiang.Du@ndsu.edu -----------------------------------------------------------------------Security in Sensor networks differ from those in other traditional networks with many aspects such as limited memory space, limited computation capability, etc. Therefore, sensor network security has some unique features which do not exist in other networks. The need to address security issues, and provide timely, solid technical contributions of security solutions in sensor networks establishes the motivation behind this special issue. This special issue is dedicated to sensor network security. A paper should have security in sensor networks as the focus. Specific areas of interest include, but not limit to: . Key Managements in sensor networks . Secure Routing in secure networks . Light weight Encryption and authentication in Sensor networks . Attacks and solutions in Sensor networks . Other areas which are related to both security and sensor networks. The manuscripts should be submitted as an e-mail attachment in PDF format to Prof. Bo Sun at bosun99@gmail.com. If the file is larger than 1MB, the authors are encouraged to use WINZIP. Furthermore, each author is required to help the review process of the special issue. ----------------------------------------------------------------------- Schedule: Extended deadline: Oct. 25, 2005 Notification: Jan. 15, 2006 Final Paper Submission: Feb. 1, 2005 Publication of special issue: Middle 2006 ----------------------------------------------------------------------- From nemo-bounces@ietf.org Tue Oct 18 03:54:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmIf-0006IM-RZ; Tue, 18 Oct 2005 03:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmId-0006Gj-Gk for nemo@megatron.ietf.org; Tue, 18 Oct 2005 03:54:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11055 for ; Tue, 18 Oct 2005 03:54:11 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmU5-0004OQ-Pn for nemo@ietf.org; Tue, 18 Oct 2005 04:06:12 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j9I89f0G008324; Tue, 18 Oct 2005 01:09:41 -0700 (MST) Received: from [144.189.72.55] (mvp-144-189-72-55.corp.mot.com [144.189.72.55]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9I80c4J008452; Tue, 18 Oct 2005 03:00:39 -0500 (CDT) Message-ID: <4354AA19.90701@motorola.com> Date: Tue, 18 Oct 2005 09:54:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/mixed; boundary="------------020308000808090900020707" X-Spam-Score: 0.0 (/) X-Scan-Signature: 042b0959f295506e650a8ec417043122 Cc: Gopal Dommety , Kent Leung , Narayanan Vidya-CVN065 , Alexandru Petrescu Subject: [nemo] NEMO for IPv4 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --------------020308000808090900020707 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We've just submitted draft-leung-nemov4-base-00.txt and until it shows on the rfc-editor site it could be found at: http://www.mobilenetworks.org/nemo/drafts/draft-leung-nemov4-base-00.txt and attached (we have missed the deadline by a few hours.) Knowing the past list interest in IPv4 NEMO and existing IPv4 NEMO-like implementations we think we need interoperability. The 23 pages of text propose two extensions to Registration Request and Reply to carry Mobile Network Prefixes, the respective MR and HA behaviours and IANA numbers. We would like to target the draft as a WG document at some point. We would like to obtain feedback on the document from the WG members on the mailing list prior to discussion in Vancouver. Alex Network Working Group K. Leung Internet-Draft G. Dommety Expires: April 20, 2006 Cisco Systems V. Narayanan A. Petrescu Motorola October 17, 2005 IPv4 Network Mobility (NEMO) Basic Support Protocol draft-leung-nemov4-base-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may Leung, et al. Expires April 20, 2006 [Page 1] Internet-Draft Mobile Router October 2005 be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 6 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 6 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 7 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 9 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 9 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 11 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 11 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 12 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 12 6.4. Advertising Mobile Network Reachability . . . . . . . . . 13 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 13 6.6. Sending Registration Replies . . . . . . . . . . . . . . . 14 6.7. Mobile Network Prefix De-registration . . . . . . . . . . 14 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 15 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Leung, et al. Expires April 20, 2006 [Page 2] Internet-Draft Mobile Router October 2005 1. Introduction This document describes protocol extensions to Mobile IPv4 ([RFC3344]) to enable support for Mobile Networks. A Mobile Network is defined as a network segment or subnet that can change its point of attachment to the routing infrastructure. Such movement is performed by a Mobile Router, which is the mobility entity that provides connectivity and reachability as well as session continuity for all the nodes in the Mobile Network. The Mobile Router typically serves as the default gateway for the devices on the Mobile Network. Mobility for the Mobile Network is supported by the Mobile Router registering the point of attachment to its Home Agent. This signaling sets up the tunnel between the two entities. The Mobile Networks (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router) are advertised by the Home Agent for route propagation. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from the Mobile Network can be forwarded directly without tunneling when reverse tunneling is not enabled, reachability is still subject to ingress filtering conditions for the path in this case. This document specifies an additional tunnel between Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in Collocated CoA mode, the additional tunnel is not essential and can be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not cover route optimization of this traffic. Multihoming for Mobile Routers is outside of scope of this document. Leung, et al. Expires April 20, 2006 [Page 3] Internet-Draft Mobile Router October 2005 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology for network mobility support is defined in [RFC3344]. In addition, this document defines the following terms. Mobile Network Prefix The network prefix of the subnet delegated to a Mobile Router as the Mobile Network. Prefix Table A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router. Leung, et al. Expires April 20, 2006 [Page 4] Internet-Draft Mobile Router October 2005 3. Requirements Although Mobile IPv4 stated that Mobile Network can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol, there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. The following requirements for Mobile Network support are enumerated: o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the mobile networks through other means, such as from the AAA server or via pre-configuration. o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 without any changes. o The mobile network should allow Fixed nodes, Mobile Nodes, or Mobile Routers to be on it. Leung, et al. Expires April 20, 2006 [Page 5] Internet-Draft Mobile Router October 2005 4. Mobile Network Extensions 4.1. Mobile Network Request Extension For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of ([RFC3344]). When several Mobile Networks are needed to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length and Prefix fields. A Mobile Network Request extension is encoded in Type-Length-Value (TLV) format and respects the following 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 | Length | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 6 Sub-Type: 1 (Mobile Network Request) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. Leung, et al. Expires April 20, 2006 [Page 6] Internet-Draft Mobile Router October 2005 4.2. Mobile Network Acknowledgement Extension The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of ([RFC3344]). For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes served by the Home Agent. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks are needed to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length and Prefix Length fields. Optionally, all requested Mobile Networks could be acknowledged using only one Mobile Network Acknowledgement extension with "Prefix Length" and "Prefix" fields set to zero. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, thereby not skipped by the Home Agent. A Registration Reply may have either or both Implicit Mode Acknowledgement or Explicit Mode Acknowledgement extensions. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format and respects the following format: When the registration is denied with code HA_MOBNET_ERROR, the Code field in the extension provides the reason for the failure. 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 | Length | Sub-Type | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 7 Leung, et al. Expires April 20, 2006 [Page 7] Internet-Draft Mobile Router October 2005 Sub-Type: 2 (Explicit Mode Acknowledgement) 3 (Implicit Mode Acknowledgement) Code: Value indicating success or failure. 0 Success 1 Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 2 MR is not authorized for prefix (MOBNET_UNAUTHORIZED) 3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Reserved: Sent as zero; ignored on reception. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. Leung, et al. Expires April 20, 2006 [Page 8] Internet-Draft Mobile Router October 2005 5. Mobile Router Operation A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in ([RFC3344]). In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router. A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the mobile network will be subject to ingress filtering in the visited networks. Upon reception of successful registration reply, the Mobile Router processes the registration in accordance to RFC 3344. In addition, the following steps are taken: o Check for Mobile Network Acknowledgement extension(s) in Registration Reply o Create tunnel to the Home Agent if registered in reverse tunneling mode o Set up default route via this tunnel or roaming interface when registered with or without reverse tunneling, respectively In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In this latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. A Mobile Router can obtain a Collocated or Foreign Agent Care-of- Address while operating in explicit or implicit modes. For de-registration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions. 5.1. Error Processing A Mobile Router interprets the values of the Code field in Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. If the value of the Code field in the Registration Reply is set to Leung, et al. Expires April 20, 2006 [Page 9] Internet-Draft Mobile Router October 2005 HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent. If the value of the Code field in the Registration Reply is set to HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router. It is possible that the Mobile Router receives a registration reply with no mobile network extensions if the registration was processed by a Mobile IPv4 home agent that does not support this specification at all. In that case, the absence of mobile network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support mobile networks. All the error code values are subject to IANA allocation. Leung, et al. Expires April 20, 2006 [Page 10] Internet-Draft Mobile Router October 2005 6. Home Agent Operation 6.1. Summary A Home Agent MUST support all the operations specified in ([RFC3344]) for mobile node support. The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router. The Home Agent processes the registration in accordance to RFC 3344, which includes route set up to the Mobile Router's home address via the tunnel to the Care-of Address. In addition, for a Mobile Router registering in explicit mode, the following steps are taken: 1. Check that the subnet information is valid 2. Ensure such subnet is authorized to be on the Mobile Router 3. Create tunnel to the Mobile Router if it does not already exist 4. Set up route for the subnets via this tunnel 5. Propagate subnet routes via routing protocol 6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s) If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed. In the case where the Mobile Node is not permitted to act as a Mobile Router, the Home Agent sends a registration denied message with error code HA_MOBNET_DISALLOWED. For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully. For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored. 6.2. Data Structures 6.2.1. Registration Table The registration table in the Home Agent, in accordance with ([RFC3344]), contains binding information for every mobile node Leung, et al. Expires April 20, 2006 [Page 11] Internet-Draft Mobile Router October 2005 registered with it. In addition to all the parameters specified by ([RFC3344]), the home agent MUST store the mobile network prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to mobile network prefixes served by a Mobile Router, this information stored in the registration table can be used. 6.2.2. Prefix Table The Home Agent must be able to authorize a Mobile Router for use of mobile network prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the mobile network prefixes associated with that Mobile Router. The Home Agent may store the home address of the Mobile Router along with the mobile network prefixes associated with that Mobile Router. If the Mobile Router does not have a home address assigned, this table may store the NAI ([RFC2794]) of the Mobile Router that will be used in dynamic home address assignment. 6.3. Mobile Network Prefix Registration The Home Agent must process registration requests coming from Mobile Routers in accordance with this section. ([RFC3344]) specifies that the home address of a mobile node registering with a Home Agent must belong to a prefix advertised on the home network. In accordance with this specification, however, the home address must be configured from a prefix that is served by the Home Agent, not necessarily the one on the home network. If the registration request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the registration request. If so, the Mobile Network Prefix information is obtained from the included extensions. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the check fails or if the Mobile Router is not authorized for using any of those prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. On the other hand, if check passes for every requested Mobile Network Prefix, the Home Agent MUST attempt to set up forwarding for all the Mobile Network Prefixes included in the registration request. If forwarding set up fails for any of the prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_FWDING_SETUP_FAILED. The Home Agent, in this case, MUST NOT forward traffic to any of these prefixes. Note that only the Mobile Network Prefix(es) that failed validation or set up Leung, et al. Expires April 20, 2006 [Page 12] Internet-Draft Mobile Router October 2005 procedure are included in the denied Registration Reply with error code HA_MOBNET_ERROR. If the registration request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre- configured mobile network prefix information for the Mobile Router to set up forwarding. If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the registration table against the prefixes included in the registration request. If one or more mobile network prefix is missing from the included information in the registration request, it MUST delete those prefixes from the registration table. Also, the Home Agent MUST disable forwarding for those prefixes. If all checks are successful, the Home Agent either creates a new entry(ies) for the Mobile Router or updates an existing binding entry(ies) for it and returns a successful registration reply back to the Mobile Router or the Foreign Agent (if the registration request was received from a Foreign Agent). In accordance with ([RFC3344]), the Home Agent does proxy ARP for the Mobile Router home address, when the Mobile Router home address is derived from the home network. If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding mobile network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself. 6.4. Advertising Mobile Network Reachability If the mobile network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to do anything different than normal. The routes for the mobile network prefix are automatically aggregated into the home network prefix. If the Mobile Router updates the mobile network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks. 6.5. Establishment of Bi-directional Tunnel The Home Agent creates and maintains a bi-directional tunnel for the mobile network prefixes of a Mobile Router registered with it. A home agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the mobile network prefixes served by the mobile router to its care-of-address. Also, the Home Agent MUST be Leung, et al. Expires April 20, 2006 [Page 13] Internet-Draft Mobile Router October 2005 able to accept packets tunneled by the Mobile Router with the source address of the outer header is set to the care-of-address of the mobile router and that of the inner header is set to the Mobile Router's home address or an address from one of the registered mobile network prefixes. 6.6. Sending Registration Replies The Home Agents MUST set the status code in the registration reply to 0 to indicate successful processing of the registration request and successful set up of forwarding for all the mobile network prefixes served by the Mobile Router. The registration reply MUST contain at least one Mobile Network Acknowledgement extension. If the Home Agent does not support Mobile Routers, it SHOULD set the status code in the registration reply to HA_MOBNET_UNSUPPORTED. If the Home Agent is unable to set up forwarding for one of more mobile network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status code in the registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than 32, the status code MUST be set to MOBNET_INVALID_PREFIX_LEN. If the Mobile Router is not authorized to forward packets to one or mobile network prefixes included in the request, the Home Agent MUST set the code to MOBNET_UNAUTHORIZED_MR. 6.7. Mobile Network Prefix De-registration If the received registration request is for de-registration of the care-of-address, the Home Agent, upon successful processing of it, MUST delete the entry(ies) from its registration table. The home agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a de-registration request. Leung, et al. Expires April 20, 2006 [Page 14] Internet-Draft Mobile Router October 2005 7. Data Forwarding Operation For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent care-of-address. In this case, the Home Agent MUST encapsulate the packet with tunnel header (source IP address set to Home Agent and destination IP address set to Mobile Router's home address) and then encapsulate one more time with tunnel header (source IP address set to Home Agent and destination IP address set to CoA). For optimization, the Home Agent SHOULD only encapsulate the packet with the tunnel header (source IP address set to Home Agent and destination IP address set to CoA) for Collocated CoA mode. When a Home Agent receives a packet from the mobile network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming packet has the source IP address set to the care-of-address of the Mobile Router. The packet MUST be dropped if the source address is not set to the care-of-address of the Mobile Router. For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with tunnel header (source IP address set to Mobile Router's home address and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router. In Collocated CoA mode, the Mobile Router MAY encapsulate one more time with tunnel header (source IP address set to the CoA and destination IP address set to Home Agent). For optimization, the Mobile Router SHOULD encapsulate the packet only with the tunnel header (source IP address set to CoA and destination IP address set to the Home Agent). Leung, et al. Expires April 20, 2006 [Page 15] Internet-Draft Mobile Router October 2005 8. Nested Mobile Networks Nested Network Mobility is a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But note that this might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. Leung, et al. Expires April 20, 2006 [Page 16] Internet-Draft Mobile Router October 2005 9. Security Considerations The Mobile Network extension is protected by the same rules for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344. The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the registration request, before anchoring these subnets on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. A registration failure MUST be notified to the mobile router when it cannot be successfully authorized for prefixes requested by it. All registration requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in ([RFC3344]). When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value. The Mobile Router should perform ingress filtering on all the packets received on the mobile network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the mobile network. The Mobile Router MUST also ensure that the source address of packets arriving on the mobile network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel. The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's care-of-address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the mobile network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network. If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the mobile network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers. Leung, et al. Expires April 20, 2006 [Page 17] Internet-Draft Mobile Router October 2005 10. IANA Considerations IANA to modify rules for the existing registry "Mobile IPv4 numbers - per RFC 3344". The numbering space for Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434) should be modified. The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following: Value Name ----- ------------------------------------------ 45 Mobile Network Extension (to be assigned by IANA) The new Values and Names for the Sub-Type for Mobile Network Extension are the following: Value Name ----- ------------------------------------------ 1 Mobile Network Request Extension 2 Explicit Mode Acknowledgement Extension 3 Implicit Mode Acknowledgement Extension The new Code values for Mobile IP Registration Reply messages are the following: Code Values for Mobile IP Registration Reply messages ----------------------------------------------------- Registration denied by the Home Agent: (to be assigned by IANA) 143 Mobile Network Prefix operation error (HA_MOBNET_ERROR) 144 MR is not supported on HA (HA_MOBNET_UNSUPPORTED) 145 MR operation is not permitted (HA_MOBNET_DISALLOWED) The new Code Values for Mobile IP Registration Reply messages are the following: Leung, et al. Expires April 20, 2006 [Page 18] Internet-Draft Mobile Router October 2005 Code Values for Mobile Network Acknowledgement Extension ----------------------------------------------------- Registration denied by the Home Agent: 1 Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) 2 MR is not authorized for prefix (MOBNET_UNAUTHORIZED) 3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) The current (non-modified) numbering spaces could be consulted at the following URL: http://www.iana.org/assignments/mobileip-numbers Leung, et al. Expires April 20, 2006 [Page 19] Internet-Draft Mobile Router October 2005 11. Acknowledgements The authors would like to thank Christophe Janneteau, George Popovich, Ty Bekiares, Ganesh Srinivasan and Alpesh Patel for their helpful discussions, reviews and comments. Leung, et al. Expires April 20, 2006 [Page 20] Internet-Draft Mobile Router October 2005 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 12.2. Informative References [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Leung, et al. Expires April 20, 2006 [Page 21] Internet-Draft Mobile Router October 2005 Authors' Addresses Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 Email: kleung@cisco.com Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-525-1404 Email: gdommety@cisco.com Vidya Narayanan Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: vidya@motorola.com Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Leung, et al. Expires April 20, 2006 [Page 22] Internet-Draft Mobile Router October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Leung, et al. Expires April 20, 2006 [Page 23] --------------020308000808090900020707 Content-Type: text/plain; name="draft-leung-nemov4-base-00.txt" Content-Disposition: inline; filename="draft-leung-nemov4-base-00.txt" Content-Transfer-Encoding: 7bit Network Working Group K. Leung Internet-Draft G. Dommety Expires: April 20, 2006 Cisco Systems V. Narayanan A. Petrescu Motorola October 17, 2005 IPv4 Network Mobility (NEMO) Basic Support Protocol draft-leung-nemov4-base-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may Leung, et al. Expires April 20, 2006 [Page 1] Internet-Draft Mobile Router October 2005 be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 6 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 6 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 7 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 9 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 9 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 11 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 11 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 12 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 12 6.4. Advertising Mobile Network Reachability . . . . . . . . . 13 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 13 6.6. Sending Registration Replies . . . . . . . . . . . . . . . 14 6.7. Mobile Network Prefix De-registration . . . . . . . . . . 14 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 15 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Leung, et al. Expires April 20, 2006 [Page 2] Internet-Draft Mobile Router October 2005 1. Introduction This document describes protocol extensions to Mobile IPv4 ([RFC3344]) to enable support for Mobile Networks. A Mobile Network is defined as a network segment or subnet that can change its point of attachment to the routing infrastructure. Such movement is performed by a Mobile Router, which is the mobility entity that provides connectivity and reachability as well as session continuity for all the nodes in the Mobile Network. The Mobile Router typically serves as the default gateway for the devices on the Mobile Network. Mobility for the Mobile Network is supported by the Mobile Router registering the point of attachment to its Home Agent. This signaling sets up the tunnel between the two entities. The Mobile Networks (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router) are advertised by the Home Agent for route propagation. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from the Mobile Network can be forwarded directly without tunneling when reverse tunneling is not enabled, reachability is still subject to ingress filtering conditions for the path in this case. This document specifies an additional tunnel between Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in Collocated CoA mode, the additional tunnel is not essential and can be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not cover route optimization of this traffic. Multihoming for Mobile Routers is outside of scope of this document. Leung, et al. Expires April 20, 2006 [Page 3] Internet-Draft Mobile Router October 2005 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology for network mobility support is defined in [RFC3344]. In addition, this document defines the following terms. Mobile Network Prefix The network prefix of the subnet delegated to a Mobile Router as the Mobile Network. Prefix Table A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router. Leung, et al. Expires April 20, 2006 [Page 4] Internet-Draft Mobile Router October 2005 3. Requirements Although Mobile IPv4 stated that Mobile Network can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol, there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. The following requirements for Mobile Network support are enumerated: o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the mobile networks through other means, such as from the AAA server or via pre-configuration. o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 without any changes. o The mobile network should allow Fixed nodes, Mobile Nodes, or Mobile Routers to be on it. Leung, et al. Expires April 20, 2006 [Page 5] Internet-Draft Mobile Router October 2005 4. Mobile Network Extensions 4.1. Mobile Network Request Extension For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of ([RFC3344]). When several Mobile Networks are needed to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length and Prefix fields. A Mobile Network Request extension is encoded in Type-Length-Value (TLV) format and respects the following 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 | Length | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 6 Sub-Type: 1 (Mobile Network Request) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. Leung, et al. Expires April 20, 2006 [Page 6] Internet-Draft Mobile Router October 2005 4.2. Mobile Network Acknowledgement Extension The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of ([RFC3344]). For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes served by the Home Agent. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks are needed to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length and Prefix Length fields. Optionally, all requested Mobile Networks could be acknowledged using only one Mobile Network Acknowledgement extension with "Prefix Length" and "Prefix" fields set to zero. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, thereby not skipped by the Home Agent. A Registration Reply may have either or both Implicit Mode Acknowledgement or Explicit Mode Acknowledgement extensions. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format and respects the following format: When the registration is denied with code HA_MOBNET_ERROR, the Code field in the extension provides the reason for the failure. 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 | Length | Sub-Type | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 7 Leung, et al. Expires April 20, 2006 [Page 7] Internet-Draft Mobile Router October 2005 Sub-Type: 2 (Explicit Mode Acknowledgement) 3 (Implicit Mode Acknowledgement) Code: Value indicating success or failure. 0 Success 1 Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 2 MR is not authorized for prefix (MOBNET_UNAUTHORIZED) 3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Reserved: Sent as zero; ignored on reception. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. Leung, et al. Expires April 20, 2006 [Page 8] Internet-Draft Mobile Router October 2005 5. Mobile Router Operation A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in ([RFC3344]). In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router. A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the mobile network will be subject to ingress filtering in the visited networks. Upon reception of successful registration reply, the Mobile Router processes the registration in accordance to RFC 3344. In addition, the following steps are taken: o Check for Mobile Network Acknowledgement extension(s) in Registration Reply o Create tunnel to the Home Agent if registered in reverse tunneling mode o Set up default route via this tunnel or roaming interface when registered with or without reverse tunneling, respectively In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In this latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. A Mobile Router can obtain a Collocated or Foreign Agent Care-of- Address while operating in explicit or implicit modes. For de-registration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions. 5.1. Error Processing A Mobile Router interprets the values of the Code field in Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. If the value of the Code field in the Registration Reply is set to Leung, et al. Expires April 20, 2006 [Page 9] Internet-Draft Mobile Router October 2005 HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent. If the value of the Code field in the Registration Reply is set to HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router. It is possible that the Mobile Router receives a registration reply with no mobile network extensions if the registration was processed by a Mobile IPv4 home agent that does not support this specification at all. In that case, the absence of mobile network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support mobile networks. All the error code values are subject to IANA allocation. Leung, et al. Expires April 20, 2006 [Page 10] Internet-Draft Mobile Router October 2005 6. Home Agent Operation 6.1. Summary A Home Agent MUST support all the operations specified in ([RFC3344]) for mobile node support. The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router. The Home Agent processes the registration in accordance to RFC 3344, which includes route set up to the Mobile Router's home address via the tunnel to the Care-of Address. In addition, for a Mobile Router registering in explicit mode, the following steps are taken: 1. Check that the subnet information is valid 2. Ensure such subnet is authorized to be on the Mobile Router 3. Create tunnel to the Mobile Router if it does not already exist 4. Set up route for the subnets via this tunnel 5. Propagate subnet routes via routing protocol 6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s) If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed. In the case where the Mobile Node is not permitted to act as a Mobile Router, the Home Agent sends a registration denied message with error code HA_MOBNET_DISALLOWED. For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully. For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored. 6.2. Data Structures 6.2.1. Registration Table The registration table in the Home Agent, in accordance with ([RFC3344]), contains binding information for every mobile node Leung, et al. Expires April 20, 2006 [Page 11] Internet-Draft Mobile Router October 2005 registered with it. In addition to all the parameters specified by ([RFC3344]), the home agent MUST store the mobile network prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to mobile network prefixes served by a Mobile Router, this information stored in the registration table can be used. 6.2.2. Prefix Table The Home Agent must be able to authorize a Mobile Router for use of mobile network prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the mobile network prefixes associated with that Mobile Router. The Home Agent may store the home address of the Mobile Router along with the mobile network prefixes associated with that Mobile Router. If the Mobile Router does not have a home address assigned, this table may store the NAI ([RFC2794]) of the Mobile Router that will be used in dynamic home address assignment. 6.3. Mobile Network Prefix Registration The Home Agent must process registration requests coming from Mobile Routers in accordance with this section. ([RFC3344]) specifies that the home address of a mobile node registering with a Home Agent must belong to a prefix advertised on the home network. In accordance with this specification, however, the home address must be configured from a prefix that is served by the Home Agent, not necessarily the one on the home network. If the registration request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the registration request. If so, the Mobile Network Prefix information is obtained from the included extensions. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the check fails or if the Mobile Router is not authorized for using any of those prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED. On the other hand, if check passes for every requested Mobile Network Prefix, the Home Agent MUST attempt to set up forwarding for all the Mobile Network Prefixes included in the registration request. If forwarding set up fails for any of the prefixes, the Home Agent MUST reject the registration request with Mobile Network Acknowledgement Extension code MOBNET_FWDING_SETUP_FAILED. The Home Agent, in this case, MUST NOT forward traffic to any of these prefixes. Note that only the Mobile Network Prefix(es) that failed validation or set up Leung, et al. Expires April 20, 2006 [Page 12] Internet-Draft Mobile Router October 2005 procedure are included in the denied Registration Reply with error code HA_MOBNET_ERROR. If the registration request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre- configured mobile network prefix information for the Mobile Router to set up forwarding. If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the registration table against the prefixes included in the registration request. If one or more mobile network prefix is missing from the included information in the registration request, it MUST delete those prefixes from the registration table. Also, the Home Agent MUST disable forwarding for those prefixes. If all checks are successful, the Home Agent either creates a new entry(ies) for the Mobile Router or updates an existing binding entry(ies) for it and returns a successful registration reply back to the Mobile Router or the Foreign Agent (if the registration request was received from a Foreign Agent). In accordance with ([RFC3344]), the Home Agent does proxy ARP for the Mobile Router home address, when the Mobile Router home address is derived from the home network. If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding mobile network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself. 6.4. Advertising Mobile Network Reachability If the mobile network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to do anything different than normal. The routes for the mobile network prefix are automatically aggregated into the home network prefix. If the Mobile Router updates the mobile network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks. 6.5. Establishment of Bi-directional Tunnel The Home Agent creates and maintains a bi-directional tunnel for the mobile network prefixes of a Mobile Router registered with it. A home agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the mobile network prefixes served by the mobile router to its care-of-address. Also, the Home Agent MUST be Leung, et al. Expires April 20, 2006 [Page 13] Internet-Draft Mobile Router October 2005 able to accept packets tunneled by the Mobile Router with the source address of the outer header is set to the care-of-address of the mobile router and that of the inner header is set to the Mobile Router's home address or an address from one of the registered mobile network prefixes. 6.6. Sending Registration Replies The Home Agents MUST set the status code in the registration reply to 0 to indicate successful processing of the registration request and successful set up of forwarding for all the mobile network prefixes served by the Mobile Router. The registration reply MUST contain at least one Mobile Network Acknowledgement extension. If the Home Agent does not support Mobile Routers, it SHOULD set the status code in the registration reply to HA_MOBNET_UNSUPPORTED. If the Home Agent is unable to set up forwarding for one of more mobile network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status code in the registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than 32, the status code MUST be set to MOBNET_INVALID_PREFIX_LEN. If the Mobile Router is not authorized to forward packets to one or mobile network prefixes included in the request, the Home Agent MUST set the code to MOBNET_UNAUTHORIZED_MR. 6.7. Mobile Network Prefix De-registration If the received registration request is for de-registration of the care-of-address, the Home Agent, upon successful processing of it, MUST delete the entry(ies) from its registration table. The home agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a de-registration request. Leung, et al. Expires April 20, 2006 [Page 14] Internet-Draft Mobile Router October 2005 7. Data Forwarding Operation For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent care-of-address. In this case, the Home Agent MUST encapsulate the packet with tunnel header (source IP address set to Home Agent and destination IP address set to Mobile Router's home address) and then encapsulate one more time with tunnel header (source IP address set to Home Agent and destination IP address set to CoA). For optimization, the Home Agent SHOULD only encapsulate the packet with the tunnel header (source IP address set to Home Agent and destination IP address set to CoA) for Collocated CoA mode. When a Home Agent receives a packet from the mobile network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming packet has the source IP address set to the care-of-address of the Mobile Router. The packet MUST be dropped if the source address is not set to the care-of-address of the Mobile Router. For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with tunnel header (source IP address set to Mobile Router's home address and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router. In Collocated CoA mode, the Mobile Router MAY encapsulate one more time with tunnel header (source IP address set to the CoA and destination IP address set to Home Agent). For optimization, the Mobile Router SHOULD encapsulate the packet only with the tunnel header (source IP address set to CoA and destination IP address set to the Home Agent). Leung, et al. Expires April 20, 2006 [Page 15] Internet-Draft Mobile Router October 2005 8. Nested Mobile Networks Nested Network Mobility is a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But note that this might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. Leung, et al. Expires April 20, 2006 [Page 16] Internet-Draft Mobile Router October 2005 9. Security Considerations The Mobile Network extension is protected by the same rules for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344. The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the registration request, before anchoring these subnets on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. A registration failure MUST be notified to the mobile router when it cannot be successfully authorized for prefixes requested by it. All registration requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in ([RFC3344]). When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value. The Mobile Router should perform ingress filtering on all the packets received on the mobile network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the mobile network. The Mobile Router MUST also ensure that the source address of packets arriving on the mobile network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel. The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's care-of-address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the mobile network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network. If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the mobile network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers. Leung, et al. Expires April 20, 2006 [Page 17] Internet-Draft Mobile Router October 2005 10. IANA Considerations IANA to modify rules for the existing registry "Mobile IPv4 numbers - per RFC 3344". The numbering space for Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434) should be modified. The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following: Value Name ----- ------------------------------------------ 45 Mobile Network Extension (to be assigned by IANA) The new Values and Names for the Sub-Type for Mobile Network Extension are the following: Value Name ----- ------------------------------------------ 1 Mobile Network Request Extension 2 Explicit Mode Acknowledgement Extension 3 Implicit Mode Acknowledgement Extension The new Code values for Mobile IP Registration Reply messages are the following: Code Values for Mobile IP Registration Reply messages ----------------------------------------------------- Registration denied by the Home Agent: (to be assigned by IANA) 143 Mobile Network Prefix operation error (HA_MOBNET_ERROR) 144 MR is not supported on HA (HA_MOBNET_UNSUPPORTED) 145 MR operation is not permitted (HA_MOBNET_DISALLOWED) The new Code Values for Mobile IP Registration Reply messages are the following: Leung, et al. Expires April 20, 2006 [Page 18] Internet-Draft Mobile Router October 2005 Code Values for Mobile Network Acknowledgement Extension ----------------------------------------------------- Registration denied by the Home Agent: 1 Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) 2 MR is not authorized for prefix (MOBNET_UNAUTHORIZED) 3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) The current (non-modified) numbering spaces could be consulted at the following URL: http://www.iana.org/assignments/mobileip-numbers Leung, et al. Expires April 20, 2006 [Page 19] Internet-Draft Mobile Router October 2005 11. Acknowledgements The authors would like to thank Christophe Janneteau, George Popovich, Ty Bekiares, Ganesh Srinivasan and Alpesh Patel for their helpful discussions, reviews and comments. Leung, et al. Expires April 20, 2006 [Page 20] Internet-Draft Mobile Router October 2005 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 12.2. Informative References [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Leung, et al. Expires April 20, 2006 [Page 21] Internet-Draft Mobile Router October 2005 Authors' Addresses Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 Email: kleung@cisco.com Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-525-1404 Email: gdommety@cisco.com Vidya Narayanan Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: vidya@motorola.com Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Leung, et al. Expires April 20, 2006 [Page 22] Internet-Draft Mobile Router October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Leung, et al. Expires April 20, 2006 [Page 23] --------------020308000808090900020707-- From nemo-bounces@ietf.org Tue Oct 18 23:49:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES4xZ-0000RS-DJ; Tue, 18 Oct 2005 23:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES4xX-0000RN-HE for nemo@megatron.ietf.org; Tue, 18 Oct 2005 23:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17578 for ; Tue, 18 Oct 2005 23:49:39 -0400 (EDT) Received: from mail.hongo.wide.ad.jp ([203.178.135.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES59A-0005DP-ME for nemo@ietf.org; Wed, 19 Oct 2005 00:01:51 -0400 Received: from [127.0.0.1] (unknown [IPv6:2001:200:0:1cd1::2]) by mail.hongo.wide.ad.jp (Postfix) with ESMTP id 2061012B64 for ; Wed, 19 Oct 2005 12:49:18 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: Guillaume Valadon Date: Wed, 19 Oct 2005 12:49:17 +0900 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [nemo] Typo in RFC3963 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Tittles of section 7.1 and 7.2 (HAAD Request and Reply) are buggy: In TOC: 7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20 7.2. Modified Dynamic Home Agent Discovery Address Request . 20 In document body: 7.1. Modified Dynamic Home Agent Discovery Address Request 7.2. Modified Dynamic Home Agent Discovery Address Request Texts following these titles are OK. Guillaume From nemo-bounces@ietf.org Wed Oct 19 21:17:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESP3G-0003UY-I8; Wed, 19 Oct 2005 21:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESP3E-0003UT-Vr for nemo@megatron.ietf.org; Wed, 19 Oct 2005 21:17:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01071 for ; Wed, 19 Oct 2005 21:16:46 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESPEv-0002Zv-Um for nemo@ietf.org; Wed, 19 Oct 2005 21:29:11 -0400 Received: from [192.168.11.3] (c246.230.c3-net.ne.jp [219.124.246.230]) by mail.sfc.wide.ad.jp (Postfix) with SMTP id 3C47A4C6B7; Thu, 20 Oct 2005 10:16:17 +0900 (JST) Date: Thu, 20 Oct 2005 10:16:17 +0900 From: Manabu Tsukada To: nemo@ietf.org Message-Id: <20051020100158.EE01.TU-KA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: kuntz@sfc.wide.ad.jp, tu-ka@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp Subject: [nemo] New draft submitted: draft-tsukada-nemo-mr-cooperation-analysis-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted a new draft about MRs cooperation analysis. The aim of this document is to investigate issues and requirements for MRs cooperation to get benefits of multihoming. Any feedback is of course welcome. A URL for this Internet-Draft is: http://www.nautilus6.org/doc/drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.txt Title : Analysis of Multiple Mobile Routers Cooperation Author(s) : M. Tsukada, R. Kuntz and T. Ernst Filename : draft-tsukada-nemo-mr-cooperation-analysis-00.txt Pages : 19 Date : 2005-10-17 Abstract: This document is an analysis of multiple Mobile Routers Cooperation in the context of network mobility support (NEMO) in IPv6. Our objective is to identify when cooperation between MRs is needed and what information must be exchanged. Best Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Keio University Murai Laboratory Manabu Tsukada =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From nemo-bounces@ietf.org Thu Oct 20 02:26:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTsz-0007fN-G6; Thu, 20 Oct 2005 02:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTsx-0007f4-4x for nemo@megatron.ietf.org; Thu, 20 Oct 2005 02:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14783 for ; Thu, 20 Oct 2005 02:26:33 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESU4o-0002Jf-AW for nemo@ietf.org; Thu, 20 Oct 2005 02:39:00 -0400 Received: from mmlabsmbaek ([147.46.216.64]) by mmlab.snu.ac.kr (8.13.5/8.12.10) with ESMTP id j9K6Sqwg077846 for ; Thu, 20 Oct 2005 15:28:52 +0900 (KST) (envelope-from smbaek@mmlab.snu.ac.kr) Message-Id: <200510200628.j9K6Sqwg077846@mmlab.snu.ac.kr> From: "sungmin baek" To: Subject: [nemo] New draft submitted : draft-baek-nemo-nested-ro-00.txt Date: Thu, 20 Oct 2005 15:26:21 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C5D58A.A2EDBE20" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXVPy/RVSsc0qzLRU+hynsG5nFs7w== X-Spam-Score: 0.3 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C5D58A.A2EDBE20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, My name is Sungmin Baek, a master student at Seoul National University. I co-worked a new Internet draft with professor Kwon and other people. It is about Routing Optimization Protocol for NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baek-nemo-nested-ro-00.txt Any questions and comments welcome. Title : Routing Optimization in the same nested mobile network Author(s) : S. Baek, et al. Filename : draft-baek-nemo-nested-ro-00.txt Pages : 12 Date : 2005-10-19 This document describes a nested NEMO Route Optimization (NNRO) protocol for the communications between any two nodes in the same nested mobile network. A nested NEMO Route Optimization message is used to exchange the routing information between two mobile network nodes in the same nested mobile network. The protocol is designed in a way such that the mobility of the entire nested mobile network is transparent to the nodes therein. Thanks, Baek. ------=_NextPart_000_0016_01C5D58A.A2EDBE20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

My name is = Sungmin Baek, a master student at Seoul National University.

I co-worked a = new Internet draft with professor Kwon and other = people.

It is about = Routing Optimization Protocol for NEMO.

 

A URL for this Internet-Draft =
is:
http://www.ietf.org/internet-drafts/draft-baek-nemo-nested-ro-00.txt=

 

Any questions = and comments welcome.

 

         =
      =
Title           &n=
bsp;            : =
Routing Optimization in the same nested mobile =
network
         =
      Author(s) : S. Baek, et =
al.
         =
      Filename : =
draft-baek-nemo-nested-ro-00.txt
         =
      =
Pages           &n=
bsp;        : =
12
         =
      =
Date           &nb=
sp;            : =
2005-10-19
         =
      
   This document describes a nested NEMO =
Route Optimization (NNRO)
   protocol for the communications between =
any two nodes in the same
   nested mobile network.  A nested =
NEMO Route Optimization message =
is
   used to exchange the routing information =
between two mobile network
   nodes in the same nested mobile =
network.  The protocol is designed =
in
   a way such that the mobility of the =
entire nested mobile network is
   transparent to the nodes =
therein.

 

Thanks,

Baek.

 

------=_NextPart_000_0016_01C5D58A.A2EDBE20-- From nemo-bounces@ietf.org Thu Oct 20 17:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiCg-0007EG-Qz; Thu, 20 Oct 2005 17:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiCf-0007DT-4k for nemo@megatron.ietf.org; Thu, 20 Oct 2005 17:44:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15661 for ; Thu, 20 Oct 2005 17:43:46 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESi8A-0003jY-AQ for nemo@ietf.org; Thu, 20 Oct 2005 17:39:23 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9KLcRpK025992; Thu, 20 Oct 2005 14:38:27 -0700 (MST) Received: from [144.189.72.157] (mvp-144-189-72-157.corp.mot.com [144.189.72.157]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9KLYTIa011100; Thu, 20 Oct 2005 16:34:30 -0500 (CDT) Message-ID: <43580B8C.8010307@motorola.com> Date: Thu, 20 Oct 2005 23:26:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Guillaume Valadon Subject: Re: [nemo] Typo in RFC3963 References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Guillaume, thank you for posting this. This is an unfortunate error which slipped in after many many reviews, and the authors are aware of it. I think the first co-author maintains somehow a list of issues that have been mentioned publicly. If you have any other remarks about 3963 that may have shown up during implementation, please post. We also have some remarks that have been exposed during implementation and experimentation. Alex Guillaume Valadon wrote: > Hi, > > Tittles of section 7.1 and 7.2 (HAAD Request and Reply) are buggy: > > In TOC: > 7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20 > 7.2. Modified Dynamic Home Agent Discovery Address Request . 20 > > In document body: > 7.1. Modified Dynamic Home Agent Discovery Address Request > 7.2. Modified Dynamic Home Agent Discovery Address Request > > Texts following these titles are OK. > > Guillaume From nemo-bounces@ietf.org Thu Oct 20 21:26:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESlgN-0005Ho-5D; Thu, 20 Oct 2005 21:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESlgL-0005HZ-Nd for nemo@megatron.ietf.org; Thu, 20 Oct 2005 21:26:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15253 for ; Thu, 20 Oct 2005 21:26:43 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESlsN-0002ON-Ja for nemo@ietf.org; Thu, 20 Oct 2005 21:39:21 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 62AFE4C6B7; Fri, 21 Oct 2005 10:26:23 +0900 (JST) Date: Fri, 21 Oct 2005 10:26:24 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: tj Subject: [nemo] Preparing NEMO Slot for Vancouver X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, The NEMO WG will meet at Vancouver for a 2 hours session. In Paris, we mentioned about rechartering the WG, so I think this will be one of the important discussion: how are we So, the main topics will be: 1. status of WG documents 2. RO PB Statement 3. RO issues we should work on, and where 4. Multihoming: what issues we should work on, and where 5. Rechartering (mainly based on point 3 & 4) If you intend to obtain a slot to discuss one of the above topics (particularly the status of WG doc) or other topics please send your request to TJ and myself, indicating:- name of speaker - title of presentation - associated draft (if any, and preferably) - length - purpose - what is the relation with current NEMO activities Please send your requests by Oct 28th. Requests will be honored based on: - relevance with the priorities of the WG - active discussion on the mailing list TJ & Thierry From nemo-bounces@ietf.org Fri Oct 21 10:20:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxko-0004Cp-E9; Fri, 21 Oct 2005 10:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxkl-0004Ck-FL for nemo@megatron.ietf.org; Fri, 21 Oct 2005 10:20:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24220 for ; Fri, 21 Oct 2005 10:20:03 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxwu-0002kr-NN for nemo@ietf.org; Fri, 21 Oct 2005 10:32:49 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9LEVuWK023211; Fri, 21 Oct 2005 07:31:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9LERwTB022014; Fri, 21 Oct 2005 09:27:59 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4B124865980; Fri, 21 Oct 2005 16:20:05 +0200 (CEST) Message-ID: <4358F915.1070508@motorola.com> Date: Fri, 21 Oct 2005 16:20:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: Denis Ortega Subject: [nemo] Implemetor's comments on RFC3963 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, Here are some remarks that came up while implementing RFC3963 MR and HA on laptops over iWiFi. page 12, last par: > If the Binding Acknowledgement from the Home Agent has the status > 140, the Mobile Router SHOULD send a Binding Update to another Home > Agent on the same home link. But how could the MR know another HA? The only way to build the HA list is currently with DHAAD. Per rfc3775 DHAAD is not mandatory to happen, and the bootstrapping procedure is not yet fixed. In addition, even if the MR learns a list of HAs by some other means (like manual configuration), the MR should probably not send a BU to another HA which only supports MHs. So I suggest to relax the SHOULD from above to a MAY, and probably later make it a MUST. Additionally, I suggest to send the BU to another HA that supports Mobile Routers (not just any HA). page 14, 1st par: > However, the Mobile > Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface, for addresses valid > on the visited link. It was not immediately obvious what a "valid address on the visited link" is, terminology of "valid address on a link" is not yet widely used by the non-IETF. So it would be good to shortly explain the "valid address". For example, "for addresses derived from that link's prefix, that do not risk being ingress filtered by that link's router" or similar. page 15, last bullet, and over to page 16: > - If a Mobile Network Prefix Option is present in the Binding > Update, the prefix information for the Mobile Network Prefix is > retrieved from the Mobile Network Prefix field and the Prefix > Length field of the option. If the Binding Update contains more > than one option, the Home Agent MUST set up forwarding for all the > Mobile Network Prefixes. If the Home Agent fails to set up > forwarding to all the prefixes listed in the Binding Update, then > it MUST NOT forward traffic to any of the prefixes. Furthermore, > it MUST reject the Binding Update and send a Binding > Acknowledgement with status set to 141 (Invalid Prefix). > > If the Home Agent verifies the prefix information with the Prefix > Table and the check fails, the Home Agent MUST discard the Binding > Update and send a Binding Acknowledgement with status set to 142 > (Not Authorized for Prefix). Security-wise, the implementation order of verification would put the last par before the middle of the first par: the HA first checks the MNP against the Prefix Table and only then it tries to set up forwarding. So I suggest re-writing these two paragraphs as: "If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the Mobile Network Prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Home Agent verifies the prefix information with the Prefix Table and the check fails, the Home Agent MUST discard the Binding Update and send a Binding Acknowledgement with status set to 142 (Not Authorized for Prefix). This verification should happen for all Mobile Network Prefixes present in that Binding Update and if any one fails then send status 142 (Not Authorized for Prefix). If all Mobile Network Prefixes verifications against the Prefix Table are successfull, the Home Agent MUST set up forwarding for all the Mobile Network Prefixes. If the Home Agent fails to set up for at least one prefixe listed in the Binding Update, then it MUST NOT forward traffic to any of the prefixes. Furthermore, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix)." The detail explanation of how the search in the Prefix Table could help too, especially since we count on the Prefix Table as a security measure. -would HA check the HoA for every entry's HoA field and then match the MNP in the BU against that entry's MNP field? -or would it first check the MNP and then the HoA? -what's a successfull check. page 16, 2nd bullet: > - If there is no option in the Binding Update carrying prefix > information, the Home Agent uses manual pre-configured information > to determine the prefixes assigned to the Mobile Router and to set > up forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update and > send a Binding Acknowledgement with status set to 143 (Forwarding > Setup failed). It was not immediately obvious what "manual pre-configured information" represents. Maybe it would be clearer to just say "routing table" instead of explaining "manual pre-configured information". If we are specific about that being a "routing table" then further explanation in the same paragraph is also easier. Because, there was another thing not immediately clear: how would the HA "use" that "manual pre-configured information"? What would HA use as a key to search that information? Fixed-match or longest-prefix match? What would be a successful search? If we say it's a "routing table" then we can also simply say that the HA "checks the HoA from the BU against every GW field of the routing table, and when a match is found the corresponding prefix field of the table is used as a substitute for the MNP that would have come from the BU", or similar. Otherwise it's not clear at all how that "use of manual pre-configured information" should be implemented. page 20, last par: > A new flag (R) (Support for Mobile Routers) is introduced in the > DHAAD Reply message, defined in [1]. If a Home Agent receives a > Dynamic Home Agent Discovery request message with the Mobile Router > Support Flag set, it MUST reply with a list of Home Agents supporting > Mobile Routers. The Mobile Router Support Flag MUST be set if there > is at least one Home Agent supporting Mobile Routers. If none of the > Home Agents support Mobile Routers, the Home Agent MAY reply with a > list of Home Agents that only support Mobile IPv6 Mobile Nodes. In > this case, the Mobile Router Support Flag MUST be set to 0. Again on terminology of "Mobile Nodes". What we want to achieve with the above par is that if there's no HA supporting MRs then the HA should reply with a list of HAs that only support Mobile Hosts. So I suggest substitute Mobile Hosts for Mobile Nodes in the paragraph above. (at several places throughout 3963 we made good distinction Mobile Host - Mobile Router and avoided "Mobile Node"). page 21, the message 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 | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identifier |R| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It would be convenient if that wide field after "Reserved" would have a textual description pasted on it, about its contents. Otherwise and implementor has to dig it in rfc3775. That's all we have up to now, and all other preceding text was easily understood and we have it implemented and tested, we're happy with that. Alex From nemo-bounces@ietf.org Fri Oct 21 12:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESza5-0000Y6-H3; Fri, 21 Oct 2005 12:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESza3-0000QZ-Dp for nemo@megatron.ietf.org; Fri, 21 Oct 2005 12:17:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16298 for ; Fri, 21 Oct 2005 12:17:02 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzm7-0004Df-Kq for nemo@ietf.org; Fri, 21 Oct 2005 12:29:48 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9LGSpNe016711; Fri, 21 Oct 2005 09:28:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9LGOtGf011252; Fri, 21 Oct 2005 11:24:55 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DC1D4865980; Fri, 21 Oct 2005 18:17:00 +0200 (CEST) Message-ID: <4359147C.2050008@motorola.com> Date: Fri, 21 Oct 2005 18:17:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst , tj Subject: Re: [nemo] Preparing NEMO Slot for Vancouver References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> In-Reply-To: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Gopal Dommety , Kent Leung , Narayanan Vidya-CVN065 , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: >> If you intend to obtain a slot to discuss one of the above topics >> (particularly the status of WG doc) or other topics please send your >> request to TJ and myself, indicating:- name of speaker - title of >> presentation - associated draft (if any, and preferably) - length - >> purpose - what is the relation with current NEMO activities Hello, we'd like to request a 10min slot for presenting IPv4 NEMO. name of speaker: either Alex Petrescu or Kent Leung title: NEMO Basic Support for IPv4 assc'd draft: draft-leung-nemov4-base-00.txt http://www.ietf.org/internet-drafts/draft-leung-nemov4-base-00.txt length: 10min purpose: Present Mobile IPv4 extensions to support IPv4 Mobile Routers. relation with NEMO activities: the draft is just about basic support for NEMO (direct relationship with Network Mobility). Alex From nemo-bounces@ietf.org Fri Oct 21 12:55:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0Ah-00087u-Pg; Fri, 21 Oct 2005 12:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0Ae-000856-QU for nemo@megatron.ietf.org; Fri, 21 Oct 2005 12:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18493 for ; Fri, 21 Oct 2005 12:54:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET0Mp-0005el-24 for nemo@ietf.org; Fri, 21 Oct 2005 13:07:44 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9LGsYH25444; Fri, 21 Oct 2005 18:54:34 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9LGsYjL060360; Fri, 21 Oct 2005 18:54:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510211654.j9LGsYjL060360@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [nemo] Preparing NEMO Slot for Vancouver In-reply-to: Your message of Fri, 21 Oct 2005 18:17:00 +0200. <4359147C.2050008@motorola.com> Date: Fri, 21 Oct 2005 18:54:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ml-nemo , Gopal Dommety , tj , Narayanan Vidya-CVN065 , Thierry Ernst , Kent Leung X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: Hello, we'd like to request a 10min slot for presenting IPv4 NEMO. => two questions: - I believe that Mobile IPv4 already includes support for mobile routers (this is what is written in the specs and in my Mobility books) - is IPv4 in the scope? (I've just look at the charter: it is) Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Fri Oct 21 13:02:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0HP-00024M-UB; Fri, 21 Oct 2005 13:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0HN-00024G-25 for nemo@megatron.ietf.org; Fri, 21 Oct 2005 13:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18764 for ; Fri, 21 Oct 2005 13:01:53 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET0TP-0005rt-Vn for nemo@ietf.org; Fri, 21 Oct 2005 13:14:40 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9LHDgAp023937 for ; Fri, 21 Oct 2005 10:13:42 -0700 (MST) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9LHAwkl021788 for ; Fri, 21 Oct 2005 12:10:58 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Preparing NEMO Slot for Vancouver Date: Fri, 21 Oct 2005 13:01:50 -0400 Message-ID: <0B40B6F9CB990B428819561A2A55613A1038A7@de01exm69.ds.mot.com> Thread-Topic: [nemo] Preparing NEMO Slot for Vancouver Thread-Index: AcXWYC5Pl7tlVXaLSb+Ers2n2yHX1AAAJk7Q From: "Narayanan Vidya-CVN065" To: , "Petrescu Alexandru-AAP021" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: ml-nemo , Gopal Dommety , Thierry Ernst , tj , Kent Leung X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Francis, >=20 > In your previous mail you wrote: >=20 > Hello, we'd like to request a 10min slot for presenting IPv4 NEMO. > =20 > =3D> two questions: > - I believe that Mobile IPv4 already includes support for=20 > mobile routers > (this is what is written in the specs and in my Mobility books) RFC3344 contains a short mention of mobile routers, but it does not define any extensions to the registration request to do prefix binding explicitly with the HA. Also, it does not specify any details on how the prefixes are maintained and managed by the HA, etc. This is required for basic support and interoperability.=20 > - is IPv4 in the scope? (I've just look at the charter: it is) I guess you've answered that question :) The charter never excluded v4 - just that no one had done it so far.=20 Regards, Vidya From nemo-bounces@ietf.org Fri Oct 21 19:12:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET645-00018F-M2; Fri, 21 Oct 2005 19:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET644-000174-4t for nemo@megatron.ietf.org; Fri, 21 Oct 2005 19:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29361 for ; Fri, 21 Oct 2005 19:12:30 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET6G0-0003jt-Rj for nemo@ietf.org; Fri, 21 Oct 2005 19:25:21 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 2AF1F8AD12D; Fri, 21 Oct 2005 16:11:35 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87562-01; Fri, 21 Oct 2005 16:11:27 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 7E3768AD12C; Fri, 21 Oct 2005 16:11:27 -0700 (PDT) X-Spam-Score: -2.9 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.103.16.119] (unknown [192.103.16.119]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 0B03F8AB9DD; Fri, 21 Oct 2005 16:11:27 -0700 (PDT) In-Reply-To: <200510211654.j9LGsYjL060360@givry.rennes.enst-bretagne.fr> References: <200510211654.j9LGsYjL060360@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Preparing NEMO Slot for Vancouver Date: Fri, 21 Oct 2005 16:12:00 -0700 To: ml-nemo X-Mailer: Apple Mail (2.734) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Gopal Dommety X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Oct 21, 2005, at 9:54 AM, Francis Dupont wrote: > - is IPv4 in the scope? (I've just look at the charter: it is) Yes, IPv4 was explicitly included, since there was interest shown, back when the charter was written, to work on a v4 version of the spec. We purposefully started out the basic support spec in a manner so it should be easy to port to v4, though that's not what ended up happening. In fact, nothing really happened since then, till now. Which is good timing for the authors of this draft, since we are in the middle of rewriting the charter. It remains to be seen what the interest level of the overall working group is for creating a v4 solution and the associated documents that would be necessary, and that's what we need to discuss on this list (and in the IETF meeting, if the topic appears on the agenda). The key components, in my personal view, would be a core group of some people willing to work on all of the documents, and the consensus of the WG (and ADs, etc) that it's something that we want to keep in the charter and it's proceeding in a reasonable way. TJ From nemo-bounces@ietf.org Sat Oct 22 02:25:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCoM-000123-E6; Sat, 22 Oct 2005 02:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCo5-00010Z-84 for nemo@megatron.ietf.org; Sat, 22 Oct 2005 02:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21248 for ; Sat, 22 Oct 2005 02:24:30 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETD0H-0001fz-SC for nemo@ietf.org; Sat, 22 Oct 2005 02:37:23 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j9M6dVa1010781 for ; Fri, 21 Oct 2005 23:39:31 -0700 (MST) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9M6V9L5007316 for ; Sat, 22 Oct 2005 01:31:10 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Preparing NEMO Slot for Vancouver Date: Sat, 22 Oct 2005 02:24:25 -0400 Message-ID: <0B40B6F9CB990B428819561A2A55613A103A3A@de01exm69.ds.mot.com> Thread-Topic: [nemo] Preparing NEMO Slot for Vancouver Thread-Index: AcXWlWPJVCK/73nOQqqiZRgj3PI/WwAOyQEg From: "Narayanan Vidya-CVN065" To: "T.J. Kniveton" , "ml-nemo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Gopal Dommety X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org TJ, > The key components, in my=20 > personal view, would be a core group of some people willing=20 > to work on all of the documents, and the consensus of the WG=20 > (and ADs, etc) that it's something that we want to keep in=20 > the charter and it's proceeding in a reasonable way. >=20 What do you mean by "all of the documents"? If there is consensus to work on basic support, without having to address other topics that are not required for basic support, is that not (minimally) enough?=20 Vidya From nemo-bounces@ietf.org Sat Oct 22 07:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETH7Q-00088G-Iz; Sat, 22 Oct 2005 07:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETH7O-000888-KQ for nemo@megatron.ietf.org; Sat, 22 Oct 2005 07:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02630 for ; Sat, 22 Oct 2005 07:00:42 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETHJg-00027M-Ak for nemo@ietf.org; Sat, 22 Oct 2005 07:13:39 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j9MB0iTD017079; Sat, 22 Oct 2005 04:00:44 -0700 (MST) Received: from [144.189.72.65] (mvp-144-189-72-65.corp.mot.com [144.189.72.65]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9MB7xWt014412; Sat, 22 Oct 2005 06:08:00 -0500 (CDT) Message-ID: <435A1BD6.7010104@motorola.com> Date: Sat, 22 Oct 2005 13:00:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] Preparing NEMO Slot for Vancouver References: <200510211654.j9LGsYjL060360@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510211654.j9LGsYjL060360@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Gopal Dommety , tj , Narayanan Vidya-CVN065 , Alexandru Petrescu , Thierry Ernst , Kent Leung X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > Hello, we'd like to request a 10min slot for presenting IPv4 NEMO. > > => two questions: - I believe that Mobile IPv4 already includes > support for mobile routers (this is what is written in the specs and > in my Mobility books) Right, the 3344 (Mobile IPv4) gives principles, scenarios and some mechanisms for Mobile Routers support. However it lacks means to encode transportation of MNPs in the Registration Requests which led to some implementors encode that in some unspecified way. Which is why we try to propose a common behaviour. > - is IPv4 in the scope? (I've just look at the charter: it is) Right, in addition to IPv4 being in the Charter, the mip6trans DT looking at running NEMOv6 over a v4 access network has recently discussed giving also v4 access to MNNs, when connected to a v4 access network. Which is a natural application for NEMOv4. Do you think IPv4 would not be in scope? Alex From nemo-bounces@ietf.org Mon Oct 24 17:04:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU9US-0000B0-JW; Mon, 24 Oct 2005 17:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU9UR-0000As-3r for nemo@megatron.ietf.org; Mon, 24 Oct 2005 17:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20433 for ; Mon, 24 Oct 2005 17:04:04 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU9hA-00082S-97 for nemo@ietf.org; Mon, 24 Oct 2005 17:17:34 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 809168AB98D; Mon, 24 Oct 2005 14:03:14 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16576-14; Mon, 24 Oct 2005 14:03:06 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id D2CBC8AD139; Mon, 24 Oct 2005 14:03:06 -0700 (PDT) X-Spam-Score: -3.5 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.103.16.119] (unknown [192.103.16.119]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id A87378ABA39; Mon, 24 Oct 2005 14:02:57 -0700 (PDT) In-Reply-To: <0B40B6F9CB990B428819561A2A55613A103A3A@de01exm69.ds.mot.com> References: <0B40B6F9CB990B428819561A2A55613A103A3A@de01exm69.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Preparing NEMO Slot for Vancouver Date: Mon, 24 Oct 2005 14:03:44 -0700 To: Narayanan Vidya-CVN065 X-Mailer: Apple Mail (2.734) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Gopal Dommety X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org There would be additional documents. Take a look at the NEMO home page and count the documents. There are many drafts there related to NEMO (v6), and accordingly, there would be more than one v4 document. MIB, network models, security, ... whatever is needed to describe how support works in a fully-baked way. Many of the documents could be shared, so you wouldn't have to repeat existing work, but some of them don't translate to v4. TJ On Oct 21, 2005, at 11:24 PM, Narayanan Vidya-CVN065 wrote: > TJ, > > >> The key components, in my >> personal view, would be a core group of some people willing >> to work on all of the documents, and the consensus of the WG >> (and ADs, etc) that it's something that we want to keep in >> the charter and it's proceeding in a reasonable way. >> >> > > What do you mean by "all of the documents"? If there is consensus to > work on basic support, without having to address other topics that are > not required for basic support, is that not (minimally) enough? > > Vidya > > From nemo-bounces@ietf.org Mon Oct 24 22:37:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEhA-0000PG-2j; Mon, 24 Oct 2005 22:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEh8-0000P3-Ff for nemo@megatron.ietf.org; Mon, 24 Oct 2005 22:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12205 for ; Mon, 24 Oct 2005 22:37:30 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUEtv-0001fD-Gd for nemo@ietf.org; Mon, 24 Oct 2005 22:51:04 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9P2nQJY009212 for ; Mon, 24 Oct 2005 19:49:26 -0700 (MST) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9P2kA6W024228 for ; Mon, 24 Oct 2005 21:46:10 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Preparing NEMO Slot for Vancouver Date: Mon, 24 Oct 2005 22:37:31 -0400 Message-ID: <0B40B6F9CB990B428819561A2A55613A103E8F@de01exm69.ds.mot.com> Thread-Topic: [nemo] Preparing NEMO Slot for Vancouver Thread-Index: AcXY3nja+DlJ6KT5Spi1lj4eOI/emQALWRLg From: "Narayanan Vidya-CVN065" To: "T.J. Kniveton" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: ml-nemo , Gopal Dommety X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Among the list of documents on the NEMO page, the only document I can see being applicable to having v4 basic support interoperability is perhaps the MIB document. Debatably, the home network models may apply. But then, a lot can be leveraged from the v6 document for that.=20 Other than that, RO, prefix delegation, etc. are all topics that aren't essential to basic support of the protocol itself. RO doesn't even apply to v4 (given that mip4 doesn't have RO, it doesn't make much sense to talk about RO for nemov4).=20 Am I missing something else that you have in mind?=20 Vidya > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com]=20 > Sent: Monday, October 24, 2005 4:04 PM > To: Narayanan Vidya-CVN065 > Cc: ml-nemo; Gopal Dommety > Subject: Re: [nemo] Preparing NEMO Slot for Vancouver=20 >=20 > There would be additional documents. Take a look at the NEMO=20 > home page and count the documents. There are many drafts=20 > there related to NEMO (v6), and accordingly, there would be=20 > more than one v4 document. =20 > MIB, network models, security, ... whatever is needed to=20 > describe how support works in a fully-baked way. >=20 > Many of the documents could be shared, so you wouldn't have=20 > to repeat existing work, but some of them don't translate to v4. >=20 > TJ >=20 > On Oct 21, 2005, at 11:24 PM, Narayanan Vidya-CVN065 wrote: >=20 > > TJ, > > > > > >> The key components, in my > >> personal view, would be a core group of some people=20 > willing to work=20 > >> on all of the documents, and the consensus of the WG (and=20 > ADs, etc)=20 > >> that it's something that we want to keep in the charter and it's=20 > >> proceeding in a reasonable way. > >> > >> > > > > What do you mean by "all of the documents"? If there is=20 > consensus to=20 > > work on basic support, without having to address other=20 > topics that are=20 > > not required for basic support, is that not (minimally) enough? > > > > Vidya > > > > >=20 >=20 From nemo-bounces@ietf.org Tue Oct 25 09:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPKc-0003EL-JO; Tue, 25 Oct 2005 09:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPKb-0003E3-L3 for nemo@megatron.ietf.org; Tue, 25 Oct 2005 09:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18948 for ; Tue, 25 Oct 2005 09:58:58 -0400 (EDT) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPXZ-0003am-M8 for nemo@ietf.org; Tue, 25 Oct 2005 10:12:38 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id BD7E9C31C for ; Tue, 25 Oct 2005 09:58:57 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j9PDwvGT026690; Tue, 25 Oct 2005 09:58:57 -0400 (EDT) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j9PDwuiD004972; Tue, 25 Oct 2005 09:58:56 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j9PDwqZn004960; Tue, 25 Oct 2005 09:58:52 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 6664F4FD4A; Tue, 25 Oct 2005 09:55:00 -0400 (EDT) Date: Tue, 25 Oct 2005 09:55:00 -0400 From: Wesley Eddy To: "Lee, Chao-Hsien" Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt Message-ID: <20051025135500.GF13790@grc.nasa.gov> References: <001f01c5cbd4$f7979960$7af7748c@leechlab> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xkXJwpr35CY/Lc3I" Content-Disposition: inline In-Reply-To: <001f01c5cbd4$f7979960$7af7748c@leechlab> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nemo@ietf.org, acast-arch-net@grc.nasa.gov X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --xkXJwpr35CY/Lc3I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 08, 2005 at 02:53:19PM +0800, Lee, Chao-Hsien wrote: > Dear all: >=20 > We have submitted a new draft that extends SIP to support network mobility > and to achieve RO. >=20 > You can get this document from the following URL. >=20 > http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt > The use of SIP to perform route optimization that this document describes is fairly straightforward and seems technically sound to me. The only problem I see is that the solution doesn't seem to satisfy NEMO goals. The sipnemo-00 draft says: "The extensions, which is called SIP-based Network Mobility (SIP-NEMO) protocol, are compatible with SIP and satisfy the goals and requirements defined in [6] for network mobility.", where [6] is Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04 (work in progress), February 2005. This statement doesn't seem to be correct, since in [6], section 3.3, it is stated: "Consequently, NEMO support is expected to be performed only by the MR(s). Specific support functions on any other node than the MR(s) would better be avoided." Also, in 3.4, "NEMO support is to be implemented at the level of IP layer. It is expected to be transparent to upper layers so that any upper layer protocol can run unchanged on top of an IP layer extended with NEMO support." SIP-NEMO seems to break these desired transparencies since it requires a SIP server infrastructure, and presumably applications would have to use SIP in order to have their traffic route optimized. So although this is a neat solution, it doesn't quite seem to fit the NEMO goals. Would you agree with this analysis? -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems http://roland.grc.nasa.gov/~weddy --xkXJwpr35CY/Lc3I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDXjkzzBuYqbnj3IwRAiw3AJ4l+PsgAWByb5on04DE30k6EDeTiACfdq4O X9ucK0SDAuDS64DOLG3a2x0= =hwxt -----END PGP SIGNATURE----- --xkXJwpr35CY/Lc3I-- From nemo-bounces@ietf.org Tue Oct 25 12:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUS5u-0003Mt-OX; Tue, 25 Oct 2005 12:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUS5t-0003Ml-NM for nemo@megatron.ietf.org; Tue, 25 Oct 2005 12:56:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04886 for ; Tue, 25 Oct 2005 12:56:00 -0400 (EDT) Received: from locust.csie.ncku.edu.tw ([140.116.247.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSIq-0002Ju-Qb for nemo@ietf.org; Tue, 25 Oct 2005 13:09:39 -0400 Received: from leechlab (leech.csie.ncku.edu.tw [140.116.247.122]) by locust.csie.ncku.edu.tw (8.12.10+Sun/8.12.10) with ESMTP id j9PGk7lg019075; Wed, 26 Oct 2005 00:46:12 +0800 (CST) From: "Lee, Chao-Hsien" To: , Subject: RE: [nemo] New draft draft-ming-nemo-sipnemo-00.txt Date: Wed, 26 Oct 2005 00:57:22 +0800 Message-ID: <001801c5d985$2ba664d0$7af7748c@leechlab> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20051025135500.GF13790@grc.nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXZauh6eV/TcKx7TXulctqxLzyxlwAFkRMQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Mr. Wesley Eddy: Yes, I agree your analysis. I think that our wording needs to be revised more precisely. Since the proposed SIP-NEMO adopts SIP to achieve RO, SIP-NEMO only satisfies some NEMO goals, such as Migration Transparency, Arbitrary Configurations, Scalability, and Backward Compatibility. Thus, I think that SIP-NEMO satisfies the basic spirit/concept of Network Mobility except that SIP-NEMO is from the perspective of application layer. Thanks for your suggestions and comments. best regards, Lee, Chao-Hsien -----Original Message----- From: Wesley Eddy [mailto:weddy@grc.nasa.gov] Sent: Tuesday, October 25, 2005 9:55 PM To: Lee, Chao-Hsien Cc: nemo@ietf.org; acast-arch-net@grc.nasa.gov Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt On Sat, Oct 08, 2005 at 02:53:19PM +0800, Lee, Chao-Hsien wrote: > Dear all: > > We have submitted a new draft that extends SIP to support network mobility > and to achieve RO. > > You can get this document from the following URL. > > http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt > The use of SIP to perform route optimization that this document describes is fairly straightforward and seems technically sound to me. The only problem I see is that the solution doesn't seem to satisfy NEMO goals. The sipnemo-00 draft says: "The extensions, which is called SIP-based Network Mobility (SIP-NEMO) protocol, are compatible with SIP and satisfy the goals and requirements defined in [6] for network mobility.", where [6] is Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04 (work in progress), February 2005. This statement doesn't seem to be correct, since in [6], section 3.3, it is stated: "Consequently, NEMO support is expected to be performed only by the MR(s). Specific support functions on any other node than the MR(s) would better be avoided." Also, in 3.4, "NEMO support is to be implemented at the level of IP layer. It is expected to be transparent to upper layers so that any upper layer protocol can run unchanged on top of an IP layer extended with NEMO support." SIP-NEMO seems to break these desired transparencies since it requires a SIP server infrastructure, and presumably applications would have to use SIP in order to have their traffic route optimized. So although this is a neat solution, it doesn't quite seem to fit the NEMO goals. Would you agree with this analysis? -Wes -- Wesley M. Eddy Verizon Federal Network Systems http://roland.grc.nasa.gov/~weddy From nemo-bounces@ietf.org Wed Oct 26 06:02:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUi6j-0008Es-Pg; Wed, 26 Oct 2005 06:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUi6h-0008Ea-Qb for nemo@megatron.ietf.org; Wed, 26 Oct 2005 06:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08463 for ; Wed, 26 Oct 2005 06:01:52 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiJp-0003gY-8B for nemo@ietf.org; Wed, 26 Oct 2005 06:15:42 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j9QAH3Nf000498; Wed, 26 Oct 2005 03:17:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9QA8buc012066; Wed, 26 Oct 2005 05:08:38 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 676D2865980; Wed, 26 Oct 2005 12:01:49 +0200 (CEST) Message-ID: <435F540D.2080105@motorola.com> Date: Wed, 26 Oct 2005 12:01:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: multihoming topics (was: [nemo] Preparing NEMO Slot for Vancouver) References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> In-Reply-To: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ml-nemo , tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Dear all, > > The NEMO WG will meet at Vancouver for a 2 hours session. > > In Paris, we mentioned about rechartering the WG, so I think this will > be one of the important discussion: how are we > > So, the main topics will be: > 1. status of WG documents > 2. RO PB Statement > 3. RO issues we should work on, and where > 4. Multihoming: what issues we should work on, and where > 5. Rechartering (mainly based on point 3 & 4) Thierry, just a question. I agree with most points in the agenda. Isn't the 4th topic dealt with in Monami6 WG? I mean, we already had extensive discussion slots at several NEMO meetings about what are the multi-homing issues and where should they be worked on. And then there was Monami6 BoF, and now Monami6 is created so they should logically be worked there, no? Alex From nemo-bounces@ietf.org Wed Oct 26 06:31:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiZS-0005fK-HP; Wed, 26 Oct 2005 06:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiZQ-0005fF-VK for nemo@megatron.ietf.org; Wed, 26 Oct 2005 06:31:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10223 for ; Wed, 26 Oct 2005 06:31:33 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUimZ-0004dL-Tr for nemo@ietf.org; Wed, 26 Oct 2005 06:45:24 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5FC494C7C0 for ; Wed, 26 Oct 2005 19:31:39 +0900 (JST) Date: Wed, 26 Oct 2005 19:31:44 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: multihoming topics (was: [nemo] Preparing NEMO Slot for Vancouver) Message-Id: <20051026193144.6dc78e8b.ernst@sfc.wide.ad.jp> In-Reply-To: <435F540D.2080105@motorola.com> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thanks Alex for rising this up ! > > The NEMO WG will meet at Vancouver for a 2 hours session. > > > > In Paris, we mentioned about rechartering the WG, so I think this > > will be one of the important discussion: how are we > > > > So, the main topics will be: > > 1. status of WG documents > > 2. RO PB Statement > > 3. RO issues we should work on, and where > > 4. Multihoming: what issues we should work on, and where > > 5. Rechartering (mainly based on point 3 & 4) > > Thierry, just a question. I agree with most points in the agenda. > Isn't the 4th topic dealt with in Monami6 WG? I mean, we already had > extensive discussion slots at several NEMO meetings about what are the > multi-homing issues and where should they be worked on. And then > there was Monami6 BoF, and now Monami6 is created so they should > logically be worked there, no? We still didn't come to a conclusion about which of the issues should be dealt with in each WG. The corresponding text (i.e. suggestion by draft authors) has been clarified in the new version (not announced yet, but it's available from http://www.nautilus6.org/doc/drafts/draft-ietf-nemo-multihoming-issues-04.txt http://www.nautilus6.org/doc/drafts/draft-ietf-nemo-multihoming-issues-04.html See Figure 10: Matrix of NEMO Multihoming Issues ) We need this discussion to happen now before the meeting in order to conclude in Vancouver. So, Monami6 has not been chartered to solve these issues, besides the multiple CoA registration. This means that most of the issues are WG-orphan. If the issues are important to be solved, and can be solved in a reasonable way, we should discuss which WG should take care of them, and go in these WGs to make them consider these new topics. We do think that some should be dealt with Monami6. Can we start the debate on this so that ChanWah doesn't have the impression to repeat himself in Vancouver ? Thanks, Thierry. From nemo-bounces@ietf.org Wed Oct 26 06:41:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiin-0008Eu-EC; Wed, 26 Oct 2005 06:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiil-0008EU-2r for nemo@megatron.ietf.org; Wed, 26 Oct 2005 06:41:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10680 for ; Wed, 26 Oct 2005 06:41:11 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUivs-0004uB-Jz for nemo@ietf.org; Wed, 26 Oct 2005 06:55:02 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9QAfFJh026148; Wed, 26 Oct 2005 19:41:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9QAfG006010; Wed, 26 Oct 2005 19:41:16 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j9QAfFq10750; Wed, 26 Oct 2005 19:41:15 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 18:38:30 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 2ED05D5A34; Wed, 26 Oct 2005 18:45:15 +0800 (SGT) Subject: Re: multihoming topics (was: [nemo] Preparing NEMO Slot for Vancouver) From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <435F540D.2080105@motorola.com> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 26 Oct 2005 18:45:15 +0800 Message-Id: <1130323515.11457.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 26 Oct 2005 10:38:30.0185 (UTC) FILETIME=[67E25190:01C5DA19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alex, On Wed, 2005-10-26 at 12:01 +0200, Alexandru Petrescu wrote: > Thierry Ernst wrote: > > Dear all, > > > > The NEMO WG will meet at Vancouver for a 2 hours session. > > > > In Paris, we mentioned about rechartering the WG, so I think this will > > be one of the important discussion: how are we > > > > So, the main topics will be: > > 1. status of WG documents > > 2. RO PB Statement > > 3. RO issues we should work on, and where > > 4. Multihoming: what issues we should work on, and where > > 5. Rechartering (mainly based on point 3 & 4) > > Thierry, just a question. I agree with most points in the agenda. > > Isn't the 4th topic dealt with in Monami6 WG? I mean, we already had > extensive discussion slots at several NEMO meetings about what are the > multi-homing issues and where should they be worked on. And then there > was Monami6 BoF, and now Monami6 is created so they should logically be > worked there, no? > In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have clearly recommended which issues to be worked on by which WG. There are two points of considerations for the NEMO WG. I would definitely like to use the slot in Vancouver to clear this two points. /rgds /cwng [*] Submitted on 24th, still in I-D secretariat's queue. Those impatient, can get it at http://www.psl.com.sg/Internet-Drafts/draft-ietf-nemo-multihoming-issues-04.txt From nemo-bounces@ietf.org Wed Oct 26 07:04:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUj4n-0004Xa-9A; Wed, 26 Oct 2005 07:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUj4l-0004XB-NY for nemo@megatron.ietf.org; Wed, 26 Oct 2005 07:04:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11744 for ; Wed, 26 Oct 2005 07:03:55 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUjHt-0005Yi-Mn for nemo@ietf.org; Wed, 26 Oct 2005 07:17:47 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 79C1789848; Wed, 26 Oct 2005 14:03:56 +0300 (EEST) Message-ID: <435F62A8.8090406@piuha.net> Date: Wed, 26 Oct 2005 14:04:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <20051026193144.6dc78e8b.ernst@sfc.wide.ad.jp> In-Reply-To: <20051026193144.6dc78e8b.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >We need this discussion to happen now before the meeting in order to >conclude in Vancouver. > > Good! >So, Monami6 has not been chartered to solve these issues, besides the >multiple CoA registration. This means that most of the issues are >WG-orphan. If the issues are important to be solved, and can be solved >in a reasonable way, we should discuss which WG should take care of >them, and go in these WGs to make them consider these new topics. We do >think that some should be dealt with Monami6. > > Hopefully the first step is to decide what issues we really need to solve now. Or has that already been decided? --Jari From nemo-bounces@ietf.org Wed Oct 26 07:43:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjgK-0007aF-DZ; Wed, 26 Oct 2005 07:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjgJ-0007Zs-Bt for nemo@megatron.ietf.org; Wed, 26 Oct 2005 07:42:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13293 for ; Wed, 26 Oct 2005 07:42:43 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUjtR-0006ZP-P1 for nemo@ietf.org; Wed, 26 Oct 2005 07:56:35 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j9QC5e7Z020858; Wed, 26 Oct 2005 05:05:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9QBpx31012960; Wed, 26 Oct 2005 06:52:00 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 326D0865980; Wed, 26 Oct 2005 13:42:41 +0200 (CEST) Message-ID: <435F6BB1.3020304@motorola.com> Date: Wed, 26 Oct 2005 13:42:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> In-Reply-To: <1130323515.11457.16.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj , Alexandru Petrescu Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > Hello Alex, > > On Wed, 2005-10-26 at 12:01 +0200, Alexandru Petrescu wrote: > >> Thierry Ernst wrote: >> >>> Dear all, >>> >>> The NEMO WG will meet at Vancouver for a 2 hours session. >>> >>> In Paris, we mentioned about rechartering the WG, so I think this >>> will be one of the important discussion: how are we >>> >>> So, the main topics will be: 1. status of WG documents 2. RO PB >>> Statement 3. RO issues we should work on, and where 4. >>> Multihoming: what issues we should work on, and where 5. >>> Rechartering (mainly based on point 3 & 4) >> >> Thierry, just a question. I agree with most points in the agenda. >> >> Isn't the 4th topic dealt with in Monami6 WG? I mean, we already >> had extensive discussion slots at several NEMO meetings about what >> are the multi-homing issues and where should they be worked on. >> And then there was Monami6 BoF, and now Monami6 is created so they >> should logically be worked there, no? >> > > > In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have > clearly recommended which issues to be worked on by which WG. There > are two points of considerations for the NEMO WG. Well, I read the draft's recommendation as three not two NEMO topics: -(multiple) HA ingress filtering for (n,n,n). -review prefix delegation. -loop prevention. Which are the two? Alex From nemo-bounces@ietf.org Wed Oct 26 07:59:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjwO-000738-D2; Wed, 26 Oct 2005 07:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjwM-00072t-00 for nemo@megatron.ietf.org; Wed, 26 Oct 2005 07:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13832 for ; Wed, 26 Oct 2005 07:59:19 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUk9U-00075K-FZ for nemo@ietf.org; Wed, 26 Oct 2005 08:13:10 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9QBxKJh015797; Wed, 26 Oct 2005 20:59:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9QBxL026695; Wed, 26 Oct 2005 20:59:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j9QBxLx16458; Wed, 26 Oct 2005 20:59:21 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 19:56:36 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 83CC1D5A34; Wed, 26 Oct 2005 20:03:23 +0800 (SGT) From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <435F6BB1.3020304@motorola.com> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <435F6BB1.3020304@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 26 Oct 2005 20:03:23 +0800 Message-Id: <1130328203.11457.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 26 Oct 2005 11:56:36.0985 (UTC) FILETIME=[516F3E90:01C5DA24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Wed, 2005-10-26 at 13:42 +0200, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > > Hello Alex, > > > > On Wed, 2005-10-26 at 12:01 +0200, Alexandru Petrescu wrote: > > > >> Thierry Ernst wrote: > >> > >>> Dear all, > >>> > >>> The NEMO WG will meet at Vancouver for a 2 hours session. > >>> > >>> In Paris, we mentioned about rechartering the WG, so I think this > >>> will be one of the important discussion: how are we > >>> > >>> So, the main topics will be: 1. status of WG documents 2. RO PB > >>> Statement 3. RO issues we should work on, and where 4. > >>> Multihoming: what issues we should work on, and where 5. > >>> Rechartering (mainly based on point 3 & 4) > >> > >> Thierry, just a question. I agree with most points in the agenda. > >> > >> Isn't the 4th topic dealt with in Monami6 WG? I mean, we already > >> had extensive discussion slots at several NEMO meetings about what > >> are the multi-homing issues and where should they be worked on. > >> And then there was Monami6 BoF, and now Monami6 is created so they > >> should logically be worked there, no? > >> > > > > > > In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have > > clearly recommended which issues to be worked on by which WG. There > > are two points of considerations for the NEMO WG. > > Well, I read the draft's recommendation as three not two NEMO topics: > -(multiple) HA ingress filtering for (n,n,n). > -review prefix delegation. > -loop prevention. > Sorry, it should be the first and last. The review prefix delegation part is a obviously-must-be-done. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 26 08:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkCg-0008Is-NJ; Wed, 26 Oct 2005 08:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkCf-0008Ij-7J for nemo@megatron.ietf.org; Wed, 26 Oct 2005 08:16:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15013 for ; Wed, 26 Oct 2005 08:16:10 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkPn-0007fi-Ru for nemo@ietf.org; Wed, 26 Oct 2005 08:30:01 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9QCS9fR023860; Wed, 26 Oct 2005 05:28:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9QCOphZ009559; Wed, 26 Oct 2005 07:24:51 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 77648865980; Wed, 26 Oct 2005 14:16:11 +0200 (CEST) Message-ID: <435F738B.9090407@motorola.com> Date: Wed, 26 Oct 2005 14:16:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <435F6BB1.3020304@motorola.com> <1130328203.11457.20.camel@localhost> In-Reply-To: <1130328203.11457.20.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj , Alexandru Petrescu Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > On Wed, 2005-10-26 at 13:42 +0200, Alexandru Petrescu wrote: > >>Chan-Wah Ng wrote: >> >> >>>Hello Alex, >>> >>>On Wed, 2005-10-26 at 12:01 +0200, Alexandru Petrescu wrote: >>> >>> >>>>Thierry Ernst wrote: >>>> >>>> >>>>>Dear all, >>>>> >>>>>The NEMO WG will meet at Vancouver for a 2 hours session. >>>>> >>>>>In Paris, we mentioned about rechartering the WG, so I think this >>>>>will be one of the important discussion: how are we >>>>> >>>>>So, the main topics will be: 1. status of WG documents 2. RO PB >>>>>Statement 3. RO issues we should work on, and where 4. >>>>>Multihoming: what issues we should work on, and where 5. >>>>>Rechartering (mainly based on point 3 & 4) >>>> >>>>Thierry, just a question. I agree with most points in the agenda. >>>> >>>>Isn't the 4th topic dealt with in Monami6 WG? I mean, we already >>>>had extensive discussion slots at several NEMO meetings about what >>>>are the multi-homing issues and where should they be worked on. >>>>And then there was Monami6 BoF, and now Monami6 is created so they >>>>should logically be worked there, no? >>>> >>> >>> >>>In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have >>> clearly recommended which issues to be worked on by which WG. There >>>are two points of considerations for the NEMO WG. >> >>Well, I read the draft's recommendation as three not two NEMO topics: >>-(multiple) HA ingress filtering for (n,n,n). >>-review prefix delegation. >>-loop prevention. >> > Sorry, it should be the first and last. The review prefix delegation > part is a obviously-must-be-done. Ok, so the draft recommends working on the NEMO issues related to (1) multiple HA ingress filtering each other's prefixes and (2) loop prevention. Could I address the 2nd: loop prevention. First, it does not look like a 'multi-homing' topic: it's about multiple MRs non necessarily with multiple interfaces and not necessarily with multiple HAs. Is this correct? Alex From nemo-bounces@ietf.org Wed Oct 26 08:38:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkYJ-0003ub-OI; Wed, 26 Oct 2005 08:38:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkYI-0003uL-2G for nemo@megatron.ietf.org; Wed, 26 Oct 2005 08:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16107 for ; Wed, 26 Oct 2005 08:38:31 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUklR-0008KA-Sg for nemo@ietf.org; Wed, 26 Oct 2005 08:52:22 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j9QCcXfg017698; Wed, 26 Oct 2005 21:38:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9QCcYh06745; Wed, 26 Oct 2005 21:38:34 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j9QCcZq19074; Wed, 26 Oct 2005 21:38:35 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 20:35:50 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id E6A83D5A34; Wed, 26 Oct 2005 20:42:36 +0800 (SGT) From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <435F738B.9090407@motorola.com> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <435F6BB1.3020304@motorola.com> <1130328203.11457.20.camel@localhost> <435F738B.9090407@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 26 Oct 2005 20:42:36 +0800 Message-Id: <1130330556.11457.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 26 Oct 2005 12:35:50.0220 (UTC) FILETIME=[CC1268C0:01C5DA29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Wed, 2005-10-26 at 14:16 +0200, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > >>>In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have > >>> clearly recommended which issues to be worked on by which WG. There > >>>are two points of considerations for the NEMO WG. > >> > >>Well, I read the draft's recommendation as three not two NEMO topics: > >>-(multiple) HA ingress filtering for (n,n,n). > >>-review prefix delegation. > >>-loop prevention. > >> > > Sorry, it should be the first and last. The review prefix delegation > > part is a obviously-must-be-done. > > Ok, so the draft recommends working on the NEMO issues related to (1) > multiple HA ingress filtering each other's prefixes and (2) loop prevention. > > Could I address the 2nd: loop prevention. Of-course, very much welcomed. > > First, it does not look like a 'multi-homing' topic: it's about multiple > MRs non necessarily with multiple interfaces and not necessarily with > multiple HAs. > > Is this correct? Correct. It is strictly speaking possible with a non-multihomed NEMO, given sufficient number of nestings. However, with every additional interface a mobile router has, the probability of loop forming will be increased. And there is a danger when someone design a loop prevention algorithm without "multihoming NEMO" in mind: A router would typically have a global IPv6 address configured on each interface. Thus multihomed NEMO-Link would likely have MR or MRs having multiple global IPv6 addresses. Without consideration to multihoming, a loop prevention algorithm (such as one that tries to generate a spanning tree) is likely to use the global address of a MR as a node of the spanning tree. This may run into a danger that two distinct nodes on the spanning tree may well be physically linked into a single node (thus the tree is in fact a mesh, with non-zero probability of a loop forming). That is the reason why this issue is documented in the draft. /rgds /cwng From nemo-bounces@ietf.org Wed Oct 26 08:44:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkdx-0002tB-Qb; Wed, 26 Oct 2005 08:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkdw-0002t3-L7 for nemo@megatron.ietf.org; Wed, 26 Oct 2005 08:44:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16925 for ; Wed, 26 Oct 2005 08:44:21 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkr4-0000DM-ON for nemo@ietf.org; Wed, 26 Oct 2005 08:58:13 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j9QD7OYJ008918; Wed, 26 Oct 2005 06:07:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9QCpteV009422; Wed, 26 Oct 2005 07:51:56 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AF92C865980; Wed, 26 Oct 2005 14:44:25 +0200 (CEST) Message-ID: <435F7A29.40407@motorola.com> Date: Wed, 26 Oct 2005 14:44:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <435F6BB1.3020304@motorola.com> <1130328203.11457.20.camel@localhost> <435F738B.9090407@motorola.com> <1130330556.11457.33.camel@localhost> In-Reply-To: <1130330556.11457.33.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , tj , Alexandru Petrescu Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > On Wed, 2005-10-26 at 14:16 +0200, Alexandru Petrescu wrote: > >> Chan-Wah Ng wrote: >> >> >>>>> In the upcoming -04 [*] of >>>>> draft-ietf-nemo-multihoming-issues, I have clearly >>>>> recommended which issues to be worked on by which WG. There >>>>> are two points of considerations for the NEMO WG. >>>> >>>> Well, I read the draft's recommendation as three not two NEMO >>>> topics: -(multiple) HA ingress filtering for (n,n,n). -review >>>> prefix delegation. -loop prevention. >>>> >>> >>> Sorry, it should be the first and last. The review prefix >>> delegation part is a obviously-must-be-done. >> >> Ok, so the draft recommends working on the NEMO issues related to >> (1) multiple HA ingress filtering each other's prefixes and (2) >> loop prevention. >> >> Could I address the 2nd: loop prevention. > > > Of-course, very much welcomed. > > >> First, it does not look like a 'multi-homing' topic: it's about >> multiple MRs non necessarily with multiple interfaces and not >> necessarily with multiple HAs. >> >> Is this correct? > > > Correct. It is strictly speaking possible with a non-multihomed > NEMO, given sufficient number of nestings. > > However, with every additional interface a mobile router has, the > probability of loop forming will be increased. And there is a danger > when someone design a loop prevention algorithm without "multihoming > NEMO" in mind: > > A router would typically have a global IPv6 address configured on > each interface. Thus multihomed NEMO-Link would likely have MR or > MRs having multiple global IPv6 addresses. Without consideration to > multihoming, a loop prevention algorithm (such as one that tries to > generate a spanning tree) is likely to use the global address of a MR > as a node of the spanning tree. Well, routing protocols that use spanning-tree algorithms do take into account each interface having its own global address and all works fine. > This may run into a danger that two distinct nodes on the spanning > tree may well be physically linked into a single node (thus the tree > is in fact a mesh, with non-zero probability of a loop forming). This may indeed become an issue. > That is the reason why this issue is documented in the draft. Thanks, so at this point one may wonder whether this is an issue that is urgent to be worked on now. Could we discuss whether some experiment revealed a loop in practice. Could we discuss about some external non-NEMO people complaining about the loop problem. Alex From nemo-bounces@ietf.org Wed Oct 26 21:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwVl-0008Es-E0; Wed, 26 Oct 2005 21:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwVj-0008CJ-A1 for nemo@megatron.ietf.org; Wed, 26 Oct 2005 21:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13565 for ; Wed, 26 Oct 2005 21:24:40 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwiz-0001tu-Hz for nemo@ietf.org; Wed, 26 Oct 2005 21:38:38 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2D3DB4C82E for ; Thu, 27 Oct 2005 10:24:23 +0900 (JST) Date: Thu, 27 Oct 2005 10:24:28 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051027102428.77f97b33.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__27_Oct_2005_10_24_28_+0900_hH6z8s3k/VrX60F4" X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [nemo] FYI [Mip6] General comments/questions on MIPv6 bootstrapping X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --Multipart=_Thu__27_Oct_2005_10_24_28_+0900_hH6z8s3k/VrX60F4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, In case you are not on the MIP6 ML, I think this thread is interesting for the NEMO WG. Thierry. --Multipart=_Thu__27_Oct_2005_10_24_28_+0900_hH6z8s3k/VrX60F4 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: ernst@sfc.wide.ad.jp Received: from ironport2.sfc.wide.ad.jp (ironport2.sfc.wide.ad.jp [203.178.142.137]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 43EA04C76B; Wed, 26 Oct 2005 21:16:09 +0900 (JST) Received: from megatron.ietf.org ([132.151.6.71]) by ironport2.sfc.wide.ad.jp with ESMTP; 26 Oct 2005 21:16:06 +0900 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.97,253,1125846000"; d="scan'208"; a="3628995:sNHT36740864" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkAd-0006WK-Q4; Wed, 26 Oct 2005 08:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkAb-0006VJ-Fc for mip6@megatron.ietf.org; Wed, 26 Oct 2005 08:14:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14922 for ; Wed, 26 Oct 2005 08:14:03 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkNk-0007cE-9p for mip6@ietf.org; Wed, 26 Oct 2005 08:27:53 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9QCDrA30681; Wed, 26 Oct 2005 14:13:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9QCDrOr013107; Wed, 26 Oct 2005 14:13:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510261213.j9QCDrOr013107@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "COMBES Jean-Michel RD-MAPS-ISS" Subject: Re: [Mip6] General comments/questions on MIPv6 bootstrapping In-reply-to: Your message of Mon, 24 Oct 2005 19:41:23 +0200. Date: Wed, 26 Oct 2005 14:13:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org MIME-Version: 1.0 In your previous mail you wrote: I have 2 main comments/questions. The first one is regarding the fact that we have two (very) different mechanisms for only one functionality (on one side DNS+IKEv2, on the other side PANA+AAA+DCHP). So, personally, I am a little afraid how all => PANA is not in the I-D, i.e., the protocol between the MN and the NAS is not specified (but it can be PANA). this will be managed in the user's terminal and in the MSP's network. E.g., what will be the trigger in the terminal to know which is the bootstrapping mechanism the terminal has to use? => I don't believe it is a real issue, or to use another argument, you have already the issue for the network access control itself. My second comment is regarding the interoperability with NEMO. I believe that if MIPv6 is deployed soon, NEMO will be deployed at the same time because the protocol is as mature as MIPv6. So I would like to know if the bootstrapping mechanisms working for MIPv6, will work with NEMO too. I would like to avoid to add new mechanisms again and so increase the complexity in a deployement architecture. => we can classify mechanisms into mechanisms with a NEMO flag (ICMP-based DHAAD for instance) or NEMO knowledge (HA-switch for instance), and zero-knowledge mechanisms where the NEMO knowledge has to be out of band. I believe it is the case today for DHCP (but it can be easily fixed) and IKEv2 HA-assignment (where IMHO it is harder without another anycast address). I can't see a reason to get really different mechanisms for MIPv6 and NEMO. Regards Francis.Dupont@enst-bretagne.fr PS: I'll do a second answer with my comments about the draft (i.e., I'll keep the subject and the subject header). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Multipart=_Thu__27_Oct_2005_10_24_28_+0900_hH6z8s3k/VrX60F4-- From nemo-bounces@ietf.org Wed Oct 26 21:41:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwm5-0007Ci-Ts; Wed, 26 Oct 2005 21:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwm4-00078w-B4 for nemo@megatron.ietf.org; Wed, 26 Oct 2005 21:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14516 for ; Wed, 26 Oct 2005 21:41:33 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwzK-0002Q5-9C for nemo@ietf.org; Wed, 26 Oct 2005 21:55:31 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AA98E4C803 for ; Thu, 27 Oct 2005 10:41:37 +0900 (JST) Date: Thu, 27 Oct 2005 10:41:43 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: multihoming topics (was: [nemo] Preparing NEMO Slot for Vancouver) Message-Id: <20051027104143.00d4dc34.ernst@sfc.wide.ad.jp> In-Reply-To: <1130323515.11457.16.camel@localhost> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, > > Thierry, just a question. I agree with most points in the agenda. > > > > Isn't the 4th topic dealt with in Monami6 WG? I mean, we already > > had extensive discussion slots at several NEMO meetings about what > > are the multi-homing issues and where should they be worked on. And > > then there was Monami6 BoF, and now Monami6 is created so they > > should logically be worked there, no? > > > > In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have > clearly recommended which issues to be worked on by which WG. There > are two points of considerations for the NEMO WG. I would definitely > like to use the slot in Vancouver to clear this two points. We also need to clear the other points: we cannot just say, well, this is a task for IPv6, or a task for DNA, or a task for monami6 and doing nothing. So, 1. do we think as a WG that the issue is important enough to be solved ? 2. if yes, where ? 3. if "where" is identified, we need to rise the discussion in the given WG which will decide if it's solvable in a reasonable amount of time and possibly add a new item. => but it's our responsability as the NEMO WG members to push for the relevant discussion to happen on the designed WGs. Thierrry > > /rgds > /cwng > > [*] Submitted on 24th, still in I-D secretariat's queue. Those > impatient, can get it at > http://www.psl.com.sg/Internet-Drafts/draft-ietf-nemo-multihoming-issues-04.txt > > -- Thierry ERNST, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Thu Oct 27 05:08:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3kN-0007da-9Q; Thu, 27 Oct 2005 05:08:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3kL-0007bf-QN for nemo@megatron.ietf.org; Thu, 27 Oct 2005 05:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17048 for ; Thu, 27 Oct 2005 05:08:13 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV3xe-0003eX-Ef for nemo@ietf.org; Thu, 27 Oct 2005 05:22:16 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9R988I27684; Thu, 27 Oct 2005 11:08:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9R988Ix019586; Thu, 27 Oct 2005 11:08:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510270908.j9R988Ix019586@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Thierry Ernst Subject: Re: [nemo] FYI [Mip6] General comments/questions on MIPv6 bootstrapping In-reply-to: Your message of Thu, 27 Oct 2005 10:24:28 +0900. <20051027102428.77f97b33.ernst@sfc.wide.ad.jp> Date: Thu, 27 Oct 2005 11:08:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ml-nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: In case you are not on the MIP6 ML, I think this thread is interesting for the NEMO WG. => BTW I have a question for the NEMO WG. The current HA-assignement by IKEv2 (which is being validated by the IPsec people, at least I expect :-) cf http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html could need a second anycast address for HAs supporting NEMO on the link. Is it a problem? Regards Francis.Dupont@enst-bretagne.fr PS: note the new anycast address matters only for: - HA configuration (in case the anycast address is wired in the code) - MN configuration (same) - IANA With the DNS-based service or address discovery, it is fully flexible and transparent. Same for the current ICMP-based DHAAD, the HA-switch, etc. In conclusion I can't see a problem if nobody has wired the address in its code, something which can be considered as pretty wrong in any case (but I am old enough to know some did this :-). From nemo-bounces@ietf.org Thu Oct 27 08:46:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV79U-00078F-QY; Thu, 27 Oct 2005 08:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV79S-00072s-VF for nemo@megatron.ietf.org; Thu, 27 Oct 2005 08:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26715 for ; Thu, 27 Oct 2005 08:46:21 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV7Mo-0000ok-Ki for nemo@ietf.org; Thu, 27 Oct 2005 09:00:27 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9RCwLsk019896; Thu, 27 Oct 2005 05:58:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9RCuKBu026222; Thu, 27 Oct 2005 07:56:21 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8E0CC865980; Thu, 27 Oct 2005 14:46:21 +0200 (CEST) Message-ID: <4360CC1D.7020306@motorola.com> Date: Thu, 27 Oct 2005 14:46:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] FYI [Mip6] General comments/questions on MIPv6 bootstrapping References: <200510270908.j9R988Ix019586@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510270908.j9R988Ix019586@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > In case you are not on the MIP6 ML, I think this thread is > interesting for the NEMO WG. > > => BTW I have a question for the NEMO WG. The current HA-assignement > by IKEv2 (which is being validated by the IPsec people, at least I > expect :-) cf > http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html could need > a second anycast address for HAs supporting NEMO on the link. Is it a > problem? Probably not a problem, but something that concerns NEMO, since HAs that support MRs need to tell that to MR. If IKEv2 could be used instead of DHAAD to help MR populate its HA list then yes, good. Probably the effect of assigning two anycast addresses for HAs could be obtained otherwise: just extend the IKEv2 message containing the HA list to tell it it's a HA that supports MR (instead of MN). Or similar? > PS: note the new anycast address matters only for: - HA configuration > (in case the anycast address is wired in the code) - MN configuration > (same) - IANA With the DNS-based service or address discovery, it is > fully flexible and transparent. Same for the current ICMP-based > DHAAD, the HA-switch, etc. I agree. > In conclusion I can't see a problem if nobody has wired the address > in its code, something which can be considered as pretty wrong in any > case (but I am old enough to know some did this :-). I do hardcode stuff now and then, especially with specs that change - it's quicker to hardcode and then delete than trying to write re-usable code in a world where specs are hardcoded and then deleted. Alex From nemo-bounces@ietf.org Thu Oct 27 09:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8EI-0003ah-8n; Thu, 27 Oct 2005 09:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8EH-0003YC-FM for nemo@megatron.ietf.org; Thu, 27 Oct 2005 09:55:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00867 for ; Thu, 27 Oct 2005 09:55:25 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8Rd-0002pe-SV for nemo@ietf.org; Thu, 27 Oct 2005 10:09:31 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9RDsV822091; Thu, 27 Oct 2005 15:54:31 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9RDsVod021147; Thu, 27 Oct 2005 15:54:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510271354.j9RDsVod021147@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [nemo] FYI [Mip6] General comments/questions on MIPv6 bootstrapping In-reply-to: Your message of Thu, 27 Oct 2005 14:46:21 +0200. <4360CC1D.7020306@motorola.com> Date: Thu, 27 Oct 2005 15:54:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: Probably the effect of assigning two anycast addresses for HAs could be obtained otherwise: just extend the IKEv2 message containing the HA list to tell it it's a HA that supports MR (instead of MN). Or similar? => I am strongly against the idea to add a notification to IKEv2 or something like that. A new anycast address is in phase with the general idea of anycast: it selects one of the members of a group, here we have two groups so should have two addresses! I summary your position: not a problem but a question in the scope of NEMO (i.e., NEMO has to decide). I agree. Thanks Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Thu Oct 27 10:00:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Ij-0004No-VE; Thu, 27 Oct 2005 10:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Ii-0004NB-LO for nemo@megatron.ietf.org; Thu, 27 Oct 2005 10:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01168 for ; Thu, 27 Oct 2005 10:00:01 -0400 (EDT) Received: from darla.ti-wmc.nl ([217.114.97.45] helo=smtp.wmc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8W2-0002yf-1i for nemo@ietf.org; Thu, 27 Oct 2005 10:14:06 -0400 Received: from [10.0.1.82] (pc032.wmc [10.0.1.82]) by smtp.wmc (Postfix) with ESMTP id 45CE6A0DC for ; Thu, 27 Oct 2005 15:59:49 +0200 (CEST) Message-ID: <4360DD55.3020701@ti-wmc.nl> Date: Thu, 27 Oct 2005 15:59:49 +0200 From: Simon Oosthoek Organization: WMC User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ml-nemo Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO simulation in ns-2 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all We're trying to code an extension to ns-2 for simulating NEMO. The code will probably be in part based on mobiwan. However, before we put too much effort into this, I was wondering if people here are aware of any existing ns-2 implementations that are freely available already? If not, what would be the minimum requirement regarding functionality of the HA/MR to allow a meaningful simulation of NEMO to be done in ns-2? We intend to release this extension if it would get to the point of being usable and publishable ;-) TIA Simon PS, we're also working on theoretical work on using NEMO for building Personal Networks (www.ist-magnet.org) -- phone:(+31|0)53 4810319 fax: (+31|0)53 4810333 simon.oosthoek@ti-wmc.nl http://www.ti-wmc.nl/ From nemo-bounces@ietf.org Thu Oct 27 10:17:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8ZN-0002Sd-OG; Thu, 27 Oct 2005 10:17:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8ZM-0002Rp-O8 for nemo@megatron.ietf.org; Thu, 27 Oct 2005 10:17:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02296 for ; Thu, 27 Oct 2005 10:17:13 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8mj-0003aN-1Z for nemo@ietf.org; Thu, 27 Oct 2005 10:31:18 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j9REXCeZ021350; Thu, 27 Oct 2005 07:33:16 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9REO9TO020765; Thu, 27 Oct 2005 09:24:10 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 26493865980; Thu, 27 Oct 2005 16:17:19 +0200 (CEST) Message-ID: <4360E16F.2020700@motorola.com> Date: Thu, 27 Oct 2005 16:17:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Preparing NEMO Slot for Vancouver References: <0B40B6F9CB990B428819561A2A55613A103A3A@de01exm69.ds.mot.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ml-nemo , Gopal Dommety , Narayanan Vidya-CVN065 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org T.J. Kniveton wrote: > There would be additional documents. Take a look at the NEMO home > page and count the documents. There are many drafts there related to > NEMO (v6), I agree, I believe there are at least three documents about IPv4 moving networks: DSMIPv6, draft-shima-nemo-v4prefix-01.txt and draft-leung-nemov4-base. The first two try to build IPv4 moving networks by using MIP6 (instead of MIP4). There was some discussion about this recently on MIP6 and further back on NEMO. > and accordingly, there would be more than one v4 document. MIB, > network models, security, ... whatever is needed to describe how > support works in a fully-baked way. Right, I think we'll see based on interest. > Many of the documents could be shared, so you wouldn't have to repeat > existing work, but some of them don't translate to v4. I agree, Alex From nemo-bounces@ietf.org Thu Oct 27 10:30:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8mM-0005MS-WF; Thu, 27 Oct 2005 10:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8mM-0005LZ-3q for nemo@megatron.ietf.org; Thu, 27 Oct 2005 10:30:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03087 for ; Thu, 27 Oct 2005 10:30:38 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8zi-00041A-R4 for nemo@ietf.org; Thu, 27 Oct 2005 10:44:44 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j9REjxjP010041; Thu, 27 Oct 2005 07:45:59 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9REbWui029856; Thu, 27 Oct 2005 09:37:33 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 80D94865980; Thu, 27 Oct 2005 16:30:41 +0200 (CEST) Message-ID: <4360E491.9010307@motorola.com> Date: Thu, 27 Oct 2005 16:30:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <20051027104143.00d4dc34.ernst@sfc.wide.ad.jp> In-Reply-To: <20051027104143.00d4dc34.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] Re: multihoming topics X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Hi, > > >>>Thierry, just a question. I agree with most points in the agenda. >>> >>>Isn't the 4th topic dealt with in Monami6 WG? I mean, we already >>>had extensive discussion slots at several NEMO meetings about what >>>are the multi-homing issues and where should they be worked on. And >>>then there was Monami6 BoF, and now Monami6 is created so they >>>should logically be worked there, no? >>> >> >>In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I have >>clearly recommended which issues to be worked on by which WG. There >>are two points of considerations for the NEMO WG. I would definitely >>like to use the slot in Vancouver to clear this two points. > > > We also need to clear the other points: we cannot just say, well, this > is a task for IPv6, or a task for DNA, or a task for monami6 and doing > nothing. So, > 1. do we think as a WG that the issue is important enough to be solved ? Could a NEMO Chair just ask a Monami6 Chair to deal with HAHA within its scope, and publicly discuss adoption within the Monami6 group? > 2. if yes, where ? > 3. if "where" is identified, we need to rise the discussion in the given > WG which will decide if it's solvable in a reasonable amount of time and > possibly add a new item. Could you please raise the HAHA discussion on Monami6, I agree with that. In this way probably more slots will be available during the NEMO meeting for other-than-HAHA discussions? HAHA discussions and presentations on NEMO happened twice (Washington and San Diego). If it still appears in the Vancouver agenda it should be relatively short I believe. > => but it's our responsability as the NEMO WG members to push for the > relevant discussion to happen on the designed WGs. Thierry, is this with the NEMO Chair hat on or as a NEMO WG member? If you believe that NEMO responsability is to do something then, as a Chair you have the maximum responsibility, please do it. If on the other hand the NEMO WG believes HAHA is local NEMO scope, then let's just ask that prior to the meeting: there have already been two meetings with HAHA slots. Alex From nemo-bounces@ietf.org Thu Oct 27 10:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV966-0003rx-3j; Thu, 27 Oct 2005 10:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV951-0003UC-FH; Thu, 27 Oct 2005 10:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03996; Thu, 27 Oct 2005 10:49:55 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IH-0004Wt-FR; Thu, 27 Oct 2005 11:03:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000Iv-L1; Thu, 27 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-04.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-04.txt Pages : 27 Date : 2005-10-27 This document defines a terminology for discussing network mobility issues and solution requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-terminology-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27095947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27095947.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 27 10:51:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96C-0003to-6j; Thu, 27 Oct 2005 10:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV951-0003Ud-RL; Thu, 27 Oct 2005 10:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03997; Thu, 27 Oct 2005 10:49:55 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IG-0004WS-PD; Thu, 27 Oct 2005 11:03:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000HM-3B; Thu, 27 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-requirements-05.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Goals and Requirements Author(s) : T. Ernst Filename : draft-ietf-nemo-requirements-05.txt Pages : 16 Date : 2005-10-27 Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such kind of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-requirements-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-requirements-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27084038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-requirements-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27084038.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 27 10:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96i-0004CK-R4; Thu, 27 Oct 2005 10:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV956-0003Wl-SC; Thu, 27 Oct 2005 10:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04038; Thu, 27 Oct 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9II-0004XS-2q; Thu, 27 Oct 2005 11:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94t-0000KU-Af; Thu, 27 Oct 2005 10:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Solution Space Analysis Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-space-analysis-01.txt Pages : 40 Date : 2005-10-27 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-space-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27103405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-space-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27103405.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 27 15:50:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlW-0007la-2M; Thu, 27 Oct 2005 15:50:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlE-0007bw-NC; Thu, 27 Oct 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25294; Thu, 27 Oct 2005 15:49:48 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDyd-0000dG-MM; Thu, 27 Oct 2005 16:03:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlC-0006On-A9; Thu, 27 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-04.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-04.txt Pages : 44 Date : 2005-10-27 This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Issues are classified according to the Working Group which is the best chartered to solve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27105040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27105040.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Thu Oct 27 20:49:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVIR8-0002BZ-O8; Thu, 27 Oct 2005 20:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVIR5-00027i-Ti for nemo@megatron.ietf.org; Thu, 27 Oct 2005 20:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07788 for ; Thu, 27 Oct 2005 20:49:18 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVIeX-0001Tb-0J for nemo@ietf.org; Thu, 27 Oct 2005 21:03:30 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CFC474CD47 for ; Fri, 28 Oct 2005 09:49:23 +0900 (JST) Date: Fri, 28 Oct 2005 09:49:30 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO simulation in ns-2 Message-Id: <20051028094930.2ffb2677.ernst@sfc.wide.ad.jp> In-Reply-To: <4360DD55.3020701@ti-wmc.nl> References: <4360DD55.3020701@ti-wmc.nl> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Simon, I'm not sure this list is the right venue for a discussion on NS, but I think your enquiry deserve to be dealt with because I do suspect that quite a few people did have / are / will contemplate NEMO simulation, using NS or other tools. My personal answer is that if you do have some code, that would be nice to make it public and some people will definitely use it, once it's posted. Any pointer like a URL would be nice, together with the NS version you are considering extending. Minimum requirement: it's pretty hard to answer, as it depends on the type of simulation. Some people may be interested in RO optimization protocols, other of the behavior of transport protocols over nested NEMO with high velocity, other in multicast of NEMO. Some may be concerned by the underlying wirless technology being used, other may not care so much and would just need a rough emulation with some given packet loss. >From my experience (and from many others), it was pretty hard to deal with the 802.11 internal - it did introduce a lot of complexity and memory leak. So, if yourself you can live with no 802.11 simulation, I would recommend to draft something independent from the underlying L2 - all is needed is a link that is not added in the routing fabric and for which you can specify some rough delay and packet loss. With such feature, simulation of NEMO RO could easily be performed (to the condition one can manipulate easily large or complex topologies, which was the case thanks to the additional library in Mobiwan) Thierry. On Thu, 27 Oct 2005 15:59:49 +0200 Simon Oosthoek wrote: > Hi all > > We're trying to code an extension to ns-2 for simulating NEMO. The > code will probably be in part based on mobiwan. However, before we put > too much effort into this, I was wondering if people here are aware of > any existing ns-2 implementations that are freely available already? > > If not, what would be the minimum requirement regarding functionality > of the HA/MR to allow a meaningful simulation of NEMO to be done in > ns-2? > > We intend to release this extension if it would get to the point of > being usable and publishable ;-) > > TIA > > Simon > > PS, we're also working on theoretical work on using NEMO for building > Personal Networks (www.ist-magnet.org) > > -- > phone:(+31|0)53 4810319 > fax: (+31|0)53 4810333 > simon.oosthoek@ti-wmc.nl > http://www.ti-wmc.nl/ From nemo-bounces@ietf.org Thu Oct 27 21:12:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVInT-0008BI-JD; Thu, 27 Oct 2005 21:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVInR-0008BD-QL for nemo@megatron.ietf.org; Thu, 27 Oct 2005 21:12:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09311 for ; Thu, 27 Oct 2005 21:12:24 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVJ0s-00026h-3o for nemo@ietf.org; Thu, 27 Oct 2005 21:26:37 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2BF9D4CD47 for ; Fri, 28 Oct 2005 10:12:29 +0900 (JST) Date: Fri, 28 Oct 2005 10:12:35 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: multihoming topics Message-Id: <20051028101235.06bda3e3.ernst@sfc.wide.ad.jp> In-Reply-To: <4360E491.9010307@motorola.com> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <20051027104143.00d4dc34.ernst@sfc.wide.ad.jp> <4360E491.9010307@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > >>>Thierry, just a question. I agree with most points in the agenda. > >>> > >>>Isn't the 4th topic dealt with in Monami6 WG? I mean, we already > >>>had extensive discussion slots at several NEMO meetings about what > >>>are the multi-homing issues and where should they be worked on. > >And>>then there was Monami6 BoF, and now Monami6 is created so they > >>>should logically be worked there, no? > >>> > >> > >>In the upcoming -04 [*] of draft-ietf-nemo-multihoming-issues, I > >have>clearly recommended which issues to be worked on by which WG. > >There>are two points of considerations for the NEMO WG. I would > >definitely>like to use the slot in Vancouver to clear this two > >points. > > > > > > We also need to clear the other points: we cannot just say, well, > > this is a task for IPv6, or a task for DNA, or a task for monami6 > > and doing nothing. So, > > 1. do we think as a WG that the issue is important enough to be > > solved ? > > Could a NEMO Chair just ask a Monami6 Chair to deal with HAHA within > its scope, and publicly discuss adoption within the Monami6 group? I think I could do that ;-) But, as a NEMO chair, I need to make sure it's a consensus of the NEMO WG that: 1. Monami6 is the best place, according to the NEMO WG 2. The NEMO WG is not willing to work on the topic in the NEMO WG (for some reasons, like rechartering, and above all work efficiency and complementarity) So, if we can discuss now on NEMO ML if we think a solution like HAHA must be standardized, and that this should be done in Monami6, may be we can discuss this point in Vancouver (in the NEMO WG or MONAMI6 or both depending on the progress of the discussion). > > 2. if yes, where ? > > 3. if "where" is identified, we need to rise the discussion in the > > given WG which will decide if it's solvable in a reasonable amount > > of time and possibly add a new item. > > Could you please raise the HAHA discussion on Monami6, See my comment above. > I agree with > that. In this way probably more slots will be available during the > NEMO meeting for other-than-HAHA discussions? HAHA discussions and > presentations on NEMO happened twice (Washington and San Diego). If > it still appears in the Vancouver agenda it should be relatively short > I believe. Agree it should be short, in the meeting. So, we have 1 week to drive a WG consensus on this point on the ML. > > => but it's our responsability as the NEMO WG members to push for > > the relevant discussion to happen on the designed WGs. > > Thierry, is this with the NEMO Chair hat on or as a NEMO WG member? > If you believe that NEMO responsability is to do something then, as a > Chair you have the maximum responsibility, please do it. I would say it's a personal message with a NEMO chair profiled hat, but I didn't sync with TJ, so this may not be a "NEMO chairs" view. To answer your question, responsability of chairs is to make this discussion happen and to drive the conclusions, possibly report the conclusion to other chairs or IESG. But it's not the chair responsability to decide. It's the WG's. And, for this, we need the discussion to be happening on NEMO ML right now. (actually, we need to discuss the entire process or rechartering NEMO, I guess TJ and me need to initiate this debate on a separate thread) > If on the other hand the NEMO WG believes HAHA is local NEMO scope, > then let's just ask that prior to the meeting: there have already been > two meetings with HAHA slots. My personal feeling is that it''s both MIP6 and NEMO scope, and could address some of the multihoming concerns (though I know motivations come from a RO point of view), so Monami6 would be a good place. Just my point of view. I would like to conclude what is the NEMO WG point of view. Alex, what's yours ? Thierry From nemo-bounces@ietf.org Thu Oct 27 22:58:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKS0-0003ff-Oy; Thu, 27 Oct 2005 22:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKRz-0003fY-P1 for nemo@megatron.ietf.org; Thu, 27 Oct 2005 22:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14135 for ; Thu, 27 Oct 2005 22:58:23 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVKfS-0004sj-Fu for nemo@ietf.org; Thu, 27 Oct 2005 23:12:36 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9S2wOp0013247; Fri, 28 Oct 2005 11:58:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9S2wRU06437; Fri, 28 Oct 2005 11:58:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j9S2wPj21466; Fri, 28 Oct 2005 11:58:26 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 10:55:39 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 8DB13D5A34; Fri, 28 Oct 2005 11:02:39 +0800 (SGT) Subject: Re: [nemo] Preparing NEMO Slot for Vancouver From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 28 Oct 2005 11:02:39 +0800 Message-Id: <1130468559.25865.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 28 Oct 2005 02:55:39.0927 (UTC) FILETIME=[1458BA70:01C5DB6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: ml-nemo , tj X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello NEMO Chairs, on behalf of the co-authors, I would like to request the following slots: ----- (1) Title: NEMO Multihoming Issues Status Update Speaker: One of the authors (Thierry, Eun-Kyoung, Marcelo, or myself) Length: ~ 15 mins Draft: draft-ietf-nemo-multihoming-issues-04.txt Purpose: (a) Status Update on the daft (b) WG consensus on the recommendations by the draft Relevance: Its is WG draft. ----- (2) Title: NEMO Route Optimization Drafts Update Length: ~ 15 mins Speaker: One of the authors (Watari-san, Pascal, or myself) Draft: draft-ietf-nemo-ro-problem-statement-01.txt draft-ietf-nemo-ro-space-analysis-01.txt Purpose: (a) Status Update on the drafts (b) Brief description on RO-SA, since this is the first presentation for the draft Relevance: They are WG drafts ----- /rgds /cwng On Fri, 2005-10-21 at 10:26 +0900, Thierry Ernst wrote: > Dear all, > > The NEMO WG will meet at Vancouver for a 2 hours session. > > In Paris, we mentioned about rechartering the WG, so I think this will > be one of the important discussion: how are we > > So, the main topics will be: > 1. status of WG documents > 2. RO PB Statement > 3. RO issues we should work on, and where > 4. Multihoming: what issues we should work on, and where > 5. Rechartering (mainly based on point 3 & 4) > > > If you intend to obtain a slot to discuss one of the above topics > (particularly the status of WG doc) or other topics please send your > request to TJ and myself, indicating:- name of speaker > - title of presentation > - associated draft (if any, and preferably) > - length > - purpose > - what is the relation with current NEMO activities > > Please send your requests by Oct 28th. Requests will be honored based > on: > - relevance with the priorities of the WG > - active discussion on the mailing list > > > TJ & Thierry > From nemo-bounces@ietf.org Thu Oct 27 23:41:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVL7t-00043Z-4w; Thu, 27 Oct 2005 23:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVL7r-00042p-IE for nemo@megatron.ietf.org; Thu, 27 Oct 2005 23:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16585 for ; Thu, 27 Oct 2005 23:41:39 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVLLL-00067m-0v for nemo@ietf.org; Thu, 27 Oct 2005 23:55:52 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CB8534CDAD for ; Fri, 28 Oct 2005 12:41:30 +0900 (JST) Date: Fri, 28 Oct 2005 12:41:37 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] New draft submitted: draft-tsukada-nemo-mr-cooperation-analysis-00.txt Message-Id: <20051028124137.2bd8053e.ernst@sfc.wide.ad.jp> In-Reply-To: <20051020100158.EE01.TU-KA@sfc.wide.ad.jp> References: <20051020100158.EE01.TU-KA@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, Regarding issues developped in Analysis of Multihoming in Network Mobility Support http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt I will like to highlight the need for MR cooperation (the issues are further developped in our draft Analysis of Multiple Mobile Routers Cooperation http://www.nautilus6.org/doc/drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.txt I don't have a personal conclusion whether we could rely on existing or generic but to be developped mechanisms for MR cooperation OR we should take the specificities of bi-directional tunneling into account (HoA, CoA, etc). So, this draft has been written with the objective of advancing the thinking on this. We would appreciate to receive comments on the draft, but more importantly, as chair, I would appreciate if we could discuss the need to address this issue, as pointed in as issue 4.4 http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-multihoming-issues-04.html#sec:problem.mrsync in draft-ietf-nemo-multihoming-issues-04.txt Thanks, Thierry. On Thu, 20 Oct 2005 10:16:17 +0900 Manabu Tsukada wrote: > Dear all, > > We have submitted a new draft about MRs cooperation analysis. > The aim of this document is to investigate issues and requirements > for MRs cooperation to get benefits of multihoming. > > Any feedback is of course welcome. > > A URL for this Internet-Draft is: > http://www.nautilus6.org/doc/drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.txt > > Title : Analysis of Multiple Mobile Routers Cooperation > Author(s) : M. Tsukada, R. Kuntz and T. Ernst > Filename : draft-tsukada-nemo-mr-cooperation-analysis-00.txt > Pages : 19 > Date : 2005-10-17 > Abstract: > This document is an analysis of multiple Mobile Routers Cooperation > in the context of network mobility support (NEMO) in IPv6. Our > objective is to identify when cooperation between MRs is needed and > what information must be exchanged. From nemo-bounces@ietf.org Fri Oct 28 00:07:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVLWr-00047w-76; Fri, 28 Oct 2005 00:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVLWq-00046Q-2X for nemo@megatron.ietf.org; Fri, 28 Oct 2005 00:07:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17588 for ; Fri, 28 Oct 2005 00:07:27 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVLkJ-0006s7-TE for nemo@ietf.org; Fri, 28 Oct 2005 00:21:41 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 22F504CDCD for ; Fri, 28 Oct 2005 13:07:24 +0900 (JST) Date: Fri, 28 Oct 2005 13:07:30 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051028130730.5517f999.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [nemo] Points of Failure X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, In draft-tsukada-nemo-mr-cooperation-analysis-00 we attempted to describe where failures could occur: see section 3 http://www.nautilus6.org/doc/drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.html#sec:failures I'm wondering if it would be useful or not to write more text in draft-nemo-ieft-multihoming-issues regarding the potential points of failure, as such a description could help describing many of the multihoming issues. Thoughts ? Thierry. From nemo-bounces@ietf.org Fri Oct 28 02:52:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVO6J-0007gZ-GL; Fri, 28 Oct 2005 02:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVO6H-0007gI-9V for nemo@megatron.ietf.org; Fri, 28 Oct 2005 02:52:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26623 for ; Fri, 28 Oct 2005 02:52:11 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVOJk-0003YI-Rw for nemo@ietf.org; Fri, 28 Oct 2005 03:06:27 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9C3F14CD47 for ; Fri, 28 Oct 2005 15:51:47 +0900 (JST) Date: Fri, 28 Oct 2005 15:51:54 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [nemo] WG Last Call on draft-ietf-nemo-terminology X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, This is a WG last call for draft-ietf-nemo-terminology before submission to the IESG. The call ends on Nov.09th (NEMO meeting day). I have submitted a revised version of the terminology. Changes include: - figure brush up - updated text for the home network models - 2 new terms from the NEMO RO drafts You can check the issues http://www.sfc.wide.ad.jp/~ernst/nemo/ . Issues addressed in the draft are these marked "Validate B4 Closing 0510". If no one complains, I will close all issues marked "Validate B4 Closing" and, if no one gives input on issues marked as "Open" I will also close them, with a "Reject" mention. Thierry. On Thu, 27 Oct 2005 10:50:02 -0400 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network Mobility Working > Group of the IETF. > > Title : Network Mobility Support Terminology > Author(s) : T. Ernst, H. Lach > Filename : draft-ietf-nemo-terminology-04.txt > Pages : 27 > Date : 2005-10-27 > > This document defines a terminology for discussing network mobility > issues and solution requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. From nemo-bounces@ietf.org Fri Oct 28 03:23:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOZp-0007nP-Nk; Fri, 28 Oct 2005 03:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOZo-0007kr-9s for nemo@megatron.ietf.org; Fri, 28 Oct 2005 03:23:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27477 for ; Fri, 28 Oct 2005 03:22:42 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVOnK-0004CT-El for nemo@ietf.org; Fri, 28 Oct 2005 03:36:59 -0400 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2C3504C0C3; Fri, 28 Oct 2005 16:22:50 +0900 (JST) Date: Fri, 28 Oct 2005 16:22:56 +0900 From: Thierry Ernst To: "Lee, Chao-Hsien" Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt Message-Id: <20051028162256.4fb0f0d2.ernst@sfc.wide.ad.jp> In-Reply-To: <001801c5d985$2ba664d0$7af7748c@leechlab> References: <20051025135500.GF13790@grc.nasa.gov> <001801c5d985$2ba664d0$7af7748c@leechlab> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, I have 3 comments to make on the comments: 1. Section 3 of draft-ietf-nemo-requirements are "design goals", not requirements, so a specific solution (for extended support) doesn't have to fulfill them. 2. Design goal "3.3" says "expected to be transparent" not "must be transparent" 3. I agree that NEMO WG may not be relevant to discuss application layer solutions to the RO problem. But, more importantly, we are still not in the process of evaluating solutions since we haven't decided yet if the NEMO WG will work on the solutions ... So, 1st thing 1st, we need to debate around the 2 RO drafts draft-ietf-nemo-ro-problem-statement and draft-ietf-nemo-ro-space-analysis. And, in Vancouver, we need to answer the question "what are the next steps for the NEMO WG. Are we going to conclude the WG (if yes, with which missions), or recharter?" Thierry. On Wed, 26 Oct 2005 00:57:22 +0800 "Lee, Chao-Hsien" wrote: > Dear Mr. Wesley Eddy: > > Yes, I agree your analysis. I think that our wording needs to be > revised more precisely. Since the proposed SIP-NEMO adopts SIP to > achieve RO, SIP-NEMO only satisfies some NEMO goals, such as Migration > Transparency, Arbitrary Configurations, Scalability, and Backward > Compatibility. Thus, I think that SIP-NEMO satisfies the basic > spirit/concept of Network Mobility except that SIP-NEMO is from the > perspective of application layer. Thanks for your suggestions and > comments. > > best regards, > > Lee, Chao-Hsien > > -----Original Message----- > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > Sent: Tuesday, October 25, 2005 9:55 PM > To: Lee, Chao-Hsien > Cc: nemo@ietf.org; acast-arch-net@grc.nasa.gov > Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt > > On Sat, Oct 08, 2005 at 02:53:19PM +0800, Lee, Chao-Hsien wrote: > > Dear all: > > > > We have submitted a new draft that extends SIP to support network > > mobility and to achieve RO. > > > > You can get this document from the following URL. > > > > http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt > > > > The use of SIP to perform route optimization that this document > describes is fairly straightforward and seems technically sound to me. > The only > problem I see is that the solution doesn't seem to satisfy NEMO goals. > > The sipnemo-00 draft says: "The extensions, which is called SIP-based > Network Mobility (SIP-NEMO) protocol, are compatible with SIP and > satisfy the goals and requirements defined in [6] for network > mobility.", where[6] is Ernst, T., "Network Mobility Support Goals and > Requirements", > draft-ietf-nemo-requirements-04 (work in progress), > February 2005. > > This statement doesn't seem to be correct, since in [6], section 3.3, > it is stated: "Consequently, NEMO support is expected to be performed > only by the MR(s). Specific support functions on any other node than > the MR(s) would better be avoided." Also, in 3.4, "NEMO support is to > be implemented at the level of IP layer. It is expected to be > transparent to upper layers so that any upper layer protocol can run > unchanged on top of an IP layer extended with NEMO support." > > SIP-NEMO seems to break these desired transparencies since it requires > a SIP server infrastructure, and presumably applications would have to > use SIP in order to have their traffic route optimized. So although > this is a neat solution, it doesn't quite seem to fit the NEMO goals. > Would you agree with this analysis? > > -Wes > > -- > Wesley M. Eddy > Verizon Federal Network Systems > http://roland.grc.nasa.gov/~weddy > > From nemo-bounces@ietf.org Fri Oct 28 04:25:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPXs-00013T-IP; Fri, 28 Oct 2005 04:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPXq-00012i-K2 for nemo@megatron.ietf.org; Fri, 28 Oct 2005 04:25:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00613 for ; Fri, 28 Oct 2005 04:24:46 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVPlM-00065o-Pg for nemo@ietf.org; Fri, 28 Oct 2005 04:39:02 -0400 Received: from [203.178.138.10] (unknown [203.178.138.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C0DBA4CC0B for ; Fri, 28 Oct 2005 17:24:51 +0900 (JST) Message-ID: <4361E0BF.3090200@sfc.wide.ad.jp> Date: Fri, 28 Oct 2005 17:26:39 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear authors, I have few comments relative to this draft. > 4.2. Ingress Filtering You state: > For the (*,1,n) cases, there is not such a problem, since there is a > single HA, accepting all the MNPs. When you have multiple MR, ingress filtering can happen sooner than at the HA: at the MR. You say it a bit later, in the example: > This would cause ingress filtering at HA2 to occur (or even at MR2). You also say: > In the (1,n,n) case, the problem is simplified because all the > traffic from and to the NEMO is routed through a single MR. Such > configuration allows the MR to properly route packets respecting the > constraints imposed by ingress filtering draft-montavont-monami6-multihoming-pb-statement-05 has a section speaking about ingress filtering (6.1.2) from the node point of view. Adding a reference could be useful, as it seems more tricky than stated in the draft. > 4.3. HA Synchronization [...] > In the (*,n,*) mobile networks, a single MNP would be registered at > different HAs. Do you mean (*,n,1)? BTW, the draft-tsukada-nemo-mr-cooperation-analysis-00 tries to list some requirements that should be taken into account when designing a MR-cooperation solution. We tried to take into account the issues described in the multihoming-issue draft. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Fri Oct 28 04:29:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPc6-0003ir-1P; Fri, 28 Oct 2005 04:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPc3-0003hy-M3 for nemo@megatron.ietf.org; Fri, 28 Oct 2005 04:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00806 for ; Fri, 28 Oct 2005 04:29:07 -0400 (EDT) Received: from darla.ti-wmc.nl ([217.114.97.45] helo=smtp.wmc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVPpX-0006Bs-Q5 for nemo@ietf.org; Fri, 28 Oct 2005 04:43:23 -0400 Received: from [10.0.1.82] (pc032.wmc [10.0.1.82]) by smtp.wmc (Postfix) with ESMTP id A870D7D4F for ; Fri, 28 Oct 2005 10:29:18 +0200 (CEST) Message-ID: <4361E15E.5090200@ti-wmc.nl> Date: Fri, 28 Oct 2005 10:29:18 +0200 From: Simon Oosthoek Organization: WMC User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ml-nemo Subject: Re: [nemo] NEMO simulation in ns-2 References: <4360DD55.3020701@ti-wmc.nl> <20051028094930.2ffb2677.ernst@sfc.wide.ad.jp> In-Reply-To: <20051028094930.2ffb2677.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Thierry thanks for your quick reply Thierry Ernst wrote: > My personal answer is that if you do have some code, that would be nice > to make it public and some people will definitely use it, once it's > posted. Any pointer like a URL would be nice, together with the NS > version you are considering extending. We have this URL, but it only contains an updated version of mobiwan for ns-2.26. http://www.ti-wmc.nl/mobiwan2/ I think for a NEMO extension, we'll be using ns-2.29 > Minimum requirement: it's pretty hard to answer, as it depends on the > type of simulation. Some people may be interested in RO optimization > protocols, other of the behavior of transport protocols over nested NEMO > with high velocity, other in multicast of NEMO. Some may be concerned by > the underlying wirless technology being used, other may not care so much > and would just need a rough emulation with some given packet loss. route optimisation is certainly on our agenda, because when dealing with multimedia traffic or personal data, you want to avoid bouncing stuff around. Anyway, thanks for the tips, if we have something useful, we'll put it on our site and notify ns-2 and perhaps announce it on the ietf list as well. Meanwhile, if you know of anyone willing to cooperate on such an implementation, please let us know! Cheers Simon -- phone:(+31|0)53 4810319 fax: (+31|0)53 4810333 simon.oosthoek@ti-wmc.nl http://www.ti-wmc.nl/ From nemo-bounces@ietf.org Fri Oct 28 04:56:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQ1q-0001Q0-AP; Fri, 28 Oct 2005 04:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQ1o-0001Ot-G1 for nemo@megatron.ietf.org; Fri, 28 Oct 2005 04:56:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02486 for ; Fri, 28 Oct 2005 04:55:44 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVQFK-0006zl-9T for nemo@ietf.org; Fri, 28 Oct 2005 05:10:00 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9S8tWCr024685; Fri, 28 Oct 2005 17:55:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9S8tZU01512; Fri, 28 Oct 2005 17:55:35 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j9S8tYj16091; Fri, 28 Oct 2005 17:55:34 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 16:52:45 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 2EACDD5A35; Fri, 28 Oct 2005 16:59:47 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-04.txt From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <4361E0BF.3090200@sfc.wide.ad.jp> References: <4361E0BF.3090200@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 28 Oct 2005 16:59:47 +0800 Message-Id: <1130489987.31605.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 28 Oct 2005 08:52:45.0511 (UTC) FILETIME=[F6FD6570:01C5DB9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, Romain, On Fri, 2005-10-28 at 17:26 +0900, Romain KUNTZ wrote: > Dear authors, > > I have few comments relative to this draft. > > > 4.2. Ingress Filtering > > You state: > > For the (*,1,n) cases, there is not such a problem, since there is a > > single HA, accepting all the MNPs. > > When you have multiple MR, ingress filtering can happen sooner than at > the HA: at the MR. You say it a bit later, in the example: > > > This would cause ingress filtering at HA2 to occur (or even at MR2). > Okay, so the sentence should be changed to: "For (1,1,*) and (n,1,n) cases ..." We then need to address (n,1,n) separately, or perhaps group this case into (n,n,n). I need to review the text a bit to address this, get back to you once I have a satisfactory resolution ready. > You also say: > > In the (1,n,n) case, the problem is simplified because all the > > traffic from and to the NEMO is routed through a single MR. Such > > configuration allows the MR to properly route packets respecting the > > constraints imposed by ingress filtering > > draft-montavont-monami6-multihoming-pb-statement-05 has a section > speaking about ingress filtering (6.1.2) from the node point of view. > Adding a reference could be useful, as it seems more tricky than stated > in the draft. No dispute there (considering I wrote the text on both drafts ;)). Will do that. > > > 4.3. HA Synchronization > [...] > > In the (*,n,*) mobile networks, a single MNP would be registered at > > different HAs. > > Do you mean (*,n,1)? > Right, thanks for catching that. > > BTW, the draft-tsukada-nemo-mr-cooperation-analysis-00 tries to list > some requirements that should be taken into account when designing a > MR-cooperation solution. We tried to take into account the issues > described in the multihoming-issue draft. > Indeed, I saw the draft announcement, but have no time to read it before submitting -04, and I don't want to simply reference a draft I have not yet read. /rgds /cwng From nemo-bounces@ietf.org Fri Oct 28 06:37:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRcB-0006jJ-Ic; Fri, 28 Oct 2005 06:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRc9-0006j5-R8 for nemo@megatron.ietf.org; Fri, 28 Oct 2005 06:37:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06594 for ; Fri, 28 Oct 2005 06:37:20 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRpf-00013N-Rc for nemo@ietf.org; Fri, 28 Oct 2005 06:51:38 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j9SAbTCj005534; Fri, 28 Oct 2005 03:37:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j9SAiwg0006195; Fri, 28 Oct 2005 05:44:59 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8F6D1865980; Fri, 28 Oct 2005 12:37:26 +0200 (CEST) Message-ID: <4361FF66.4030107@motorola.com> Date: Fri, 28 Oct 2005 12:37:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: multihoming topics References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105@motorola.com> <1130323515.11457.16.camel@localhost> <20051027104143.00d4dc34.ernst@sfc.wide.ad.jp> <4360E491.9010307@motorola.com> <20051028101235.06bda3e3.ernst@sfc.wide.ad.jp> In-Reply-To: <20051028101235.06bda3e3.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > But, as a NEMO chair, I need to make sure it's a consensus of the > NEMO WG that: 1. Monami6 is the best place, according to the NEMO WG > 2. The NEMO WG is not willing to work on the topic in the NEMO WG > (for some reasons, like rechartering, and above all work efficiency > and complementarity) I personally am not willing to work on HAHA types of protocols, not at this time, for reasons of reachartering and work efficiency. > So, if we can discuss now on NEMO ML if we think a solution like HAHA > must be standardized, and that this should be done in Monami6, may > be we can discuss this point in Vancouver Yes, best starting discuss now; but we've already said that. Why don't we start with authors giving their oppinion about what their intentions are with respect to which WG? Or some technical advantage of HAHA for NEMO? > (in the NEMO WG or MONAMI6 or both depending on the progress of the > discussion). It would be nice if we could avoid same topic presented in several meetings. And it's already been presented here. >>> 2. if yes, where ? 3. if "where" is identified, we need to rise >>> the discussion in the given WG which will decide if it's solvable >>> in a reasonable amount of time and possibly add a new item. IMHO - not in NEMO, not now in NEMO. >> I agree with that. In this way probably more slots will be >> available during the NEMO meeting for other-than-HAHA discussions? >> HAHA discussions and presentations on NEMO happened twice >> (Washington and San Diego). If it still appears in the Vancouver >> agenda it should be relatively short I believe. > > Agree it should be short, in the meeting. So, we have 1 week to drive > a WG consensus on this point on the ML. I said _if_ it still appears... >>> => but it's our responsability as the NEMO WG members to push for >>> the relevant discussion to happen on the designed WGs. >> >> Thierry, is this with the NEMO Chair hat on or as a NEMO WG member? >> If you believe that NEMO responsability is to do something then, >> as a Chair you have the maximum responsibility, please do it. > > > I would say it's a personal message with a NEMO chair profiled hat, > but I didn't sync with TJ, so this may not be a "NEMO chairs" view. > > To answer your question, responsability of chairs is to make this > discussion happen and to drive the conclusions, possibly report the > conclusion to other chairs or IESG. But it's not the chair > responsability to decide. It's the WG's. And, for this, we need the > discussion to be happening on NEMO ML right now. (actually, we need > to discuss the entire process or rechartering NEMO, I guess TJ and me > need to initiate this debate on a separate thread) Right. Until Charter discussion starts, do you want me to send message to Monami6 about HAHA? If I start reviewing the HAHA documents posting on Monami6 do you think I raise any chance that other people will review documents I'm currently interested in (FMIP, RO, v4 traversal and v4 in general)? Alex From nemo-bounces@ietf.org Fri Oct 28 06:43:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRhy-0001Wx-Ve; Fri, 28 Oct 2005 06:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRhw-0001Wq-Kd for nemo@megatron.ietf.org; Fri, 28 Oct 2005 06:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06830 for ; Fri, 28 Oct 2005 06:43:19 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRvU-0001BZ-0M for nemo@ietf.org; Fri, 28 Oct 2005 06:57:37 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j9SAxHtt028915; Fri, 28 Oct 2005 03:59:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j9SAqjFi022639; Fri, 28 Oct 2005 05:52:46 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7A942865980; Fri, 28 Oct 2005 12:43:22 +0200 (CEST) Message-ID: <436200CA.3080109@motorola.com> Date: Fri, 28 Oct 2005 12:43:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt References: <20051025135500.GF13790@grc.nasa.gov> <001801c5d985$2ba664d0$7af7748c@leechlab> <20051028162256.4fb0f0d2.ernst@sfc.wide.ad.jp> In-Reply-To: <20051028162256.4fb0f0d2.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > And, in Vancouver, we need to answer the question "what are the next > steps for the NEMO WG. Are we going to conclude the WG (if yes, with > which missions), or recharter?" _If_ new Charter, I'd support the following new missions as part of it: -v4 stuff -clarifying DHAAD interactions. -deployment aspects, implementation feedback, eventual implementation feedback about security leaks. Alex From nemo-bounces@ietf.org Mon Oct 31 01:14:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWSwV-0001aO-QP; Mon, 31 Oct 2005 01:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWSwU-0001aD-BM for nemo@megatron.ietf.org; Mon, 31 Oct 2005 01:14:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13975 for ; Mon, 31 Oct 2005 01:14:31 -0500 (EST) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWTAb-0000iw-36 for nemo@ietf.org; Mon, 31 Oct 2005 01:29:26 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j9V6EVdE013979; Mon, 31 Oct 2005 15:14:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9V6EVI20418; Mon, 31 Oct 2005 15:14:31 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j9V6EVv23396; Mon, 31 Oct 2005 15:14:31 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 14:11:43 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 5CC1ED5519; Mon, 31 Oct 2005 14:19:08 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-04.txt From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <4361E0BF.3090200@sfc.wide.ad.jp> References: <4361E0BF.3090200@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 31 Oct 2005 14:19:07 +0800 Message-Id: <1130739548.19589.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 31 Oct 2005 06:11:43.0421 (UTC) FILETIME=[F72CB6D0:01C5DDE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Fri, 2005-10-28 at 17:26 +0900, Romain KUNTZ wrote: > Dear authors, > > I have few comments relative to this draft. > > > 4.2. Ingress Filtering > > You state: > > For the (*,1,n) cases, there is not such a problem, since there is a > > single HA, accepting all the MNPs. > > When you have multiple MR, ingress filtering can happen sooner than at > the HA: at the MR. You say it a bit later, in the example: > > > This would cause ingress filtering at HA2 to occur (or even at MR2). > > You also say: > > In the (1,n,n) case, the problem is simplified because all the > > traffic from and to the NEMO is routed through a single MR. Such > > configuration allows the MR to properly route packets respecting the > > constraints imposed by ingress filtering > > draft-montavont-monami6-multihoming-pb-statement-05 has a section > speaking about ingress filtering (6.1.2) from the node point of view. > Adding a reference could be useful, as it seems more tricky than stated > in the draft. > Hello Romain, See if the following modified text suits you: o For the (*,*,1) cases, there is not such an issue, since there is a single MNP. o For the (1,1,*) and (n,1,1) cases, there is not such a problem, since there is a single HA, accepting all the MNPs. o For the (n,1,n) case, though ingress filtering would not occur at the HA, it may occur at the MRs, when each MR is handling different MNPs. o (*,n,n) are the cases where the ingress filtering presents some difficulties. In the (1,n,n) case, the problem is simplified because all the traffic from and to the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. In this case, the single MR may face ingress filtering problems that a multihomed mobile node may face, as documented in [7]. The more complex case is the (n,n,n) case. A simplified case occurs when all the prefixes are accepted by all the HAs, so that no problems occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below. /rgds /cwng From nemo-bounces@ietf.org Mon Oct 31 08:03:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZJi-0005xJ-JV; Mon, 31 Oct 2005 08:03:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZJg-0005wZ-R1 for nemo@megatron.ietf.org; Mon, 31 Oct 2005 08:03:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06059 for ; Mon, 31 Oct 2005 08:02:53 -0500 (EST) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWZXs-0001IT-1l for nemo@ietf.org; Mon, 31 Oct 2005 08:17:52 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9VD31FV008215 for ; Mon, 31 Oct 2005 22:03:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9VD34S16991 for ; Mon, 31 Oct 2005 22:03:04 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id j9VD32v16908 for ; Mon, 31 Oct 2005 22:03:02 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 21:00:13 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 86DFCD5519; Mon, 31 Oct 2005 21:07:40 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 31 Oct 2005 21:07:40 +0800 Message-Id: <1130764060.19589.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 31 Oct 2005 13:00:13.0376 (UTC) FILETIME=[083F0C00:01C5DE1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, Some "advertisements" for this draft :) The change-log says: o draft-ietf-nemo-ro-space-analysis-01: * Changed the term "Correspondent Agent" to "Correspondent Entity" [Issue #13] * Added clarifying text to some benefits listed in Sect 2 [Issue #14] * Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issue #5, #6, #16] * Added Section 4.9 [Issue #3] * Added clarifying text to various parts of Sect 5 [Issue #7, #8, #9, #11, and #16] * Combined "MR as a Proxy" and "MR as a Transparent Proxy" in Sect 5.5.1 [Issue #11] * Changed the term "identity of MNN" to "address of MNN" in Sect 5.5 [Issue #12] * Added text on signaling using upper layer protocols in Sect 5.6 * Added more security consideration to Sect 5.8 [Issue #15] As seen above, this version mainly addresses the issues brought up for -00. The issues list is now available at: http://www.mobilenetworks.org/~chanwah/rosa/issues.html I would appreciate if the originators of the issues (i.e. Jari, Carlos, Alexandru) check through to see if the issues are sufficiently dealt with in -01. Thanks, /rgds /cwng On Thu, 2005-10-27 at 10:50 -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Network Mobility Route Optimization Solution Space Analysis > Author(s) : C. Ng, et al. > Filename : draft-ietf-nemo-ro-space-analysis-01.txt > Pages : 40 > Date : 2005-10-27 > > With current Network Mobility (NEMO) Basic Support, all > communications to and from Mobile Network Nodes must go through the > MRHA tunnel when the mobile network is away. This results in > increased length of packet route and increased packet delay in most > cases. To overcome these limitations, one might have to turn to > Route Optimization (RO) for NEMO. This memo documents various types > of Route Optimization in NEMO, and explores the benefits and > tradeoffs in different aspects of NEMO Route Optimization. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-ro-space-analysis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.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. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From nemo-bounces@ietf.org Mon Oct 31 10:38:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbkG-0000cU-V0; Mon, 31 Oct 2005 10:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbkE-0000c8-A0 for nemo@megatron.ietf.org; Mon, 31 Oct 2005 10:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14633 for ; Mon, 31 Oct 2005 10:38:26 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbyO-0007lF-6e for nemo@ietf.org; Mon, 31 Oct 2005 10:53:27 -0500 Received: from [192.168.0.5] (p626b29.ykhmac00.ap.so-net.ne.jp [219.98.107.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8E3EF4C801; Tue, 1 Nov 2005 00:38:29 +0900 (JST) Message-ID: <43663AE5.9050605@sfc.wide.ad.jp> Date: Tue, 01 Nov 2005 00:40:21 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-04.txt References: <4361E0BF.3090200@sfc.wide.ad.jp> <1130739548.19589.2.camel@localhost> In-Reply-To: <1130739548.19589.2.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Chan-Wah, Chan-Wah Ng wrote: > See if the following modified text suits you: > > o For the (*,*,1) cases, there is not such an issue, since there is > a single MNP. > > o For the (1,1,*) and (n,1,1) cases, there is not such a problem, > since there is a single HA, accepting all the MNPs. I believe (n,1,1) is included in the first statement, and (1,1,1) is trivial, so you can just say (1,1,n). It's more coherent IMHO, as you speak about "all the MNPs". > o For the (n,1,n) case, though ingress filtering would not occur at > the HA, it may occur at the MRs, when each MR is handling > different MNPs. > > o (*,n,n) are the cases where the ingress filtering presents some > difficulties. In the (1,n,n) case, the problem is simplified > because all the traffic from and to the NEMO is routed through a > single MR. Such configuration allows the MR to properly route > packets respecting the constraints imposed by ingress filtering. > In this case, the single MR may face ingress filtering problems > that a multihomed mobile node may face, as documented in [7]. > > The more complex case is the (n,n,n) case. A simplified case > occurs when all the prefixes are accepted by all the HAs, so that > no problems occur with the ingress filtering. However, this > cannot be always assumed, resulting in the problem described > below. Otherwise it looks good to me. thanks, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Mon Oct 31 12:58:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdvL-0003lD-Ix; Mon, 31 Oct 2005 12:58:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdvI-0003kB-7o for nemo@megatron.ietf.org; Mon, 31 Oct 2005 12:58:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24097 for ; Mon, 31 Oct 2005 12:57:59 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWe9V-0004ND-D1 for nemo@ietf.org; Mon, 31 Oct 2005 13:13:02 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9VIABV2029922; Mon, 31 Oct 2005 11:10:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9VI6IW0003550; Mon, 31 Oct 2005 12:06:18 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0A757865980; Mon, 31 Oct 2005 18:58:05 +0100 (CET) Message-ID: <43665B2C.5020808@motorola.com> Date: Mon, 31 Oct 2005 18:58:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt References: <1130764060.19589.13.camel@localhost> In-Reply-To: <1130764060.19589.13.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I agree with issue numbers that have been suggested by myself - they've been dealt with. It was about CA and MNN terms. The first one is integrated (became CE) and the last one isn't and probably will never be ("MNN" is here to stay). The draft looks good to me overall, has good abstract and a relatively complete analysis of possible RO solutions for NEMO. It's also good for me it doesn't have strong recommendations. It should be used as a good starting point for designing a NEMO RO solution, when time arrives. Alex Chan-Wah Ng wrote: > Hello all, > > Some "advertisements" for this draft :) > > The change-log says: > > o draft-ietf-nemo-ro-space-analysis-01: * Changed the term > "Correspondent Agent" to "Correspondent Entity" [Issue #13] * Added > clarifying text to some benefits listed in Sect 2 [Issue #14] * > Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issue #5, #6, #16] * > Added Section 4.9 [Issue #3] * Added clarifying text to various > parts of Sect 5 [Issue #7, #8, #9, #11, and #16] * Combined "MR as a > Proxy" and "MR as a Transparent Proxy" in Sect 5.5.1 [Issue #11] * > Changed the term "identity of MNN" to "address of MNN" in Sect 5.5 > [Issue #12] * Added text on signaling using upper layer protocols in > Sect 5.6 * Added more security consideration to Sect 5.8 [Issue #15] > > > As seen above, this version mainly addresses the issues brought up > for -00. The issues list is now available at: > > http://www.mobilenetworks.org/~chanwah/rosa/issues.html > > I would appreciate if the originators of the issues (i.e. Jari, > Carlos, Alexandru) check through to see if the issues are > sufficiently dealt with in -01. > > Thanks, > > /rgds /cwng > > > On Thu, 2005-10-27 at 10:50 -0400, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Network Mobility >> Working Group of the IETF. >> >> Title : Network Mobility Route Optimization Solution Space >> Analysis Author(s) : C. Ng, et al. Filename : >> draft-ietf-nemo-ro-space-analysis-01.txt Pages : 40 Date : >> 2005-10-27 With current Network Mobility (NEMO) Basic Support, all >> communications to and from Mobile Network Nodes must go through >> the MRHA tunnel when the mobile network is away. This results in >> increased length of packet route and increased packet delay in most >> cases. To overcome these limitations, one might have to turn to >> Route Optimization (RO) for NEMO. This memo documents various >> types of Route Optimization in NEMO, and explores the benefits and >> tradeoffs in different aspects of NEMO Route Optimization. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt >> >> >> To remove yourself from the I-D Announcement list, send a message >> to i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-ietf-nemo-ro-space-analysis-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: mailserv@ietf.org. In the body type: "FILE >> /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.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. >> _______________________________________________ I-D-Announce >> mailing list I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce From nemo-bounces@ietf.org Mon Oct 31 13:20:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeGQ-0008PM-Mz; Mon, 31 Oct 2005 13:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeGK-0008OW-UT for nemo@megatron.ietf.org; Mon, 31 Oct 2005 13:20:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25401 for ; Mon, 31 Oct 2005 13:19:45 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWeUY-0005Jw-VH for nemo@ietf.org; Mon, 31 Oct 2005 13:34:47 -0500 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j9VIhESU010517; Mon, 31 Oct 2005 11:43:14 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9VIWgAp027036; Mon, 31 Oct 2005 12:32:43 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 37EBD865980; Mon, 31 Oct 2005 19:19:59 +0100 (CET) Message-ID: <4366604F.9010503@motorola.com> Date: Mon, 31 Oct 2005 19:19:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt References: <1129083768.9252.2.camel@localhost> In-Reply-To: <1129083768.9252.2.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Suggestions I have, > With current Network Mobility (NEMO) Basic Support, all > communications to and from Mobile Network Nodes must go through the > bi-directional tunnel established between the Mobile Router and Home > Agent when the mobile network is away. This results in various > inefficiencies associated with packet delivery. This document > investigates such inefficiencies, and provides for the motivation > behind Route Optimization (RO) for NEMO. So either call the draft "inefficiencies of NEMO", or alternatively do the following. Resume the problems of NEMO basic protocol that relate to RO in a few lines. Put these lines in the abstract. For example: "With NEMO Basic Support protocol, IP paths for application-layer data are artificially including the fixed HA of every Mobile Router, even when nested. This leads to multi-angular routing, while shorter IP paths would avoid the Home Agents. Additionally, the number of tunnel encapsulation layers when using nested moving networks may grow to a point that fragmentation becomes too heavy load. Finally, there exist at least one simple mobility configuration ("mobile" HA, MH at home below MR) that is not supported by the NEMO Basic Support protocol. This document formulates the above problems." Or something along these lines, I mean concentrate the document into the abstract and clearly articulate one of the problems that really breaks something, or that shows NEMO Basic Support is useless in that case. And shortly :-) > 2. NEMO Route Optimization Problem Statement > > In essence, the goal of Route Optimization in NEMO is to reduce > limitations and sub-optimalities introduced by the bi-directional > tunnel between a Mobile Router and its Home Agent (also known as the > MRHA tunnel). Compare to this: > 2. NEMO RO problem statement > > Given the NEMO Basic Support protocol all IP paths for application > data is forced through the Home Agent, although shorter paths exist > between LFN and CN (application runs between LFN and CN). > Additionally, with multiple MRs and nested moving networks several > levels of encapsulation are used for that application data, whereas > it is be possible to use none. > > Multi-angular routing through HAs and multiple encapsulation lead > to the following inneficiencies: ... So a problem statement is a problem statement, not a list of inefficiencies that are addressed by the goals of some RO solutions. Overall I like the document, it's short and easy to grasp for me, thanks for maintaining it. Alex Chan-Wah Ng wrote: > Hello all, > > just a quick note on the changes from -00 to -01: > > * Added text on effect on TCP contributed by Carlos in Sect 2.1 - > "Sub-Optimality with NEMO Basic Support" > > * Added text on VMN using CoA as source address in Appendix B.4.3 > > * Re-written Section 2.5 - "Security Policy Prohibiting Traffic From > Visiting Nodes" > > * Replaced "deadlock" with "stalemate" in Section 2.7. > > * Minor typographical corrections > > /rgds /cwng > > > On Tue, 2005-10-11 at 10:50 -0400, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Network Mobility >> Working Group of the IETF. >> >> Title : Network Mobility Route Optimization Problem Statement >> Author(s) : C. Ng, et al. Filename : >> draft-ietf-nemo-ro-problem-statement-01.txt Pages : 25 Date : >> 2005-10-11 With current Network Mobility (NEMO) Basic Support, all >> communications to and from Mobile Network Nodes must go through >> the bi-directional tunnel established between the Mobile Router and >> Home Agent when the mobile network is away. This results in >> various inefficiencies associated with packet delivery. This >> document investigates such inefficiencies, and provides for the >> motivation behind Route Optimization (RO) for NEMO. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt >> >> >> To remove yourself from the I-D Announcement list, send a message >> to i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-ietf-nemo-ro-problem-statement-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: mailserv@ietf.org. In the body type: "FILE >> /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.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. reference to >> remote file attachment Content-Type: Message/External-body; >> access-type="mail-server"; server="mailserv@ietf.org" >> >> Content-Type: text/plain Content-ID: >> <2005-10-11103426.I-D@ietf.org> >> >> ENCODING mime FILE >> /internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt >> _______________________________________________ I-D-Announce >> mailing list I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce