From nemo-bounces@ietf.org Tue Nov 01 02:17:12 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 1EWqOO-0008AJ-6N; Tue, 01 Nov 2005 02:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWqOM-0008AD-B3 for nemo@megatron.ietf.org; Tue, 01 Nov 2005 02:17:10 -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 CAA17163 for ; Tue, 1 Nov 2005 02:16:50 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWqcg-0005sC-EJ for nemo@ietf.org; Tue, 01 Nov 2005 02:31:59 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D88C14C516 for ; Tue, 1 Nov 2005 16:16:36 +0900 (JST) Date: Tue, 1 Nov 2005 16:16:37 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> In-Reply-To: <43665B2C.5020808@motorola.com> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Subject: [nemo] Next steps in RO - was :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 Hi, On Mon, 31 Oct 2005 18:58:04 +0100 Alexandru Petrescu wrote: > 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). Note that I took the benefit of being late to send the terminology document to the IESG to add this term in the terminology. (so it's sometimes positive to be late - wasn't this on purpose, indeed ? ;-) > 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. Time has arrived ! We need to discuss right now what will be the next steps of the NEMO WG - shutting down, or rechartering ? - and if these next steps include or not some work on RO and if so which one. I think authors of the drafts have done their part of the work, so now it's our turn as a WG to decide where to go from now. Thierry > 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-analysi > >s-01.txt> From nemo-bounces@ietf.org Wed Nov 02 06:06:17 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 1EXGRd-0003cP-3W; Wed, 02 Nov 2005 06:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXGRa-0003cH-Cz for nemo@megatron.ietf.org; Wed, 02 Nov 2005 06:06:14 -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 GAA27284 for ; Wed, 2 Nov 2005 06:05:51 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXGg7-0003ca-Lw for nemo@ietf.org; Wed, 02 Nov 2005 06:21:16 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8EF729D809; Wed, 2 Nov 2005 12:06:01 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 6A7599D4F1; Wed, 2 Nov 2005 12:06:00 +0100 (CET) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng In-Reply-To: <1130764060.19589.13.camel@localhost> References: <1130764060.19589.13.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+MtttLpu87N6BnN4EHL9" Organization: UC3M Date: Wed, 02 Nov 2005 12:06:07 +0100 Message-Id: <1130929567.7004.5.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 --=-+MtttLpu87N6BnN4EHL9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, I've checked the changes made in the new version of the I-D and I have some minor comments (just typos): Issue #3 (Support of LFR): - Typo: "Optimization schemes" instead of "Optimization shcemes" Issue #11 (MIRON cited as Transparent Proxy) - Typo: "initiate the Return" instead of "initiate teh Return" - Typo: "transparently alter" instead of "transparently alters" I'm fine with the rest of the text. Thanks a lot. Kind Regards, Carlos J. El lun, 31-10-2005 a las 21:07 +0800, Chan-Wah Ng escribi=F3:=20 > Hello all, >=20 > Some "advertisements" for this draft :) >=20 > The change-log says: >=20 > 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] >=20 > As seen above, this version mainly addresses the issues brought up for -0= 0. > The issues list is now available at: >=20 > http://www.mobilenetworks.org/~chanwah/rosa/issues.html >=20 > 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. >=20 > Thanks, >=20 > /rgds > /cwng >=20 >=20 > 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 dire= ctories. > > This draft is a work item of the Network Mobility Working Group of the = IETF. > >=20 > > 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 > > =09 > > 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. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-0= 1.txt > >=20 > > To remove yourself from the I-D Announcement list, send a message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the use= rname > > "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". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt". > > =09 > > 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. > > =09 > > =09 > > 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 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-+MtttLpu87N6BnN4EHL9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDaJ2f7QxZUr+JuXQRAmgAAKCb4b8RgTa0w0YekV2wf/JEJntIJACgiCvn oU3BL9raK8hHhrZSODobZd4= =c0P6 -----END PGP SIGNATURE----- --=-+MtttLpu87N6BnN4EHL9-- From nemo-bounces@ietf.org Wed Nov 02 13:02:41 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 1EXMwZ-0001zR-Dl; Wed, 02 Nov 2005 13:02:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMwX-0001wa-5Z for nemo@megatron.ietf.org; Wed, 02 Nov 2005 13:02:37 -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 NAA27539 for ; Wed, 2 Nov 2005 13:02:15 -0500 (EST) 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 1EXNB4-0007TJ-Ie for nemo@ietf.org; Wed, 02 Nov 2005 13:17:44 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 663678AD12F for ; Wed, 2 Nov 2005 10:00:52 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03527-06 for ; Wed, 2 Nov 2005 10:00:44 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id B4B228ABA7B; Wed, 2 Nov 2005 10:00:44 -0800 (PST) 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 575A98AB98E for ; Wed, 2 Nov 2005 10:00:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@motorola.com> <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Date: Wed, 2 Nov 2005 10:02:09 -0800 To: ml-nemo WG X-Mailer: Apple Mail (2.734) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] Next steps in RO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 31, 2005, at 11:16 PM, Thierry Ernst wrote: > I think authors of the drafts have done their part of the work, so now > it's our turn as a WG to decide where to go from now. Folks, Please let's have some more discussion on this point. What are important aspects of RO that NEMO should work on, and why? Is this area still too undeveloped for standardization? Perhaps RO in mobile networks should be turned over to MOBOPTS and the IRTF for further research? TJ From nemo-bounces@ietf.org Wed Nov 02 21:39:50 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 1EXV14-0002UU-UR; Wed, 02 Nov 2005 21:39:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXV11-0002UL-NP for nemo@megatron.ietf.org; Wed, 02 Nov 2005 21:39:48 -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 VAA25438 for ; Wed, 2 Nov 2005 21:39:25 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXVFj-0005he-HX for nemo@ietf.org; Wed, 02 Nov 2005 21:55:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA326EG28887; Wed, 2 Nov 2005 18:06:14 -0800 X-mProtect: <200511030206> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14193.americas.nokia.com (172.18.141.93, claiming to be "[172.18.141.93]") by darkstar.iprg.nokia.com smtpdGDOy4o; Wed, 02 Nov 2005 18:06:13 PST Message-ID: <4369785A.7000303@iprg.nokia.com> Date: Wed, 02 Nov 2005 18:39:22 -0800 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: Alexandru Petrescu Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> In-Reply-To: <4358F915.1070508@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Denis Ortega X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: > 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. RFC 3963 assumes DHAAD is used to obtain the list of HAs that support mobile routers. > 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. true. but if it uses DHAAD, then it knows whether the HA supports mobile routers. otherwise, it would know when the binding ack comes back without the 'R' flag. > 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). ok. > 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. sounds good to me. > > 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. agreed. > 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. shouldnt this be implementation specific? its internal to the HA. > > 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". well the prefix table could be used too. if you remember we deliberatly picked this text. it is very possible that the prefix information is stored somewhere else and routing entries are only created when the BU is received. in such a case the routing table wont be used. > 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"). you are right. it should say mobile hosts. > 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. agreed. dont know how we (even the RFC Editor) missed this. > 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. awesome. :) Vijay From nemo-bounces@ietf.org Thu Nov 03 01:34:07 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 1EXYfn-0006HE-13; Thu, 03 Nov 2005 01:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXYfk-0006F9-Lc for nemo@megatron.ietf.org; Thu, 03 Nov 2005 01:34:04 -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 BAA09964 for ; Thu, 3 Nov 2005 01:33:36 -0500 (EST) Received: from bb219-74-16-64.singnet.com.sg ([219.74.16.64] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXYuM-0000BX-K3 for nemo@ietf.org; Thu, 03 Nov 2005 01:49:13 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id BCE78186934; Thu, 3 Nov 2005 14:36:43 +0800 (SGT) Subject: Re: [nemo] Next steps in RO From: Chan-Wah NG To: "T.J. Kniveton" In-Reply-To: <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@motorola.com> <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Thu, 03 Nov 2005 14:36:43 +0800 Message-Id: <1130999803.13516.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, On Wed, 2005-11-02 at 10:02 -0800, T.J. Kniveton wrote: > On Oct 31, 2005, at 11:16 PM, Thierry Ernst wrote: > > > I think authors of the drafts have done their part of the work, so now > > it's our turn as a WG to decide where to go from now. > > > Folks, > > Please let's have some more discussion on this point. What are > important aspects of RO that NEMO should work on, and why? > > Is this area still too undeveloped for standardization? Perhaps RO in > mobile networks should be turned over to MOBOPTS and the IRTF for > further research? > I am contributing my two cents. Judging by the number of proposals since begining, I think there are definitely interest in having a standardized RO solution. The danger of moving this to the IRTF is that (1) the IRTF is not chartered to produce standard, (2) it will take a lot longer. I do not know what is IETF's basis for moving work to IRTF. Can someone shed a light on this? When there are too many competing proposals? Or when there is not enough knowledge in the particular problem area for there to be a sound engineering solution to the problem? Now that the solution space is starting to be analyzed, people should have a better understanding of the scope of RO work in NEMO. I don't know whether the work we did would suggest to people that we know the solution space well enough to engineer a solution, or that we do not know enough and more research work has to be done. :) I peronally would like to think its the former though :). But that is the first thing the WG should decide: Based on what is documented in the two RO drafts, do the WG feel that there is more research work that needs to be done? If yes, what are they? If not, I don't wee why the NEMO WG should not be re-chartered to develop the RO solution. If we are to go forward and devise an RO solution, I think it is definitely not a single piece of solution. Instead, I see a lot of different pieces to the puzzle. My personal views are that the following 3 main pieces are needed: (1) A mechanism for MNNs to send packet from where the NEMO is attached. This mechanism would allow MNNs, however deeply they are nested, to appear to a node outside the NEMO as if they are a simple mobile node. attached to the point of attachement of the root-MR. This mechanism would allow a solution to the nested mobile HA problem, and the security policy prohitbiting visitor traffic problem. Not only that, it also allows VMN to operate MIPv6 RO without being subjected to NEMO-BS tunnel. (2) A mechanism for MRs to offer route optimization to LFNs. This is less important, but it's a mean to complete the entire RO process. The mechanism above will allowed modified nodes (i.e. VMN) to achieve RO in a way compatible to the more "legacy" MIPv6 RO. This mechanism, will allow RO to be achieved for unmodified LFNs. (3) A correspondent router solution. The deployment of such an entity would allow two benefits: (1) perform RO for non-modified CNs, and (2) the discovery of MR by other mobile nodes, if this MR is treated as a CR. Some of the above may require future research, and may encompass a lot of smaller but significant issues to be solved. One can in fact have the NEMO WG re-chartered to work on only 1 or 2 of the above, and have the rest moved to IRTF for futher research. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 03 04:29:58 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 1EXbPy-0003Jr-Tm; Thu, 03 Nov 2005 04:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbPw-0003JB-Ro for nemo@megatron.ietf.org; Thu, 03 Nov 2005 04:29:57 -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 EAA17144 for ; Thu, 3 Nov 2005 04:29:31 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXbeg-00087B-4K for nemo@ietf.org; Thu, 03 Nov 2005 04:45:10 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0CB9E84047; Thu, 3 Nov 2005 10:29:37 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C250584053; Thu, 3 Nov 2005 10:29:35 +0100 (CET) Subject: Re: [nemo] Next steps in RO From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah NG In-Reply-To: <1130999803.13516.30.camel@localhost> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@motorola.com> <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> <1130999803.13516.30.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-u8YTsiR7Kmzo0vEL0Aru" Organization: UC3M Date: Thu, 03 Nov 2005 10:29:45 +0100 Message-Id: <1131010185.7179.18.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-u8YTsiR7Kmzo0vEL0Aru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I completely agree with Chan-Wah. I also think that there are people interested in working on a NEMO RO solution and I also share his view about that it's more likely to have a set of different solutions, each of them, solving a different part/scenario of the NEMO RO problem. My two cents. Kind Regards, Carlos J. P.S.: If the WG is also asking people about which NEMO RO topics they are working on or they'd like to work on, we have been/keep working on what Chan-Wah calls pieces 1 and 2. El jue, 03-11-2005 a las 14:36 +0800, Chan-Wah NG escribi=F3: > Hello all, >=20 > On Wed, 2005-11-02 at 10:02 -0800, T.J. Kniveton wrote: > > On Oct 31, 2005, at 11:16 PM, Thierry Ernst wrote: > >=20 > > > I think authors of the drafts have done their part of the work, so no= w > > > it's our turn as a WG to decide where to go from now. > >=20 > >=20 > > Folks, > >=20 > > Please let's have some more discussion on this point. What are =20 > > important aspects of RO that NEMO should work on, and why? > >=20 > > Is this area still too undeveloped for standardization? Perhaps RO in =20 > > mobile networks should be turned over to MOBOPTS and the IRTF for =20 > > further research? > >=20 >=20 > I am contributing my two cents. >=20 > Judging by the number of proposals since begining, I think there are > definitely interest in having a standardized RO solution. The danger of > moving this to the IRTF is that (1) the IRTF is not chartered to produce > standard, (2) it will take a lot longer. >=20 > I do not know what is IETF's basis for moving work to IRTF. Can someone > shed a light on this? When there are too many competing proposals? Or > when there is not enough knowledge in the particular problem area for > there to be a sound engineering solution to the problem? >=20 > Now that the solution space is starting to be analyzed, people should > have a better understanding of the scope of RO work in NEMO. I don't > know whether the work we did would suggest to people that we know the > solution space well enough to engineer a solution, or that we do not > know enough and more research work has to be done. :) I peronally would > like to think its the former though :). But that is the first thing the > WG should decide: Based on what is documented in the two RO drafts, do > the WG feel that there is more research work that needs to be done? If > yes, what are they? If not, I don't wee why the NEMO WG should not be > re-chartered to develop the RO solution. >=20 > If we are to go forward and devise an RO solution, I think it is > definitely not a single piece of solution. Instead, I see a lot of > different pieces to the puzzle.=20 >=20 > My personal views are that the following 3 main pieces are needed: >=20 > (1) A mechanism for MNNs to send packet from where the NEMO is attached. >=20 > This mechanism would allow MNNs, however deeply they are nested, to > appear to a node outside the NEMO as if they are a simple mobile node. > attached to the point of attachement of the root-MR. This mechanism > would allow a solution to the nested mobile HA problem, and the security > policy prohitbiting visitor traffic problem. Not only that, it also > allows VMN to operate MIPv6 RO without being subjected to NEMO-BS > tunnel. >=20 > (2) A mechanism for MRs to offer route optimization to LFNs. >=20 > This is less important, but it's a mean to complete the entire RO > process. The mechanism above will allowed modified nodes (i.e. VMN) to > achieve RO in a way compatible to the more "legacy" MIPv6 RO. This > mechanism, will allow RO to be achieved for unmodified LFNs. >=20 > (3) A correspondent router solution. >=20 > The deployment of such an entity would allow two benefits: (1) perform > RO for non-modified CNs, and (2) the discovery of MR by other mobile > nodes, if this MR is treated as a CR. >=20 > Some of the above may require future research, and may encompass a lot > of smaller but significant issues to be solved. One can in fact have > the NEMO WG re-chartered to work on only 1 or 2 of the above, and have > the rest moved to IRTF for futher research. >=20 > /rgds > /cwng >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-u8YTsiR7Kmzo0vEL0Aru Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDadiI7QxZUr+JuXQRAm0AAKC9mMqoBaiK3aJKh5TU8XpHJ1GKJwCfQGWJ wlQQn9uuuXnV43kR9BF3Rpw= =EKlI -----END PGP SIGNATURE----- --=-u8YTsiR7Kmzo0vEL0Aru-- From nemo-bounces@ietf.org Thu Nov 03 09:20:53 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 1EXfxV-0007TA-7v; Thu, 03 Nov 2005 09:20:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXfxT-0007Rb-GF for nemo@megatron.ietf.org; Thu, 03 Nov 2005 09:20:51 -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 JAA03337 for ; Thu, 3 Nov 2005 09:20:28 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXgCE-0003tt-I4 for nemo@ietf.org; Thu, 03 Nov 2005 09:36:10 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2005 15:20:39 +0100 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 jA3EKAdp006190; Thu, 3 Nov 2005 15:20:35 +0100 (MET) 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, 3 Nov 2005 15:20:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Next steps in RO Date: Thu, 3 Nov 2005 15:20:27 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0173EBEC@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Next steps in RO Thread-Index: AcXgQQjE8Ph1uNGKRuayVye4EfJn7QAOoUGw From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah NG" , "T.J. Kniveton" X-OriginalArrivalTime: 03 Nov 2005 14:20:34.0770 (UTC) FILETIME=[C142A320:01C5E081] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I'm globally with with Chan-Wah on this: >My personal views are that the following 3 main pieces are needed: > >(1) A mechanism for MNNs to send packet from where the NEMO is attached. > >This mechanism would allow MNNs, however deeply they are nested, to >appear to a node outside the NEMO as if they are a simple mobile node. >attached to the point of attachement of the root-MR. This mechanism >would allow a solution to the nested mobile HA problem, and the security >policy prohitbiting visitor traffic problem. Not only that, it also >allows VMN to operate MIPv6 RO without being subjected to NEMO-BS >tunnel. > [] In understand your case 1 as being a nested RO situation. And I understand that your definition is very open to the meaning of MNN. Could be a host or a router, and the RO solution could require an additional support from MNN that does not exist today, right?=20 >(2) A mechanism for MRs to offer route optimization to LFNs. > >This is less important, but it's a mean to complete the entire RO >process. The mechanism above will allowed modified nodes (i.e. VMN) to >achieve RO in a way compatible to the more "legacy" MIPv6 RO. This >mechanism, will allow RO to be achieved for unmodified LFNs. > [] If you meant doing between MRs what MIP6 does between MNs, then I'd be with you. That is MRs locate each other, establish a tunnel and exchange MNP routes over that tunnel, using a signaling that is close to existing NEMO, directly or via MAPs, proxy HAs or such. I do think that this is really important and that we have to consider it in NEMO; for instance, 2) is the base for route projection. But if you mean MR doing some proxy MIP on behalf of LFN to be able to do RO with MIP6 CN, then I see that as a next step for proxy-MIP as opposed to a next step for NEMO, and I know of few scenarios that really require it. >(3) A correspondent router solution. > >The deployment of such an entity would allow two benefits: (1) perform >RO for non-modified CNs, and (2) the discovery of MR by other mobile >nodes, if this MR is treated as a CR. > >Some of the above may require future research, and may encompass a lot >of smaller but significant issues to be solved. One can in fact have >the NEMO WG re-chartered to work on only 1 or 2 of the above, and have >the rest moved to IRTF for futher research. > [] Yes. We are introducing a number of boxes which do related things for related goals. I mean HMIP MAP, EMP EMAP, proxy-MIP, HAHA MIP proxy, CR. So maybe it will take more than one WG to decide what we really need from that regional box; I guess that MIP6 and NETLMM would be required in the loop... Pascal From nemo-bounces@ietf.org Thu Nov 03 11:07:48 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 1EXhcy-0000Ss-SR; Thu, 03 Nov 2005 11:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhcw-0000Sc-JH for nemo@megatron.ietf.org; Thu, 03 Nov 2005 11:07: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 LAA09019 for ; Thu, 3 Nov 2005 11:07:25 -0500 (EST) Received: from bb219-74-21-254.singnet.com.sg ([219.74.21.254] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhrl-0000OL-3i for nemo@ietf.org; Thu, 03 Nov 2005 11:23:06 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 074C0186934; Fri, 4 Nov 2005 00:10:33 +0800 (SGT) Subject: RE: [nemo] Next steps in RO From: Chan-Wah NG To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0173EBEC@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0173EBEC@xmb-ams-337.emea.cisco.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 04 Nov 2005 00:10:32 +0800 Message-Id: <1131034232.12530.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-11-03 at 15:20 +0100, Pascal Thubert (pthubert) wrote: > I'm globally with with Chan-Wah on this: > > >My personal views are that the following 3 main pieces are needed: > > > >(1) A mechanism for MNNs to send packet from where the NEMO is > attached. > > > >This mechanism would allow MNNs, however deeply they are nested, to > >appear to a node outside the NEMO as if they are a simple mobile node. > >attached to the point of attachement of the root-MR. This mechanism > >would allow a solution to the nested mobile HA problem, and the > security > >policy prohitbiting visitor traffic problem. Not only that, it also > >allows VMN to operate MIPv6 RO without being subjected to NEMO-BS > >tunnel. > > > [] In understand your case 1 as being a nested RO situation. And I > understand that your definition is very open to the meaning of MNN. > Could be a host or a router, and the RO solution could require an > additional support from MNN that does not exist today, right? > Perhaps. I envision all MRs to require additional functionality to support this. I suspect VMH to need that as well, but I can at least give you an example where it does not require this, though it is achieved in a slightly complicated and less intuitive way. However, that is going into specific. What I want to say is the first pieces is to allow a MNN to appear (to an outside node) as if it is not nested behind a MR, but directly attached to the AR. This particularly important for the problem spelt out in 2.5 and 2.7 of RO-PS draft. > >(2) A mechanism for MRs to offer route optimization to LFNs. > > > >This is less important, but it's a mean to complete the entire RO > >process. The mechanism above will allowed modified nodes (i.e. VMN) to > >achieve RO in a way compatible to the more "legacy" MIPv6 RO. This > >mechanism, will allow RO to be achieved for unmodified LFNs. > > > [] If you meant doing between MRs what MIP6 does between MNs, then > I'd be with you. That is MRs locate each other, establish a tunnel and > exchange MNP routes over that tunnel, using a signaling that is close to > existing NEMO, directly or via MAPs, proxy HAs or such. I do think that > this is really important and that we have to consider it in NEMO; for > instance, 2) is the base for route projection. > > But if you mean MR doing some proxy MIP on behalf of LFN to be able to > do RO with MIP6 CN, then I see that as a next step for proxy-MIP as > opposed to a next step for NEMO, and I know of few scenarios that really > require it. > I am not looking at it that deep. This second piece is to enable route optimization to LFN. There are different ways to achieved that, (by modifying CN, for instance). Since LFN are not-modified, it follows that someone else must do the RO on its behalf, and the logical best node to do it will be the MR. > > >(3) A correspondent router solution. > > > >The deployment of such an entity would allow two benefits: (1) perform > >RO for non-modified CNs, and (2) the discovery of MR by other mobile > >nodes, if this MR is treated as a CR. > > > >Some of the above may require future research, and may encompass a lot > >of smaller but significant issues to be solved. One can in fact have > >the NEMO WG re-chartered to work on only 1 or 2 of the above, and have > >the rest moved to IRTF for futher research. > > > [] Yes. We are introducing a number of boxes which do related things > for related goals. I mean HMIP MAP, EMP EMAP, proxy-MIP, HAHA MIP proxy, > CR. So maybe it will take more than one WG to decide what we really need > from that regional box; I guess that MIP6 and NETLMM would be required > in the loop... > Right, which is why I presented the pieces in this order. This 3rd piece can potentially have implications in more than the NEMO WG. For instance, a CR could very well deployed for MIPv6 RO as well. And yes, a HAHA mechanism can be seen as part of this 3rd piece. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 03 11:15:22 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 1EXhkI-00047R-UQ; Thu, 03 Nov 2005 11:15:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhkH-00046K-GU for nemo@megatron.ietf.org; Thu, 03 Nov 2005 11:15:21 -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 LAA09765 for ; Thu, 3 Nov 2005 11:15:00 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhz5-0000sZ-Ho for nemo@ietf.org; Thu, 03 Nov 2005 11:30:40 -0500 Received: from [192.168.0.4] (p2212-ipbf401marunouchi.tokyo.ocn.ne.jp [221.187.26.212]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D19814C12D for ; Fri, 4 Nov 2005 01:14:56 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF WG NEMO From: Ryuji Wakikawa Date: Fri, 4 Nov 2005 01:14:54 +0900 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [nemo] v4traversal ID X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 have submitted a draft on MIP6/NEMO v4 traversal. This is both MIP6 and NEMO WG document. Your comments are really appreciated. http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- v4traversal-00.txt thanks ryuji From nemo-bounces@ietf.org Thu Nov 03 11:29:11 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 1EXhxf-0008Gg-0n; Thu, 03 Nov 2005 11:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhxe-0008GV-3d for nemo@megatron.ietf.org; Thu, 03 Nov 2005 11:29:10 -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 LAA10662 for ; Thu, 3 Nov 2005 11:28:48 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXiCQ-0001fv-Er for nemo@ietf.org; Thu, 03 Nov 2005 11:44:29 -0500 Received: from [192.168.0.4] (p2212-ipbf401marunouchi.tokyo.ocn.ne.jp [221.187.26.212]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A524A4C0D6; Fri, 4 Nov 2005 01:28:57 +0900 (JST) In-Reply-To: <4369785A.7000303@iprg.nokia.com> References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Implemetor's comments on RFC3963 Date: Fri, 4 Nov 2005 01:28:55 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Denis Ortega , 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 Hi Alex and Vijay Please check interoperability with our implementation, SHISA:-) some comments inline. On 2005/11/03, at 11:39, Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> 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. > > RFC 3963 assumes DHAAD is used to obtain the list of HAs > that support mobile routers. > >> 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. > > true. but if it uses DHAAD, then it knows whether the HA > supports mobile routers. otherwise, it would know when the > binding ack comes back without the 'R' flag. > >> 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). > > ok. Only if there is another NEMO capable HA, it MUST send BU to the HA. Otherwise, it re-issues DHAAD or stop sending BU. >> 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. > > sounds good to me. Well, we should be very careful for the valid address definition. If i remember correctly, the valid address's ND state must be preferred or deprecated. NA must not be replied for an address which state is tentative and invalid. We should check NDP spec... >> 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. > > agreed. > >> 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. > > shouldnt this be implementation specific? its internal > to the HA. agree with Vijay. thanks ryuji >> 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". > > well the prefix table could be used too. if you remember we > deliberatly picked this text. it is very possible that the > prefix information is stored somewhere else and routing > entries are only created when the BU is received. in such a > case the routing table wont be used. > >> 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"). > > you are right. it should say mobile hosts. > >> 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. > > agreed. dont know how we (even the RFC Editor) missed this. > >> 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. > > awesome. :) > > Vijay > From nemo-bounces@ietf.org Thu Nov 03 15:02: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 1EXlHq-0002iP-RV; Thu, 03 Nov 2005 15:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlHm-0002hR-Jq for nemo@megatron.ietf.org; Thu, 03 Nov 2005 15:02: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 PAA23365 for ; Thu, 3 Nov 2005 15:01:47 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXlWb-0002Vi-R5 for nemo@ietf.org; Thu, 03 Nov 2005 15:17:31 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 84D9E84106; Thu, 3 Nov 2005 21:01:56 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 5963584124; Thu, 3 Nov 2005 21:01:55 +0100 (CET) Subject: RE: [nemo] Next steps in RO From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0173EBEC@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0173EBEC@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iXnmknXfqJBL3zJgVhGc" Organization: UC3M Date: Thu, 03 Nov 2005 21:02:05 +0100 Message-Id: <1131048125.7179.72.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ml-nemo WG , "T.J. Kniveton" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-iXnmknXfqJBL3zJgVhGc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Pascal, > >(2) A mechanism for MRs to offer route optimization to LFNs. > > > >This is less important, but it's a mean to complete the entire RO > >process. The mechanism above will allowed modified nodes (i.e. VMN) to > >achieve RO in a way compatible to the more "legacy" MIPv6 RO. This > >mechanism, will allow RO to be achieved for unmodified LFNs. > > > [] If you meant doing between MRs what MIP6 does between MNs, then > I'd be with you. That is MRs locate each other, establish a tunnel and > exchange MNP routes over that tunnel, using a signaling that is close to > existing NEMO, directly or via MAPs, proxy HAs or such. I do think that > this is really important and that we have to consider it in NEMO; for > instance, 2) is the base for route projection. >=20 > But if you mean MR doing some proxy MIP on behalf of LFN to be able to > do RO with MIP6 CN, then I see that as a next step for proxy-MIP as > opposed to a next step for NEMO, and I know of few scenarios that really > require it. I disagree here. What about a NEMO in a train, bus, ... in which passengers switch on their laptops/PDAs, obtain an IPv6 address belonging to the MNP deployed in the NEMO (through stateless/stateful autoconfiguration) and start communicating using this IP address?. These nodes would be LFNs (since they are using addresses belonging to the NEMO and are not going to move from this network to a different one) and I clearly see the benefit from enabling the traffic of these nodes to be route optimised. Kind Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-iXnmknXfqJBL3zJgVhGc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDamy97QxZUr+JuXQRApLvAKDGSOhVoThZ1hbNutWPDcO9YZlPSwCeMQ11 rEw3bt/7KG7OQ9RabxPL68M= =MDvb -----END PGP SIGNATURE----- --=-iXnmknXfqJBL3zJgVhGc-- From nemo-bounces@ietf.org Fri Nov 04 02:27:38 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 1EXvz8-0007wl-4d; Fri, 04 Nov 2005 02:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXvz3-0007sl-DM for nemo@megatron.ietf.org; Fri, 04 Nov 2005 02:27:35 -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 CAA28436 for ; Fri, 4 Nov 2005 02:27:10 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXwDz-0004DM-GJ for nemo@ietf.org; Fri, 04 Nov 2005 02:43:00 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D3C874C638 for ; Fri, 4 Nov 2005 16:27:03 +0900 (JST) Date: Fri, 4 Nov 2005 16:27:06 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20051104162706.5f4f7229.ernst@sfc.wide.ad.jp> In-Reply-To: <436200CA.3080109@motorola.com> References: <20051025135500.GF13790@grc.nasa.gov> <001801c5d985$2ba664d0$7af7748c@leechlab> <20051028162256.4fb0f0d2.ernst@sfc.wide.ad.jp> <436200CA.3080109@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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [nemo] Recharter items X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, On Fri, 28 Oct 2005 12:43:22 +0200 Alexandru Petrescu wrote: > 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. Let me change this thread to what it is about, i.e recharter items: Could you clarify all of the above points ? I'm not sure we had any discussion for some of them, and about the last one, I don't see what it has to do with a WG in the Internet Area. Let me add more things to the list, coming from the multihoming analysis draft: - multihomng considerations in prefix delegation - loop prevention in nested NEMO - MR synchronization And, the following, for which we need more discussion to know if it should be dealt with NEMO WG or another WG: - HAHA - RO (see thread Next steps in RO and particularly ChanWah's email on Nov.03) I would appreciated that any response to this mail would add the respective item in the subject line. Thierry From nemo-bounces@ietf.org Fri Nov 04 03:49:38 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 1EXxGU-0007CX-3a; Fri, 04 Nov 2005 03:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxGS-0007CI-Lv for nemo@megatron.ietf.org; Fri, 04 Nov 2005 03:49:36 -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 DAA02688 for ; Fri, 4 Nov 2005 03:49:13 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXxVM-0006cR-NW for nemo@ietf.org; Fri, 04 Nov 2005 04:05:04 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9EB324C0E9 for ; Fri, 4 Nov 2005 17:49:16 +0900 (JST) Date: Fri, 4 Nov 2005 17:49:19 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051104174919.119a888c.ernst@sfc.wide.ad.jp> In-Reply-To: <4361FF66.4030107@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> <20051028101235.06bda3e3.ernst@sfc.wide.ad.jp> <4361FF66.4030107@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: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Subject: [nemo] Recharter items: multihoming - HAHA ? X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I missed this mail. Comments inline. On Fri, 28 Oct 2005 12:37:26 +0200 Alexandru Petrescu wrote: > 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? Well, I don't know. I would say any list is fine, but probably NEMO is better to start with so that we could come up with a conclusion on this point in the NEMO WG first. Let me point out the HAHA is documented as issue 4.4 http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-multihoming-issues-04.html#sec:problem.hasync in draft-ietf-nemo-multihoming-issues-04.txt > 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)? I'm not sure what you mean, here. Particularly, what FMIP has to do with NEMO ? Thierry From nemo-bounces@ietf.org Fri Nov 04 03:54:57 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 1EXxLd-000090-PM; Fri, 04 Nov 2005 03:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxLb-00008u-LR for nemo@megatron.ietf.org; Fri, 04 Nov 2005 03:54:55 -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 DAA03017 for ; Fri, 4 Nov 2005 03:54:32 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXxaX-0006nS-Gx for nemo@ietf.org; Fri, 04 Nov 2005 04:10:23 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2005 09:54:46 +0100 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 jA48sFdn017752; Fri, 4 Nov 2005 09:54:40 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Nov 2005 09:54:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Next steps in RO Date: Fri, 4 Nov 2005 09:54:33 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0173EEB1@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Next steps in RO Thread-Index: AcXgsXrzVJOgOy89Q+CzHtg7lxAx9AAaforw From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 04 Nov 2005 08:54:39.0597 (UTC) FILETIME=[63E1C9D0:01C5E11D] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: ml-nemo WG , "T.J. Kniveton" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Carlos :) > >Dear Pascal, > > >> >(2) A mechanism for MRs to offer route optimization to LFNs. >> > >> >This is less important, but it's a mean to complete the entire RO >> >process. The mechanism above will allowed modified nodes (i.e. VMN) = to >> >achieve RO in a way compatible to the more "legacy" MIPv6 RO. This >> >mechanism, will allow RO to be achieved for unmodified LFNs. >> > >> [] If you meant doing between MRs what MIP6 does between MNs, = then >> I'd be with you. That is MRs locate each other, establish a tunnel = and >> exchange MNP routes over that tunnel, using a signaling that is close = to >> existing NEMO, directly or via MAPs, proxy HAs or such. I do think = that >> this is really important and that we have to consider it in NEMO; for >> instance, 2) is the base for route projection. >> >> But if you mean MR doing some proxy MIP on behalf of LFN to be able = to >> do RO with MIP6 CN, then I see that as a next step for proxy-MIP as >> opposed to a next step for NEMO, and I know of few scenarios that = really >> require it. > > I disagree here. What about a NEMO in a train, bus, ... in which >passengers switch on their laptops/PDAs, obtain an IPv6 address >belonging to the MNP deployed in the NEMO (through stateless/stateful >autoconfiguration) and start communicating using this IP address?. = These >nodes would be LFNs (since they are using addresses belonging to the >NEMO and are not going to move from this network to a different one) = and >I clearly see the benefit from enabling the traffic of these nodes to = be >route optimised. > [] I guess that item 2) is very broad in its description. So it = could cover the 2 approaches that I detailed. And RO for your user in = the bus could be handled in both fashions. What I believe is that the MR takes things up one step, placing things = from the host based to the prefix based. So RO between MRs, or MR to CR = makes more sense to me then spoofed MIP RO between LFN and CN. In your bus case, if, say, the correspondent is in another bus or a = train, then MR to MR RO will do the job. But MR to MR RO has a number of = other applications:=20 For instance, say a bunch of MRs establish a mesh of MRMR tunnels, and = exchange MNP routes, using NEMO based RO; they end up forming a = community, a form of dynamic VPN if you wish. If you couple that with a = MIPTRANS type of solution, the encapsulation could be IPv4, and the = backbone the current IPv4 infrastructure, while the 'VPN' is dual stack = or IPv6 only. Something like that changes the Internet Model from a common grid where = you have your given position (your IPv4 address) to an infinite number = of user or application centric on-demand networks, and you can scale to = the sky. I think it's worth considering, even if the goal is a bit = far-fetched... Pascal From nemo-bounces@ietf.org Fri Nov 04 05:16:33 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 1EXycb-0007vt-NQ; Fri, 04 Nov 2005 05:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyca-0007vo-9C for nemo@megatron.ietf.org; Fri, 04 Nov 2005 05:16:32 -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 FAA08175 for ; Fri, 4 Nov 2005 05:16:05 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXyrW-0000vs-72 for nemo@ietf.org; Fri, 04 Nov 2005 05:31:58 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4EB2182CD2; Fri, 4 Nov 2005 11:16:15 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 6AE6482CBB; Fri, 4 Nov 2005 11:16:14 +0100 (CET) Subject: RE: [nemo] Next steps in RO From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0173EEB1@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0173EEB1@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2DHfJg/nfAu5XbnYVQLS" Organization: UC3M Date: Fri, 04 Nov 2005 11:16:26 +0100 Message-Id: <1131099386.7249.8.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ml-nemo WG , "T.J. Kniveton" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-2DHfJg/nfAu5XbnYVQLS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, El vie, 04-11-2005 a las 09:54 +0100, Pascal Thubert (pthubert) escribi=F3: > Hi Carlos :) >=20 > > > >Dear Pascal, > > > > > >> >(2) A mechanism for MRs to offer route optimization to LFNs. > >> > > >> >This is less important, but it's a mean to complete the entire RO > >> >process. The mechanism above will allowed modified nodes (i.e. VMN) = to > >> >achieve RO in a way compatible to the more "legacy" MIPv6 RO. This > >> >mechanism, will allow RO to be achieved for unmodified LFNs. > >> > > >> [] If you meant doing between MRs what MIP6 does between MNs, then > >> I'd be with you. That is MRs locate each other, establish a tunnel and > >> exchange MNP routes over that tunnel, using a signaling that is close = to > >> existing NEMO, directly or via MAPs, proxy HAs or such. I do think tha= t > >> this is really important and that we have to consider it in NEMO; for > >> instance, 2) is the base for route projection. > >> > >> But if you mean MR doing some proxy MIP on behalf of LFN to be able to > >> do RO with MIP6 CN, then I see that as a next step for proxy-MIP as > >> opposed to a next step for NEMO, and I know of few scenarios that real= ly > >> require it. > > > > I disagree here. What about a NEMO in a train, bus, ... in which > >passengers switch on their laptops/PDAs, obtain an IPv6 address > >belonging to the MNP deployed in the NEMO (through stateless/stateful > >autoconfiguration) and start communicating using this IP address?. These > >nodes would be LFNs (since they are using addresses belonging to the > >NEMO and are not going to move from this network to a different one) and > >I clearly see the benefit from enabling the traffic of these nodes to be > >route optimised. > > > [] I guess that item 2) is very broad in its description. So it could= cover the 2 approaches that I detailed. And RO for your user in the bus co= uld be handled in both fashions. RO can be handled in both fashions if the communication peers are both attached to NEMOs. If one peer is an LFN and the other one is a video streaming server in the fixed Internet, then only one of the both approaches aforementioned is valid. And if you want not to change or add any special support in the LFNs, then, as Chan-Wah said, the MR seems to be the natural entity to put special functionality into. >=20 > What I believe is that the MR takes things up one step, placing things fr= om the host based to the prefix based. So RO between MRs, or MR to CR makes= more sense to me then spoofed MIP RO between LFN and CN. OK, agree if NEMO-to-NEMO communication takes place. Note that in my example I was talking of NEMO-to-CN at fixed Internet communication. >=20 > In your bus case, if, say, the correspondent is in another bus or a train= , then MR to MR RO will do the job. But MR to MR RO has a number of other a= pplications:=20 Agree. Kind Regards, Carlos J. >=20 > For instance, say a bunch of MRs establish a mesh of MRMR tunnels, and ex= change MNP routes, using NEMO based RO; they end up forming a community, a = form of dynamic VPN if you wish. If you couple that with a MIPTRANS type of= solution, the encapsulation could be IPv4, and the backbone the current IP= v4 infrastructure, while the 'VPN' is dual stack or IPv6 only. >=20 > Something like that changes the Internet Model from a common grid where y= ou have your given position (your IPv4 address) to an infinite number of us= er or application centric on-demand networks, and you can scale to the sky.= I think it's worth considering, even if the goal is a bit far-fetched... >=20 > Pascal >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-2DHfJg/nfAu5XbnYVQLS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDazT57QxZUr+JuXQRAuPhAJ9KKOqYzYBipNQunVdbovGVM8kqfQCfXduF hFvew82cD2hvGsoruVyN36I= =swBa -----END PGP SIGNATURE----- --=-2DHfJg/nfAu5XbnYVQLS-- From nemo-bounces@ietf.org Fri Nov 04 05:57:55 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 1EXzGd-0007yo-Io; Fri, 04 Nov 2005 05:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzGa-0007ye-Tf for nemo@megatron.ietf.org; Fri, 04 Nov 2005 05:57:53 -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 FAA12166 for ; Fri, 4 Nov 2005 05:57:30 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXzVZ-0002aU-6C for nemo@ietf.org; Fri, 04 Nov 2005 06:13:22 -0500 Received: from [192.168.0.4] (unknown [61.196.102.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 62F344C6B7; Fri, 4 Nov 2005 19:57:42 +0900 (JST) Date: Fri, 04 Nov 2005 19:57:40 +0900 From: Shinta Sugimoto To: Ryuji Wakikawa Subject: Re: [nemo] v4traversal ID In-Reply-To: References: Message-Id: <20051104195359.9642.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_436B3DC798DD06EC6D18_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: IETF WG 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 --------_436B3DC798DD06EC6D18_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Ryuji, Please find my comments on the draft. The third bullet is more related to NEMO. Regards, Shinta On Fri, 4 Nov 2005 01:14:54 +0900 Ryuji Wakikawa wrote: > Hi all, > > We have submitted a draft on MIP6/NEMO v4 traversal. > This is both MIP6 and NEMO WG document. > Your comments are really appreciated. > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- > v4traversal-00.txt > > thanks > ryuji > --------_436B3DC798DD06EC6D18_MULTIPART_MIXED_ Content-Type: message/rfc822 Content-Description: [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2) Return-Path: X-Original-To: shinta@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 1BBF84C6B7; Fri, 4 Nov 2005 19:54:22 +0900 (JST) Received: from megatron.ietf.org ([132.151.6.71]) by ironport2.sfc.wide.ad.jp with ESMTP; 04 Nov 2005 19:54:17 +0900 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 1EXzAK-00070V-3e; Fri, 04 Nov 2005 05:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzAI-00070Q-0i for mip6@megatron.ietf.org; Fri, 04 Nov 2005 05:51:22 -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 FAA11810 for ; Fri, 4 Nov 2005 05:50:57 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXzPB-0002QC-4F for mip6@ietf.org; Fri, 04 Nov 2005 06:06:51 -0500 Received: from [192.168.0.4] (unknown [61.196.102.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 78AAD4C63D for ; Fri, 4 Nov 2005 19:50:48 +0900 (JST) Date: Fri, 04 Nov 2005 19:50:46 +0900 From: Shinta Sugimoto To: mip6@ietf.org Message-Id: <20051104195036.963F.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2) 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 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, I've reviewed the v4traversal protocol document. First of all, thanks for writing this up. I think this technology is really useful. I have following comments and questions as below. Technical Comments: - In Section 2.2, there are descriptions about use of IPsec for sending and receiving MPS/MPA. However, I found the texts are not clear about how the IPsec should be applied to the MIPv6 messages. Does the specification recommend to use IPsec as similar to the MIPv6's case (RFC 3776) ? Or does it (intentionally) leave it to operation ? > A dual stack mobile node MAY send a Mobile Prefix Solicitation > message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where > the mobile node has no access to IPv6 within the local network. > Securing such messages would require the mobile node to have security > association with the home agent, using IPsec (AH or ESP) and based on > the mobile node's IPv4 care-of address as described in [MIPv6]. Since > the mobile node needs to encapsulate all IPv6 traffic sent to the > home agent into IPv4, while located in an IPv4-only visited network, > such SA would affect all packets if the selectors were based on the > information in the outer header. That is, the SA selectors being the > protocol number (protocol is always IP in IP), as well as, source and > destination addresses are all common to all packets. If this effect > is not desired, the mobile node can base the SA on the information in > the inner header (i.e. using the home agent's IPv6 address, the > mobile node's home address and the ICMP protocol number). Such > security association would use transport mode ESP protection. - Related to the above question, I found there is few description about IPsec processing. How should IPsec be applied to v4traversal scenario should be provided, IMHO. If it is expected to be similar to MIPv6 case (RFC 3776), the spec should say so. - In Section 3.1.1, header format of IPv4 home address option is defined. If I understand it correctly, the option allows BU to carry both IPv4 home address and MNP in a common formant. Let me clarify a little bit more: I assume that the single IPv4 home address option is allowed in a BU message but is it right ? As for IPv4 MNP, does the spec allow BU message to carry multiple IPv4 MNPs as in NEMO base protocol (I hope so) ? - There is no description about the case where MN returns home. Does v4traversal also support MN returning home ? Or is it outside of the scope ? - From security perspective, I believe HA should perform strict validity check for the incoming v4-tunneled traffic. Since the HA has no choice but to accept IPv4-tunneled packet from any IPv4 address (as the packet may contain BU from MN which has just moved to IPv4 network), decapsulation of the IPv4-tunneled packet should be carefully done. Otherwise, adding v4traversal feature may cause a security hole in HA, IMHO. So, the spec should state the need for the verification, and the steps of the validity check should be provided. For instance, [If the next header indicates that the inner packet is IPv6, then HA should first check its BCE and see if corresponding entry exists. If not, HA proceeds the validity check and see if the packet looks like BU (ESP protected packet) or not. If yes, pass the packet to IPsec processing. If not, discard the packet. If the inner packet is IPv4, HA should first check BCE and see if there is corresponding entry. If yes, pass the inner packet to the IPv4 input. If not, discard the packet.] Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------_436B3DC798DD06EC6D18_MULTIPART_MIXED_-- From nemo-bounces@ietf.org Fri Nov 04 06:36:59 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 1EXzsR-0006uz-U9; Fri, 04 Nov 2005 06:36:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzsQ-0006uu-Pw for nemo@megatron.ietf.org; Fri, 04 Nov 2005 06:36:58 -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 GAA13861 for ; Fri, 4 Nov 2005 06:36:36 -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 1EY07P-0003XH-Pw for nemo@ietf.org; Fri, 04 Nov 2005 06:52:28 -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 jA4BaYJK019362; Fri, 4 Nov 2005 20:36:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jA4BabS21236; Fri, 4 Nov 2005 20:36:37 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id jA4Baav21561; Fri, 4 Nov 2005 20:36:36 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 19:33:44 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id DE0ACD5509; Fri, 4 Nov 2005 19:41:43 +0800 (SGT) Subject: Sub-optimal Terminology (was Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <4366604F.9010503@motorola.com> References: <1129083768.9252.2.camel@localhost> <4366604F.9010503@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 04 Nov 2005 19:41:43 +0800 Message-Id: <1131104503.23646.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 04 Nov 2005 11:33:44.0709 (UTC) FILETIME=[9D364B50:01C5E133] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Mon, 2005-10-31 at 19:19 +0100, Alexandru Petrescu wrote: > 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 :-) OK. > > > 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. > OK. > Overall I like the document, it's short and easy to grasp for me, thanks > for maintaining it. Thanks for the suggestions. However, I do have a concern over the choice of words. It might suggest that perhaps a terminology is needed for the phenomenon where the routing path is anchored at the home agent(s). In MIPv6, I recall it used to be called "triangular routing" (traditionally though, I doubt it is used in RFC3775). You seems to favour the generalization of this term into "multi-angular routing". Logical, since with multiple HAs, there would be more than three vertexes. In some of the NEMO-related individual drafts (eg. draft-thubert-nemo-ro-taxonomy), there have been instances on the use of "dog-leg routing" and "pinball routing". In draft-ietf-nemo-ro-problem-statement, however, we have sticked to the very general term "sub-optimal routing". What do the rest of the WG think? Is there a need to have a more specific term? Or is sub-optimal routing good enough? /rgds /cwng From nemo-bounces@ietf.org Fri Nov 04 08:16:16 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 1EY1QW-0008UW-IR; Fri, 04 Nov 2005 08:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY1QQ-0008TJ-0W for nemo@megatron.ietf.org; Fri, 04 Nov 2005 08:16:14 -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 IAA18762 for ; Fri, 4 Nov 2005 08:15:47 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY1fP-0006He-4Z for nemo@ietf.org; Fri, 04 Nov 2005 08:31:40 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2005 14:16:00 +0100 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 jA4DFXdl018461; Fri, 4 Nov 2005 14:15:54 +0100 (MET) 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); Fri, 4 Nov 2005 14:15:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Next steps in RO Date: Fri, 4 Nov 2005 14:15:47 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0173F018@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Next steps in RO Thread-Index: AcXhKNadlPr0bFdiSz2TjD8aAszragAF4Ngg From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 04 Nov 2005 13:15:52.0399 (UTC) FILETIME=[E19995F0:01C5E141] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ml-nemo WG , "T.J. Kniveton" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Carlos:=20 >> [] I guess that item 2) is very broad in its description. So it = could cover the 2 approaches >that I detailed. And RO for your user in the bus could be handled in = both fashions. > > RO can be handled in both fashions if the communication peers are both >attached to NEMOs. If one peer is an LFN and the other one is a video >streaming server in the fixed Internet, then only one of the both >approaches aforementioned is valid. And if you want not to change or = add >any special support in the LFNs, then, as Chan-Wah said, the MR seems = to >be the natural entity to put special functionality into. > [] I'm not challenging the fact that the MR is a good position for = doing this on the LFN side :) In some case it surely is. Some other times, it might be simpler for = security reasons to place that feature in a proxy that is part of a = trust domain in the infrastructure. What I'm considering is the correspondent side. In the example you give, = and if RO is desirable, I'd think that the CR is the logical place to = terminate a tunnel started at the MR. There might be more ten one LFN in = the bus going to the same 'site' behind a same CR, and there's a benefit = in doing MR-CR as soon as you get a second connection. Note that I did not challenge the examples themselves but on the side: - in the case of a bus, Home might be very close (same city) and RO = might be less important than, say, for planes - If the correspondent is a video streaming server in the fixed = Internet, I doubt it will want to support CN, which is an additional = burden on its resources, and a source of DOS attacks even if the = protocol is as safe as can be. Also, there is a good chance that a load = balancer is placed in front of a large server site, and that load = balancer could be a *very* good place for a CR function :) Pascal From nemo-bounces@ietf.org Fri Nov 04 09:25:56 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 1EY2Vw-0006I7-T0; Fri, 04 Nov 2005 09:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2Vt-0006I2-RB for nemo@megatron.ietf.org; Fri, 04 Nov 2005 09:25:56 -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 JAA22846 for ; Fri, 4 Nov 2005 09:25:30 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY2kr-0008Od-6X for nemo@ietf.org; Fri, 04 Nov 2005 09:41:24 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 15:25:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Next steps in RO Date: Fri, 4 Nov 2005 15:24:25 +0100 Message-ID: Thread-Topic: [nemo] Next steps in RO Thread-Index: AcXgsXrzVJOgOy89Q+CzHtg7lxAx9AAaforwAAvL5zA= From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Pascal Thubert \(pthubert\)" , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 04 Nov 2005 14:25:45.0568 (UTC) FILETIME=[A4EC6600:01C5E14B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: ml-nemo WG , "T.J. Kniveton" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Friday, November 04, 2005 9:55 AM > To: Carlos Jes=FAs Bernardos Cano > Cc: ml-nemo WG; T.J. Kniveton; Chan-Wah NG > Subject: RE: [nemo] Next steps in RO >=20 > Hi Carlos :) >=20 > > > >Dear Pascal, > > > > > >> >(2) A mechanism for MRs to offer route optimization to LFNs. > >> > > >> >This is less important, but it's a mean to complete the entire RO=20 > >> >process. The mechanism above will allowed modified nodes=20 > (i.e. VMN)=20 > >> >to achieve RO in a way compatible to the more "legacy" MIPv6 RO. =20 > >> >This mechanism, will allow RO to be achieved for unmodified LFNs. > >> > > >> [] If you meant doing between MRs what MIP6 does between MNs,=20 > >> then I'd be with you. That is MRs locate each other, establish a=20 > >> tunnel and exchange MNP routes over that tunnel, using a signaling=20 > >> that is close to existing NEMO, directly or via MAPs, proxy HAs or=20 > >> such. I do think that this is really important and that we have to=20 > >> consider it in NEMO; for instance, 2) is the base for=20 > route projection. > >> > >> But if you mean MR doing some proxy MIP on behalf of LFN=20 > to be able=20 > >> to do RO with MIP6 CN, then I see that as a next step for=20 > proxy-MIP=20 > >> as opposed to a next step for NEMO, and I know of few=20 > scenarios that=20 > >> really require it. > > > > I disagree here. What about a NEMO in a train, bus, ...=20 > in which=20 > >passengers switch on their laptops/PDAs, obtain an IPv6 address=20 > >belonging to the MNP deployed in the NEMO (through stateless/stateful > >autoconfiguration) and start communicating using this IP address?.=20 > >These nodes would be LFNs (since they are using addresses=20 > belonging to=20 > >the NEMO and are not going to move from this network to a different=20 > >one) and I clearly see the benefit from enabling the traffic=20 > of these=20 > >nodes to be route optimised. > > > [] I guess that item 2) is very broad in its description.=20 > So it could cover the 2 approaches that I detailed. And RO=20 > for your user in the bus could be handled in both fashions. >=20 > What I believe is that the MR takes things up one step,=20 > placing things from the host based to the prefix based. So RO=20 > between MRs, or MR to CR makes more sense to me then spoofed=20 > MIP RO between LFN and CN. >From a security point of view, spoofing sets up always security issues = (e.g. trustship between the "spoofer" and the "spoofed", how to control = the rights of the "spoofer", how to give the security material to the = "spoofer", etc.) ... So I prefer Pascal's ideas. >=20 > In your bus case, if, say, the correspondent is in another=20 > bus or a train, then MR to MR RO will do the job. But MR to=20 > MR RO has a number of other applications:=20 >=20 > For instance, say a bunch of MRs establish a mesh of MRMR=20 > tunnels, and exchange MNP routes, using NEMO based RO; they=20 > end up forming a community, a form of dynamic VPN if you=20 > wish. If you couple that with a MIPTRANS type of solution,=20 > the encapsulation could be IPv4, and the backbone the current=20 > IPv4 infrastructure, while the 'VPN' is dual stack or IPv6 only. >=20 > Something like that changes the Internet Model from a common=20 > grid where you have your given position (your IPv4 address)=20 > to an infinite number of user or application centric=20 > on-demand networks, and you can scale to the sky. I think=20 > it's worth considering, even if the goal is a bit far-fetched... >=20 > Pascal >=20 >=20 >=20 >=20 >=20 Cheers. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 =20 From nemo-bounces@ietf.org Fri Nov 04 14:43:09 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 1EY7Sv-0006Bb-OD; Fri, 04 Nov 2005 14:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7Su-0006BN-5U for nemo@megatron.ietf.org; Fri, 04 Nov 2005 14:43:08 -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 OAA09149 for ; Fri, 4 Nov 2005 14:42:44 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY7hv-0008V1-1C for nemo@ietf.org; Fri, 04 Nov 2005 14:58:41 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B78CA82FD9; Fri, 4 Nov 2005 20:42:52 +0100 (CET) Received: from acorde-it-uc3m-es.it.uc3m.es (unknown [163.117.139.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 9A1B482FCB; Fri, 4 Nov 2005 20:42:51 +0100 (CET) Subject: RE: [nemo] Next steps in RO From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: COMBES Jean-Michel RD-MAPS-ISS In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CKoCpkJYkpEFKCPjp/ox" Organization: UC3M Date: Fri, 04 Nov 2005 20:42:58 +0100 Message-Id: <1131133378.5766.5.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ml-nemo WG , "T.J. Kniveton" , "Pascal Thubert \(pthubert\)" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-CKoCpkJYkpEFKCPjp/ox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Jean-Michel, El vie, 04-11-2005 a las 15:24 +0100, COMBES Jean-Michel RD-MAPS-ISS escribi=F3:=20 > Hi, >=20 > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On=20 > > Behalf Of Pascal Thubert (pthubert) > > Sent: Friday, November 04, 2005 9:55 AM > > To: Carlos Jes=FAs Bernardos Cano > > Cc: ml-nemo WG; T.J. Kniveton; Chan-Wah NG > > Subject: RE: [nemo] Next steps in RO > >=20 > > Hi Carlos :) > >=20 > > > > > >Dear Pascal, > > > > > > > > >> >(2) A mechanism for MRs to offer route optimization to LFNs. > > >> > > > >> >This is less important, but it's a mean to complete the entire RO=20 > > >> >process. The mechanism above will allowed modified nodes=20 > > (i.e. VMN)=20 > > >> >to achieve RO in a way compatible to the more "legacy" MIPv6 RO. =20 > > >> >This mechanism, will allow RO to be achieved for unmodified LFNs. > > >> > > > >> [] If you meant doing between MRs what MIP6 does between MNs,=20 > > >> then I'd be with you. That is MRs locate each other, establish a=20 > > >> tunnel and exchange MNP routes over that tunnel, using a signaling=20 > > >> that is close to existing NEMO, directly or via MAPs, proxy HAs or=20 > > >> such. I do think that this is really important and that we have to=20 > > >> consider it in NEMO; for instance, 2) is the base for=20 > > route projection. > > >> > > >> But if you mean MR doing some proxy MIP on behalf of LFN=20 > > to be able=20 > > >> to do RO with MIP6 CN, then I see that as a next step for=20 > > proxy-MIP=20 > > >> as opposed to a next step for NEMO, and I know of few=20 > > scenarios that=20 > > >> really require it. > > > > > > I disagree here. What about a NEMO in a train, bus, ...=20 > > in which=20 > > >passengers switch on their laptops/PDAs, obtain an IPv6 address=20 > > >belonging to the MNP deployed in the NEMO (through stateless/stateful > > >autoconfiguration) and start communicating using this IP address?.=20 > > >These nodes would be LFNs (since they are using addresses=20 > > belonging to=20 > > >the NEMO and are not going to move from this network to a different=20 > > >one) and I clearly see the benefit from enabling the traffic=20 > > of these=20 > > >nodes to be route optimised. > > > > > [] I guess that item 2) is very broad in its description.=20 > > So it could cover the 2 approaches that I detailed. And RO=20 > > for your user in the bus could be handled in both fashions. > >=20 > > What I believe is that the MR takes things up one step,=20 > > placing things from the host based to the prefix based. So RO=20 > > between MRs, or MR to CR makes more sense to me then spoofed=20 > > MIP RO between LFN and CN. >=20 > From a security point of view, spoofing sets up always security issues (e= .g. trustship between the "spoofer" and the "spoofed", how to control the r= ights of the "spoofer", how to give the security material to the "spoofer",= etc.) ... So I prefer Pascal's ideas. Mobile IPv6 does not protect against attackers in the path. Therefore, NEMO RO approaches based on the MR performing the MIPv6 RO signalling on behalf of the LFNs do not introduce new threads that cannot be performed with MIPv6. Kind regards, Carlos J. >=20 > >=20 > > In your bus case, if, say, the correspondent is in another=20 > > bus or a train, then MR to MR RO will do the job. But MR to=20 > > MR RO has a number of other applications:=20 > >=20 > > For instance, say a bunch of MRs establish a mesh of MRMR=20 > > tunnels, and exchange MNP routes, using NEMO based RO; they=20 > > end up forming a community, a form of dynamic VPN if you=20 > > wish. If you couple that with a MIPTRANS type of solution,=20 > > the encapsulation could be IPv4, and the backbone the current=20 > > IPv4 infrastructure, while the 'VPN' is dual stack or IPv6 only. > >=20 > > Something like that changes the Internet Model from a common=20 > > grid where you have your given position (your IPv4 address)=20 > > to an infinite number of user or application centric=20 > > on-demand networks, and you can scale to the sky. I think=20 > > it's worth considering, even if the goal is a bit far-fetched... > >=20 > > Pascal > >=20 > >=20 > >=20 > >=20 > >=20 >=20 > Cheers. >=20 > JMC. >=20 > France Telecom - R&D Division - MAPS/NSS =20 > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16=20 > =20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-CKoCpkJYkpEFKCPjp/ox Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDa7nC7QxZUr+JuXQRAqCjAJ9HU6RNhQVIQRyeZ/xy/YJWUNl4jgCfV5Ys +lkGMO39kk0DKvZq5FJISRs= =JDuL -----END PGP SIGNATURE----- --=-CKoCpkJYkpEFKCPjp/ox-- From nemo-bounces@ietf.org Fri Nov 04 17:02:17 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 1EY9dZ-00052r-Ob; Fri, 04 Nov 2005 17:02:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY9dX-00052j-Sy for nemo@megatron.ietf.org; Fri, 04 Nov 2005 17:02:15 -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 RAA16815 for ; Fri, 4 Nov 2005 17:01:51 -0500 (EST) 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 1EY9sW-00047N-H3 for nemo@ietf.org; Fri, 04 Nov 2005 17:17:50 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 4FA4C8AB9D4 for ; Fri, 4 Nov 2005 14:00:19 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35080-13 for ; Fri, 4 Nov 2005 14:00:11 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 97FCE8AB9D6; Fri, 4 Nov 2005 14:00:11 -0800 (PST) X-Spam-Score: -3.3 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-3.3 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 45FEC8AB98E for ; Fri, 4 Nov 2005 14:00:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <1130999803.13516.30.camel@localhost> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@motorola.com> <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> <1130999803.13516.30.camel@localhost> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FCE25F5-65BD-43D8-A55A-58DEC23B5421@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Next steps in RO Date: Fri, 4 Nov 2005 14:01:45 -0800 To: ml-nemo WG X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 On Nov 2, 2005, at 10:36 PM, Chan-Wah NG wrote: > This > mechanism, will allow RO to be achieved for unmodified LFNs. [...] > The deployment of such an entity would allow two benefits: (1) perform > RO for non-modified CNs, I would assume that LFNs (by definition) and CNs (by convention) would be unmodified by NEMO/MIPv6. Any statement to the contrary should contain a really good motivation and explanation for what should be modified and why. TJ From nemo-bounces@ietf.org Fri Nov 04 17:10:28 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 1EY9lU-0006RC-Lv; Fri, 04 Nov 2005 17:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY9lT-0006R5-P4 for nemo@megatron.ietf.org; Fri, 04 Nov 2005 17:10:27 -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 RAA17119 for ; Fri, 4 Nov 2005 17:10:03 -0500 (EST) 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 1EYA0W-0004IP-TV for nemo@ietf.org; Fri, 04 Nov 2005 17:26:03 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 798A58AB825 for ; Fri, 4 Nov 2005 14:08:46 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35461-05 for ; Fri, 4 Nov 2005 14:08:38 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id C4B668ABA7B; Fri, 4 Nov 2005 14:08:38 -0800 (PST) X-Spam-Score: -3.2 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-3.2 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 5BB828AB9E0 for ; Fri, 4 Nov 2005 14:08:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <1131104503.23646.40.camel@localhost> References: <1129083768.9252.2.camel@localhost> <4366604F.9010503@motorola.com> <1131104503.23646.40.camel@localhost> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: Sub-optimal Terminology (was Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) Date: Fri, 4 Nov 2005 14:10:12 -0800 To: IETF NEMO WG X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 On Nov 4, 2005, at 3:41 AM, Chan-Wah Ng wrote: > Thanks for the suggestions. However, I do have a concern over the > choice of words. It might suggest that perhaps a terminology is > needed > for the phenomenon where the routing path is anchored at the home > agent(s). > > In MIPv6, I recall it used to be called "triangular > routing" (traditionally though, I doubt it is used in RFC3775). > > You seems to favour the generalization of this term into "multi- > angular > routing". Logical, since with multiple HAs, there would be more than > three vertexes. Multi-angular makes less sense to me than triangular. > > In some of the NEMO-related individual drafts (eg. > draft-thubert-nemo-ro-taxonomy), there have been instances on the > use of > "dog-leg routing" and "pinball routing". dog-leg routing is sometimes used to be roughly synonymous to triangular routing. Pinball routing is a term which describes the route getting bounced back and forth like a pinball. I don't know whether it's used in other places in routing literature; I hadn't heard it before. > > In draft-ietf-nemo-ro-problem-statement, however, we have sticked > to the > very general term "sub-optimal routing". Sub-optimal routing, as you mentioned, is very general. In fact, whereas pinball, triangular and dog-leg routing describe routing phenomena in certain circumstances, sub-optimal routing describes a general quality, not a specific scenario. It could mean almost anything other than shortest / cheapest path. > > What do the rest of the WG think? Is there a need to have a more > specific term? Or is sub-optimal routing good enough? I'd like to use a different term, though I'm not sure the best one has been suggested yet. TJ From nemo-bounces@ietf.org Fri Nov 04 19:09:59 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 1EYBd9-0002ki-Fk; Fri, 04 Nov 2005 19:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBd8-0002ka-84 for nemo@megatron.ietf.org; Fri, 04 Nov 2005 19:09:58 -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 TAA23441 for ; Fri, 4 Nov 2005 19:09:35 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBsD-0007Z3-3d for nemo@ietf.org; Fri, 04 Nov 2005 19:25:34 -0500 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1A7A84C61B for ; Sat, 5 Nov 2005 09:09:29 +0900 (JST) Date: Sat, 5 Nov 2005 09:09:32 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Next steps in RO Message-Id: <20051105090932.1333dc6a.ernst@sfc.wide.ad.jp> In-Reply-To: <5FCE25F5-65BD-43D8-A55A-58DEC23B5421@kniveton.com> References: <1130764060.19589.13.camel@localhost> <43665B2C.5020808@motorola.com> <20051101161637.0c1e00ee.ernst@sfc.wide.ad.jp> <8DA684CF-7161-440B-8C95-0A15D1500AFE@kniveton.com> <1130999803.13516.30.camel@localhost> <5FCE25F5-65BD-43D8-A55A-58DEC23B5421@kniveton.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: 7d33c50f3756db14428398e2bdedd581 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 > > This > > mechanism, will allow RO to be achieved for unmodified LFNs. > [...] > > The deployment of such an entity would allow two benefits: (1) > > perform RO for non-modified CNs, > > I would assume that LFNs (by definition) and CNs (by convention) > would be unmodified by NEMO/MIPv6. Any statement to the contrary > should contain a really good motivation and explanation for what > should be modified and why. While I think this is desirable, I think the contrary is not a problem (as long as there are motivations for changing nodes) since this is an optimization. An optimization doesn't need to leave all nodes unchanged; nodes with no extensions could just not use the optimized path, but could still use the non-optimized path. So, I share TJ concerns, but this is not a design requirement IMHO. Thierry From nemo-bounces@ietf.org Sun Nov 06 16:47:59 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 1EYsMp-0006Er-M7; Sun, 06 Nov 2005 16:47:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsMo-0006Ei-CW for nemo@megatron.ietf.org; Sun, 06 Nov 2005 16:47:58 -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 QAA22079 for ; Sun, 6 Nov 2005 16:47:33 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYscI-0005qt-3c for nemo@ietf.org; Sun, 06 Nov 2005 17:03:58 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C7DAAEC8F1; Mon, 7 Nov 2005 06:47:27 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6129AEC8BA; Mon, 7 Nov 2005 06:47:27 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:5712] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:5712]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 966532E05C; Mon, 7 Nov 2005 06:47:12 +0900 (JST) Message-ID: <436E79F4.7040902@kddilabs.jp> Date: Mon, 07 Nov 2005 06:47:32 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: Sub-optimal Terminology (was Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) References: <1129083768.9252.2.camel@localhost> <4366604F.9010503@motorola.com> <1131104503.23646.40.camel@localhost> <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> In-Reply-To: <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Alex, thanks for your comments. Overall, I agree about making it clear on what the problem is. Some comments about the terminology below. On 2005/11/05 7:10, T.J. Kniveton wrote: > On Nov 4, 2005, at 3:41 AM, Chan-Wah Ng wrote: > >> Thanks for the suggestions. However, I do have a concern over the >> choice of words. It might suggest that perhaps a terminology is needed >> for the phenomenon where the routing path is anchored at the home >> agent(s). >> >> In MIPv6, I recall it used to be called "triangular >> routing" (traditionally though, I doubt it is used in RFC3775). >> >> You seems to favour the generalization of this term into "multi- angular >> routing". Logical, since with multiple HAs, there would be more than >> three vertexes. > > Multi-angular makes less sense to me than triangular. I agree. >> >> In some of the NEMO-related individual drafts (eg. >> draft-thubert-nemo-ro-taxonomy), there have been instances on the use of >> "dog-leg routing" and "pinball routing". > > dog-leg routing is sometimes used to be roughly synonymous to > triangular routing. Pinball routing is a term which describes the route > getting bounced back and forth like a pinball. I don't know whether > it's used in other places in routing literature; I hadn't heard it before. > >> >> In draft-ietf-nemo-ro-problem-statement, however, we have sticked to the >> very general term "sub-optimal routing". > > > Sub-optimal routing, as you mentioned, is very general. In fact, > whereas pinball, triangular and dog-leg routing describe routing > phenomena in certain circumstances, sub-optimal routing describes a > general quality, not a specific scenario. It could mean almost anything > other than shortest / cheapest path. In keeping the document at a generic level, I don't see any problem using sub-optimal routing. I mean with nested-NEMO, you could draw lines that look like a star for example... >> What do the rest of the WG think? Is there a need to have a more >> specific term? Or is sub-optimal routing good enough? > > I'd like to use a different term, though I'm not sure the best one has > been suggested yet. watari From nemo-bounces@ietf.org Sun Nov 06 20:20:12 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 1EYvgC-0004yM-Jk; Sun, 06 Nov 2005 20:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYvg9-0004yE-F7 for nemo@megatron.ietf.org; Sun, 06 Nov 2005 20:20:11 -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 UAA02653 for ; Sun, 6 Nov 2005 20:19:43 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYvvd-0002Ri-Pj for nemo@ietf.org; Sun, 06 Nov 2005 20:36:11 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 02:20:01 +0100 Received: from [209.52.152.191] ([10.193.106.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 02:20:01 +0100 Message-ID: <436EABA1.4030607@francetelecom.com> Date: Mon, 07 Nov 2005 02:19:29 +0100 From: Jean-Michel COMBES User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Next steps in RO References: <1131133378.5766.5.camel@acorde> In-Reply-To: <1131133378.5766.5.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 07 Nov 2005 01:20:01.0817 (UTC) FILETIME=[604C2090:01C5E339] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA02653 Cc: ml-nemo WG , "T.J. Kniveton" , "Pascal Thubert \(pthubert\)" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Carlos Jes=FAs Bernardos Cano a =E9crit : >Dear Jean-Michel, > >El vie, 04-11-2005 a las 15:24 +0100, COMBES Jean-Michel RD-MAPS-ISS >escribi=F3:=20 > =20 > >>Hi, >> =20 >> [snip] >>>[] I guess that item 2) is very broad in its description.=20 >>>So it could cover the 2 approaches that I detailed. And RO=20 >>>for your user in the bus could be handled in both fashions. >>> >>>What I believe is that the MR takes things up one step,=20 >>>placing things from the host based to the prefix based. So RO=20 >>>between MRs, or MR to CR makes more sense to me then spoofed=20 >>>MIP RO between LFN and CN. >>> =20 >>> >>From a security point of view, spoofing sets up always security issues = (e.g. trustship between the "spoofer" and the "spoofed", how to control t= he rights of the "spoofer", how to give the security material to the "spo= ofer", etc.) ... So I prefer Pascal's ideas. >> =20 >> > >Mobile IPv6 does not protect against attackers in the path. Therefore, >NEMO RO approaches based on the MR performing the MIPv6 RO signalling on >behalf of the LFNs do not introduce new threads that cannot be performed >with MIPv6. > >Kind regards, > >Carlos J. > =20 > I am not speaking about the security on the path but on the fact that if=20 this is the MR that will perform the RO on behalf of the LFNs, this will=20 introduce security issues (e.g. trustship between the MR and the LFN,=20 how to control the rights of the MR, how to give the security material=20 to the MR, etc.). And as far as I know, there is no such concept in MIPv6: this is the MN=20 itself that is doing RO. Regards. JMC. > =20 > >>>In your bus case, if, say, the correspondent is in another=20 >>>bus or a train, then MR to MR RO will do the job. But MR to=20 >>>MR RO has a number of other applications:=20 >>> >>>For instance, say a bunch of MRs establish a mesh of MRMR=20 >>>tunnels, and exchange MNP routes, using NEMO based RO; they=20 >>>end up forming a community, a form of dynamic VPN if you=20 >>>wish. If you couple that with a MIPTRANS type of solution,=20 >>>the encapsulation could be IPv4, and the backbone the current=20 >>>IPv4 infrastructure, while the 'VPN' is dual stack or IPv6 only. >>> >>>Something like that changes the Internet Model from a common=20 >>>grid where you have your given position (your IPv4 address)=20 >>>to an infinite number of user or application centric=20 >>>on-demand networks, and you can scale to the sky. I think=20 >>>it's worth considering, even if the goal is a bit far-fetched... >>> >>>Pascal >>> >>> >>> >>> >>> >>> =20 >>> >>Cheers. >> >>JMC. >> >>France Telecom - R&D Division - MAPS/NSS =20 >>Jean-Michel COMBES, Internet/Intranet Security >>E-Mail: jeanmichel.combes@francetelecom.com >>Phone: +33 (0)1 45 29 45 94 >>Fax: +33 (0)1 45 29 65 19 >>Mobile: +33 (0)6 07 29 30 16=20 >>=20 >> =20 >> From nemo-bounces@ietf.org Mon Nov 07 05:04:56 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 1EZ3s0-00017b-Hu; Mon, 07 Nov 2005 05:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3ry-00017N-Up for nemo@megatron.ietf.org; Mon, 07 Nov 2005 05:04:55 -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 FAA29860 for ; Mon, 7 Nov 2005 05:04:27 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ47T-00076R-1E for nemo@ietf.org; Mon, 07 Nov 2005 05:20:59 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D4A3B840A5; Mon, 7 Nov 2005 11:04:26 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id EA2E383F68; Mon, 7 Nov 2005 11:04:25 +0100 (CET) Subject: Re: [nemo] Next steps in RO From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jean-Michel COMBES In-Reply-To: <436EABA1.4030607@francetelecom.com> References: <1131133378.5766.5.camel@acorde> <436EABA1.4030607@francetelecom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9XB7lnvCxITdzQW4CNgN" Organization: UC3M Date: Mon, 07 Nov 2005 11:04:49 +0100 Message-Id: <1131357889.7374.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: ml-nemo WG , "T.J. Kniveton" , "Pascal Thubert \(pthubert\)" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-9XB7lnvCxITdzQW4CNgN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Jean-Michel, El lun, 07-11-2005 a las 02:19 +0100, Jean-Michel COMBES escribi=F3: > Hi, >=20 > Carlos Jes=FAs Bernardos Cano a =E9crit : >=20 > >Dear Jean-Michel, > > > >El vie, 04-11-2005 a las 15:24 +0100, COMBES Jean-Michel RD-MAPS-ISS > >escribi=F3:=20 > > =20 > > > >>Hi, > >> =20 > >> > [snip] >=20 > >>>[] I guess that item 2) is very broad in its description.=20 > >>>So it could cover the 2 approaches that I detailed. And RO=20 > >>>for your user in the bus could be handled in both fashions. > >>> > >>>What I believe is that the MR takes things up one step,=20 > >>>placing things from the host based to the prefix based. So RO=20 > >>>between MRs, or MR to CR makes more sense to me then spoofed=20 > >>>MIP RO between LFN and CN. > >>> =20 > >>> > >>From a security point of view, spoofing sets up always security issues = (e.g. trustship between the "spoofer" and the "spoofed", how to control the= rights of the "spoofer", how to give the security material to the "spoofer= ", etc.) ... So I prefer Pascal's ideas. > >> =20 > >> > > > >Mobile IPv6 does not protect against attackers in the path. Therefore, > >NEMO RO approaches based on the MR performing the MIPv6 RO signalling on > >behalf of the LFNs do not introduce new threads that cannot be performed > >with MIPv6. > > > >Kind regards, > > > >Carlos J. > > =20 > > > I am not speaking about the security on the path but on the fact that if=20 > this is the MR that will perform the RO on behalf of the LFNs, this will=20 > introduce security issues (e.g. trustship between the MR and the LFN,=20 > how to control the rights of the MR, how to give the security material=20 > to the MR, etc.). > And as far as I know, there is no such concept in MIPv6: this is the MN=20 > itself that is doing RO. Yes, but the MR is taking care of the LFN's traffic anyway, so there is an implicit delegation. The MR would be able to make the same kind of attacks without performing RO. By the way, we have also analysed other ways of performing RO taking into account delegation issues ([1]). Kind Regards, Carlos J. [1] Securing Route Optimisation in NEMO Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio Soto Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, 2005. WIOPT 2005. Third International Symposium on=20 3-7 April 2005 Page(s): 248 - 254 >=20 > Regards. >=20 > JMC. >=20 > > =20 > > > >>>In your bus case, if, say, the correspondent is in another=20 > >>>bus or a train, then MR to MR RO will do the job. But MR to=20 > >>>MR RO has a number of other applications:=20 > >>> > >>>For instance, say a bunch of MRs establish a mesh of MRMR=20 > >>>tunnels, and exchange MNP routes, using NEMO based RO; they=20 > >>>end up forming a community, a form of dynamic VPN if you=20 > >>>wish. If you couple that with a MIPTRANS type of solution,=20 > >>>the encapsulation could be IPv4, and the backbone the current=20 > >>>IPv4 infrastructure, while the 'VPN' is dual stack or IPv6 only. > >>> > >>>Something like that changes the Internet Model from a common=20 > >>>grid where you have your given position (your IPv4 address)=20 > >>>to an infinite number of user or application centric=20 > >>>on-demand networks, and you can scale to the sky. I think=20 > >>>it's worth considering, even if the goal is a bit far-fetched... > >>> > >>>Pascal > >>> > >>> > >>> > >>> > >>> > >>> =20 > >>> > >>Cheers. > >> > >>JMC. > >> > >>France Telecom - R&D Division - MAPS/NSS =20 > >>Jean-Michel COMBES, Internet/Intranet Security > >>E-Mail: jeanmichel.combes@francetelecom.com > >>Phone: +33 (0)1 45 29 45 94 > >>Fax: +33 (0)1 45 29 65 19 > >>Mobile: +33 (0)6 07 29 30 16=20 > >>=20 > >> =20 > >> >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-9XB7lnvCxITdzQW4CNgN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDbybA7QxZUr+JuXQRAuskAJ9YNWI51pLPCvJQm0qbhBlR0tn/sgCeK+fO HfPOtc2DGF7fQzNCUOWz100= =Vxq1 -----END PGP SIGNATURE----- --=-9XB7lnvCxITdzQW4CNgN-- From nemo-bounces@ietf.org Mon Nov 07 14:29:24 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 1EZCgG-0000Kf-RI; Mon, 07 Nov 2005 14:29:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCgE-0000KS-Tj for nemo@megatron.ietf.org; Mon, 07 Nov 2005 14:29:23 -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 OAA02253 for ; Mon, 7 Nov 2005 14:28:56 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCvt-0005uC-U8 for nemo@ietf.org; Mon, 07 Nov 2005 14:45:34 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 20:29:19 +0100 Received: from [209.52.105.152] ([10.193.106.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 20:29:19 +0100 Message-ID: <436FAB0B.50409@francetelecom.com> Date: Mon, 07 Nov 2005 20:29:15 +0100 From: Jean-Michel COMBES User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] Next steps in RO References: <1131133378.5766.5.camel@acorde> <436EABA1.4030607@francetelecom.com> <1131357889.7374.19.camel@localhost> In-Reply-To: <1131357889.7374.19.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 07 Nov 2005 19:29:19.0422 (UTC) FILETIME=[8C7735E0:01C5E3D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA02253 Cc: ml-nemo WG , "T.J. Kniveton" , "Pascal Thubert \(pthubert\)" , Chan-Wah NG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Carlos Jes=FAs Bernardos Cano a =E9crit : >Dear Jean-Michel, > >El lun, 07-11-2005 a las 02:19 +0100, Jean-Michel COMBES escribi=F3: > =20 > >>Hi, >> >>Carlos Jes=FAs Bernardos Cano a =E9crit : >> >> =20 >> >>>Dear Jean-Michel, >>> >>>El vie, 04-11-2005 a las 15:24 +0100, COMBES Jean-Michel RD-MAPS-ISS >>>escribi=F3:=20 >>>=20 >>> >>> =20 >>> >>>>Hi, >>>> =20 >>>> >>>> =20 >>>> >>[snip] >> >> =20 >> >>>>>[] I guess that item 2) is very broad in its description.=20 >>>>>So it could cover the 2 approaches that I detailed. And RO=20 >>>>>for your user in the bus could be handled in both fashions. >>>>> >>>>>What I believe is that the MR takes things up one step,=20 >>>>>placing things from the host based to the prefix based. So RO=20 >>>>>between MRs, or MR to CR makes more sense to me then spoofed=20 >>>>>MIP RO between LFN and CN. >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>From a security point of view, spoofing sets up always security issue= s (e.g. trustship between the "spoofer" and the "spoofed", how to control= the rights of the "spoofer", how to give the security material to the "s= poofer", etc.) ... So I prefer Pascal's ideas. >>> =20 >>> >>>> =20 >>>> >>>> =20 >>>> >>>Mobile IPv6 does not protect against attackers in the path. Therefore, >>>NEMO RO approaches based on the MR performing the MIPv6 RO signalling = on >>>behalf of the LFNs do not introduce new threads that cannot be perform= ed >>>with MIPv6. >>> >>>Kind regards, >>> >>>Carlos J. >>>=20 >>> >>> =20 >>> >>I am not speaking about the security on the path but on the fact that i= f=20 >>this is the MR that will perform the RO on behalf of the LFNs, this wil= l=20 >>introduce security issues (e.g. trustship between the MR and the LFN,=20 >>how to control the rights of the MR, how to give the security material=20 >>to the MR, etc.). >>And as far as I know, there is no such concept in MIPv6: this is the MN= =20 >>itself that is doing RO. >> =20 >> > > Yes, but the MR is taking care of the LFN's traffic anyway, so there is >an implicit delegation. > Sorry, but I don't agree with you on the fact that a node which is=20 linked with a Access Router, has always a strong trustship with it. > The MR would be able to make the same kind of >attacks without performing RO. > May you precise, please? Because I don't see which attacks you speak abou= t. > By the way, we have also analysed other >ways of performing RO taking into account delegation issues ([1]). > =20 > I tried to get the paper on WWW but I did'nt find it. May you send it to=20 me, please? Thanks. Best regards. JMC. > Kind Regards, > > Carlos J. > >[1] Securing Route Optimisation in NEMO >Mar=EDa Calder=F3n, Carlos Jes=FAs Bernardos, Marcelo Bagnulo, Ignacio S= oto >Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, >2005. WIOPT 2005. Third International Symposium on=20 >3-7 April 2005 Page(s): 248 - 254 > > =20 > >>Regards. >> >>JMC. >> >> =20 >> >>>=20 >>> >>> =20 >>> >>>>>In your bus case, if, say, the correspondent is in another=20 >>>>>bus or a train, then MR to MR RO will do the job. But MR to=20 >>>>>MR RO has a number of other applications:=20 >>>>> >>>>>For instance, say a bunch of MRs establish a mesh of MRMR=20 >>>>>tunnels, and exchange MNP routes, using NEMO based RO; they=20 >>>>>end up forming a community, a form of dynamic VPN if you=20 >>>>>wish. If you couple that with a MIPTRANS type of solution,=20 >>>>>the encapsulation could be IPv4, and the backbone the current=20 >>>>>IPv4 infrastructure, while the 'VPN' is dual stack or IPv6 only. >>>>> >>>>>Something like that changes the Internet Model from a common=20 >>>>>grid where you have your given position (your IPv4 address)=20 >>>>>to an infinite number of user or application centric=20 >>>>>on-demand networks, and you can scale to the sky. I think=20 >>>>>it's worth considering, even if the goal is a bit far-fetched... >>>>> >>>>>Pascal >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>Cheers. >>>> >>>>JMC. >>>> >>>>France Telecom - R&D Division - MAPS/NSS =20 >>>>Jean-Michel COMBES, Internet/Intranet Security >>>>E-Mail: jeanmichel.combes@francetelecom.com >>>>Phone: +33 (0)1 45 29 45 94 >>>>Fax: +33 (0)1 45 29 65 19 >>>>Mobile: +33 (0)6 07 29 30 16=20 >>>> >>>> =20 >>>> >>>> =20 >>>> From nemo-bounces@ietf.org Mon Nov 07 19:18:04 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 1EZHBc-0000Sy-10; Mon, 07 Nov 2005 19:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHBb-0000SN-3j for nemo@megatron.ietf.org; Mon, 07 Nov 2005 19:18:03 -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 TAA25829 for ; Mon, 7 Nov 2005 19:17:37 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHRH-00081H-PW for nemo@ietf.org; Mon, 07 Nov 2005 19:34:17 -0500 Received: from iseran.local (unknown [IPv6:2001:410:1000:f000:20a:95ff:fef5:49a5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B08CF4C584 for ; Tue, 8 Nov 2005 09:17:33 +0900 (JST) Date: Tue, 8 Nov 2005 09:12:52 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20051108091252.6b2716b9.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.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [nemo] WG Last Call on 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 Dear all, [I thought I sent this WGLC at the same time as the other for nemo-terminology but it was still in my draft mail folder ...] This is a WG last call for draft-ietf-nemo-requirements before submission to the IESG. The call ends on Nov.16th. A revised version was submitted recently: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt or http://www.mobilenetworks/nemo/drafts/draft-ietf-nemo-requirements-05.html There aren't any significant changes besides editing ones. One thing I did was to refer all draft-ietf-nemo- drafts from the requirement document. 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 has concerns, or new issues, I will close all issues marked "Validate B4 Closing" and send the document to the IESG. 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 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 From nemo-bounces@ietf.org Mon Nov 07 20:16:39 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 1EZI6J-0001R1-3w; Mon, 07 Nov 2005 20:16:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZI6I-0001Qi-3f for nemo@megatron.ietf.org; Mon, 07 Nov 2005 20:16:38 -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 UAA28714 for ; Mon, 7 Nov 2005 20:16:11 -0500 (EST) Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZILy-00012P-VU for nemo@ietf.org; Mon, 07 Nov 2005 20:32:52 -0500 Received: (qmail 17023 invoked from network); 8 Nov 2005 10:16:13 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 8 Nov 2005 10:16:13 +0900 To: nemo@ietf.org From: "K.Kawaguchi" Message-Id: <200511081016.DCB64543.VUBHBJLX@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 8 Nov 2005 10:16:12 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [nemo] developing conformance tests and interoperability tests for 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 Dear all, We are researching and developing conformance tests and interoperability tests for NEMO basic(RFC3963). And we are requesting the opinion of the tests under developing. Please look for following URL if you are interested. Our Conformance tests and Scenario tests have been opened to the public. http://www.tahi.org/nemo/ Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp From nemo-bounces@ietf.org Mon Nov 07 20:45:29 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 1EZIYD-0000Hl-8R; Mon, 07 Nov 2005 20:45:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIYB-0000Hd-TA for nemo@megatron.ietf.org; Mon, 07 Nov 2005 20:45:27 -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 UAA29903 for ; Mon, 7 Nov 2005 20:45:01 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZInt-0001eY-F8 for nemo@ietf.org; Mon, 07 Nov 2005 21:01:42 -0500 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA81vZ1p005034; Mon, 7 Nov 2005 18:57:36 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA81t8xY021624; Mon, 7 Nov 2005 19:55:09 -0600 (CST) Message-ID: <4370032D.9040503@motorola.com> Date: Mon, 07 Nov 2005 17:45:17 -0800 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: Ryuji Wakikawa Subject: Re: [nemo] v4traversal ID 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: IETF WG 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 Dear Ryuji, thanks for posting. I have sent several reviewing remarks on the mip6 list where it was initially announced. There was a long thread about it on the mip6 list. It would be good to discuss this draft on a single list. The main remark I had about is that it looks good and has good ideas in it. Having an IPv4 address in the v6 BC may help a lot with v4 traversal for MH and MR. I also suggested that giving v4 access to LFNs of an MR, when MR connects to a v4 network, may be realised more naturally with MIP4 extensions instead of MIP6 extensions. Also suggested that the draft does not address proxy-ARP for HA for the v4 Home Address nor how MH may change its v4 CoA when connecting to a FA-based v4 network. Also suggested that 7-author list may look a little long, more than 5 is probably too high. What do you think about these items? What do you think about NEMOv4 extensions to MIP4 to achieve the goal of giving v4 access to LFNs when the MR connects to a v4-only network? Thanks, Alex Ryuji Wakikawa wrote: > Hi all, > > We have submitted a draft on MIP6/NEMO v4 traversal. > This is both MIP6 and NEMO WG document. > Your comments are really appreciated. > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- > v4traversal-00.txt > > thanks > ryuji > > From nemo-bounces@ietf.org Mon Nov 07 20:51:25 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 1EZIdx-0001ki-Ow; Mon, 07 Nov 2005 20:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIdw-0001j9-Q9 for nemo@megatron.ietf.org; Mon, 07 Nov 2005 20:51:24 -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 UAA00300 for ; Mon, 7 Nov 2005 20:50:58 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZItf-0001pw-Cl for nemo@ietf.org; Mon, 07 Nov 2005 21:07:39 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA823cv6005674; Mon, 7 Nov 2005 19:03:38 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA821tFM024090; Mon, 7 Nov 2005 20:01:56 -0600 (CST) Message-ID: <43700497.20100@motorola.com> Date: Mon, 07 Nov 2005 17:51:19 -0800 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: Ryuji Wakikawa Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> In-Reply-To: <54F01906-71A5-441B-9565-92855B2C3ACB@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: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Denis Ortega , Vijay Devarapalli , 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 Ryuji Wakikawa wrote: >> Alexandru Petrescu wrote: >> >>> 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. >> >> >> RFC 3963 assumes DHAAD is used to obtain the list of HAs that >> support mobile routers. >> >>> 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. >> >> >> true. but if it uses DHAAD, then it knows whether the HA supports >> mobile routers. otherwise, it would know when the binding ack comes >> back without the 'R' flag. >> >>> 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). >> >> >> ok. > > > Only if there is another NEMO capable HA, it MUST send BU to the HA. > Otherwise, it re-issues DHAAD or stop sending BU. Ok me too. A clarification is still needed as suggested above I think. >>> 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. >> >> >> sounds good to me. > > > Well, we should be very careful for the valid address definition. If > i remember correctly, the valid address's ND state must be preferred > or deprecated. NA must not be replied for an address which state is > tentative and invalid. We should check NDP spec... Ok, if "valid address" could be formulated easily in ND-state terms I agree with it. It's just a simple issue, I don't look to make the document much longer to explain what "valid address" is. Just a short explanation. >>> 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. >> >> >> agreed. >> >>> 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. >> >> >> shouldnt this be implementation specific? its internal to the HA. > > > agree with Vijay. It is indeed implementation-specific. It should however clarify _why_ this check is done and the kind of attack it protects against. The text could say: "this Prefix Table verification helps protect against an attack where an attacker MR sends BUs with the legitimate MR's MNP, both MRs being managed by same HA". Alex From nemo-bounces@ietf.org Mon Nov 07 21:03:38 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 1EZIpm-0005hq-D9; Mon, 07 Nov 2005 21:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIpl-0005gJ-LM for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:03:37 -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 VAA00939 for ; Mon, 7 Nov 2005 21:03:10 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJ5U-00028d-Dc for nemo@ietf.org; Mon, 07 Nov 2005 21:19:52 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jA82R4LT021588; Mon, 7 Nov 2005 19:27:04 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA82BNpB029172; Mon, 7 Nov 2005 20:11:23 -0600 (CST) Message-ID: <43700771.6080409@motorola.com> Date: Mon, 07 Nov 2005 18:03:29 -0800 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] Recharter items References: <20051025135500.GF13790@grc.nasa.gov> <001801c5d985$2ba664d0$7af7748c@leechlab> <20051028162256.4fb0f0d2.ernst@sfc.wide.ad.jp> <436200CA.3080109@motorola.com> <20051104162706.5f4f7229.ernst@sfc.wide.ad.jp> In-Reply-To: <20051104162706.5f4f7229.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: f60d0f7806b0c40781eee6b9cd0b2135 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: > Hi, > > On Fri, 28 Oct 2005 12:43:22 +0200 Alexandru Petrescu > wrote: > > >> 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. > > Could you clarify all of the above points ? I'm not sure we had any > discussion for some of them, and about the last one, I don't see what > it has to do with a WG in the Internet Area. YEs, clarifying the above points. v4 stuff: all related to v4 traversal and NEMOv4 extensions to MIP4. We had discussion about that on the mip6 list, because the mip6trans was announced there first. It's been announced here too so I sollicited comments from authors here too. Clarifying DHAAD interactions: implementation feedback shows that NEMO basic support has a strong dependency on DHAAD implementation. If DHAAD is not implemented then some NEMOv6 BAck error codes are never used. DHAAD not being implemented is a common case knowing that secure DHAAD is difficult to implement (the anycast aspects). Deployment aspects: when NEMOv6 is deployed on larger-than-lab-prorotype scale (and _if_) then most certainly some deployment feedback will be made on rfc3963. It's good to have a place to receive these comments. > Let me add more things to the list, coming from the multihoming > analysis draft: - multihomng considerations in prefix delegation - > loop prevention in nested NEMO - MR synchronization I personally don't see exactly where other than monami6 multi-homing aspects should be dealt with. Loop prevention: let's discuss. MR synchronization - what's it? > And, the following, for which we need more discussion to know if it > should be dealt with NEMO WG or another WG: - HAHA - RO (see thread > Next steps in RO and particularly ChanWah's email on Nov.03) HAHA: I don't know. > I would appreciated that any response to this mail would add the > respective item in the subject line. YEs, that is a reasonable thing to do, just that in this email I've tried to address all items. Maybe it's better to make separate emails, let's see. Thanks, Alex From nemo-bounces@ietf.org Mon Nov 07 21:05:56 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 1EZIs0-00064y-TI; Mon, 07 Nov 2005 21:05:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIrz-00064t-Mv for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:05:56 -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 VAA01030 for ; Mon, 7 Nov 2005 21:05:29 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJ7h-0002Bl-DO for nemo@ietf.org; Mon, 07 Nov 2005 21:22:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA81W2K17611; Mon, 7 Nov 2005 17:32:02 -0800 X-mProtect: <200511080132> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdvskPGu; Mon, 07 Nov 2005 17:32:01 PST Message-ID: <437007E2.5050706@iprg.nokia.com> Date: Mon, 07 Nov 2005 18:05:22 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] v4traversal ID References: <4370032D.9040503@motorola.com> In-Reply-To: <4370032D.9040503@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: IETF WG NEMO , tj , Ryuji Wakikawa , 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 Alexandru Petrescu wrote: > What do you think about NEMOv4 extensions to MIP4 to achieve the goal of > giving v4 access to LFNs when the MR connects to a v4-only network? we discussed this a bit yesterday. the NEMO WG chairs I think will clarify this in the NEMO meeting on Wednesday. mainly about when to use NEMOv4 and when to use mip6trans v4 MNP extensions. Vijay From nemo-bounces@ietf.org Mon Nov 07 21:07: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 1EZItC-0006M9-PH; Mon, 07 Nov 2005 21:07:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZItA-0006M3-MT for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:07:08 -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 VAA01071 for ; Mon, 7 Nov 2005 21:06:41 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJ8r-0002Df-DA for nemo@ietf.org; Mon, 07 Nov 2005 21:23:23 -0500 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jA82UVue022709; Mon, 7 Nov 2005 19:30:31 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA82E6RE011643; Mon, 7 Nov 2005 20:14:07 -0600 (CST) Message-ID: <43700840.1060802@motorola.com> Date: Mon, 07 Nov 2005 18:06:56 -0800 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] Recharter items: multihoming - HAHA ? 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> <4361FF66.4030107@motorola.com> <20051104174919.119a888c.ernst@sfc.wide.ad.jp> In-Reply-To: <20051104174919.119a888c.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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit 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 Thierry Ernst wrote: >> Until Charter discussion starts, do you want me to send message to >> Monami6 about HAHA? > > > Well, I don't know. I would say any list is fine, but probably NEMO > is better to start with so that we could come up with a conclusion on > this point in the NEMO WG first. Let me point out the HAHA is > documented as issue 4.4 > http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-multihoming-issues-04.html#sec:problem.hasync > in draft-ietf-nemo-multihoming-issues-04.txt My personal conclusion is that we've already discussed HAHA several times here. I don't think the HAHA protocols themselves have evolved since. >> 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)? > > > I'm not sure what you mean, here. Particularly, what FMIP has to do > with NEMO ? Sorry, I meant to say that I personally would like to have feedback on my own discussions on FMIP on the the mipshop mailing list. Some people on the nemo list are also active on the mipshop list. What does HAHA have to do with NEMO? Alex From nemo-bounces@ietf.org Mon Nov 07 21:12:34 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 1EZIyQ-00089A-GX; Mon, 07 Nov 2005 21:12:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIyP-00085R-8m for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:12:33 -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 VAA01370 for ; Mon, 7 Nov 2005 21:12:06 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJE8-0002MZ-2m for nemo@ietf.org; Mon, 07 Nov 2005 21:28:48 -0500 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA82OlQO007850; Mon, 7 Nov 2005 19:24:47 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA82PZ8q000104; Mon, 7 Nov 2005 20:25:36 -0600 (CST) Message-ID: <4370098B.6040107@motorola.com> Date: Mon, 07 Nov 2005 18:12:27 -0800 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: Shinta Sugimoto Subject: Re: [nemo] v4traversal ID References: <20051104195359.9642.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20051104195359.9642.SHINTA@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: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: IETF WG NEMO , 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 Shinta Sugimoto wrote: > Hi Ryuji, > > Please find my comments on the draft. The third bullet is more > related to NEMO. > > Regards, > Shinta > > On Fri, 4 Nov 2005 01:14:54 +0900 > Ryuji Wakikawa wrote: > > >>Hi all, >> >>We have submitted a draft on MIP6/NEMO v4 traversal. >>This is both MIP6 and NEMO WG document. >>Your comments are really appreciated. >> >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- >>v4traversal-00.txt >> >>thanks >>ryuji >> > > > > > > ------------------------------------------------------------------------ > > Subject: > [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2) > From: > Shinta Sugimoto > Date: > Fri, 04 Nov 2005 19:50:46 +0900 > To: > mip6@ietf.org > > To: > mip6@ietf.org > > > Hello, > > I've reviewed the v4traversal protocol document. First of all, thanks > for writing this up. I think this technology is really useful. I have > following comments and questions as below. > > Technical Comments: > > - In Section 2.2, there are descriptions about use of IPsec for sending > and receiving MPS/MPA. However, I found the texts are not clear about > how the IPsec should be applied to the MIPv6 messages. Does the > specification recommend to use IPsec as similar to the MIPv6's case > (RFC 3776) ? Or does it (intentionally) leave it to operation ? > > >> A dual stack mobile node MAY send a Mobile Prefix Solicitation >> message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where >> the mobile node has no access to IPv6 within the local network. >> Securing such messages would require the mobile node to have security >> association with the home agent, using IPsec (AH or ESP) and based on >> the mobile node's IPv4 care-of address as described in [MIPv6]. Since >> the mobile node needs to encapsulate all IPv6 traffic sent to the >> home agent into IPv4, while located in an IPv4-only visited network, >> such SA would affect all packets if the selectors were based on the >> information in the outer header. That is, the SA selectors being the >> protocol number (protocol is always IP in IP), as well as, source and >> destination addresses are all common to all packets. If this effect >> is not desired, the mobile node can base the SA on the information in >> the inner header (i.e. using the home agent's IPv6 address, the >> mobile node's home address and the ICMP protocol number). Such >> security association would use transport mode ESP protection. > > > - Related to the above question, I found there is few description about > IPsec processing. How should IPsec be applied to v4traversal scenario > should be provided, IMHO. If it is expected to be similar to MIPv6 case > (RFC 3776), the spec should say so. > > - In Section 3.1.1, header format of IPv4 home address option is defined. > If I understand it correctly, the option allows BU to carry both IPv4 > home address and MNP in a common formant. Let me clarify a little bit > more: I assume that the single IPv4 home address option is allowed in a > BU message but is it right ? As for IPv4 MNP, does the spec allow BU > message to carry multiple IPv4 MNPs as in NEMO base protocol (I hope so) ? Currently it doesn't IMHO. It does not allow for the IPv4 Home Address to be different than the v4 MNP either. (0th bit different). The draft also has strong relationships to HMIP6 ("BU sent to HA or to MAP"). Which was no initial goal of mip6trans. Alex From nemo-bounces@ietf.org Mon Nov 07 21:14:26 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 1EZJ0E-0008SJ-BV; Mon, 07 Nov 2005 21:14:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ0D-0008SE-JV for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:14:25 -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 VAA01540 for ; Mon, 7 Nov 2005 21:13:58 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJFj-0002QQ-53 for nemo@ietf.org; Mon, 07 Nov 2005 21:30:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA81eRx23643; Mon, 7 Nov 2005 17:40:27 -0800 X-mProtect: <200511080140> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdvIM3U6; Mon, 07 Nov 2005 17:40:25 PST Message-ID: <437009DA.5010000@iprg.nokia.com> Date: Mon, 07 Nov 2005 18:13:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> <43700497.20100@motorola.com> In-Reply-To: <43700497.20100@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Denis Ortega , 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 Alexandru Petrescu wrote: >>>>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. >>> >>> >>>shouldnt this be implementation specific? its internal to the HA. >> >> >>agree with Vijay. > > > It is indeed implementation-specific. It should however clarify _why_ > this check is done and the kind of attack it protects against. The text > could say: "this Prefix Table verification helps protect against an > attack where an attacker MR sends BUs with the legitimate MR's MNP, both > MRs being managed by same HA". we have some text in section 6.1.2 The Home Agent SHOULD be able to prevent a Mobile Router from claiming Mobile Network Prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains a Prefix Table and verifies the prefix information provided by the Mobile Router against Prefix Table entries. isnt this sufficient? Vijay From nemo-bounces@ietf.org Mon Nov 07 21:14:59 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 1EZJ0l-00006L-S7; Mon, 07 Nov 2005 21:14:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ0k-00006B-6f for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:14:58 -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 VAA01565 for ; Mon, 7 Nov 2005 21:14:31 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJGR-0002RK-UF for nemo@ietf.org; Mon, 07 Nov 2005 21:31:13 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jA82V3Be027210; Mon, 7 Nov 2005 19:31:03 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA82MeHA003769; Mon, 7 Nov 2005 20:22:41 -0600 (CST) Message-ID: <43700A17.2060207@motorola.com> Date: Mon, 07 Nov 2005 18:14:47 -0800 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: Sub-optimal Terminology (was Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) References: <1129083768.9252.2.camel@localhost> <4366604F.9010503@motorola.com> <1131104503.23646.40.camel@localhost> <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> In-Reply-To: <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 T.J. Kniveton wrote: > On Nov 4, 2005, at 3:41 AM, Chan-Wah Ng wrote: > >> Thanks for the suggestions. However, I do have a concern over the >> choice of words. It might suggest that perhaps a terminology is needed >> for the phenomenon where the routing path is anchored at the home >> agent(s). >> >> In MIPv6, I recall it used to be called "triangular >> routing" (traditionally though, I doubt it is used in RFC3775). >> >> You seems to favour the generalization of this term into "multi- angular >> routing". Logical, since with multiple HAs, there would be more than >> three vertexes. > > > Multi-angular makes less sense to me than triangular. > >> >> In some of the NEMO-related individual drafts (eg. >> draft-thubert-nemo-ro-taxonomy), there have been instances on the use of >> "dog-leg routing" and "pinball routing". > > dog-leg routing is sometimes used to be roughly synonymous to > triangular routing. Pinball routing is a term which describes the route > getting bounced back and forth like a pinball. I don't know whether > it's used in other places in routing literature; I hadn't heard it before. > >> >> In draft-ietf-nemo-ro-problem-statement, however, we have sticked to the >> very general term "sub-optimal routing". > > > Sub-optimal routing, as you mentioned, is very general. In fact, > whereas pinball, triangular and dog-leg routing describe routing > phenomena in certain circumstances, sub-optimal routing describes a > general quality, not a specific scenario. It could mean almost anything > other than shortest / cheapest path. > >> >> What do the rest of the WG think? Is there a need to have a more >> specific term? Or is sub-optimal routing good enough? > > > I'd like to use a different term, though I'm not sure the best one has > been suggested yet. Maybe something along the lines of through-HA-enforced routing, or through-the-HA TTH routing... Alex From nemo-bounces@ietf.org Mon Nov 07 21:17:36 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 1EZJ3I-0000UO-C9; Mon, 07 Nov 2005 21:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ3H-0000Tk-48 for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:17:35 -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 VAA01761 for ; Mon, 7 Nov 2005 21:17:08 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJIz-0002VO-0Y for nemo@ietf.org; Mon, 07 Nov 2005 21:33:50 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA82TcFa008320; Mon, 7 Nov 2005 19:29:38 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA82QLPm029342; Mon, 7 Nov 2005 20:26:26 -0600 (CST) Message-ID: <43700AAC.8030402@motorola.com> Date: Mon, 07 Nov 2005 18:17:16 -0800 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Masafumi Watari Subject: Re: Sub-optimal Terminology (was Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) References: <1129083768.9252.2.camel@localhost> <4366604F.9010503@motorola.com> <1131104503.23646.40.camel@localhost> <5867AEB4-1F80-4B28-8223-A61461A0B8D1@kniveton.com> <436E79F4.7040902@kddilabs.jp> In-Reply-To: <436E79F4.7040902@kddilabs.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: > Hi, > > Alex, thanks for your comments. Overall, I agree about making it > clear on what the problem is. > > Some comments about the terminology below. > > On 2005/11/05 7:10, T.J. Kniveton wrote: > >> On Nov 4, 2005, at 3:41 AM, Chan-Wah Ng wrote: >> >>> Thanks for the suggestions. However, I do have a concern over the >>> choice of words. It might suggest that perhaps a terminology is needed >>> for the phenomenon where the routing path is anchored at the home >>> agent(s). >>> >>> In MIPv6, I recall it used to be called "triangular >>> routing" (traditionally though, I doubt it is used in RFC3775). >>> >>> You seems to favour the generalization of this term into "multi- angular >>> routing". Logical, since with multiple HAs, there would be more than >>> three vertexes. >> >> >> Multi-angular makes less sense to me than triangular. > > > I agree. > >>> >>> In some of the NEMO-related individual drafts (eg. >>> draft-thubert-nemo-ro-taxonomy), there have been instances on the >>> use of >>> "dog-leg routing" and "pinball routing". >> >> >> dog-leg routing is sometimes used to be roughly synonymous to >> triangular routing. Pinball routing is a term which describes the >> route getting bounced back and forth like a pinball. I don't know >> whether it's used in other places in routing literature; I hadn't >> heard it before. >> >>> >>> In draft-ietf-nemo-ro-problem-statement, however, we have sticked to >>> the >>> very general term "sub-optimal routing". >> >> >> >> Sub-optimal routing, as you mentioned, is very general. In fact, >> whereas pinball, triangular and dog-leg routing describe routing >> phenomena in certain circumstances, sub-optimal routing describes a >> general quality, not a specific scenario. It could mean almost >> anything other than shortest / cheapest path. > > > In keeping the document at a generic level, I don't see any problem > using sub-optimal routing. I mean with nested-NEMO, you could draw > lines that look like a star for example... A star pictured as a hexagon is "multi-angular" still :-) I agree with you. I could live with "sub-optimal" too. Alex From nemo-bounces@ietf.org Mon Nov 07 21:20:40 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 1EZJ6G-0001Qa-NL; Mon, 07 Nov 2005 21:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ6F-0001QN-3k for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:20:39 -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 VAA02046 for ; Mon, 7 Nov 2005 21:20:12 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJLx-0002cB-PF for nemo@ietf.org; Mon, 07 Nov 2005 21:36:54 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jA82aotI029679; Mon, 7 Nov 2005 19:36:50 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA82UNOC006232; Mon, 7 Nov 2005 20:30:23 -0600 (CST) Message-ID: <43700B6F.4090206@motorola.com> Date: Mon, 07 Nov 2005 18:20:31 -0800 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: Vijay Devarapalli Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> <43700497.20100@motorola.com> <437009DA.5010000@iprg.nokia.com> In-Reply-To: <437009DA.5010000@iprg.nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Denis Ortega , Ryuji Wakikawa , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >>>>> 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. >>>> >>>> >>>> >>>> shouldnt this be implementation specific? its internal to the >>>> HA. >>> >>> >>> >>> agree with Vijay. >> >> >> >> It is indeed implementation-specific. It should however clarify >> _why_ this check is done and the kind of attack it protects >> against. The text could say: "this Prefix Table verification helps >> protect against an attack where an attacker MR sends BUs with the >> legitimate MR's MNP, both MRs being managed by same HA". > > > we have some text in section 6.1.2 > > The Home Agent SHOULD be able to prevent a Mobile Router from > claiming Mobile Network Prefixes belonging to another Mobile Router. > The Home Agent can prevent such attacks if it maintains a Prefix > Table and verifies the prefix information provided by the Mobile > Router against Prefix Table entries. > > isnt this sufficient? Sorry - I agree! For some reason that text wasn't immediately handy to me. That was exactly the text I was looking for. If both of you guys think that that text is enough, and that an example check is not necessary (check the MNP of BU to MNP in the prefix table, exact match with prefix length) then I won't fight for it. Alex From nemo-bounces@ietf.org Mon Nov 07 21:22:58 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 1EZJ8U-0002PU-Q4; Mon, 07 Nov 2005 21:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ8S-0002PM-O4 for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:22:56 -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 VAA02305 for ; Mon, 7 Nov 2005 21:22:29 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJOA-0002hV-JM for nemo@ietf.org; Mon, 07 Nov 2005 21:39:11 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id jA82cV7N020573; Mon, 7 Nov 2005 19:38:31 -0700 (MST) Received: from [10.19.249.95] (mvp-10-19-249-95.corp.mot.com [10.19.249.95]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA82ZuoA004159; Mon, 7 Nov 2005 20:35:57 -0600 (CST) Message-ID: <43700BF9.6050609@motorola.com> Date: Mon, 07 Nov 2005 18:22:49 -0800 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: Vijay Devarapalli Subject: Re: [nemo] v4traversal ID References: <4370032D.9040503@motorola.com> <437007E2.5050706@iprg.nokia.com> In-Reply-To: <437007E2.5050706@iprg.nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: IETF WG NEMO , tj , Ryuji Wakikawa , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: >> What do you think about NEMOv4 extensions to MIP4 to achieve the >> goal of giving v4 access to LFNs when the MR connects to a v4-only >> network? [...] > mainly about when to use NEMOv4 and when to use mip6trans v4 MNP > extensions. A new mechanism for switching modes? Or just a scenario recommendation? Alex From nemo-bounces@ietf.org Mon Nov 07 21:29:09 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 1EZJET-0005Yd-Dq; Mon, 07 Nov 2005 21:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJER-0005YT-BT for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:29:07 -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 VAA02747 for ; Mon, 7 Nov 2005 21:28:40 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJU9-0002ra-6C for nemo@ietf.org; Mon, 07 Nov 2005 21:45:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA81t3905642; Mon, 7 Nov 2005 17:55:03 -0800 X-mProtect: <200511080155> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdz74pMh; Mon, 07 Nov 2005 17:55:01 PST Message-ID: <43700D45.2080206@iprg.nokia.com> Date: Mon, 07 Nov 2005 18:28:21 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] v4traversal ID References: <4370032D.9040503@motorola.com> <437007E2.5050706@iprg.nokia.com> <43700BF9.6050609@motorola.com> In-Reply-To: <43700BF9.6050609@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: IETF WG NEMO , tj , Ryuji Wakikawa , 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 Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >>>What do you think about NEMOv4 extensions to MIP4 to achieve the >>>goal of giving v4 access to LFNs when the MR connects to a v4-only >>>network? > > [...] > >>mainly about when to use NEMOv4 and when to use mip6trans v4 MNP >>extensions. > > > A new mechanism for switching modes? Or just a scenario recommendation? just a recommendation. definitely not a new switching mechanism. :) Vijay > > Alex > From nemo-bounces@ietf.org Mon Nov 07 21:35:30 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 1EZJKc-0007mJ-27; Mon, 07 Nov 2005 21:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJKZ-0007m9-M2 for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:35:27 -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 VAA03186 for ; Mon, 7 Nov 2005 21:35:00 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJaI-00033A-K2 for nemo@ietf.org; Mon, 07 Nov 2005 21:51:43 -0500 Received: from [IPv6:2001:410:1000:f000:211:24ff:fe21:a941] (unknown [IPv6:2001:410:1000:f000:211:24ff:fe21:a941]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 908C04C0FB; Tue, 8 Nov 2005 11:35:17 +0900 (JST) In-Reply-To: <4370032D.9040503@motorola.com> References: <4370032D.9040503@motorola.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F9D199F-F0A0-46D9-AAD7-8C4AAD95820A@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] v4traversal ID Date: Tue, 8 Nov 2005 11:35:12 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF WG 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 Alex Well, I sent email because I was not sure that everybody in NEMO ML is also in MIP6 ML. On 2005/11/08, at 10:45, Alexandru Petrescu wrote: > Dear Ryuji, thanks for posting. > > I have sent several reviewing remarks on the mip6 list where it was > initially announced. There was a long thread about it on the mip6 > list. > It would be good to discuss this draft on a single list. > > The main remark I had about is that it looks good and has good > ideas in > it. Having an IPv4 address in the v6 BC may help a lot with v4 > traversal for MH and MR. > > I also suggested that giving v4 access to LFNs of an MR, when MR > connects to a v4 network, may be realised more naturally with MIP4 > extensions instead of MIP6 extensions. Also suggested that the draft IPv4 access to LFNs can be provided regardless of MR's access network. > does not address proxy-ARP for HA for the v4 Home Address nor how > MH may > change its v4 CoA when connecting to a FA-based v4 network. How the HA capture the packet for the IPv4 HoA will be added in the next version. We understood this issue and already discussed within DT. > Also suggested that 7-author list may look a little long, more than > 5 is > probably too high. > > What do you think about these items? > > What do you think about NEMOv4 extensions to MIP4 to achieve the > goal of > giving v4 access to LFNs when the MR connects to a v4-only network? This is not what we tried to solve in v4traversal DT. ryuji > Thanks, > > Alex > > Ryuji Wakikawa wrote: > >> Hi all, >> >> We have submitted a draft on MIP6/NEMO v4 traversal. >> This is both MIP6 and NEMO WG document. >> Your comments are really appreciated. >> >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo- >> v4traversal-00.txt >> >> thanks >> ryuji >> >> > From nemo-bounces@ietf.org Mon Nov 07 21:54:09 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 1EZJcf-0006O2-2r; Mon, 07 Nov 2005 21:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJcd-0006Nu-5k for nemo@megatron.ietf.org; Mon, 07 Nov 2005 21:54:07 -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 VAA04360 for ; Mon, 7 Nov 2005 21:53:39 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJsL-0003dq-2U for nemo@ietf.org; Mon, 07 Nov 2005 22:10:22 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id jA839b1A008538; Mon, 7 Nov 2005 20:09:37 -0700 (MST) Received: from [10.181.32.220] (mvp-10-181-32-220.ea.mot.com [10.181.32.220]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA8312J4002032; Mon, 7 Nov 2005 21:01:03 -0600 (CST) Message-ID: <4370133F.2000506@motorola.com> Date: Mon, 07 Nov 2005 18:53:51 -0800 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: Ryuji Wakikawa Subject: Re: [nemo] v4traversal ID References: <4370032D.9040503@motorola.com> <5F9D199F-F0A0-46D9-AAD7-8C4AAD95820A@sfc.wide.ad.jp> In-Reply-To: <5F9D199F-F0A0-46D9-AAD7-8C4AAD95820A@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: IETF WG NEMO , 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 Ryuji Wakikawa wrote: >> I also suggested that giving v4 access to LFNs of an MR, when MR >> connects to a v4 network, may be realised more naturally with MIP4 >> extensions instead of MIP6 extensions. Also suggested that the >> draft > > IPv4 access to LFNs can be provided regardless of MR's access > network. I understand that goal: DSMIPv6 tries to provide IPv4 access to LFNs regardless of MR's access network being v4 or v6. >> does not address proxy-ARP for HA for the v4 Home Address nor how >> MH may change its v4 CoA when connecting to a FA-based v4 network. > > > How the HA capture the packet for the IPv4 HoA will be added in the > next version. We understood this issue and already discussed within > DT. > >> Also suggested that 7-author list may look a little long, more than >> 5 is probably too high. >> >> What do you think about these items? >> >> What do you think about NEMOv4 extensions to MIP4 to achieve the >> goal of giving v4 access to LFNs when the MR connects to a v4-only >> network? > > > This is not what we tried to solve in v4traversal DT. I understand that. Us too, it was none of our goals to write a draft for mip6 extensions for v4 addresses/prefixes, and I still read that draft :-) Alex From nemo-bounces@ietf.org Tue Nov 08 01:05:21 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 1EZMbh-0008Nb-3a; Tue, 08 Nov 2005 01:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZMbe-0008NW-Qd for nemo@megatron.ietf.org; Tue, 08 Nov 2005 01:05:18 -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 BAA12898 for ; Tue, 8 Nov 2005 01:04:52 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZMrO-00006P-5f for nemo@ietf.org; Tue, 08 Nov 2005 01:21:35 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id jA86DbtD004752; Mon, 7 Nov 2005 23:13:37 -0700 (MST) Received: from [144.189.73.172] (mvp-144-189-73-172.corp.mot.com [144.189.73.172]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA86Eu9e006893; Tue, 8 Nov 2005 00:14:56 -0600 (CST) Message-ID: <43704012.4080506@motorola.com> Date: Mon, 07 Nov 2005 22:05:06 -0800 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: "K.Kawaguchi" Subject: Re: [nemo] developing conformance tests and interoperability tests for NEMO References: <200511081016.DCB64543.VUBHBJLX@ysknet.co.jp> In-Reply-To: <200511081016.DCB64543.VUBHBJLX@ysknet.co.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org K.Kawaguchi wrote: > Dear all, > > We are researching and developing conformance tests and interoperability > tests for NEMO basic(RFC3963). And we are requesting the opinion of the > tests under developing. > > Please look for following URL if you are interested. > Our Conformance tests and Scenario tests have been opened to the public. > > http://www.tahi.org/nemo/ Thanks for this announcement. In the lab, we support the following NEMOv6 BU message formats, are they part of the TAHI tests? http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnp?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpacoanonceauth?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpaltcoa?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpnonceauth?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnp?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpaltcoa?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpaltcoanonceauth?rev=1.2&view=auto http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpnonceauth?rev=1.2&view=auto Thanks, Alex From nemo-bounces@ietf.org Tue Nov 08 03:14:20 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 1EZOcW-00082R-OZ; Tue, 08 Nov 2005 03:14:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZOcV-00082M-J5 for nemo@megatron.ietf.org; Tue, 08 Nov 2005 03:14:19 -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 DAA19727 for ; Tue, 8 Nov 2005 03:13:52 -0500 (EST) Received: from darla.ti-wmc.nl ([217.114.97.45] helo=smtp.wmc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZOsG-0003Rf-H6 for nemo@ietf.org; Tue, 08 Nov 2005 03:30:37 -0500 Received: from [10.0.1.82] (pc032.wmc [10.0.1.82]) by smtp.wmc (Postfix) with ESMTP id 581A674BD for ; Tue, 8 Nov 2005 09:13:58 +0100 (CET) Message-ID: <43705E46.7050506@ti-wmc.nl> Date: Tue, 08 Nov 2005 09:13:58 +0100 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: nemo@ietf.org Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> <43700497.20100@motorola.com> <437009DA.5010000@iprg.nokia.com> <43700B6F.4090206@motorola.com> In-Reply-To: <43700B6F.4090206@motorola.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: >>>>>>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. >>> >>>It is indeed implementation-specific. It should however clarify >>>_why_ this check is done and the kind of attack it protects >>>against. The text could say: "this Prefix Table verification helps >>>protect against an attack where an attacker MR sends BUs with the >>>legitimate MR's MNP, both MRs being managed by same HA". >> >> >>we have some text in section 6.1.2 >> >>The Home Agent SHOULD be able to prevent a Mobile Router from >>claiming Mobile Network Prefixes belonging to another Mobile Router. >>The Home Agent can prevent such attacks if it maintains a Prefix >>Table and verifies the prefix information provided by the Mobile >>Router against Prefix Table entries. >> >>isnt this sufficient? > > > Sorry - I agree! For some reason that text wasn't immediately handy to > me. That was exactly the text I was looking for. > > If both of you guys think that that text is enough, and that an example > check is not necessary (check the MNP of BU to MNP in the prefix table, > exact match with prefix length) then I won't fight for it. Just out of interest, how would you verify this table? I'm sure this would need some form of crypto verification to make sure the MR isn't an imposter, right? (I'm looking at NEMO as a solution for secure personal networks, so from my perspective, authentication and authorisation is very important) 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 Tue Nov 08 03:33:28 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 1EZOv2-0003ye-4y; Tue, 08 Nov 2005 03:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZOv0-0003xy-3b for nemo@megatron.ietf.org; Tue, 08 Nov 2005 03:33:26 -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 DAA20942 for ; Tue, 8 Nov 2005 03:32:59 -0500 (EST) Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZPAk-00043w-RO for nemo@ietf.org; Tue, 08 Nov 2005 03:49:44 -0500 Received: (qmail 28495 invoked from network); 8 Nov 2005 17:33:20 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 8 Nov 2005 17:33:20 +0900 To: nemo@ietf.org Subject: Re: [nemo] developing conformance tests and interoperability testsfor NEMO From: "K.Kawaguchi" References: <200511081016.DCB64543.VUBHBJLX@ysknet.co.jp> <43704012.4080506@motorola.com> In-Reply-To: <43704012.4080506@motorola.com> Message-Id: <200511081733.FGE82316.VXBULBJH@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 8 Nov 2005 17:33:19 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thank you for the answer immediately. "Alexandru Petrescu " wrote: > K.Kawaguchi wrote: > > Dear all, > > > > We are researching and developing conformance tests and interoperability > > tests for NEMO basic(RFC3963). And we are requesting the opinion of the > > tests under developing. > > > > Please look for following URL if you are interested. > > Our Conformance tests and Scenario tests have been opened to the public. > > > > http://www.tahi.org/nemo/ > > Thanks for this announcement. > > In the lab, we support the following NEMOv6 BU message formats, are they > part of the TAHI tests? > > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnp?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpacoanonceauth?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpaltcoa?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-mnpnonceauth?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnp?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpaltcoa?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpaltcoanonceauth?rev=1.2&view=auto > http://www.enrl.motlabs.com/cgi-bin/viewcvs.cgi/livsix/doc/bu-nmnpnonceauth?rev=1.2&view=auto Isn't Mobile Network Prefix option unnecessary in Buindin update to CN ? We show one standard packet format though we think that other patterns like the arrangement of the option etc. exist, too. Moreover, Conformance Test suite is inspected by using the packet of this standard pattern. http://www.tahi.org/nemo/nemo_profile_v0_1_0.pdf "4. Packet formats" I give one's views in the packet that you showed. mobility header, total message divisible by 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ binding update +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^^^^ ** addition padn +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ alternate care-of address, aligned 8n+6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ padn +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | 2 | 0 $B!!(B | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mnp, aligned 8n+4 ^^^^^^^^^^^^ ** adition +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 18 | Reserved |Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp From nemo-bounces@ietf.org Tue Nov 08 09:16:11 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 1EZUGh-00011G-Oe; Tue, 08 Nov 2005 09:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUGg-000116-Fu for nemo@megatron.ietf.org; Tue, 08 Nov 2005 09:16:10 -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 JAA08103 for ; Tue, 8 Nov 2005 09:15:43 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZUWT-00050G-H8 for nemo@ietf.org; Tue, 08 Nov 2005 09:32:31 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2005 15:15:54 +0100 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 jA8EFk3b026818; Tue, 8 Nov 2005 15:15:49 +0100 (MET) 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); Tue, 8 Nov 2005 15:15:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) Date: Tue, 8 Nov 2005 15:15:46 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0173FA2E@xmb-ams-337.emea.cisco.com> Thread-Topic: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) Thread-Index: AcXkCytuW52tGoaYQcqrowvO3Wtf9AAYrG2A From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Masafumi Watari" X-OriginalArrivalTime: 08 Nov 2005 14:15:47.0229 (UTC) FILETIME=[E9F01CD0:01C5E46E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org There is a topological view, where pinball routing and multi-angular are contenders, and there is a tunnel view, for which we'd need a term like telescopic or something. Any idea? Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Alexandru Petrescu >Sent: Tuesday, November 08, 2005 3:17 AM >To: Masafumi Watari >Cc: IETF NEMO WG; T.J. Kniveton >Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem- >statement-01.txt) > >Masafumi Watari wrote: > >> Hi, >> >> Alex, thanks for your comments. Overall, I agree about making it >> clear on what the problem is. >> >> Some comments about the terminology below. >> >> On 2005/11/05 7:10, T.J. Kniveton wrote: >> >>> On Nov 4, 2005, at 3:41 AM, Chan-Wah Ng wrote: >>> >>>> Thanks for the suggestions. However, I do have a concern over the >>>> choice of words. It might suggest that perhaps a terminology is needed >>>> for the phenomenon where the routing path is anchored at the home >>>> agent(s). >>>> >>>> In MIPv6, I recall it used to be called "triangular >>>> routing" (traditionally though, I doubt it is used in RFC3775). >>>> >>>> You seems to favour the generalization of this term into "multi- angular >>>> routing". Logical, since with multiple HAs, there would be more than >>>> three vertexes. >>> >>> >>> Multi-angular makes less sense to me than triangular. >> >> >> I agree. >> >>>> >>>> In some of the NEMO-related individual drafts (eg. >>>> draft-thubert-nemo-ro-taxonomy), there have been instances on the >>>> use of >>>> "dog-leg routing" and "pinball routing". >>> >>> >>> dog-leg routing is sometimes used to be roughly synonymous to >>> triangular routing. Pinball routing is a term which describes the >>> route getting bounced back and forth like a pinball. I don't know >>> whether it's used in other places in routing literature; I hadn't >>> heard it before. >>> >>>> >>>> In draft-ietf-nemo-ro-problem-statement, however, we have sticked to >>>> the >>>> very general term "sub-optimal routing". >>> >>> >>> >>> Sub-optimal routing, as you mentioned, is very general. In fact, >>> whereas pinball, triangular and dog-leg routing describe routing >>> phenomena in certain circumstances, sub-optimal routing describes a >>> general quality, not a specific scenario. It could mean almost >>> anything other than shortest / cheapest path. >> >> >> In keeping the document at a generic level, I don't see any problem >> using sub-optimal routing. I mean with nested-NEMO, you could draw >> lines that look like a star for example... > >A star pictured as a hexagon is "multi-angular" still :-) > >I agree with you. I could live with "sub-optimal" too. > >Alex From nemo-bounces@ietf.org Tue Nov 08 09:16:12 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 1EZUGi-00011f-7A; Tue, 08 Nov 2005 09:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUGh-00011B-83 for nemo@megatron.ietf.org; Tue, 08 Nov 2005 09:16:11 -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 JAA08106 for ; Tue, 8 Nov 2005 09:15:44 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZUWW-00050G-9V for nemo@ietf.org; Tue, 08 Nov 2005 09:32:32 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2005 15:16:00 +0100 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 jA8EFU3x026765; Tue, 8 Nov 2005 15:15:57 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 15:15:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Implemetor's comments on RFC3963 Date: Tue, 8 Nov 2005 15:15:37 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0173FA2F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Implemetor's comments on RFC3963 Thread-Index: AcXkPOPPhg7c+cMWRNyV857L3ulL/AAMdc7Q From: "Pascal Thubert \(pthubert\)" To: "Simon Oosthoek" , X-OriginalArrivalTime: 08 Nov 2005 14:15:47.0492 (UTC) FILETIME=[EA183E40:01C5E46E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Simon Oosthoek >Sent: Tuesday, November 08, 2005 9:14 AM >To: nemo@ietf.org >Subject: Re: [nemo] Implemetor's comments on RFC3963 > >Alexandru Petrescu wrote: >>>>>>>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. >>>> >>>>It is indeed implementation-specific. It should however clarify >>>>_why_ this check is done and the kind of attack it protects >>>>against. The text could say: "this Prefix Table verification helps >>>>protect against an attack where an attacker MR sends BUs with the >>>>legitimate MR's MNP, both MRs being managed by same HA". >>> >>> >>>we have some text in section 6.1.2 >>> >>>The Home Agent SHOULD be able to prevent a Mobile Router from >>>claiming Mobile Network Prefixes belonging to another Mobile Router. >>>The Home Agent can prevent such attacks if it maintains a Prefix >>>Table and verifies the prefix information provided by the Mobile >>>Router against Prefix Table entries. >>> >>>isnt this sufficient? >> >> >> Sorry - I agree! For some reason that text wasn't immediately handy to >> me. That was exactly the text I was looking for. >> >> If both of you guys think that that text is enough, and that an example >> check is not necessary (check the MNP of BU to MNP in the prefix table, >> exact match with prefix length) then I won't fight for it. > >Just out of interest, how would you verify this table? I'm sure this >would need some form of crypto verification to make sure the MR isn't an >imposter, right? > >(I'm looking at NEMO as a solution for secure personal networks, so from >my perspective, authentication and authorisation is very important) > >Cheers > [] Just to give you an example, there might be a crypto relationship between the Home Address and the last bits in the MNP. Pascal From nemo-bounces@ietf.org Tue Nov 08 11:07:56 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 1EZW0q-0002de-L8; Tue, 08 Nov 2005 11:07:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZW0p-0002dZ-E5 for nemo@megatron.ietf.org; Tue, 08 Nov 2005 11:07:55 -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 LAA14349 for ; Tue, 8 Nov 2005 11:07:27 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZWGe-00085O-54 for nemo@ietf.org; Tue, 08 Nov 2005 11:24:17 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id jA8GHDku026232; Tue, 8 Nov 2005 09:17:17 -0700 (MST) Received: from [144.189.75.116] (mvp-144-189-75-116.corp.mot.com [144.189.75.116]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA8GEi2a019452; Tue, 8 Nov 2005 10:14:45 -0600 (CST) Message-ID: <4370CD44.3000304@motorola.com> Date: Tue, 08 Nov 2005 17:07:32 +0100 From: Christophe Janneteau User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) References: <7892795E1A87F04CADFCCF41FADD00FC0173FA2E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0173FA2E@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > There is a topological view, where pinball routing and multi-angular are > contenders, and there is a tunnel view, for which we'd need a term like > telescopic or something. Any idea? > Hi, Is the term "nested tunnels" not the one we used to use? Christophe From nemo-bounces@ietf.org Tue Nov 08 11:27:31 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 1EZWJm-0006bM-VP; Tue, 08 Nov 2005 11:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWJl-0006bE-MQ for nemo@megatron.ietf.org; Tue, 08 Nov 2005 11:27:29 -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 LAA15328 for ; Tue, 8 Nov 2005 11:27:03 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZWZb-000077-G4 for nemo@ietf.org; Tue, 08 Nov 2005 11:43:52 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2005 17:27:16 +0100 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 jA8GQv3l001908; Tue, 8 Nov 2005 17:27:12 +0100 (MET) 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); Tue, 8 Nov 2005 17:27:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) Date: Tue, 8 Nov 2005 17:27:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> Thread-Topic: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem-statement-01.txt) Thread-Index: AcXkfpomcKt/Mzs4Q5S4OKkqxqipKwAAfYmQ From: "Pascal Thubert \(pthubert\)" To: "Christophe Janneteau" X-OriginalArrivalTime: 08 Nov 2005 16:27:12.0402 (UTC) FILETIME=[45DE0720:01C5E481] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J. Kniveton" , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] >Sent: Tuesday, November 08, 2005 5:08 PM >To: Pascal Thubert (pthubert) >Cc: Alexandru Petrescu; Masafumi Watari; IETF NEMO WG; T.J. Kniveton >Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D ACTION:draft-ietf-nemo-ro-problem- >statement-01.txt) > > >Pascal Thubert (pthubert) wrote: >> There is a topological view, where pinball routing and multi-angular are >> contenders, and there is a tunnel view, for which we'd need a term like >> telescopic or something. Any idea? >> > >Hi, > >Is the term "nested tunnels" not the one we used to use? [] Yes, it is.=20 But that term, like suboptimal, is very generic.=20 Now we are considering RO and finding more specific terms which would be more uniquely associated to our problem would be nice, but if we don't, I agree we have a default. It could be also useful to distinguish when one side ends multiple layers of tunneling, like a HA does if you form a nested structure of MRs that depend on that same HA. Any idea? Pascal From nemo-bounces@ietf.org Tue Nov 08 12:38:31 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 1EZXQV-0000JP-Tj; Tue, 08 Nov 2005 12:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXQU-0000JB-T0 for nemo@megatron.ietf.org; Tue, 08 Nov 2005 12:38:30 -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 MAA20283 for ; Tue, 8 Nov 2005 12:38:01 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZXgI-0002KP-IC for nemo@ietf.org; Tue, 08 Nov 2005 12:54:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA8H4eH01459; Tue, 8 Nov 2005 09:04:40 -0800 X-mProtect: <200511081704> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp167155.americas.nokia.com (10.241.167.155, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdn8UZNh; Tue, 08 Nov 2005 09:04:38 PST Message-ID: <4370E278.4040509@iprg.nokia.com> Date: Tue, 08 Nov 2005 09:38:00 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Oosthoek Subject: Re: [nemo] Implemetor's comments on RFC3963 References: <4358F915.1070508@motorola.com> <4369785A.7000303@iprg.nokia.com> <54F01906-71A5-441B-9565-92855B2C3ACB@sfc.wide.ad.jp> <43700497.20100@motorola.com> <437009DA.5010000@iprg.nokia.com> <43700B6F.4090206@motorola.com> <43705E46.7050506@ti-wmc.nl In-Reply-To: <43705E46.7050506@ti-wmc.nl> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Simon Oosthoek wrote: > Just out of interest, how would you verify this table? I'm sure this > would need some form of crypto verification to make sure the MR isn't an > imposter, right? do you want to authenticate the mobile router or check if the mobile router is authorized to use a certain MNP? if its the former, the MR and the HA run IKEv2 to authenticate each other and setup security associations. if its the later, the prefix table contains a mapping of the identity of the mobile router to the MNPs that it is allowed to advertise on the mobile network. Vijay > > (I'm looking at NEMO as a solution for secure personal networks, so from > my perspective, authentication and authorisation is very important) > > Cheers > > Simon From nemo-bounces@ietf.org Tue Nov 08 17:50:29 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 1EZcIP-0005HW-3u; Tue, 08 Nov 2005 17:50:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcIN-0005H8-PZ for nemo@megatron.ietf.org; Tue, 08 Nov 2005 17:50:27 -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 RAA11658 for ; Tue, 8 Nov 2005 17:50:01 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcYD-0003ee-SL for nemo@ietf.org; Tue, 08 Nov 2005 18:06:53 -0500 Received: from iseran.local (unknown [IPv6:2001:410:1000:f000:20a:95ff:fef5:49a5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id ACB8F4C138 for ; Wed, 9 Nov 2005 07:49:45 +0900 (JST) Date: Wed, 9 Nov 2005 07:49:30 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051109074930.43393f9d.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: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [nemo] Rechartering: FMIPv6 for 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 Dear all, Shouldn't we take a look at how FMIPv6 should work for NEMO Basic Support ? Isn't there any other protocol we need to fx ? Thierry From nemo-bounces@ietf.org Tue Nov 08 18:42:32 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 1EZd6m-00053M-QG; Tue, 08 Nov 2005 18:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZd6l-00053E-Rl for nemo@megatron.ietf.org; Tue, 08 Nov 2005 18:42:31 -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 SAA13913 for ; Tue, 8 Nov 2005 18:42:05 -0500 (EST) Received: from pp107-98.bctel.ca ([209.52.107.98] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdMe-0004mf-VA for nemo@ietf.org; Tue, 08 Nov 2005 18:58:58 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 2543C16E568; Wed, 9 Nov 2005 07:45:19 +0800 (SGT) Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO From: Chan-Wah NG To: Thierry Ernst In-Reply-To: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> References: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Wed, 09 Nov 2005 07:45:18 +0800 Message-Id: <1131493518.12021.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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 On Wed, 2005-11-09 at 07:49 +0900, Thierry Ernst wrote: > Dear all, > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > Support ? Isn't there any other protocol we need to fx ? I am not a FMIP expert, but AFAICR, FMIP does not concern the HA. FMIP only concerns the mobile node and pAR, nAR. Thus, NEMO-BS should work independently with NEMO-BS. There is nothing to fix, be it the FMIP between MR and nAR,pAR or when the MR is a nAR or pAR (might be very slow to have MR acting as FMIP-enabled AR for its VMNs though). However, when we do have NEMO RO, then I forsee there may be a need to address FMIP. But that is jumping the gun a bit, since we have not even decide we want to RO. /rgds /cwng From nemo-bounces@ietf.org Tue Nov 08 19:09:07 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 1EZdWV-0005Pj-TK; Tue, 08 Nov 2005 19:09:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZdWU-0005PT-2p for nemo@megatron.ietf.org; Tue, 08 Nov 2005 19:09: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 TAA18852 for ; Tue, 8 Nov 2005 19:08:39 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdmM-0006f9-L1 for nemo@ietf.org; Tue, 08 Nov 2005 19:25:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA8NZEG17194; Tue, 8 Nov 2005 15:35:14 -0800 X-mProtect: <200511082335> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp162174.americas.nokia.com (10.241.162.174, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdcvjwnf; Tue, 08 Nov 2005 15:35:13 PST Message-ID: <43713E02.907@iprg.nokia.com> Date: Tue, 08 Nov 2005 16:08:34 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO References: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> In-Reply-To: <20051109074930.43393f9d.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: 1ac7cc0a4cd376402b85bc1961a86ac2 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: > Dear all, > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > Support ? Isn't there any other protocol we need to fx ? not for NEMO basic support. the access router always sees the CoA of the mobile router. never the actual mobile network traffic. so just setting up forwarding from the old CoA to the new CoA is enough for NEMO. FMIPv6 already does this. Vijay From nemo-bounces@ietf.org Tue Nov 08 19:16:32 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 1EZddg-0001Gl-7y; Tue, 08 Nov 2005 19:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZddd-0001GE-Sk for nemo@megatron.ietf.org; Tue, 08 Nov 2005 19:16:30 -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 TAA22016 for ; Tue, 8 Nov 2005 19:16:02 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZdtW-0007oh-4j for nemo@ietf.org; Tue, 08 Nov 2005 19:32:55 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA90SUnl014030; Tue, 8 Nov 2005 17:28:30 -0700 (MST) Received: from [144.189.73.10] (mvp-144-189-73-10.corp.mot.com [144.189.73.10]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA90OdFv012685; Tue, 8 Nov 2005 18:24:40 -0600 (CST) Message-ID: <43713FC9.3070705@motorola.com> Date: Wed, 09 Nov 2005 01:16:09 +0100 From: Christophe Janneteau User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO References: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> <1131493518.12021.5.camel@localhost> In-Reply-To: <1131493518.12021.5.camel@localhost> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chan-Wah NG 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, I have the same understanding as Chan-Wah. I am not an FMIP expert neither but to my understanding FMIP deals with redirecting the traffic sent to the MN's oCoA (arriving at pAR) to the MN's nCoA (at the nAR). Binding at the pAR is between oCoA and nCoA, not HoA. When MN is an MR using NEMO-BS, then traffic to MNNs is always tunneled to the MR'sCoA (thanks to HA). As a result it is sufficient for MR's to use standard FMIPv6 to support redirection of traffic for MNNs between pAR and nAR. Christophe Chan-Wah NG wrote: > On Wed, 2005-11-09 at 07:49 +0900, Thierry Ernst wrote: >> Dear all, >> >> Shouldn't we take a look at how FMIPv6 should work for NEMO Basic >> Support ? Isn't there any other protocol we need to fx ? > > I am not a FMIP expert, but AFAICR, FMIP does not concern the HA. FMIP > only concerns the mobile node and pAR, nAR. Thus, NEMO-BS should work > independently with NEMO-BS. There is nothing to fix, be it the FMIP > between MR and nAR,pAR or when the MR is a nAR or pAR (might be very > slow to have MR acting as FMIP-enabled AR for its VMNs though). > > However, when we do have NEMO RO, then I forsee there may be a need to > address FMIP. But that is jumping the gun a bit, since we have not even > decide we want to RO. > > /rgds > /cwng > From nemo-bounces@ietf.org Tue Nov 08 19:46:22 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 1EZe6Y-0000bb-Rq; Tue, 08 Nov 2005 19:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZe6X-0000bT-0F for nemo@megatron.ietf.org; Tue, 08 Nov 2005 19:46:21 -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 TAA29230 for ; Tue, 8 Nov 2005 19:45:54 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZeMQ-00025H-5j for nemo@ietf.org; Tue, 08 Nov 2005 20:02:47 -0500 Received: from iseran.local (unknown [IPv6:2002:d134:98d4:1::1]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 65B2F4C0BB for ; Wed, 9 Nov 2005 09:46:00 +0900 (JST) Date: Wed, 9 Nov 2005 09:45:54 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051109094554.42effe2f.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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Subject: [nemo] Final Agenda X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Here is the final agenda, and you can also find it online on https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 Thierry. #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #~~~~~~~~~~~~~~~~~~~ # NEMO WG WEDNESDAY 9, NOVEMBER 2005 1300-1500 # 64th IETF Meeting Vancouver # http://www.ietf.org/html.charters/nemo-charter.html # # Draft NEMO WG Agenda, as of Nov.06, 2005 # http://www.mobilenetworks.org/nemo/ietf64/nemo-ietf64-agenda.txt # # All NEMO WG related documents available on # http://www.mobilenetworks.org/nemo # Slides will be posted in http://www.mobilenetworks.org/nemo/ietf64/ #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #~~~~~~~~~~~~~~~~~~~ 1 Welcoming, Agenda Bashing, TAHI announcement and WG doc status ................ 05mins Chairs 2. WG Documents Status & Last Calls 2a WG Last Call: NEMO Terminology ................................................. 10mins Thierry Ernst http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-04.txt Issues: http://www.sfc.wide.ad.jp/~ernst/nemo/ Purpose: Approve issues marked as "Validate B4 Closing" 2b NEMO Requirement ............................................................... 05mins Thierry Ernst http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt Issues: http://www.sfc.wide.ad.jp/~ernst/nemo/ Purpose: Approve issues marked as "Validate B4 Closing" 2c NEMO Home Network Models ....................................................... 10mins Vijay Devarapalli http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-05.txt Issues: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issues.html 3 Analysis of Multihoming in Network Mobility Support ............................ 15mins ChanWah Ng http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt Issue List: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ Purpose: Get WG consensus on the recommendations regarding issues to be solved in which respective WG. 4 NEMO Routing Optimization 4a Status of the NEMO RO Problem Statement draft .................................. 10mins Masafumi Watari http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-01.txt 4b 1st Presentation of the NEMO RO Solution Space Analysis draft .................. 20mins Masafumi Watari http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt 5 NEMO v4 and NEMO v6 5a Status of the Mip6trans DT (presentation in the MIP6 WG) ....................... 05mins Vijay Deverapalli http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-00.txt 5b IPv4 Mobile Host/Network support for NEMO Basic Support Protocol ............... 10mins Keiichi Shima http://www.ietf.org/internet-drafts/draft-shima-nemo-v4prefix-01 Purpose: about some detailed procedures of supporting IPv4 host/net which is not currently dealt with in draft-ietf-mip6-nemo-v4ytraversal 5c NEMO Basic Support for IPv4 .................................................... 10mins Alex Petrescu & Kent Leung http://www.ietf.org/internet-drafts/draft-leung-nemov4-base-00.txt Purpose: Present Mobile IPv4 extensions to support IPv4 Mobile Routers. 6 NEMO WG Status and Charter ..................................................... 15mins Chairs 7 Conclusion / Wrap Up ........................................................... 05mins Chairs #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #~~~~~~~~~~~~~~~~~~~ # FYI only # Non WG Drafts Announced on the NEMO WG ML since Paris Meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ Dual Stack Mobile IPv6 (DSMIPv6) http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-00.txt [NEMO 0511] Global HA to HA protocol http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-01.txt [IETF 0510] Analysis of Multiple Mobile Routers Cooperation http://www.nautilus6.org/doc/drafts/draft-tsukada-nemo-mr-cooperation-analysis-00.txt Routing Optimization in the same nested mobile network http://www.ietf.org/internet-drafts/draft-baek-nemo-nested-ro-00.txt IPv4 Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-leung-nemov4-base-00.txt [NEMO 0510] SIP-based Network Mobility (SIP-NEMO) Route Optimization http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt [NEMO 0510] Local HA to HA protocol http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-nemo-local-haha-00.txt [IETF 050706] Dynamic Multicast Tree Construction for NEMO http://www.ietf.org/internet-drafts/draft-park-nemo-dyn-multicast-tree-00.txt [IETF 0510] IPv4 Mobile Host/Network support for NEMO Basic Support Protocol http://www.ietf.org/internet-drafts/draft-shima-nemo-v4prefix-01 [IETF 0510] From nemo-bounces@ietf.org Wed Nov 09 01:19:17 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 1EZjIj-00021j-9p; Wed, 09 Nov 2005 01:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZjIi-00021S-Cw for nemo@megatron.ietf.org; Wed, 09 Nov 2005 01:19:16 -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 BAA15973 for ; Wed, 9 Nov 2005 01:18:49 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZjYX-0001QQ-FB for nemo@ietf.org; Wed, 09 Nov 2005 01:35:46 -0500 Received: by wproxy.gmail.com with SMTP id 58so294597wri for ; Tue, 08 Nov 2005 22:19:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HWcer4PsntBc7qU/NrHARirZJf22jCFjMV/VG3qVdUA8TYwNMckcPDEZHB0yqiVdgd4ufLvRafzqKVte0YushWVUXdXLR5fNKzbVuRW+X/UxdsPjvD8gw1IL8JMesRLOpllEORBR79Hi8XVP80umenmAgFLSWMOQptwF/+vDOOc= Received: by 10.54.104.2 with SMTP id b2mr300828wrc; Tue, 08 Nov 2005 22:19:04 -0800 (PST) Received: by 10.54.131.1 with HTTP; Tue, 8 Nov 2005 22:19:04 -0800 (PST) Message-ID: Date: Wed, 9 Nov 2005 15:19:04 +0900 From: Koshiro MITSUYA To: Vijay Devarapalli Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO In-Reply-To: <43713E02.907@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> <43713E02.907@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, At this momemnt, I agree that nothing to be changed in FMIPv6 for NEMO Basic support. But I am just curious what happend in the case MR is the FMIP-AR for example. Additionaly don't you think it is a bit dangerous to say that without confirmation? I think it's a good time to do quick review FMIPv6 for NEMO and to do some epxeriment with implementations. If WG has interesting, I am willing to do experiment because we have both FMIPv6 and NEMO implementation on the same platform (SHISA and TARZAN). Maybe we can ask a hand from Linux guys? regards, Koshiro On 11/9/05, Vijay Devarapalli wrote: > Thierry Ernst wrote: > > Dear all, > > > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > > Support ? Isn't there any other protocol we need to fx ? > > not for NEMO basic support. the access router always > sees the CoA of the mobile router. never the actual > mobile network traffic. so just setting up forwarding > from the old CoA to the new CoA is enough for NEMO. > FMIPv6 already does this. > > Vijay > > From nemo-bounces@ietf.org Wed Nov 09 04:31:08 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 1EZmIO-00056j-Nt; Wed, 09 Nov 2005 04:31:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmIN-00056e-F1 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 04:31:07 -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 EAA24975 for ; Wed, 9 Nov 2005 04:30:39 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmYL-0006Ab-Mq for nemo@ietf.org; Wed, 09 Nov 2005 04:47:39 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2005 10:30:57 +0100 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 jA99UD1V001913; Wed, 9 Nov 2005 10:30:54 +0100 (MET) 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, 9 Nov 2005 10:30:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Rechartering: FMIPv6 for NEMO Date: Wed, 9 Nov 2005 10:30:31 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0178AD72@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Rechartering: FMIPv6 for NEMO Thread-Index: AcXkuFX+I9uDxtVdTduYRrTIKecJ0gAV5Alg From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "ml-nemo" X-OriginalArrivalTime: 09 Nov 2005 09:30:38.0557 (UTC) FILETIME=[3EC9B0D0:01C5E510] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Actually, we could consider HMIP as well. We have shown in the past that HMIP for NEMO can be achieved using a regional NEMO prefix delegation. That text was removed from the working group document, but the requirement is still there.=20 Pascal=20 >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst >Sent: Tuesday, November 08, 2005 11:50 PM >To: ml-nemo >Subject: [nemo] Rechartering: FMIPv6 for NEMO > > >Dear all, > >Shouldn't we take a look at how FMIPv6 should work for NEMO Basic >Support ? Isn't there any other protocol we need to fx ? > >Thierry From nemo-bounces@ietf.org Wed Nov 09 11:01:13 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 1EZsNt-0007Jf-DZ; Wed, 09 Nov 2005 11:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsNp-0007JX-KO for nemo@megatron.ietf.org; Wed, 09 Nov 2005 11:01: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 LAA17999 for ; Wed, 9 Nov 2005 11:00:41 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZsdo-0000BJ-8k for nemo@ietf.org; Wed, 09 Nov 2005 11:17:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA9FQim25107; Wed, 9 Nov 2005 07:26:44 -0800 X-mProtect: <200511091526> Nokia Silicon Valley Messaging Protection Received: from danira-pool05384.americas.nokia.com (10.241.53.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdar8LUK; Wed, 09 Nov 2005 07:26:42 PST Message-ID: <43721CFD.6030006@iprg.nokia.com> Date: Wed, 09 Nov 2005 07:59:57 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO References: <7892795E1A87F04CADFCCF41FADD00FC0178AD72@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0178AD72@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Pascal Thubert (pthubert) wrote: > Actually, we could consider HMIP as well. We have shown in the past that > HMIP for NEMO can be achieved using a regional NEMO prefix delegation. > That text was removed from the working group document, but the > requirement is still there. Pascal, if I understand it right, you were proposing a new mechanism not extensions to HMIPv6. Vijay > > Pascal > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > > Thierry Ernst > >>Sent: Tuesday, November 08, 2005 11:50 PM >>To: ml-nemo >>Subject: [nemo] Rechartering: FMIPv6 for NEMO >> >> >>Dear all, >> >>Shouldn't we take a look at how FMIPv6 should work for NEMO Basic >>Support ? Isn't there any other protocol we need to fx ? >> >>Thierry > > From nemo-bounces@ietf.org Wed Nov 09 11:24:48 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 1EZski-0005KN-Rv; Wed, 09 Nov 2005 11:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZskg-0005Jr-R2 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 11:24: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 LAA19531 for ; Wed, 9 Nov 2005 11:24:18 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZt0j-0000v7-Js for nemo@ietf.org; Wed, 09 Nov 2005 11:41:22 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2005 17:24:37 +0100 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 jA9GOX11021535; Wed, 9 Nov 2005 17:24:34 +0100 (MET) 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, 9 Nov 2005 17:24:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Rechartering: FMIPv6 for NEMO Date: Wed, 9 Nov 2005 17:24:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0178B004@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Rechartering: FMIPv6 for NEMO Thread-Index: AcXlRujr67Q6aQB8Rfe1znxwCN76SgAAGIxw From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 09 Nov 2005 16:24:33.0762 (UTC) FILETIME=[11B93C20:01C5E54A] X-Spam-Score: 2.0 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: ml-nemo , Thierry Ernst , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay :) Well, the general idea of LMM is in HMIP, and that's not mine. My mechanism is still LMM, but a bit different from HMIP because DHCPv6PD gives you in a standard fashion a regional prefix whereas HMIP has to define a mechanism to get a CoA from the MAP. When I have to describe it, people understand much better when I say it's to NEMO what HMIP is to MIP.=20 And there are additional advantages in the NEMOized approach, since the delegated prefix can be used to accept visitors in an anonymous fashion, including MRs, which is the beginning of TIT-4-TAT in nested NEMO. The mechanism could also be twisted to enable some Route Optimization for the nested NEMO, to be discussed. This might seem a bit cryptic for those who did not follow the NEMO prefix delegation story. There is more in chapter 3.2 of the obsolete version of the nemo DHCPv6PD draft: http://mobilenetworks.org/nemo/drafts/draft-ietf-nemo-dhcpv6-pd-00.txt=20 Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Wednesday, November 09, 2005 5:00 PM >To: Pascal Thubert (pthubert) >Cc: Thierry Ernst; ml-nemo >Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO > >Pascal Thubert (pthubert) wrote: >> Actually, we could consider HMIP as well. We have shown in the past that >> HMIP for NEMO can be achieved using a regional NEMO prefix delegation. >> That text was removed from the working group document, but the >> requirement is still there. > >Pascal, if I understand it right, you were proposing a new >mechanism not extensions to HMIPv6. > >Vijay > >> >> Pascal >> >> >>>-----Original Message----- >>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of >> >> Thierry Ernst >> >>>Sent: Tuesday, November 08, 2005 11:50 PM >>>To: ml-nemo >>>Subject: [nemo] Rechartering: FMIPv6 for NEMO >>> >>> >>>Dear all, >>> >>>Shouldn't we take a look at how FMIPv6 should work for NEMO Basic >>>Support ? Isn't there any other protocol we need to fx ? >>> >>>Thierry >> >> From nemo-bounces@ietf.org Wed Nov 09 11:51:58 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 1EZtB0-000647-T6; Wed, 09 Nov 2005 11:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtAz-00063z-8u for nemo@megatron.ietf.org; Wed, 09 Nov 2005 11:51:57 -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 LAA21272 for ; Wed, 9 Nov 2005 11:51:28 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtR1-0001ie-9e for nemo@ietf.org; Wed, 09 Nov 2005 12:08:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA9GI7J11981; Wed, 9 Nov 2005 08:18:07 -0800 X-mProtect: <200511091618> Nokia Silicon Valley Messaging Protection Received: from danira-pool05384.americas.nokia.com (10.241.53.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdF2LIKe; Wed, 09 Nov 2005 08:18:05 PST Message-ID: <43722908.8090902@iprg.nokia.com> Date: Wed, 09 Nov 2005 08:51:20 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO References: <7892795E1A87F04CADFCCF41FADD00FC0178B004@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0178B004@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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Vijay :) > > Well, the general idea of LMM is in HMIP, and that's not mine. My > mechanism is still LMM, but a bit different from HMIP because DHCPv6PD > gives you in a standard fashion a regional prefix whereas HMIP has to > define a mechanism to get a CoA from the MAP. When I have to describe > it, people understand much better when I say it's to NEMO what HMIP is > to MIP. right. but the prefix delegation draft was the wrong place to specify this new mechanim. Vijay > > And there are additional advantages in the NEMOized approach, since the > delegated prefix can be used to accept visitors in an anonymous fashion, > including MRs, which is the beginning of TIT-4-TAT in nested NEMO. The > mechanism could also be twisted to enable some Route Optimization for > the nested NEMO, to be discussed. > > This might seem a bit cryptic for those who did not follow the NEMO > prefix delegation story. There is more in chapter 3.2 of the obsolete > version of the nemo DHCPv6PD draft: > http://mobilenetworks.org/nemo/drafts/draft-ietf-nemo-dhcpv6-pd-00.txt > > Pascal > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Wednesday, November 09, 2005 5:00 PM >>To: Pascal Thubert (pthubert) >>Cc: Thierry Ernst; ml-nemo >>Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO >> >>Pascal Thubert (pthubert) wrote: >> >>>Actually, we could consider HMIP as well. We have shown in the past > > that > >>>HMIP for NEMO can be achieved using a regional NEMO prefix > > delegation. > >>>That text was removed from the working group document, but the >>>requirement is still there. >> >>Pascal, if I understand it right, you were proposing a new >>mechanism not extensions to HMIPv6. >> >>Vijay >> >> >>>Pascal >>> >>> >>> >>>>-----Original Message----- >>>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > > Of > >>>Thierry Ernst >>> >>> >>>>Sent: Tuesday, November 08, 2005 11:50 PM >>>>To: ml-nemo >>>>Subject: [nemo] Rechartering: FMIPv6 for NEMO >>>> >>>> >>>>Dear all, >>>> >>>>Shouldn't we take a look at how FMIPv6 should work for NEMO Basic >>>>Support ? Isn't there any other protocol we need to fx ? >>>> >>>>Thierry >>> >>> From nemo-bounces@ietf.org Wed Nov 09 13:45: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 1EZuxD-00075L-Cb; Wed, 09 Nov 2005 13:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuxC-00075E-ME for nemo@megatron.ietf.org; Wed, 09 Nov 2005 13:45: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 NAA29340 for ; Wed, 9 Nov 2005 13:45:23 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvDF-0005WT-Or for nemo@ietf.org; Wed, 09 Nov 2005 14:02:27 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2005 19:45:41 +0100 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 jA9IjY13023295; Wed, 9 Nov 2005 19:45:37 +0100 (MET) 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, 9 Nov 2005 19:45:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Rechartering: FMIPv6 for NEMO Date: Wed, 9 Nov 2005 19:45:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0178B09E@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Rechartering: FMIPv6 for NEMO Thread-Index: AcXlTfdmPTfT1k0XSl2CdWkoSwDafQAD4RcA From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 09 Nov 2005 18:45:34.0578 (UTC) FILETIME=[C4C34D20:01C5E55D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ml-nemo , Thierry Ernst , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Wednesday, November 09, 2005 5:51 PM >To: Pascal Thubert (pthubert) >Cc: Thierry Ernst; ml-nemo; Ralph Droms (rdroms) >Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO > >Pascal Thubert (pthubert) wrote: >> Hi Vijay :) >> >> Well, the general idea of LMM is in HMIP, and that's not mine. My >> mechanism is still LMM, but a bit different from HMIP because DHCPv6PD >> gives you in a standard fashion a regional prefix whereas HMIP has to >> define a mechanism to get a CoA from the MAP. When I have to describe >> it, people understand much better when I say it's to NEMO what HMIP is >> to MIP. > >right. but the prefix delegation draft was the wrong >place to specify this new mechanim. > [] I think that was agreed. But if we recharter accordingly, this might be the right moment to reintroduce as a new draft the part that we took off when it was misplaced. I think it was the sense of Thierry's question.=20 Pascal From nemo-bounces@ietf.org Wed Nov 09 14:58:01 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 1EZw53-0008W8-Rt; Wed, 09 Nov 2005 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZw52-0008VN-RC for nemo@megatron.ietf.org; Wed, 09 Nov 2005 14:58:00 -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 OAA04448 for ; Wed, 9 Nov 2005 14:57:33 -0500 (EST) 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 1EZwL6-0007pk-5d for nemo@ietf.org; Wed, 09 Nov 2005 15:14:37 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 19BC58AB917 for ; Wed, 9 Nov 2005 11:55:45 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85761-01 for ; Wed, 9 Nov 2005 11:55:37 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 6B6248AB99C; Wed, 9 Nov 2005 11:55:37 -0800 (PST) X-Spam-Score: -2.4 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [209.52.105.114] (pp105-114.bctel.ca [209.52.105.114]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 16D628AB91D for ; Wed, 9 Nov 2005 11:55:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> References: <20051109074930.43393f9d.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO Date: Wed, 9 Nov 2005 11:55:51 -0800 To: ml-nemo X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Folks, Our revised charter needs to stick to outstanding issues that (a) are understood (b) affect a significant number of the realistic deployment scenarios (c) are not research problems (d) follow sound architectural principles w.r.t. Internet engineering Whether FMIPv6 affects NEMO, or vice-versa, should be determined before we discuss whether it's important enough to add to the charter. Otherwise, it does not satisfy requirement (a). So it's fine to discuss the topic, but premature to discuss it in the same sentence as the charter. TJ From nemo-bounces@ietf.org Wed Nov 09 15:12:27 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 1EZwJ1-0006Xd-Qj; Wed, 09 Nov 2005 15:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwJ0-0006XF-HI for nemo@megatron.ietf.org; Wed, 09 Nov 2005 15:12:26 -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 PAA05693 for ; Wed, 9 Nov 2005 15:11:58 -0500 (EST) 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 1EZwZ5-0008Pq-4N for nemo@ietf.org; Wed, 09 Nov 2005 15:29:03 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id C5B808AD14A for ; Wed, 9 Nov 2005 12:10:24 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85440-17 for ; Wed, 9 Nov 2005 12:10:17 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 2AD938AD150; Wed, 9 Nov 2005 12:10:17 -0800 (PST) X-Spam-Score: -2.4 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [209.52.105.114] (pp105-114.bctel.ca [209.52.105.114]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id CC3C88AD14E for ; Wed, 9 Nov 2005 12:10:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Wed, 9 Nov 2005 12:11:51 -0800 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] Jabber, Audio, Minutes X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 the past, I've tried to put everyone's comments on the Jabber session in real time. For this meeting, the Jabber can be used for general commentary and also for those participating remotely to submit questions and comments back to the WG. So, the audio stream will be the primary source of hearing what's being discussed during the meeting. The minutes will reflect only the general points and conclusions, not necessarily every person's individual comments. (Those can always be reposted to the ML for further discussion). There will also be a video recording of the meeting, as we have been doing (last meeting's video is available on the web site, btw). TJ From nemo-bounces@ietf.org Wed Nov 09 15:15:52 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 1EZwMK-0007an-MJ; Wed, 09 Nov 2005 15:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwMJ-0007ah-6p for nemo@megatron.ietf.org; Wed, 09 Nov 2005 15:15:51 -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 PAA05959 for ; Wed, 9 Nov 2005 15:15:23 -0500 (EST) 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 1EZwcN-00005h-0T for nemo@ietf.org; Wed, 09 Nov 2005 15:32:28 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 70F008AD14F; Wed, 9 Nov 2005 12:13:48 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85761-09; Wed, 9 Nov 2005 12:13:40 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id C8D858AD155; Wed, 9 Nov 2005 12:13:40 -0800 (PST) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [209.52.105.114] (pp105-114.bctel.ca [209.52.105.114]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 3DAE28AB9D5; Wed, 9 Nov 2005 12:13:39 -0800 (PST) In-Reply-To: <43700840.1060802@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> <20051028101235.06bda3e3.ernst@sfc.wide.ad.jp> <4361FF66.4030107@motorola.com> <20051104174919.119a888c.ernst@sfc.wide.ad.jp> <43700840.1060802@motorola.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Recharter items: multihoming - HAHA ? Date: Wed, 9 Nov 2005 12:15:33 -0800 To: Alexandru Petrescu X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 On Nov 7, 2005, at 6:06 PM, Alexandru Petrescu wrote: > What does HAHA have to do with NEMO? In my view, the global HAHA, which allows distributed HAs, is a real deployment issue for situations with large distances being traversed. The WG has received input from Boeing, NASA, and I believe an aeronautics organization, that this is a desired feature for RO in their networks. So to me, it seems that we should work on this, if people in the WG are interested. For local HAHA, which provides a cache coherency protocol, the topic is availability and load balancing. I am not as convinced this is something we need to work on, right now, in NEMO. But that's my personal opinion, and perhaps if someone has a convincing argument, we can discuss that. TJ From nemo-bounces@ietf.org Wed Nov 09 15:39:15 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 1EZwix-0007Wy-5Z; Wed, 09 Nov 2005 15:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwiv-0007We-Eq for nemo@megatron.ietf.org; Wed, 09 Nov 2005 15:39:13 -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 PAA07115 for ; Wed, 9 Nov 2005 15:38:45 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZwyz-0000fV-C7 for nemo@ietf.org; Wed, 09 Nov 2005 15:55:50 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id jA9KsiXK007130; Wed, 9 Nov 2005 13:54:44 -0700 (MST) Received: from [10.19.252.207] (mvp-10-19-252-207.corp.mot.com [10.19.252.207]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA9KqE6N026664; Wed, 9 Nov 2005 14:52:15 -0600 (CST) Message-ID: <43725E64.8050902@motorola.com> Date: Wed, 09 Nov 2005 12:39:00 -0800 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] Audio streaming and slides 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org T.J. Kniveton wrote: > In the past, I've tried to put everyone's comments on the Jabber > session in real time. > > For this meeting, the Jabber can be used for general commentary and > also for those participating remotely to submit questions and comments > back to the WG. > > So, the audio stream will be the primary source of hearing what's being > discussed during the meeting. The minutes will reflect only the general > points and conclusions, not necessarily every person's individual > comments. (Those can always be reposted to the ML for further discussion). > > There will also be a video recording of the meeting, as we have been > doing (last meeting's video is available on the web site, btw). > > TJ > For remoters, audio streaming is at http://videolab.uoregon.edu/events/ietf/ and most slides at http://onsite.ietf.org/proceedings/05nov/slides/ Alex From nemo-bounces@ietf.org Wed Nov 09 16:16:37 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 1EZxJ7-0005gP-3r; Wed, 09 Nov 2005 16:16:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxJ6-0005gD-5F for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:16:36 -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 QAA10226 for ; Wed, 9 Nov 2005 16:16:07 -0500 (EST) 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 1EZxYv-0002G4-LT for nemo@ietf.org; Wed, 09 Nov 2005 16:33:01 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id CE9E58AD145 for ; Wed, 9 Nov 2005 13:14:18 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86066-18 for ; Wed, 9 Nov 2005 13:14:11 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 0D1AE8AD14E; Wed, 9 Nov 2005 13:14:11 -0800 (PST) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [209.52.156.146] (unknown [209.52.156.146]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id EB0AB8AD145 for ; Wed, 9 Nov 2005 13:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: ml-nemo WG Message-Id: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-792428560 From: "T.J. Kniveton" Date: Wed, 9 Nov 2005 13:16:07 -0800 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [nemo] Issue A14 - e-face and i-face X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-1-792428560 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Can we have some comments from non-English speakers that think i-face and e-face are easier to understand than ingress interface and egress interface? This still seems awkward to me -- I wouldn't know what e- face and i-face mean unless I go do some research. TJ http://www.sfc.wide.ad.jp/~ernst/nemo/node17.html Issue A15: [VALIDATE B4 CLOSING 0502] I-face and E-face [Comment #1] by Vijay 040721 and 040722: Ojection to terms E-face and I-face. RFC3753 does not include E-face and I-face. Ingress and Egress are widely used terms, and everybody understands them. [Comment #2] Thierry: I don't consider this as an issue. This is not a new definition, not a redefinition, just an abbreviation. Note that the terms egress interface and ingress interface are defined in RFC3753 Conclusion: I think it helps people to keep the abbreviation, particularly non native English speakers for who "ingress" and "egress" sounds similar --Apple-Mail-1-792428560 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Can we have some comments from = non-English speakers that think i-face and e-face are easier to = understand than ingress interface and egress interface? This still seems = awkward to me -- I wouldn't know what e-face and i-face mean unless I go = do some research.

TJ


Issue A15: [VALIDATE B4 = CLOSING 0502] I-face and = E-face

[Comment #1] by Vijay 040721 and = 040722:
Ojection to terms E-face and I-face. RFC3753 does not include = E-face and I-face. Ingress and Egress are widely used terms, and = everybody understands them.


[Comment #2] Thierry:


I = don't consider this as an issue. This is not a new definition, not a = redefinition, just an abbreviation. Note that the terms egress interface = and ingress interface are defined in RFC3753


Conclusion: I think it helps people to keep the = abbreviation, particularly non native English speakers for who "ingress" = and "egress" sounds similar


= --Apple-Mail-1-792428560-- From nemo-bounces@ietf.org Wed Nov 09 16:22: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 1EZxP7-00087K-8u; Wed, 09 Nov 2005 16:22:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxP5-00086g-Dn for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:22:47 -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 QAA10529 for ; Wed, 9 Nov 2005 16:22:19 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxf9-0002Pg-Pq for nemo@ietf.org; Wed, 09 Nov 2005 16:39:25 -0500 Received: from [IPv6:2001:410:1000:f000:211:24ff:fe21:a941] (unknown [IPv6:2001:410:1000:f000:211:24ff:fe21:a941]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6EC864C851; Thu, 10 Nov 2005 06:22:20 +0900 (JST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0178B09E@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0178B09E@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <125CA2F8-BCAC-4375-94B7-78B302055E94@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO Date: Thu, 10 Nov 2005 06:22:17 +0900 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , Vijay Devarapalli , "Ralph Droms \(rdroms\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal On 2005/11/10, at 3:45, Pascal Thubert (pthubert) wrote: > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >> Sent: Wednesday, November 09, 2005 5:51 PM >> To: Pascal Thubert (pthubert) >> Cc: Thierry Ernst; ml-nemo; Ralph Droms (rdroms) >> Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay :) >>> >>> Well, the general idea of LMM is in HMIP, and that's not mine. My >>> mechanism is still LMM, but a bit different from HMIP because > DHCPv6PD >>> gives you in a standard fashion a regional prefix whereas HMIP >>> has to >>> define a mechanism to get a CoA from the MAP. When I have to >>> describe >>> it, people understand much better when I say it's to NEMO what HMIP > is >>> to MIP. >> >> right. but the prefix delegation draft was the wrong >> place to specify this new mechanim. >> > [] I think that was agreed. But if we recharter accordingly, this > might be the right moment to reintroduce as a new draft the part > that we > took off when it was misplaced. I think it was the sense of Thierry's > question. Providing prefix of visited network through MR is interesting topic. It will be nice to re-introduce the document to NEMO WG, though I am not sure this is right topic in NEMO. regards ryuji From nemo-bounces@ietf.org Wed Nov 09 16:26:36 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 1EZxSm-0001Uc-68; Wed, 09 Nov 2005 16:26:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSj-0001UX-8T for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:26:34 -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 QAA10710 for ; Wed, 9 Nov 2005 16:26:05 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxib-0002Um-I0 for nemo@ietf.org; Wed, 09 Nov 2005 16:42:58 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 5328AC21E for ; Wed, 9 Nov 2005 16:26:08 -0500 (EST) 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 jA9LQ7GT000823; Wed, 9 Nov 2005 16:26:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jA9LQ64s018591; Wed, 9 Nov 2005 16:26:06 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 17918-01-3; Wed, 9 Nov 2005 16:26:06 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jA9LPM4k018268;Wed, 9 Nov 2005 16:25:22 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id D8DF734A4F; Wed, 9 Nov 2005 16:25:22 -0500 (EST) Received: from [209.52.110.168] (pp110-168.bctel.ca [209.52.110.168])by webmail.grc.nasa.gov (Postfix) with ESMTPid 3FFC234A16; Wed, 9 Nov 2005 16:24:51 -0500 (EST) Message-ID: <43726927.6030409@grc.nasa.gov> Date: Wed, 09 Nov 2005 16:24:55 -0500 From: ivancic User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Recharter items: multihoming - HAHA ? References: <20051021102624.66cd4a10.ernst@sfc.wide.ad.jp> <435F540D.2080105 @motorola.com> <1130323515.11457.16.camel@localhost> <20051027104143.00d4d c 34.ernst@sfc.wide.ad.jp> <4360E491.9010307@motorola.com> <20051028101235. 06 bda3e3.ernst@sfc.wide.ad.jp> <4361FF66.4030107@motorola.com><20051104174 919 .119a888c.ernst@sfc.wide.ad.jp><43700840.1060802@motorola.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 OpenPGP: id=FC455475 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-imss-version: 2.033 X-imss-result: Passed X-imss-scores: Clean:87.65890 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Yes, TJ is correct. HAHA is very desirable for the Aeronautics community (National AERONAUTICS and Space Administration(. I suspect military organizations, bovernments, coast guard, and any widely disperse organization would find this very useful. Will (a NASA guy) ****************************** T.J. Kniveton wrote: > On Nov 7, 2005, at 6:06 PM, Alexandru Petrescu wrote: > >> What does HAHA have to do with NEMO? > > > > In my view, the global HAHA, which allows distributed HAs, is a real > deployment issue for situations with large distances being traversed. > The WG has received input from Boeing, NASA, and I believe an > aeronautics organization, that this is a desired feature for RO in > their networks. So to me, it seems that we should work on this, if > people in the WG are interested. > > For local HAHA, which provides a cache coherency protocol, the topic > is availability and load balancing. I am not as convinced this is > something we need to work on, right now, in NEMO. But that's my > personal opinion, and perhaps if someone has a convincing argument, > we can discuss that. > > TJ > > From nemo-bounces@ietf.org Wed Nov 09 16:27:46 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 1EZxTu-0001eI-7d; Wed, 09 Nov 2005 16:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxTt-0001eC-3W for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:27:45 -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 QAA10750 for ; Wed, 9 Nov 2005 16:27:16 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxjy-0002WQ-9q for nemo@ietf.org; Wed, 09 Nov 2005 16:44:22 -0500 Received: from [IPv6:2001:410:1000:f000:211:24ff:fe21:a941] (unknown [IPv6:2001:410:1000:f000:211:24ff:fe21:a941]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id BCE4F4C064; Thu, 10 Nov 2005 06:27:28 +0900 (JST) In-Reply-To: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> References: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Issue A14 - e-face and i-face Date: Thu, 10 Nov 2005 06:27:24 +0900 To: "T.J. Kniveton" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org TJ I am one of non English speakers:-) i prefer ingress and egress interface rather than E-face/I-face. We should define only terms which we really need. Defining a lot of new terms is sometime confusing. ryuji On 2005/11/10, at 6:16, T.J. Kniveton wrote: > Can we have some comments from non-English speakers that think i- > face and e-face are easier to understand than ingress interface and > egress interface? This still seems awkward to me -- I wouldn't know > what e-face and i-face mean unless I go do some research. > > TJ > > http://www.sfc.wide.ad.jp/~ernst/nemo/node17.html > > Issue A15: [VALIDATE B4 CLOSING 0502] I-face and E-face > > [Comment #1] by Vijay 040721 and 040722: > Ojection to terms E-face and I-face. RFC3753 does not include E- > face and I-face. Ingress and Egress are widely used terms, and > everybody understands them. > > > [Comment #2] Thierry: > > > > I don't consider this as an issue. This is not a new definition, > not a redefinition, just an abbreviation. Note that the terms > egress interface and ingress interface are defined in RFC3753 > > > Conclusion: I think it helps people to keep the abbreviation, > particularly non native English speakers for who "ingress" and > "egress" sounds similar > > From nemo-bounces@ietf.org Wed Nov 09 16:29:38 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 1EZxVi-0001n3-4r; Wed, 09 Nov 2005 16:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxVg-0001mm-Vg for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:29:37 -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 QAA10804 for ; Wed, 9 Nov 2005 16:29:08 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxlm-0002YY-6H for nemo@ietf.org; Wed, 09 Nov 2005 16:46:14 -0500 Received: from l1.rennes.enst-bretagne.fr (l1.rennes.enst-bretagne.fr [192.44.77.3]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA9LTCa21216 for ; Wed, 9 Nov 2005 22:29:12 +0100 Received: from [209.52.106.196] (pp106-196.bctel.ca [209.52.106.196]) (authenticated bits=0) by l1.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA9LT23o028417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 9 Nov 2005 22:29:12 +0100 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> References: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <988525E0-28D0-40EF-AEA8-42FE6A7E28B7@enst-bretagne.fr> Content-Transfer-Encoding: 7bit From: Nicolas Montavont Subject: Re: [nemo] Issue A14 - e-face and i-face Date: Wed, 9 Nov 2005 22:29:02 +0100 To: ml-nemo WG X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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, If said by an english speaker, I have no pb to make the difference between ingress and egress. If I have to speak, or if a non-english speaker talks about ingress and egress, I can get confused. i and e are much easier to understand. Having said that, is there a pb to keep using only ingress and egress in documents, and be able to use abbreviations when speaking? Nicolas On 9 nov. 05, at 22:16, T.J. Kniveton wrote: > Can we have some comments from non-English speakers that think i- > face and e-face are easier to understand than ingress interface and > egress interface? This still seems awkward to me -- I wouldn't know > what e-face and i-face mean unless I go do some research. > > TJ > > http://www.sfc.wide.ad.jp/~ernst/nemo/node17.html > > Issue A15: [VALIDATE B4 CLOSING 0502] I-face and E-face > > [Comment #1] by Vijay 040721 and 040722: > Ojection to terms E-face and I-face. RFC3753 does not include E- > face and I-face. Ingress and Egress are widely used terms, and > everybody understands them. > > > [Comment #2] Thierry: > > > > I don't consider this as an issue. This is not a new definition, > not a redefinition, just an abbreviation. Note that the terms > egress interface and ingress interface are defined in RFC3753 > > > Conclusion: I think it helps people to keep the abbreviation, > particularly non native English speakers for who "ingress" and > "egress" sounds similar > > From nemo-bounces@ietf.org Wed Nov 09 16:30: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 1EZxWE-0001uM-1I; Wed, 09 Nov 2005 16:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxWC-0001uE-3j for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:30:08 -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 QAA10838 for ; Wed, 9 Nov 2005 16:29:40 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxmH-0002ZP-Ho for nemo@ietf.org; Wed, 09 Nov 2005 16:46:45 -0500 Received: from [IPv6:2001:410:1000:f000:211:24ff:fe21:a941] (unknown [IPv6:2001:410:1000:f000:211:24ff:fe21:a941]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 659484C0E6; Thu, 10 Nov 2005 06:29:54 +0900 (JST) In-Reply-To: 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> <4361FF66.4030107@motorola.com> <20051104174919.119a888c.ernst@sfc.wide.ad.jp> <43700840.1060802@motorola.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04C7CCEF-DD60-46A3-B97D-214FFCB1EDE6@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Recharter items: multihoming - HAHA ? Date: Thu, 10 Nov 2005 06:29:45 +0900 To: "T.J. Kniveton" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ml-nemo , Thierry Ernst , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi TJ On 2005/11/10, at 5:15, T.J. Kniveton wrote: > On Nov 7, 2005, at 6:06 PM, Alexandru Petrescu wrote: > >> What does HAHA have to do with NEMO? > > > In my view, the global HAHA, which allows distributed HAs, is a > real deployment issue for situations with large distances being > traversed. The WG has received input from Boeing, NASA, and I > believe an aeronautics organization, that this is a desired feature > for RO in their networks. So to me, it seems that we should work on > this, if people in the WG are interested. agree, it worth to work on this topic. There are interests from several groups. > For local HAHA, which provides a cache coherency protocol, the > topic is availability and load balancing. I am not as convinced > this is something we need to work on, right now, in NEMO. But > that's my personal opinion, and perhaps if someone has a convincing > argument, we can discuss that. Differences between local HAHA and global HAHA are basically operational things. There are three HAHA related documents. We separated documents because of WG inputs when we presented HAHA in NEMO WG. - The base spec. - Local HAHA - Global HAHA The base spec. is defined for the HAHA protocol spec and latter two documents describe operational matter of the HAHA protocol. If we go for the global HAHA, we need to discuss both the base spec and the global HAHA. regards, ryuji From nemo-bounces@ietf.org Wed Nov 09 16:31: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 1EZxXC-0002CM-6x; Wed, 09 Nov 2005 16:31:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxXA-0002CB-A9 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 16:31:08 -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 QAA10984 for ; Wed, 9 Nov 2005 16:30:36 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxnA-0002cJ-N5 for nemo@ietf.org; Wed, 09 Nov 2005 16:47:42 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 1DDD0C344 for ; Wed, 9 Nov 2005 16:30:54 -0500 (EST) 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 jA9LUrGT001797; Wed, 9 Nov 2005 16:30:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jA9LUrJV020931; Wed, 9 Nov 2005 16:30:53 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 20316-01-3; Wed, 9 Nov 2005 16:30:53 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jA9LTc76020618;Wed, 9 Nov 2005 16:29:38 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 4C33F34A87; Wed, 9 Nov 2005 16:29:38 -0500 (EST) Received: from [209.52.110.168] (pp110-168.bctel.ca [209.52.110.168])by webmail.grc.nasa.gov (Postfix) with ESMTPid E64C134A3E; Wed, 9 Nov 2005 16:29:24 -0500 (EST) Message-ID: <43726A3C.9030501@grc.nasa.gov> Date: Wed, 09 Nov 2005 16:29:32 -0500 From: ivancic User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Issue A14 - e-face and i-face References: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> In-Reply-To: <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=FC455475 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-imss-version: 2.033 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I get confused with ingress and egress and I am an English speaker! If the terminology is more helpful than harmful, I vote to keep it. Will T.J. Kniveton wrote: > Can we have some comments from non-English speakers that think i-face > and e-face are easier to understand than ingress interface and egress > interface? This still seems awkward to me -- I wouldn't know what > e-face and i-face mean unless I go do some research. > > TJ > > http://www.sfc.wide.ad.jp/~ernst/nemo/node17.html > > > *Issue A15: [V* *ALIDATE * *B4 * *CLOSING 0502* *] I-face and E-face* > > [Comment #1] /by Vijay 040721 and 040722/ : > Ojection to terms E-face and I-face. RFC3753 does not include E-face > and I-face. Ingress and Egress are widely used terms, and everybody > understands them. > > > [Comment #2] /Thierry/ : > > > I don't consider this as an issue. This is not a new definition, not a > redefinition, just an abbreviation. Note that the terms egress > interface and ingress interface are defined in RFC3753 > > > Conclusion: /I think it helps people to keep the abbreviation, > particularly non native English speakers for who "ingress" and > "egress" sounds similar/ > > From nemo-bounces@ietf.org Wed Nov 09 17:08:11 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 1EZy71-00013K-Eg; Wed, 09 Nov 2005 17:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZy6z-00011W-JA for nemo@megatron.ietf.org; Wed, 09 Nov 2005 17:08:09 -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 RAA13728 for ; Wed, 9 Nov 2005 17:07:41 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZyN4-0003t4-Ah for nemo@ietf.org; Wed, 09 Nov 2005 17:24:47 -0500 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 jA9M7pa24353; Wed, 9 Nov 2005 23:07:51 +0100 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 jA9M7quH098830; Wed, 9 Nov 2005 23:07:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "T.J. Kniveton" Subject: Re: [nemo] Issue A14 - e-face and i-face In-reply-to: Your message of Wed, 09 Nov 2005 13:16:07 PST. <011F483C-05B0-4C9E-8F0F-19B875171D7C@kniveton.com> Date: Wed, 09 Nov 2005 23:07:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: Can we have some comments from non-English speakers that think i-face and e-face are easier to understand than ingress interface and egress interface? This still seems awkward to me -- I wouldn't know what e- face and i-face mean unless I go do some research. => I agree with you and more, as in French the letter i is pronounce exactly like the letter e in English this can become a nightmare in its not written form! So I support TJ, PLEASE use ingress and egress at least! Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Wed Nov 09 17:31:13 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 1EZyTJ-00012t-Bi; Wed, 09 Nov 2005 17:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyTI-00012l-FX for nemo@megatron.ietf.org; Wed, 09 Nov 2005 17:31: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 RAA14767 for ; Wed, 9 Nov 2005 17:30:43 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZyjN-0004R3-5d for nemo@ietf.org; Wed, 09 Nov 2005 17:47:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8FCCAEC86F; Thu, 10 Nov 2005 07:30:43 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 490E2EC85D; Thu, 10 Nov 2005 07:30:43 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:5710] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:5710]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 1017C2E032; Thu, 10 Nov 2005 07:30:09 +0900 (JST) Message-ID: <43727899.3090600@kddilabs.jp> Date: Thu, 10 Nov 2005 07:30:49 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] Issue A14 - e-face and i-face References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I also agree. regards, watari On 2005/11/10 7:07, Francis Dupont wrote: > In your previous mail you wrote: > > Can we have some comments from non-English speakers that think i-face > and e-face are easier to understand than ingress interface and egress > interface? This still seems awkward to me -- I wouldn't know what e- > face and i-face mean unless I go do some research. > > => I agree with you and more, as in French the letter i is pronounce > exactly like the letter e in English this can become a nightmare in > its not written form! So I support TJ, PLEASE use ingress and egress > at least! > > Regards > > Francis.Dupont@enst-bretagne.fr > > From nemo-bounces@ietf.org Wed Nov 09 17:59:37 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 1EZyun-0002C7-5p; Wed, 09 Nov 2005 17:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyul-0002A7-E1 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 17:59:35 -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 RAA16010 for ; Wed, 9 Nov 2005 17:59:06 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzAo-00053i-Jx for nemo@ietf.org; Wed, 09 Nov 2005 18:16:11 -0500 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 jA9Mwba28809 for ; Wed, 9 Nov 2005 23:58:37 +0100 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 jA9MwbP5098982 for ; Wed, 9 Nov 2005 23:58:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511092258.jA9MwbP5098982@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: nemo@ietf.org Date: Wed, 09 Nov 2005 23:58:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [nemo] PD and frustration X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 am not happy at all with the current prefix delegation for NEMO proposals (draft-ietf-nemo-dhcpv6-pd-00.txt and draft-ietf-nemo-prefix-delegation-00.txt) I've complained privately but I've been asked to do it in the list. In the first proposal there are some very strange statements: - 3.1.1 assumes the MR-HA tunnel is a part of the home link and tries to play with the "intercepted" word. I am sorry but IPv6 has a clear definition of what is a link and the proposed solution is not valid at all. - 3.1.3 claims that DHCPv6 relays are not defined for DHCPv6 PD when it is not in the RFC nor in recent drafts (cf draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt for instance) But IMHO the DHCPv6 PD service is the right tool, I can see two ways to support it: - put a DHCPv6 relay in the MR itself (i.e., colocated a client and a relay). This solves the MR-HA tunnel issue but can be seemed as not natural. - put a DHCPv6 relay in the HA and use a dedicated transport on the MR-HA tunnel exactly as RS/RA are replaced by MPS/MPA in MIPv6. The second proposal follows the MPD way but in place to reuse the DHCPv6 service it proposes a fully new and very complex protocol. I don't understand why and the rationale (quoted below) doesn't convince me. Yet, in a deployment where the MNPs are preassigned to the MR, a AAA server, interfacing with the HA, and eventually coupled with a provisioning system in its back-end, can provide the required service for assigning and authorizing the prefixes to the MRs; in such a case, the value of implementing a DHCPv6PD server is highly arguable. It is more generic to let the HA handle the backend interfaces on behalf of the MR and expose a consistent NEMO interface for all deployments. If the issue is the AAA system and DHCPv6 PD service must be interfaced, for instance to assign only authorized prefix, this issue is not a NEMO one and is already addresses (fortunately because in the real world where DHCPv6 PD is already deployed security is not an option). So I'd like to know what this proposal can do the DHCPv6 PD service can't... Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Wed Nov 09 19:31:57 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 1Ea0M9-0007b5-Gg; Wed, 09 Nov 2005 19:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0M7-0007b0-Sc for nemo@megatron.ietf.org; Wed, 09 Nov 2005 19:31:55 -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 TAA21885 for ; Wed, 9 Nov 2005 19:31:28 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0cE-0007d9-Nj for nemo@ietf.org; Wed, 09 Nov 2005 19:48:35 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id jAA0VjLr082369; Thu, 10 Nov 2005 09:31:45 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (fumi.local.ini.jp [10.21.254.6]) by bahamas.64translator.com (8.13.1/8.13.1) with ESMTP id jAA0Vbkk038447; Thu, 10 Nov 2005 09:31:38 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hiroshi MIYATA Date: Thu, 10 Nov 2005 09:31:46 +0900 To: nemo@ietf.org X-Mailer: Apple Mail (2.623) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bahamas.64translator.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: contact@tahi.org Subject: [nemo] The 8th TAHI Test Event X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, # sorry if you received multiple times of this kind of email. TAHI Projcet is organizing its 8th TAHI IPv6 Test Event. The event is scheduled on January 23rd - 27th 2006 at Makuhari messe, Chiba, Japan. Registration is now available at: http://www.tahi.org/inop/8thinterop.html Early registration discount is available until December 16th 2005. Registration deadline is December 31st 2005. Please get advantage of early registration! This time we will provide the following tests: o Conformance test: Core (Compliant with IPv6 Ready Logo Phase-1) Core (Compliant with IPv6 Ready Logo Phase-2) IPsec (Compliant with IPv6 Ready Logo Phase-2) MIPv6 (Compliant with IPv6 Ready Logo Phase-2) IKEv1, NEMO Basic Support, DNS, DHCPv6, SIP, MIB, RIPng, OSPFv3, NAT-PT, 6to4 o Interoperability test: Core (Compliant with IPv6 Ready Logo Phase-1) Core (Compliant with IPv6 Ready Logo Phase-2) IPsec (Compliant with IPv6 Ready Logo Phase-2) MIPv6 (Compliant with IPv6 Ready Logo Phase-2) MIPv6 (generic), NEMO Basic Support, IPsec (generic), IKEv1/v2, DHCPv6, MLDv2, Application(DNS, HTTP...), etc. Best regards, .... Hiroshi Miyata @ TAHI Project From nemo-bounces@ietf.org Wed Nov 09 19:42:06 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 1Ea0Vy-0002tl-Mh; Wed, 09 Nov 2005 19:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0Vw-0002tX-6Z for nemo@megatron.ietf.org; Wed, 09 Nov 2005 19:42:04 -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 TAA22334 for ; Wed, 9 Nov 2005 19:41:36 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0m2-0007rS-7r for nemo@ietf.org; Wed, 09 Nov 2005 19:58:43 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAA0s3Hv026278; Wed, 9 Nov 2005 17:54:03 -0700 (MST) Received: from [144.189.73.96] (mvp-144-189-73-96.corp.mot.com [144.189.73.96]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jAA0oDvA015509; Wed, 9 Nov 2005 18:50:13 -0600 (CST) Message-ID: <43729746.4010809@motorola.com> Date: Thu, 10 Nov 2005 01:41:42 +0100 From: Christophe Janneteau User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [nemo] Issue A14 - e-face and i-face References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I agree with Francis. --another french guy Francis Dupont wrote: > In your previous mail you wrote: > > Can we have some comments from non-English speakers that think i-face > and e-face are easier to understand than ingress interface and egress > interface? This still seems awkward to me -- I wouldn't know what e- > face and i-face mean unless I go do some research. > > => I agree with you and more, as in French the letter i is pronounce > exactly like the letter e in English this can become a nightmare in > its not written form! So I support TJ, PLEASE use ingress and egress > at least! > > Regards > > Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Wed Nov 09 19:53:55 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 1Ea0hP-0004qq-DL; Wed, 09 Nov 2005 19:53:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0hN-0004qi-Aq for nemo@megatron.ietf.org; Wed, 09 Nov 2005 19:53:53 -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 TAA22809 for ; Wed, 9 Nov 2005 19:53:26 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0xT-00087s-Hk for nemo@ietf.org; Wed, 09 Nov 2005 20:10:32 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id jAA13OmP017924; Wed, 9 Nov 2005 18:03:24 -0700 (MST) Received: from [144.189.74.16] (mvp-144-189-74-16.corp.mot.com [144.189.74.16]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jAA11gBT001065; Wed, 9 Nov 2005 19:01:43 -0600 (CST) Message-ID: <43729A18.4030805@motorola.com> Date: Wed, 09 Nov 2005 16:53:44 -0800 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] Issue A14 - e-face and i-face References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511092207.jA9M7quH098830@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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > Can we have some comments from non-English speakers that think i-face > and e-face are easier to understand than ingress interface and egress > interface? This still seems awkward to me -- I wouldn't know what e- > face and i-face mean unless I go do some research. > > => I agree with you and more, as in French the letter i is pronounce > exactly like the letter e in English this can become a nightmare in > its not written form! So I support TJ, PLEASE use ingress and egress > at least! Non-native English speaker here. I second that "e" vs "i" is difficult to distinguish, as a non-native French speaker too. BEsides, sounds to me like in English "e-face" is somebody with a face of e-shape. I'll acknowledge though that e-everything seems to be widely used. Alex From nemo-bounces@ietf.org Wed Nov 09 20:00:27 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 1Ea0nj-0001G4-Uw; Wed, 09 Nov 2005 20:00:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0nh-0001Fw-Ug for nemo@megatron.ietf.org; Wed, 09 Nov 2005 20:00:26 -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 TAA23268 for ; Wed, 9 Nov 2005 19:59:58 -0500 (EST) Received: from pp107-98.bctel.ca ([209.52.107.98] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea13o-0008LK-9O for nemo@ietf.org; Wed, 09 Nov 2005 20:17:05 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id A25AC1A3C44; Thu, 10 Nov 2005 09:03:10 +0800 (SGT) Subject: Re: [nemo] NEMO for IPv4 From: Chan-Wah NG To: Alexandru Petrescu In-Reply-To: <4354AA19.90701@motorola.com> References: <4354AA19.90701@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Thu, 10 Nov 2005 09:03:09 +0800 Message-Id: <1131584589.13686.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Gopal Dommety , Kent Leung , 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 Hello, I must first admit that I have not read the entire draft, this is just a quick comment after hearing Alex's presentation today. On Tue, 2005-10-18 at 09:54 +0200, Alexandru Petrescu wrote: > 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. > ..... > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > +-+-+-+-+-+-+-+-+ > I am just wondering what is the reason behind starting the prefix field at the 5th byte instea dof the normal convention of starting a field at its proper byte-aligned boundary. I know IPv4 does not have a strict requirement for byte-boundary alignment like IPv6, so there is no need to create empty reserved bits just for byte-alignment. However, in this case, a simple re-ordering of the Code / Prefix-Length / Prefix field would achieve a natural byte alignment. So I am wondering if there is a technical reason why that is not done. If there is no technical reason, I would suggest the re-ordering of the fields. /rgds /cwng From nemo-bounces@ietf.org Wed Nov 09 20:22:19 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 1Ea18t-0000ZX-RJ; Wed, 09 Nov 2005 20:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea18l-0000ZG-E9 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 20:22:18 -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 UAA24315 for ; Wed, 9 Nov 2005 20:21:43 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1Oq-0000RQ-45 for nemo@ietf.org; Wed, 09 Nov 2005 20:38:51 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA24267; Wed, 9 Nov 2005 17:21:43 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAA1LfY23307; Wed, 9 Nov 2005 19:21:41 -0600 (CST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 17:21:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5E595.1A4E82B8" Subject: International Civil Aviation Organization - Working Group - N-1 RE - Aviation Network Considerations : [nemo] Recharter items: multihoming - HAHA ? Date: Wed, 9 Nov 2005 17:21:38 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A4CB319@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: yes Thread-Topic: International Civil Aviation Organization - Working Group - N-1 RE - Aviation Network Considerations : [nemo] Recharter items: multihoming - HAHA ? Thread-Index: AcXldHEBIVrULFAaRw+PhR/3PqXqkQAHsPCg From: "Davis, Terry L" To: "ivancic" , "T.J. Kniveton" , "Vijay Devarapalli" , "James Kempf" , "Thierry Ernst" X-OriginalArrivalTime: 10 Nov 2005 01:21:40.0834 (UTC) FILETIME=[1A8E2C20:01C5E595] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1cf48fa9036ffb4df2242830d7b83ac1 Cc: ml-nemo , "Bound, Jim" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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_01C5E595.1A4E82B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TJ, Vijay, Jim, Thierry Well I finally got a set of mobility service requirements from one group within the aviation industry; ICAO WG N-1. We just completed them last night. We decide to phrase them as "technical and implementation considerations" with the "technical considerations" being features the committee believes would be highly desirable in a standard. I will update them with a document number as soon as I receive it. Take care=20 Terry L Davis, P.E.=20 Boeing Technical Fellow=20 Connexion by Boeing=20 Email: Terry.L.Davis@Boeing.com=20 Desk Phone: 206-655-6337=20 Cell Phone: 206-280-3716=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: ivancic [mailto:wivancic@grc.nasa.gov]=20 Sent: Wednesday, November 09, 2005 1:25 PM To: T.J. Kniveton Cc: ml-nemo; Thierry Ernst; Alexandru Petrescu Subject: Re: [nemo] Recharter items: multihoming - HAHA ? Yes, TJ is correct. HAHA is very desirable for the Aeronautics community (National AERONAUTICS and Space Administration(. I suspect military organizations, bovernments, coast guard, and any widely disperse organization would find this very useful. Will (a NASA guy) ****************************** T.J. Kniveton wrote: > On Nov 7, 2005, at 6:06 PM, Alexandru Petrescu wrote: > >> What does HAHA have to do with NEMO? > > > > In my view, the global HAHA, which allows distributed HAs, is a real=20 > deployment issue for situations with large distances being traversed.=20 > The WG has received input from Boeing, NASA, and I believe an=20 > aeronautics organization, that this is a desired feature for RO in=20 > their networks. So to me, it seems that we should work on this, if=20 > people in the WG are interested. > > For local HAHA, which provides a cache coherency protocol, the topic=20 > is availability and load balancing. I am not as convinced this is=20 > something we need to work on, right now, in NEMO. But that's my=20 > personal opinion, and perhaps if someone has a convincing argument,=20 > we can discuss that. > > TJ > > ------_=_NextPart_001_01C5E595.1A4E82B8 Content-Type: application/vnd.ms-powerpoint; name="ICAO Requirements Input v1.ppt" Content-Description: ICAO Requirements Input v1.ppt Content-Disposition: attachment; filename="ICAO Requirements Input v1.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASgAAAAAAAAAA EAAATAAAAAEAAAD+////AAAAAEsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDBRAAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A 8gMUAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAA3JYT AF8+CzDclhMAAAAAADAA0g90qRMAdKkTAChAzQH8lhMAeDoLMPyWEwAAAAAADwDVBwAABAAAAKQP CAAAAIAAQAAAAP//AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xIA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BMgAAAAPAADwwAAAAAAABvBoAAAABCwAAAwAAAAeAAAACQAAAAEAAAAHAAAAAgAAAAQAAAADAAAA BwAAAAAAAAAEAAAAAAAAAAYAAAAGAAAABAAAAAcAAAAEAAAACAAAAAQAAAAJAAAABAAAAAoAAAAE AAAACwAAAAQAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQAMABAQAACMVBAAAAAP8B CAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAA AAAAAAAAAACAAAAAAA8A0AczAQAAHwAUBBwAAAAAABUEFAAAALqTsPYAypo7rQeUxwDKmjsBAQAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQwAAAGQAAABDAAAAZAAAAAAAAADMQs0BFJcTAHg6 CzAAAAAAAAAAAPb9//+g////AQATAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAT BDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABAlxMAEvQKMHSpEwAEQM0BAAAAAAAAAAAAAAAA AAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoTMAAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADaDwQA AAANACUADwDwD2YMAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACo DzwAAABJQ0FPIEF2aWF0aW9uIENvbnNpZGVyYXRpb25zC2ZvciALSW50ZXJuZXQgTW9iaWxpdHkg U2VydmljZXMQAJ8PBAAAAAUAAAAAAKgPOwAAAElDQU8gV0cgTi0xDU1lZXRpbmcgIzUNTW9udHJl YWwsIENhbmFkYQ1Ob3ZlbWJlciA3LTEwLCAyMDA1AAChDxgAAAA8AAAAAAAAEAAAUAA8AAAAAQAC AAEAHAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDx0AAABJQ0FP IFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwAAoQ8WAAAAHgAAAAAAAAAAAB4AAAABAAIAAQAoABAA nw8EAAAAAQAAAAAAqA+xAAAAVEMtMS4gIFRoZSBhcHByb2FjaCBzaG91bGQgcHJvdmlkZSBhIG1l YW5zIHRvIGRlZmluZSBkYXRhIGNvbW11bmljYXRpb25zIHRoYXQgY2FuIGJlIGNhcnJpZWQgb25s eSBvdmVyIGF1dGhvcml6ZWQgcGF0aHMgZm9yIHRoZSB0cmFmZmljIHR5cGUgYW5kIGNhdGVnb3J5 IHNwZWNpZmllZCBieSB0aGUgdXNlci4gAAChDxwAAACyAAAAAAAAAAAAsAAAAAEAAAABAAIAAAAA AAAAAACqDxgAAAAIAAAABgAAAAkQAACqAAAABgAAAAkIAAAAAPMDFAAAAAoAAAAAAAAAAgAAAAcB AAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwso Y29udCkAAKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPhwAAAFRD LTMuIFRoZSBhcHByb2FjaCBzaG91bGQgZW5hYmxlIGFuIGFpcmNyYWZ0IG1vYmlsZSBuZXR3b3Jr IHRvIGJlIHNpbXVsdGFuZW91c2x5IGNvbm5lY3RlZCB0byBtdWx0aXBsZSBpbmRlcGVuZGVudCBh aXIvZ3JvdW5kIG5ldHdvcmtzLgAAoQ8UAAAAiAAAAAAAAAAAAIgAAAABAAAAAQAAAKoPLgAAAGcA AAAGAAAACQgAABYAAAAHAAAAAAAJCAAACgAAAAYAAAAJCAAAAQAAAAAAAAAAAPMDFAAAAAUAAAAA AAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRl cmF0aW9ucwsoY29udCkAAKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAA AKgPCQEAAFRDLTQuIFRoZSBhcHByb2FjaCBzaG91bGQgbWluaW1pemUgbGF0ZW5jeSBkdXJpbmcg ZXN0YWJsaXNobWVudCBvZiBpbml0aWFsIHBhdGhzIHRvIGFuIGFpcmNyYWZ0LCBkdXJpbmcgaGFu ZG9mZiwgYW5kIGR1cmluZyB0cmFuc2ZlciBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cy4gDQ1U Qy01LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGhhdmUgaGlnaCBhdmFpbGFiaWxpdHkgd2hpY2ggaW5j bHVkZXMgbm90IGhhdmluZyBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlLiAAAKEPKAAAAAoBAAAA AAAQAABaAAcBAAABAAAAAQACAAAAAAAAAAEAAAABAAAAAQAAAKoPDAAAAAoBAAAGAAAACQgAAAAA 8wMUAAAACAAAAAAAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElDQU8gVGVjaG5p Y2FsIENvbnNpZGVyYXRpb25zCyhjb250KQAAoQ8WAAAAJQAAAAAAAAAAACUAAAABAAIAAQAkABAA nw8EAAAAAQAAAAAAqA8JAQAAVEMtNi4gVGhlIGFwcHJvYWNoIHNob3VsZCBub3QgbmVnYXRpdmVs eSBpbXBhY3QgZW5kLXRvLWVuZCBkYXRhIGludGVncml0eSwgZm9yIGV4YW1wbGUsIGJ5IGludHJv ZHVjaW5nIHBhY2tldCBsb3NzIGR1cmluZyBwYXRoIGVzdGFibGlzaG1lbnQsIGhhbmRvZmYgb3Ig ZGF0YSB0cmFuc2Zlci4gDQ1UQy03LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNjYWxlYWJsZSB0 byBhY2NvbW1vZGF0ZSBhbnRpY2lwYXRlZCBsZXZlbHMgb2YgYWlyY3JhZnQgZXF1aXBhZ2UuIAAA oQ8oAAAACgEAAAAAABAAAFoACAEAAAEAAAABAAEAAAAAAAAAAQAAAAEAAAABAAAAqg8MAAAACgEA AAYAAAAJCAAAAADzAxQAAAAJAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAA SUNBTyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAAJQAA AAEAAgABACQAEACfDwQAAAABAAAAAACoD5EAAABUQy01LiBUaGUgYXBwcm9hY2ggc2hvdWxkIHJl c3VsdCBpbiB0aHJvdWdocHV0IHdoaWNoIGFjY29tbW9kYXRlcyBhbnRpY2lwYXRlZCBsZXZlbHMg b2YgYWlyY3JhZnQgZXF1aXBhZ2UuDQ1UQy02LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNlY3Vy ZS4gAAChDxwAAACSAAAAAAAAAAAAkAAAAAEAAAABAAIAAAAAAAAAAACqDxQAAACRAAAABgAAAAkI AAABAAAAAAAAAAAA8wMUAAAABgAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAA AElDQU8gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMAAKEPFgAAACMAAAAAAAAAAAAjAAAA AQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPKAEAAElDLjEgVGhlIGFwcHJvYWNoIHNob3VsZCBwZXJt aXQgdGhlIGFkZGl0aW9uIG9mIGFpci9ncm91bmQgc2VydmljZSBwcm92aWRlcnMuIA1JQy4yIFRo ZSBhcHByb2FjaCBzaG91bGQgbm90IHJlbHkgb24gYSBwYXJ0aWN1bGFyIGFpci9ncm91bmQgc2Vy dmljZSBwcm92aWRlciBvciBhZG1pbmlzdHJhdGlvbiBmb3Igb3BlcmF0aW9uLg1JQy4zIFRoZSBh cHByb2FjaCBzaG91bGQgbm90IGJlIHVuaXF1ZSB0byBhdmlhdGlvbiBidXQgcmF0aGVyIHNob3Vs ZCBiZSBiYXNlZCBvbiBvcGVuIGluZHVzdHJ5IHN0YW5kYXJkcy4gAAChDx4AAAApAQAAAAAAEAAA WgAnAQAAAQAAAAEAAgAAAAAAAAAAAKoPIAAAAMQAAAAGAAAACQgAAGQAAAAGAAAACRAAAAEAAAAA AAAAAADzAxQAAAAHAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8pAAAASUNBTyBJ bXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9ucyAoY29udCkAAKEPFgAAACoAAAAAAAAAAAAqAAAA AQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgP/AAAAElDLjQgVGhlIGFwcHJvYWNoIHNob3VsZCBoYXZl IG1hdHVyZSBhbmQgY29tbWVyY2lhbGx5IGF2YWlsYWJsZSBpbXBsZW1lbnRhdGlvbnMuDUlDLjUg VGhlIGFwcHJvYWNoIHNob3VsZCBhbGxvdyB0aGUgaW5kdXN0cnkgdG8gaW1wbGVtZW50IGEgY2xv c2VkIG5ldHdvcmsuDUlDLjYgVGhlIGFwcHJvYWNoIHNob3VsZCBhbGxvdyBhbiBhdXRoZW50aWNh dGlvbiB0byBiZSByZXF1aXJlZCBmb3Igc3lzdGVtcyB0byBqb2luIHRoZSBuZXR3b3JrLgAAoQ8W AAAA/QAAAAAAABAAAFoA/QAAAAEAAAABAAAAqg8UAAAAUQAAAAYAAAAJEAAArAAAAAAAAAAAAOoD AAAAAA8A+AOkCQAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAACzBgAPAHIAAAAP///wAA AAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+Z ZgDMMwAAmWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAA AN728QAAAAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA ///3ADPMzAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABg APAHIAAAAIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAz ZgDM//8AM2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/ APDlAABgAPAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA ////AD4+XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACP Xy8AzLQAAIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcA AAD//+8AAAAAAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAA ANgAAABAAgAAAAAHAAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAA IiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAA ACIgAABkAAAAAP8AAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAA AAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEA YAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAA AAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAA ow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAE AAAAAAAAAAIAEAAPAAwE1gQAAA8AAvDOBAAAEAAI8AgAAAAGAAAABgQAAA8AA/BmBAAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAA AAIEAAAACgAAkwAL8DYAAAB/AAEABQCAAFx1zQGHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQABAgIAAAgAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABAM0BDwAN 8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl AACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACD AAvwMAAAAH8AAQAFAIAASHjNAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAAIAzQEPAA3wngAAAAAAnw8EAAAAAQAA AAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRo aXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAA AAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAASAArwCAAAAAQEAAAACgAA gwAL8DAAAAB/AAEABQCAABR/zQGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgA ABDwCAAAAF4PIAFgBooQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAc0BDwAN8D4AAAAAAJ8PBAAAAAQA AAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPC4 AAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAAfwABAAUAgABAhM0BgQEEAAAIgwEAAAAIvwEBABEA wAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeD7AH0A6KEA8AEfAQAAAAAADDCwgAAAADAAAACQLN AQ8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAA AgAOAAAA+g8EAAAAAAAAAA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAY ic0BgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8A EfAQAAAAAADDCwgAAAAEAAAACALNAQ8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8W AAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAjeTFAWAiWTYgALoPHAAA AEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAO4DfQIAAAIA7wMYAAAAAAAAAA8QAAAAAAAA AAAAgAAAAAAHAAswDwAMBJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgA AAACCAAAIAIAAFMAC/AeAAAAfwAAAAQAgABQ6s0BvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAABg A7AB0BTcCA8AEfAQAAAAAADDCwgAAAAAAAAADwDNAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIA AAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAB/AAAABACAAPjqzQG/AQAAAQD/AQAAAQABAwMEAAAA ABDwCAAAAJAJYAMgE+ANDwAR8BAAAAAAAMMLCAAAAAEAAAAQAM0BDwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwSAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAA AOsuCAAAAI3kxQEAqVo2AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAAB/BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA 7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBJQBAAAPAALwjAEAADAACPAIAAAAAwAA AAYMAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAADAAA BQAAAA8ABPByAAAAEgAK8AgAAAAFDAAAIAIAAFMAC/AeAAAAfwAAAAQAgABARJUAvwEAAAEA/wEA AAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCVAA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAYMAAAgAgAAUwAL8B4AAAB/AAAABACAAOhElQC/ AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUA DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQ AFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAI3kxQFQjH1nAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfx IAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAA DwACKwAAAAAPAO4DiQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBKABAAAP AALwmAEAALAACPAIAAAAAwAAAAMsAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAALAAABQAAAA8ABPB4AAAAEgAK8AgAAAACLAAAIAIAAGMAC/AkAAAAfwAA AAQAgABc6JUAvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAA AADDCwgAAAAAAAAADQCVAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMsAAAg AgAAYwAL8CQAAAB/AAAABACAADTplQC/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAA ABIACvAIAAAAASwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8B AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAP AIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAI3k xQFQjH1nAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/ BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAA AA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBJQBAAAPAALwjAEAAGAACPAIAAAAAwAAAAMYAAAPAAPw JAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPBy AAAAEgAK8AgAAAACGAAAIAIAAFMAC/AeAAAAfwAAAAQAgACAU5UAvwEAAAEA/wEAAAEAAQMCBAAA AAAQ8AgAAADAACABYBWQAw8AEfAQAAAAAADDCwgAAAAAAAAADQCVAA8ADfAMAAAAAACeDwQAAAAA AAAADwAE8HIAAAASAArwCAAAAAMYAAAgAgAAUwAL8B4AAAB/AAAABACAAFhUlQC/AQAAAQD/AQAA AQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAARgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB jp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA ALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLE2kAAAAAAOsuCAAAAI3kxQFQqeOsAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAAD AAAAAAAAAAAAAAAAAAAAAAB/BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAP AO4DMAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBKABAAAPAALwmAEAAKAA CPAIAAAAAwAAAAMoAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK 8AgAAAAAKAAABQAAAA8ABPB4AAAAEgAK8AgAAAACKAAAIAIAAGMAC/AkAAAAfwAAAAQAgACYoZUA vwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAADAACABYBWQAw8AEfAQAAAAAADDCwgAAAAA AAAADQCVAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMoAAAgAgAAYwAL8CQA AAB/AAAABACAAHCilQC/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAAPADIAFgFRMPDwAR 8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAA ASgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8A ihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAI3kxQFQqeOsDwDu AzACAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwALMA8ADASgAQAADwAC8JgBAACQAAjw CAAAAAMAAAADJAAADwAD8DABAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAACQAAAUAAAAPAATweAAAABIACvAIAAAAAiQAACACAABjAAvwJAAAAH8AAAAEAIAAQJGVAL8B AAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAAwAAgAWAVkAMPABHwEAAAAAAAwwsIAAAAAAAA AA0AzQEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPB4AAAAEgAK8AgAAAADJAAAIAIAAGMAC/AkAAAA fwAAAAQAgAAYkpUAvwEAAAEA/wEAAAEAAQMDBAAAiAMAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQ AAAAAADDCwgAAAABAAAADgCVAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEk AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoT MAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACN5MUBUKnjrA8A7gMk AgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcACzAPAAwElAEAAA8AAvCMAQAAcAAI8AgA AAADAAAAAxwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAcAAAFAAAADwAE8HIAAAASAArwCAAAAAIcAAAgAgAAUwAL8B4AAAB/AAAABACAAPRklQC/AQAA AQD/AQAAAQABAwIEAAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAJUADwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxwAACACAABTAAvwHgAAAH8AAAAEAIAA HKuVAL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAA AA4AlQAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABHAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAjuTFAeDDnkEPAO4DJAIAAAIA7wMYAAAAAQAA AA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBJQBAAAPAALwjAEAAIAACPAIAAAAAwAAAAMgAAAPAAPw JAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAIAAABQAAAA8ABPBy AAAAEgAK8AgAAAACIAAAIAIAAFMAC/AeAAAAfwAAAAQAgACM180BvwEAAAEA/wEAAAEAAQMCBAAA AAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQDNAQ8ADfAMAAAAAACeDwQAAAAA AAAADwAE8HIAAAASAArwCAAAAAMgAAAgAgAAUwAL8B4AAAB/AAAABACAAGTYzQG/AQAAAQD/AQAA AQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAM0BDwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAASAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB jp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA ALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAOsuCAAAAI/kxQFAb9VTAAByFywAAAABAKAAAAAAAA0QAAC5GQAAPhwAAFQhAABJ KAAAdSoAANkjAAARJgAAwx4AAAAA9Q8cAAAABwEAAKQZAAMAAAAAoSwAAAEAAAAKAAAAAQDFMQ8A 6APyDwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDy AxQBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdMAAAAAAC3D0QAAABBAHIAaQBhAGwAAAC8lhMA Xz4LMLyWEwAAAAAAMADSD1SpEwBUqRMAKEDNAdyWEwB4Ogsw3JYTAAAAAAAPANUHAAAEAAAApA8I AAAAgABAAAAA//8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAA BQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAFwAAAPQAAAALAAAA/AAAABAAAAAEAQAA EwAAAAwBAAAWAAAAFAEAAA0AAAAcAQAADAAAAJ0CAAACAAAA5AQAAB4AAAAQAAAAT24tc2NyZWVu IFNob3cAAB4AAAAUAAAAVGhlIEJvZWluZyBDb21wYW55AAADAAAAwHwAAAMAAAAdAAAAAwAAAAgA AAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAqBkLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAAHhAAAAoAAAAGAAAAQXJpYWwADwAAAERlZmF1bHQgRGVzaWduAD0AAABJQ0FPIEF2 aWF0aW9uIENvbnNpZGVyYXRpb25zIGZvciAgSW50ZXJuZXQgTW9iaWxpdHkgU2VydmljZXMAHgAA AElDQU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zACUAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRl cmF0aW9ucyAoY29udCkAJQAAAElDQU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zIChjb250KQAl AAAASUNBTyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMgKGNvbnQpACUAAABJQ0FPIFRlY2huaWNh bCBDb25zaWRlcmF0aW9ucyAoY29udCkAIwAAAElDQU8gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJh dGlvbnMAKgAAAElDQU8gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMgKGNvbnQpAAwQAAAG AAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAA AAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAACAAAAAAAAAcABwAIAAIABwAEAAMABQAAAPYP JgAAABQAAABfwJHjnHwAAA4A9AMDANowRGF2aXMsIFRlcnJ5IEwIAAAARABhAHYAaQBzACwAIABU AGUAcgByAHkAIABMAGVtAAAAAAAAAAAAABgAAAABAAAAuFMeAOQEAAAEAAAALQEEAAQAAADwAQMA HAAAAPsC9v8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE AAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDQAAADIKLwBKAAQAAABmb3IgAwAGAAMA AwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL2/wAAAAAAAJABAAAAAABAAABBcmlhbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMAAAAAAAUAAIAEgAQAAAAADwALBMgAAAAP AADwwAAAAAAABvBoAAAABCwAAAwAAAAeAAAACQAAAAEAAAAHAAAAAgAAAAQAAAADAAAABwAAAAAA AAAEAAAAAAAAAAYAAAAGAAAABAAAAAcAAAAEAAAACAAAAAQAAAAJAAAABAAAAAoAAAAEAAAACwAA AAQAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQAMABAQAACMVBAAAAAP8BCAAIAAEC AgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAA AACAAAAAAA8A0AczAQAAHwAUBBwAAAAAABUEFAAAALqTsPYAypo7rQeUxwDKmjsBAQAADwD6A2cA AAAAAP4DAwAAAAABAAAA/QM0AAAAQwAAAGQAAABDAAAAZAAAAAAAAADMQs0B9JYTAHg6CzAAAAAA AAAAAPb9//+g////AQATAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwATBDwAAAAA AP0DNAAAAGQAAABkAAAAZAAAAGQAAAAglxMAEvQKMFSpEwAEQM0BAAAAAAAAAAAAAAAAAAAAAAAB EwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADaDwQAAAANACUA DwDwD4YMAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDzwAAABJ Q0FPIEF2aWF0aW9uIENvbnNpZGVyYXRpb25zC2ZvciALSW50ZXJuZXQgTW9iaWxpdHkgU2Vydmlj ZXMQAJ8PBAAAAAUAAAAAAKgPOwAAAElDQU8gV0cgTi0xDU1lZXRpbmcgIzUNTW9udHJlYWwsIENh bmFkYQ1Ob3ZlbWJlciA3LTEwLCAyMDA1AAChDxgAAAA8AAAAAAAAEAAAUAA8AAAAAQACAAEAHAAA APMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDx0AAABJQ0FPIFRlY2hu aWNhbCBDb25zaWRlcmF0aW9ucwAAoQ8WAAAAHgAAAAAAAAAAAB4AAAABAAIAAQAoABAAnw8EAAAA AQAAAAAAqA+xAAAAVEMtMS4gIFRoZSBhcHByb2FjaCBzaG91bGQgcHJvdmlkZSBhIG1lYW5zIHRv IGRlZmluZSBkYXRhIGNvbW11bmljYXRpb25zIHRoYXQgY2FuIGJlIGNhcnJpZWQgb25seSBvdmVy IGF1dGhvcml6ZWQgcGF0aHMgZm9yIHRoZSB0cmFmZmljIHR5cGUgYW5kIGNhdGVnb3J5IHNwZWNp ZmllZCBieSB0aGUgdXNlci4gAAChDxwAAACyAAAAAAAAAAAAsAAAAAEAAAABAAIAAAAAAAAAAACq DxgAAAAIAAAABgAAAAkQAACqAAAABgAAAAkIAAAAAPMDFAAAAAoAAAAAAAAAAgAAAAcBAAAAAAAA AACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwsoY29udCkA AKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPoAAAAFRDLTIuIFRo ZSBhcHByb2FjaCBzaG91bGQgZW5hYmxlIGFuIGFpcmNyYWZ0IG1vYmlsZSBuZXR3b3JrIHRvIGJv dGggcm9hbSBiZXR3ZWVuIGFuZCB0byBiZSBzaW11bHRhbmVvdXNseSBjb25uZWN0ZWQgdG8gbXVs dGlwbGUgaW5kZXBlbmRlbnQgYWlyL2dyb3VuZCBuZXR3b3Jrcy4AAKEPFAAAAKEAAAAAAAAAAACh AAAAAQAAAAEAAACqDy4AAAA8AAAABgAAAAkIAAAHAAAABwAAAAAACQgAAF0AAAAGAAAACQgAAAEA AAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAASUNB TyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAAJQAAAAEA AgABACQAEACfDwQAAAABAAAAAACoDwkBAABUQy0zLiBUaGUgYXBwcm9hY2ggc2hvdWxkIG1pbmlt aXplIGxhdGVuY3kgZHVyaW5nIGVzdGFibGlzaG1lbnQgb2YgaW5pdGlhbCBwYXRocyB0byBhbiBh aXJjcmFmdCwgZHVyaW5nIGhhbmRvZmYsIGFuZCBkdXJpbmcgdHJhbnNmZXIgb2YgaW5kaXZpZHVh bCBkYXRhIHBhY2tldHMuIA0NVEMtNC4gVGhlIGFwcHJvYWNoIHNob3VsZCBoYXZlIGhpZ2ggYXZh aWxhYmlsaXR5IHdoaWNoIGluY2x1ZGVzIG5vdCBoYXZpbmcgYSBzaW5nbGUgcG9pbnQgb2YgZmFp bHVyZS4gAAChDygAAAAKAQAAAAAAEAAAWgAHAQAAAQAAAAEAAgAAAAAAAAABAAAAAQAAAAEAAACq DwwAAAAKAQAABgAAAAkIAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAA AACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwsoY29udCkAAKEPFgAAACUAAAAA AAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPCQEAAFRDLTUuIFRoZSBhcHByb2FjaCBz aG91bGQgbm90IG5lZ2F0aXZlbHkgaW1wYWN0IGVuZC10by1lbmQgZGF0YSBpbnRlZ3JpdHksIGZv ciBleGFtcGxlLCBieSBpbnRyb2R1Y2luZyBwYWNrZXQgbG9zcyBkdXJpbmcgcGF0aCBlc3RhYmxp c2htZW50LCBoYW5kb2ZmIG9yIGRhdGEgdHJhbnNmZXIuIA0NVEMtNi4gVGhlIGFwcHJvYWNoIHNo b3VsZCBiZSBzY2FsZWFibGUgdG8gYWNjb21tb2RhdGUgYW50aWNpcGF0ZWQgbGV2ZWxzIG9mIGFp cmNyYWZ0IGVxdWlwYWdlLiAAAKEPKAAAAAoBAAAAAAAQAABaAAgBAAABAAAAAQABAAAAAAAAAAEA AAABAAAAAQAAAKoPDAAAAAoBAAAGAAAACQgAAAAA8wMUAAAACQAAAAAAAAACAAAABQEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPJAAAAElDQU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zCyhjb250KQAA oQ8WAAAAJQAAAAAAAAAAACUAAAABAAIAAQAkABAAnw8EAAAAAQAAAAAAqA+RAAAAVEMtNS4gVGhl IGFwcHJvYWNoIHNob3VsZCByZXN1bHQgaW4gdGhyb3VnaHB1dCB3aGljaCBhY2NvbW1vZGF0ZXMg YW50aWNpcGF0ZWQgbGV2ZWxzIG9mIGFpcmNyYWZ0IGVxdWlwYWdlLg0NVEMtNi4gVGhlIGFwcHJv YWNoIHNob3VsZCBiZSBzZWN1cmUuIAAAoQ8cAAAAkgAAAAAAAAAAAJAAAAABAAAAAQACAAAAAAAA AAAAqg8UAAAAkQAAAAYAAAAJCAAAAQAAAAAAAAAAAPMDFAAAAAYAAAAAAAAAAgAAAAMBAAAAAAAA AACfDwQAAAAAAAAAAACoDyIAAABJQ0FPIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zAACh DxYAAAAjAAAAAAAAAAAAIwAAAAEAAgABACQAEACfDwQAAAABAAAAAACoDygBAABJQy4xIFRoZSBh cHByb2FjaCBzaG91bGQgcGVybWl0IHRoZSBhZGRpdGlvbiBvZiBhaXIvZ3JvdW5kIHNlcnZpY2Ug cHJvdmlkZXJzLiANSUMuMiBUaGUgYXBwcm9hY2ggc2hvdWxkIG5vdCByZWx5IG9uIGEgcGFydGlj dWxhciBhaXIvZ3JvdW5kIHNlcnZpY2UgcHJvdmlkZXIgb3IgYWRtaW5pc3RyYXRpb24gZm9yIG9w ZXJhdGlvbi4NSUMuMyBUaGUgYXBwcm9hY2ggc2hvdWxkIG5vdCBiZSB1bmlxdWUgdG8gYXZpYXRp b24gYnV0IHJhdGhlciBzaG91bGQgYmUgYmFzZWQgb24gb3BlbiBpbmR1c3RyeSBzdGFuZGFyZHMu IAAAoQ8eAAAAKQEAAAAAABAAAFoAJwEAAAEAAAABAAIAAAAAAAAAAACqDyAAAADEAAAABgAAAAkI AABkAAAABgAAAAkQAAABAAAAAAAAAAAA8wMUAAAABwAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPKQAAAElDQU8gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMgKGNvbnQpAACh DxYAAAAqAAAAAAAAAAAAKgAAAAEAAgABACQAEACfDwQAAAABAAAAAACoDwMBAABJQy40IFRoZSBh cHByb2FjaCBzaG91bGQgaGF2ZSBtYXR1cmUgYW5kIGNvbW1lcmNpYWxseSBhdmFpbGFibGUgaW1w bGVtZW50YXRpb25zLg1JQy41IFRoZSBhcHByb2FjaCBzaG91bGQgYWxsb3cgdGhlIGluZHVzdHJ5 IHRvIGltcGxlbWVudCBhIGNsb3NlZCBuZXR3b3JrLg1JQy42IFRoZSBhcHByb2FjaCBzaG91bGQg YWxsb3cgYW4gYXV0aGVudGljYXRpb24gdG8gYmUgcmVxdWlyZWQgZm9yIHN5c3RlbXMgdG8gam9p biB0aGUgY2xvc2VkIG5ldHdvcmsuAAChDxYAAAAEAQAAAAAAEAAAWgAEAQAAAQAAAAEAAACqDxQA AABRAAAABgAAAAkQAACzAAAAAAAAAAAA6gMAAAAADwDuA4kCAAACAO8DGAAAAAEAAAANDgAAAAAA AAAAAIAAAAAABwALMA8ADASgAQAADwAC8JgBAACwAAjwCAAAAAMAAAADLAAADwAD8DABAAAPAATw KAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACwAAAUAAAAPAATweAAAABIACvAI AAAAAiwAACACAABjAAvwJAAAAH8AAAAEAIAAXOiVAL8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAA EPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0AlQAPAA3wDAAAAAAAng8EAAAAAAAA AA8ABPB4AAAAEgAK8AgAAAADLAAAIAIAAGMAC/AkAAAAfwAAAAQAgAA06ZUAvwEAAAEA/wEAAAEA AQMDBAAAiAMAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADDCwgAAAABAAAADgCVAA8ADfAM AAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEsAAAADAAAgwAL8DAAAACBAQAAAAiDAQUA AAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICA AAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQA MQAwAAAAixNpAAAAAADrLggAAACN5MUBUIx9ZwAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAAAfwT/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisA AAAAAAByFxAAAAABABAAvUYAAAoAEADqVgAAAAD1DxwAAAAHAQAApBkAA5lGAAB7WQAAAQAAAAoA AAABAMUxDwDoA/wPAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAA AAAAAAEPAPIDFAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEA bAAAALyWEwBfPgswvJYTAAAAAAAwANIPVKkTAFSpEwAoQM0B3JYTAHg6CzDclhMAAAAAAA8A1QcA AAQAAACkDwgAAACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAA QACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD/ //////8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAE AAAAAA8ACwTIAAAADwAA8MAAAAAAAAbwaAAAAAQsAAAMAAAAHgAAAAkAAAABAAAABwAAAAIAAAAE AAAAAwAAAAcAAAAAAAAABAAAAAAAAAAGAAAABgAAAAQAAAAHAAAABAAAAAgAAAAEAAAACQAAAAQA AAAKAAAABAAAAAsAAAAEAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjF QQAAAAD/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAA AgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcA ypo7AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEMAAABkAAAAQwAAAGQAAAAAAAAAzELN AfSWEwB4OgswAAAAAAAAAAD2/f//oP///wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAA QAsAAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAIJcTABL0CjBUqRMABEDNAQAAAAAA AAAAAAAAAAAAAAAAARMAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAA8AiBM4AAAADwCKEzAA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAAAMAAAADAAAA/ANkPDAAA AAAA2g8EAAAADQAlAA8A8A9dDAAAAADzAxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAA BgAAAAAAqA88AAAASUNBTyBBdmlhdGlvbiBDb25zaWRlcmF0aW9ucwtmb3IgC0ludGVybmV0IE1v YmlsaXR5IFNlcnZpY2VzEACfDwQAAAAFAAAAAACoDzsAAABJQ0FPIFdHIE4tMQ1NZWV0aW5nICM1 DU1vbnRyZWFsLCBDYW5hZGENTm92ZW1iZXIgNy0xMCwgMjAwNQAAoQ8YAAAAPAAAAAAAABAAAFAA PAAAAAEAAgABABwAAADzAxQAAAAEAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8d AAAASUNBTyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMAAKEPFgAAAB4AAAAAAAAAAAAeAAAAAQAC AAEAKAAQAJ8PBAAAAAEAAAAAAKgPsQAAAFRDLTEuICBUaGUgYXBwcm9hY2ggc2hvdWxkIHByb3Zp ZGUgYSBtZWFucyB0byBkZWZpbmUgZGF0YSBjb21tdW5pY2F0aW9ucyB0aGF0IGNhbiBiZSBjYXJy aWVkIG9ubHkgb3ZlciBhdXRob3JpemVkIHBhdGhzIGZvciB0aGUgdHJhZmZpYyB0eXBlIGFuZCBj YXRlZ29yeSBzcGVjaWZpZWQgYnkgdGhlIHVzZXIuIAAAoQ8cAAAAsgAAAAAAAAAAALAAAAABAAAA AQACAAAAAAAAAAAAqg8YAAAACAAAAAYAAAAJEAAAqgAAAAYAAAAJCAAAAADzAxQAAAAKAAAAAAAA AAIAAAAHAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAASUNBTyBUZWNobmljYWwgQ29uc2lkZXJh dGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAAJQAAAAEAAgABACQAEACfDwQAAAABAAAAAACo D5EAAABUQy0yLiBUaGUgYXBwcm9hY2ggc2hvdWxkIGVuYWJsZSBhbiBhaXJjcmFmdCB0byBib3Ro IHJvYW0gYmV0d2VlbiBhbmQgdG8gYmUgc2ltdWx0YW5lb3VzbHkgY29ubmVjdGVkIHRvIG11bHRp cGxlIGluZGVwZW5kZW50IGFpci1ncm91bmQgbmV0d29ya3MuAAChDxQAAACSAAAAAAAAAAAAkgAA AAEAAAABAAAAqg8UAAAAkQAAAAYAAAAJCAAAAQAAAAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAIB AAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwso Y29udCkAAKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPCQEAAFRD LTMuIFRoZSBhcHByb2FjaCBzaG91bGQgbWluaW1pemUgbGF0ZW5jeSBkdXJpbmcgZXN0YWJsaXNo bWVudCBvZiBpbml0aWFsIHBhdGhzIHRvIGFuIGFpcmNyYWZ0LCBkdXJpbmcgaGFuZG9mZiwgYW5k IGR1cmluZyB0cmFuc2ZlciBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cy4gDQ1UQy00LiBUaGUg YXBwcm9hY2ggc2hvdWxkIGhhdmUgaGlnaCBhdmFpbGFiaWxpdHkgd2hpY2ggaW5jbHVkZXMgbm90 IGhhdmluZyBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlLiAAAKEPKAAAAAoBAAAAAAAQAABaAAcB AAABAAAAAQACAAAAAAAAAAEAAAABAAAAAQAAAKoPDAAAAAoBAAAGAAAACQgAAAAA8wMUAAAACAAA AAAAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElDQU8gVGVjaG5pY2FsIENvbnNp ZGVyYXRpb25zCyhjb250KQAAoQ8WAAAAJQAAAAAAAAAAACUAAAABAAIAAQAkABAAnw8EAAAAAQAA AAAAqA8JAQAAVEMtNS4gVGhlIGFwcHJvYWNoIHNob3VsZCBub3QgbmVnYXRpdmVseSBpbXBhY3Qg ZW5kLXRvLWVuZCBkYXRhIGludGVncml0eSwgZm9yIGV4YW1wbGUsIGJ5IGludHJvZHVjaW5nIHBh Y2tldCBsb3NzIGR1cmluZyBwYXRoIGVzdGFibGlzaG1lbnQsIGhhbmRvZmYgb3IgZGF0YSB0cmFu c2Zlci4gDQ1UQy02LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNjYWxlYWJsZSB0byBhY2NvbW1v ZGF0ZSBhbnRpY2lwYXRlZCBsZXZlbHMgb2YgYWlyY3JhZnQgZXF1aXBhZ2UuIAAAoQ8oAAAACgEA AAAAABAAAFoACAEAAAEAAAABAAEAAAAAAAAAAQAAAAEAAAABAAAAqg8MAAAACgEAAAYAAAAJCAAA AADzAxQAAAAJAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8kAAAASUNBTyBUZWNo bmljYWwgQ29uc2lkZXJhdGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAAJQAAAAEAAgABACQA EACfDwQAAAABAAAAAACoD5EAAABUQy01LiBUaGUgYXBwcm9hY2ggc2hvdWxkIHJlc3VsdCBpbiB0 aHJvdWdocHV0IHdoaWNoIGFjY29tbW9kYXRlcyBhbnRpY2lwYXRlZCBsZXZlbHMgb2YgYWlyY3Jh ZnQgZXF1aXBhZ2UuDQ1UQy02LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNlY3VyZS4gAAChDxwA AACSAAAAAAAAAAAAkAAAAAEAAAABAAIAAAAAAAAAAACqDxQAAACRAAAABgAAAAkIAAABAAAAAAAA AAAA8wMUAAAABgAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAAAElDQU8gSW1w bGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMAAKEPFgAAACMAAAAAAAAAAAAjAAAAAQACAAEAJAAQ AJ8PBAAAAAEAAAAAAKgPKAEAAElDLjEgVGhlIGFwcHJvYWNoIHNob3VsZCBwZXJtaXQgdGhlIGFk ZGl0aW9uIG9mIGFpci9ncm91bmQgc2VydmljZSBwcm92aWRlcnMuIA1JQy4yIFRoZSBhcHByb2Fj aCBzaG91bGQgbm90IHJlbHkgb24gYSBwYXJ0aWN1bGFyIGFpci9ncm91bmQgc2VydmljZSBwcm92 aWRlciBvciBhZG1pbmlzdHJhdGlvbiBmb3Igb3BlcmF0aW9uLg1JQy4zIFRoZSBhcHByb2FjaCBz aG91bGQgbm90IGJlIHVuaXF1ZSB0byBhdmlhdGlvbiBidXQgcmF0aGVyIHNob3VsZCBiZSBiYXNl ZCBvbiBvcGVuIGluZHVzdHJ5IHN0YW5kYXJkcy4gAAChDx4AAAApAQAAAAAAEAAAWgAnAQAAAQAA AAEAAgAAAAAAAAAAAKoPIAAAAMQAAAAGAAAACQgAAGQAAAAGAAAACRAAAAEAAAAAAAAAAADzAxQA AAAHAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8pAAAASUNBTyBJbXBsZW1lbnRh dGlvbiBDb25zaWRlcmF0aW9ucyAoY29udCkAAKEPFgAAACoAAAAAAAAAAAAqAAAAAQACAAEAJAAQ AJ8PBAAAAAEAAAAAAKgPAwEAAElDLjQgVGhlIGFwcHJvYWNoIHNob3VsZCBoYXZlIG1hdHVyZSBh bmQgY29tbWVyY2lhbGx5IGF2YWlsYWJsZSBpbXBsZW1lbnRhdGlvbnMuDUlDLjUgVGhlIGFwcHJv YWNoIHNob3VsZCBhbGxvdyB0aGUgaW5kdXN0cnkgdG8gaW1wbGVtZW50IGEgY2xvc2VkIG5ldHdv cmsuDUlDLjYgVGhlIGFwcHJvYWNoIHNob3VsZCBhbGxvdyBhbiBhdXRoZW50aWNhdGlvbiB0byBi ZSByZXF1aXJlZCBmb3Igc3lzdGVtcyB0byBqb2luIHRoZSBjbG9zZWQgbmV0d29yay4AAKEPFgAA AAQBAAAAAAAQAABaAAQBAAABAAAAAQAAAKoPFAAAAFEAAAAGAAAACRAAALMAAAAAAAAAAADqAwAA AAAPAO4DiQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBKABAAAPAALwmAEA ALAACPAIAAAAAwAAAAMsAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAALAAABQAAAA8ABPB4AAAAEgAK8AgAAAACLAAAIAIAAGMAC/AkAAAAfwAAAAQAgABc 6JUAvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgA AAAAAAAADQCVAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMsAAAgAgAAYwAL 8CQAAAB/AAAABACAADTplQC/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAAPADIAFgFRMP DwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAASwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAA AA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAI3kxQFQjH1n AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/BP////8S AAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEAEAC3WQAACgAQALtpAAAA APUPHAAAAAcBAACkGQADk1kAAExsAAABAAAACgAAAAEAxTEPAOgD/A8AAAEA6QMoAAAAgBYAAOAQ AADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gMUAQAALwDIDwwAAAAwANIPBAAA AAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAvJYTAF8+CzC8lhMAAAAAADAA0g9UqRMA VKkTAChAzQHclhMAeDoLMNyWEwAAAAAADwDVBwAABAAAAKQPCAAAAIAAQAAAAP//AAClDwwAAAAA AAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAA ZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xIAAAAAAQAAAAUAACABIAEAAAAAAAUA AEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBMgAAAAPAADwwAAAAAAABvBoAAAA BCwAAAwAAAAeAAAACQAAAAEAAAAHAAAAAgAAAAQAAAADAAAABwAAAAAAAAAEAAAAAAAAAAYAAAAG AAAABAAAAAcAAAAEAAAACAAAAAQAAAAJAAAABAAAAAoAAAAEAAAACwAAAAQAAACDAAvwMAAAAIEB BAAACIMBAAAACIZBAAAAAL8BEAAQAMABAQAACMVBAAAAAP8BCAAIAAECAgAACEAAHvEQAAAABAAA CAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0AczAQAA HwAUBBwAAAAAABUEFAAAALqTsPYAypo7rQeUxwDKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA /QM0AAAAQwAAAGQAAABDAAAAZAAAAAAAAADMQs0B9JYTAHg6CzAAAAAAAAAAAPb9//+g////AQAT AHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAA ZAAAAGQAAAAglxMAEvQKMFSpEwAEQM0BAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQM AAAAAAAAAAAAAAACAAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixMQAAAAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADaDwQAAAANACUADwDwD10MAAAAAPMDFAAA AAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDzwAAABJQ0FPIEF2aWF0aW9uIENv bnNpZGVyYXRpb25zC2ZvciALSW50ZXJuZXQgTW9iaWxpdHkgU2VydmljZXMQAJ8PBAAAAAUAAAAA AKgPOwAAAElDQU8gV0cgTi0xDU1lZXRpbmcgIzUNTW9udHJlYWwsIENhbmFkYQ1Ob3ZlbWJlciA3 LTEwLCAyMDA1AAChDxgAAAA8AAAAAAAAEAAAUAA8AAAAAQACAAEAHAAAAPMDFAAAAAQAAAAAAAAA AgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDx0AAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0 aW9ucwAAoQ8WAAAAHgAAAAAAAAAAAB4AAAABAAIAAQAoABAAnw8EAAAAAQAAAAAAqA+xAAAAVEMt MS4gIFRoZSBhcHByb2FjaCBzaG91bGQgcHJvdmlkZSBhIG1lYW5zIHRvIGRlZmluZSBkYXRhIGNv bW11bmljYXRpb25zIHRoYXQgY2FuIGJlIGNhcnJpZWQgb25seSBvdmVyIGF1dGhvcml6ZWQgcGF0 aHMgZm9yIHRoZSB0cmFmZmljIHR5cGUgYW5kIGNhdGVnb3J5IHNwZWNpZmllZCBieSB0aGUgdXNl ci4gAAChDxwAAACyAAAAAAAAAAAAsAAAAAEAAAABAAIAAAAAAAAAAACqDxgAAAAIAAAABgAAAAkQ AACqAAAABgAAAAkIAAAAAPMDFAAAAAoAAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACo DyQAAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwsoY29udCkAAKEPFgAAACUAAAAAAAAA AAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPkQAAAFRDLTIuIFRoZSBhcHByb2FjaCBzaG91 bGQgZW5hYmxlIGFuIGFpcmNyYWZ0IHRvIGJvdGggcm9hbSBiZXR3ZWVuIGFuZCB0byBiZSBzaW11 bHRhbmVvdXNseSBjb25uZWN0ZWQgdG8gbXVsdGlwbGUgaW5kZXBlbmRlbnQgYWlyLWdyb3VuZCBu ZXR3b3Jrcy4AAKEPFAAAAJIAAAAAAAAAAACSAAAAAQAAAAEAAACqDxQAAACRAAAABgAAAAkIAAAB AAAAAAAAAAAA8wMUAAAABQAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElD QU8gVGVjaG5pAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA DQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAADIAAAAYAAAA/v///xoAAAAb AAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkA AAAqAAAAKwAAACwAAAAtAAAALgAAAEUAAAD9////MQAAAP7///8zAAAANAAAADUAAAA2AAAANwAA ADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAAZAAAA/v///0EAAABCAAAAQwAAAEQAAAAXAAAA RgAAAEcAAABIAAAASQAAAP7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAA AACQ8YRatuTFAUAAAABADQAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAAEoAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAkAAAAAAABQAG8AdwBl AHIAUABvAGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA fAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAJgAAADADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABwAAAP//7wAAAAAA////////EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEyAAAAA8AAPDAAAAAAAAG8GgAAAAELAAADAAA AB4AAAAJAAAAAQAAAAcAAAACAAAABAAAAAMAAAAHAAAAAAAAAAQAAAAAAAAABgAAAAYAAAAEAAAA BwAAAAQAAAAIAAAABAAAAAkAAAAEAAAACgAAAAQAAAALAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEA AAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIA AAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBzMBAAAfABQEHAAA AAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABD AAAAZAAAAEMAAABkAAAAAAAAAMxCzQH0lhMAeDoLMAAAAAAAAAAA9v3//6D///8BABMAcAD7AwgA AAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAA ACCXEwAS9AowVKkTAARAzQEAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwAAAAAAAAA AAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AJQAPAPAPUwwAAAAA8wMUAAAAAwAAAAAA AAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPPAAAAElDQU8gQXZpYXRpb24gQ29uc2lkZXJh dGlvbnMLZm9yIAtJbnRlcm5ldCBNb2JpbGl0eSBTZXJ2aWNlcxAAnw8EAAAABQAAAAAAqA87AAAA SUNBTyBXRyBOLTENTWVldGluZyAjNQ1Nb250cmVhbCwgQ2FuYWRhDU5vdmVtYmVyIDctMTAsIDIw MDUAAKEPGAAAADwAAAAAAAAQAABQADwAAAABAAIAAQAcAAAA8wMUAAAABAAAAAAAAAACAAAAAQEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPHQAAAElDQU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zAACh DxYAAAAeAAAAAAAAAAAAHgAAAAEAAgABACgAEACfDwQAAAABAAAAAACoD7EAAABUQy0xLiAgVGhl IGFwcHJvYWNoIHNob3VsZCBwcm92aWRlIGEgbWVhbnMgdG8gZGVmaW5lIGRhdGEgY29tbXVuaWNh dGlvbnMgdGhhdCBjYW4gYmUgY2FycmllZCBvbmx5IG92ZXIgYXV0aG9yaXplZCBwYXRocyBmb3Ig dGhlIHRyYWZmaWMgdHlwZSBhbmQgY2F0ZWdvcnkgc3BlY2lmaWVkIGJ5IHRoZSB1c2VyLiAAAKEP HAAAALIAAAAAAAAAAACwAAAAAQAAAAEAAgAAAAAAAAAAAKoPGAAAAAgAAAAGAAAACRAAAKoAAAAG AAAACQgAAAAA8wMUAAAACgAAAAAAAAACAAAABwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElD QU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zCyhjb250KQAAoQ8WAAAAJQAAAAAAAAAAACUAAAAB AAIAAQAkABAAnw8EAAAAAQAAAAAAqA+HAAAAVEMtMi4gVGhlIGFwcHJvYWNoIHNob3VsZCBlbmFi bGUgYW4gYWlyY3JhZnQgbW9iaWxlIG5ldHdvcmsgdG8gYmUgc2ltdWx0YW5lb3VzbHkgY29ubmVj dGVkIHRvIG11bHRpcGxlIGluZGVwZW5kZW50IGFpci9ncm91bmQgbmV0d29ya3MuAAChDxQAAACI AAAAAAAAAAAAiAAAAAEAAAABAAAAqg8UAAAAhwAAAAYAAAAJCAAAAQAAAAAAAAAAAPMDFAAAAAUA AAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNhbCBDb25z aWRlcmF0aW9ucwsoY29udCkAAKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8PBAAAAAEA AAAAAKgPCQEAAFRDLTMuIFRoZSBhcHByb2FjaCBzaG91bGQgbWluaW1pemUgbGF0ZW5jeSBkdXJp bmcgZXN0YWJsaXNobWVudCBvZiBpbml0aWFsIHBhdGhzIHRvIGFuIGFpcmNyYWZ0LCBkdXJpbmcg aGFuZG9mZiwgYW5kIGR1cmluZyB0cmFuc2ZlciBvZiBpbmRpdmlkdWFsIGRhdGEgcGFja2V0cy4g DQ1UQy00LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGhhdmUgaGlnaCBhdmFpbGFiaWxpdHkgd2hpY2gg aW5jbHVkZXMgbm90IGhhdmluZyBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlLiAAAKEPKAAAAAoB AAAAAAAQAABaAAcBAAABAAAAAQACAAAAAAAAAAEAAAABAAAAAQAAAKoPDAAAAAoBAAAGAAAACQgA AAAA8wMUAAAACAAAAAAAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElDQU8gVGVj aG5pY2FsIENvbnNpZGVyYXRpb25zCyhjb250KQAAoQ8WAAAAJQAAAAAAAAAAACUAAAABAAIAAQAk ABAAnw8EAAAAAQAAAAAAqA8JAQAAVEMtNS4gVGhlIGFwcHJvYWNoIHNob3VsZCBub3QgbmVnYXRp dmVseSBpbXBhY3QgZW5kLXRvLWVuZCBkYXRhIGludGVncml0eSwgZm9yIGV4YW1wbGUsIGJ5IGlu dHJvZHVjaW5nIHBhY2tldCBsb3NzIGR1cmluZyBwYXRoIGVzdGFibGlzaG1lbnQsIGhhbmRvZmYg b3IgZGF0YSB0cmFuc2Zlci4gDQ1UQy02LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNjYWxlYWJs ZSB0byBhY2NvbW1vZGF0ZSBhbnRpY2lwYXRlZCBsZXZlbHMgb2YgYWlyY3JhZnQgZXF1aXBhZ2Uu IAAAoQ8oAAAACgEAAAAAABAAAFoACAEAAAEAAAABAAEAAAAAAAAAAQAAAAEAAAABAAAAqg8MAAAA CgEAAAYAAAAJCAAAAADzAxQAAAAJAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8k AAAASUNBTyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAA JQAAAAEAAgABACQAEACfDwQAAAABAAAAAACoD5EAAABUQy01LiBUaGUgYXBwcm9hY2ggc2hvdWxk IHJlc3VsdCBpbiB0aHJvdWdocHV0IHdoaWNoIGFjY29tbW9kYXRlcyBhbnRpY2lwYXRlZCBsZXZl bHMgb2YgYWlyY3JhZnQgZXF1aXBhZ2UuDQ1UQy02LiBUaGUgYXBwcm9hY2ggc2hvdWxkIGJlIHNl Y3VyZS4gAAChDxwAAACSAAAAAAAAAAAAkAAAAAEAAAABAAIAAAAAAAAAAACqDxQAAACRAAAABgAA AAkIAAABAAAAAAAAAAAA8wMUAAAABgAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP IgAAAElDQU8gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMAAKEPFgAAACMAAAAAAAAAAAAj AAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPKAEAAElDLjEgVGhlIGFwcHJvYWNoIHNob3VsZCBw ZXJtaXQgdGhlIGFkZGl0aW9uIG9mIGFpci9ncm91bmQgc2VydmljZSBwcm92aWRlcnMuIA1JQy4y IFRoZSBhcHByb2FjaCBzaG91bGQgbm90IHJlbHkgb24gYSBwYXJ0aWN1bGFyIGFpci9ncm91bmQg c2VydmljZSBwcm92aWRlciBvciBhZG1pbmlzdHJhdGlvbiBmb3Igb3BlcmF0aW9uLg1JQy4zIFRo ZSBhcHByb2FjaCBzaG91bGQgbm90IGJlIHVuaXF1ZSB0byBhdmlhdGlvbiBidXQgcmF0aGVyIHNo b3VsZCBiZSBiYXNlZCBvbiBvcGVuIGluZHVzdHJ5IHN0YW5kYXJkcy4gAAChDx4AAAApAQAAAAAA EAAAWgAnAQAAAQAAAAEAAgAAAAAAAAAAAKoPIAAAAMQAAAAGAAAACQgAAGQAAAAGAAAACRAAAAEA AAAAAAAAAADzAxQAAAAHAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8pAAAASUNB TyBJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9ucyAoY29udCkAAKEPFgAAACoAAAAAAAAAAAAq AAAAAQACAAEAJAAQAJ8PBAAAAAEAAAAAAKgPAwEAAElDLjQgVGhlIGFwcHJvYWNoIHNob3VsZCBo YXZlIG1hdHVyZSBhbmQgY29tbWVyY2lhbGx5IGF2YWlsYWJsZSBpbXBsZW1lbnRhdGlvbnMuDUlD LjUgVGhlIGFwcHJvYWNoIHNob3VsZCBhbGxvdyB0aGUgaW5kdXN0cnkgdG8gaW1wbGVtZW50IGEg Y2xvc2VkIG5ldHdvcmsuDUlDLjYgVGhlIGFwcHJvYWNoIHNob3VsZCBhbGxvdyBhbiBhdXRoZW50 aWNhdGlvbiB0byBiZSByZXF1aXJlZCBmb3Igc3lzdGVtcyB0byBqb2luIHRoZSBjbG9zZWQgbmV0 d29yay4AAKEPFgAAAAQBAAAAAAAQAABaAAQBAAABAAAAAQAAAKoPFAAAAFEAAAAGAAAACRAAALMA AAAAAAAAAADqAwAAAAAPAO4DiQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAM BKABAAAPAALwmAEAALAACPAIAAAAAwAAAAMsAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAALAAABQAAAA8ABPB4AAAAEgAK8AgAAAACLAAAIAIAAGMAC/Ak AAAAfwAAAAQAgABc6JUAvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAACtACABYBV9Aw8A EfAQAAAAAADDCwgAAAAAAAAADQCVAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAA AAMsAAAgAgAAYwAL8CQAAAB/AAAABACAADTplQC/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDw CAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAAAJ4PBAAAAAEAAAAP AATwSAAAABIACvAIAAAAASwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu CAAAAI3kxQFQjH1nAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAAB/BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMY AAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBJQBAAAPAALwjAEAAGAACPAIAAAAAwAAAAMY AAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAA AA8ABPByAAAAEgAK8AgAAAACGAAAIAIAAFMAC/AeAAAAfwAAAAQAgACAU5UAvwEAAAEA/wEAAAEA AQMCBAAAAAAQ8AgAAADAACABYBWQAw8AEfAQAAAAAADDCwgAAAAAAAAADQCVAA8ADfAMAAAAAACe DwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMYAAAgAgAAUwAL8B4AAAB/AAAABACAAFhUlQC/AQAA AQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN 8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAARgAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLE2kAAAAAAOsuCAAAAI3kxQFQqeOsAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAAB/BP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwAC KwAAAAAPAO4DMAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAswDwAMBKABAAAPAALw mAEAAKAACPAIAAAAAwAAAAMoAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAAKAAABQAAAA8ABPB4AAAAEgAK8AgAAAACKAAAIAIAAGMAC/AkAAAAfwAAAAQA gACYoZUAvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAADAACABYBWQAw8AEfAQAAAAAADD CwgAAAAAAAAADQCVAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMoAAAgAgAA YwAL8CQAAAB/AAAABACAAHCilQC/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAAPADIAFg FRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJUADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIA CvAIAAAAASgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgT OAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAI3kxQFQ qeOsDwDuAyQCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwALMA8ADASUAQAADwAC8IwB AACAAAjwCAAAAAMAAAADIAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAACAAAAUAAAAPAATwcgAAABIACvAIAAAAAiAAACACAABTAAvwHgAAAH8AAAAEAIAA jNfNAb8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAA AA0AzQEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADIAAAIAIAAFMAC/AeAAAA fwAAAAQAgABk2M0BvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADD CwgAAAABAAAADgDNAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEgAAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACP5MUBQG/VUwAAchckAAAAAQAQ APksAAAFABAAhD8AAAcAIABBRAAACUIAAAoAEADzPAAAAAD1DxwAAAABAQAApBkAA9UsAABtRgAA AQAAAAoAAAABAMUxDwDoAyUQAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAA AAAAAQAAAAAAAAEPAPIDFAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEA cgBpAGEAbAAAALyWEwBfPgswvJYTAAAAAAAwANIPVKkTAFSpEwAoQM0B3JYTAHg6CzDclhMAAAAA AA8A1QcAAAQAAACkDwgAAACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAA AgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///v AAAAAAD///////8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ABAAAAAgAA AAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAf AAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA/v///ycAAAAoAAAAKQAAACoAAAArAAAALAAAAC0A AAAuAAAALwAAADAAAAAxAAAAMgAAAP7///80AAAA/v////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAABQJAAALAAAAAQAAAGAAAAAC AAAAaAAAAAQAAACwAAAACAAAAMgAAAAJAAAA4AAAABIAAADsAAAACgAAABABAAAMAAAAHAEAAA0A AAAoAQAADwAAADQBAAARAAAAPAEAAAIAAADkBAAAHgAAAEAAAABJQ0FPIFJlcXVpcmVtZW50cyBJ bnB1dCBmb3IgIEludGVybmV0IE1vYmlsaXR5IEF2aW9uaWNzIFNlcnZpY2UAHgAAABAAAABEYXZp cywgVGVycnkgTAAAHgAAABAAAABEYXZpcywgVGVycnkgTAAAHgAAAAQAAAAxMAAAHgAAABwAAABN aWNyb3NvZnQgT2ZmaWNlIFBvd2VyUG9pbnQAQAAAALDk4PUgAAAAQAAAAFBjcp+O5MUBQAAAAGAp fVq25MUBAwAAABIBAABHAAAA0AcAAP////8DAAAACACJEGcMAAABAAkAAAPfAwAABQAxAAAAAAAE AAAAAwEIAAUAAAALAgAAAAAFAAAADAJ5AKEAAwAAAB4ABwAAAPwCAAD///8AAAAEAAAALQEAAAgA AAD6AgUAAAAAAP///wAEAAAALQEBAA4AAAAkAwUA////////eACgAHgAoAD///////8IAAAA+gIA AAAAAAAAAAAABAAAAC0BAgAEAAAALQEAAAQAAAAnAf//HAAAAPsC9v8AAAAAAACQAQAAAAAAQAAA QXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACMQAAADIKJAAPABwAAABJQ0FPIEF2aWF0aW9uIENvbnNpZGVyYXRpb25zAwAHAAcA CAACAAcABAADAAUAAwACAAUABgADAAcABQAGAAQAAwAFAAYAAwAFAAMAAgAGAAYABAAEAAAALgEA ABwAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAAAAAAAAAAAAAYAAAAAQAAALhTHgDkBAAA BAAAAC0BBAAEAAAA8AEDABwAAAD7Avb/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg0AAAAyCi8A SgAEAAAAZm9yIAMABgADAAMABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC9v8AAAAAAACQ AQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACLgAAADIKOwAaABoAAABJbnRlcm5ldCBNb2JpbGl0eSBTZXJ2aWNl cwMABgACAAYAAwAFAAYAAwACAAgABgAFAAIAAgADAAMABQACAAcABgADAAQAAwAEAAYABAAEAAAA LgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIVAAAA MgpKAD0ACQAAAElDQU8gV0cgTgACAAQABAAFAAIABgAFAAIABAAEAAAALgEAAAQAAAAtAQQABAAA APABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpKAF8AAQAAAC2aAgAE AAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJ AAAAMgpKAGEAAQAAADGaAwAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwC AAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAE AAAAAgEBAAUAAAAJAgAAAAIWAAAAMgpRAEEACgAAAE1lZXRpbmcgIzUFAAMAAwACAAIABAAEAAIA AwADAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avr/AAAAAAAAvAIAAAAAAEAAAEFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAh8AAAAyClkANwAQAAAATW9udHJlYWwsIENhbmFkYQUABAAEAAIAAgADAAMAAgACAAIABAAD AAUAAwAEAAMABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC+v8AAAAAAAC8AgAAAAAAQAAA QXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACFgAAADIKYAAyAAoAAABOb3ZlbWJlciA3BAAEAAMABAAFAAQAAwACAAMAAwAEAAAA LgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAA MgpgAFUAAQAAAC2aAgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAA AABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAITAAAAMgpgAFcACAAAADEwLCAyMDA1BAADAAIAAgADAAQAAwADAAQAAAAu AQAABAAAAC0BBAAEAAAA8AEDAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AALVzdWcLhsQk5cIACss+a4wAAAAAAMAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA xAAAAAYAAADMAAAABwAAANQAAAAIAAAA3AAAAAkAAADkAAAACgAAAOwAAABjYWwgQ29uc2lkZXJh dGlvbnMLKGNvbnQpAAChDxYAAAAlAAAAAAAAAAAAJQAAAAEAAgABACQAEACfDwQAAAABAAAAAACo DwkBAABUQy0zLiBUaGUgYXBwcm9hY2ggc2hvdWxkIG1pbmltaXplIGxhdGVuY3kgZHVyaW5nIGVz dGFibGlzaG1lbnQgb2YgaW5pdGlhbCBwYXRocyB0byBhbiBhaXJjcmFmdCwgZHVyaW5nIGhhbmRv ZmYsIGFuZCBkdXJpbmcgdHJhbnNmZXIgb2YgaW5kaXZpZHVhbCBkYXRhIHBhY2tldHMuIA0NVEMt NC4gVGhlIGFwcHJvYWNoIHNob3VsZCBoYXZlIGhpZ2ggYXZhaWxhYmlsaXR5IHdoaWNoIGluY2x1 ZGVzIG5vdCBoYXZpbmcgYSBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZS4gAAChDygAAAAKAQAAAAAA EAAAWgAHAQAAAQAAAAEAAgAAAAAAAAABAAAAAQAAAAEAAACqDwwAAAAKAQAABgAAAAkIAAAAAPMD FAAAAAgAAAAAAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDyQAAABJQ0FPIFRlY2huaWNh bCBDb25zaWRlcmF0aW9ucwsoY29udCkAAKEPFgAAACUAAAAAAAAAAAAlAAAAAQACAAEAJAAQAJ8P BAAAAAEAAAAAAKgPCQEAAFRDLTUuIFRoZSBhcHByb2FjaCBzaG91bGQgbm90IG5lZ2F0aXZlbHkg aW1wYWN0IGVuZC10by1lbmQgZGF0YSBpbnRlZ3JpdHksIGZvciBleGFtcGxlLCBieSBpbnRyb2R1 Y2luZyBwYWNrZXQgbG9zcyBkdXJpbmcgcGF0aCBlc3RhYmxpc2htZW50LCBoYW5kb2ZmIG9yIGRh dGEgdHJhbnNmZXIuIA0NVEMtNi4gVGhlIGFwcHJvYWNoIHNob3VsZCBiZSBzY2FsZWFibGUgdG8g YWNjb21tb2RhdGUgYW50aWNpcGF0ZWQgbGV2ZWxzIG9mIGFpcmNyYWZ0IGVxdWlwYWdlLiAAAKEP KAAAAAoBAAAAAAAQAABaAAgBAAABAAAAAQABAAAAAAAAAAEAAAABAAAAAQAAAKoPDAAAAAoBAAAG AAAACQgAAAAA8wMUAAAACQAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJAAAAElD QU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zCyhjb250KQAAoQ8WAAAAJQAAAAAAAAAAACUAAAAB AAIAAQAkABAAnw8EAAAAAQAAAAAAqA+RAAAAVEMtNS4gVGhlIGFwcHJvYWNoIHNob3VsZCByZXN1 bHQgaW4gdGhyb3VnaHB1dCB3aGljaCBhY2NvbW1vZGF0ZXMgYW50aWNpcGF0ZWQgbGV2ZWxzIG9m IGFpcmNyYWZ0IGVxdWlwYWdlLg0NVEMtNi4gVGhlIGFwcHJvYWNoIHNob3VsZCBiZSBzZWN1cmUu IAAAoQ8cAAAAkgAAAAAAAAAAAJAAAAABAAAAAQACAAAAAAAAAAAAqg8UAAAAkQAAAAYAAAAJCAAA AQAAAAAAAAAAAPMDFAAAAAYAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDyIAAABJ Q0FPIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zAAChDxYAAAAjAAAAAAAAAAAAIwAAAAEA AgABACQAEACfDwQAAAABAAAAAACoDygBAABJQy4xIFRoZSBhcHByb2FjaCBzaG91bGQgcGVybWl0 IHRoZSBhZGRpdGlvbiBvZiBhaXIvZ3JvdW5kIHNlcnZpY2UgcHJvdmlkZXJzLiANSUMuMiBUaGUg YXBwcm9hY2ggc2hvdWxkIG5vdCByZWx5IG9uIGEgcGFydGljdWxhciBhaXIvZ3JvdW5kIHNlcnZp Y2UgcHJvdmlkZXIgb3IgYWRtaW5pc3RyYXRpb24gZm9yIG9wZXJhdGlvbi4NSUMuMyBUaGUgYXBw cm9hY2ggc2hvdWxkIG5vdCBiZSB1bmlxdWUgdG8gYXZpYXRpb24gYnV0IHJhdGhlciBzaG91bGQg YmUgYmFzZWQgb24gb3BlbiBpbmR1c3RyeSBzdGFuZGFyZHMuIAAAoQ8eAAAAKQEAAAAAABAAAFoA JwEAAAEAAAABAAIAAAAAAAAAAACqDyAAAADEAAAABgAAAAkIAABkAAAABgAAAAkQAAABAAAAAAAA AAAA8wMUAAAABwAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKQAAAElDQU8gSW1w bGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMgKGNvbnQpAAChDxYAAAAqAAAAAAAAAAAAKgAAAAEA AgABACQAEACfDwQAAAABAAAAAACoDwMBAABJQy40IFRoZSBhcHByb2FjaCBzaG91bGQgaGF2ZSBt YXR1cmUgYW5kIGNvbW1lcmNpYWxseSBhdmFpbGFibGUgaW1wbGVtZW50YXRpb25zLg1JQy41IFRo ZSBhcHByb2FjaCBzaG91bGQgYWxsb3cgdGhlIGluZHVzdHJ5IHRvIGltcGxlbWVudCBhIGNsb3Nl ZCBuZXR3b3JrLg1JQy42IFRoZSBhcHByb2FjaCBzaG91bGQgYWxsb3cgYW4gYXV0aGVudGljYXRp b24gdG8gYmUgcmVxdWlyZWQgZm9yIHN5c3RlbXMgdG8gam9pbiB0aGUgY2xvc2VkIG5ldHdvcmsu AAChDxYAAAAEAQAAAAAAEAAAWgAEAQAAAQAAAAEAAACqDxQAAABRAAAABgAAAAkQAACzAAAAAAAA AAAA6gMAAAAAAAByFwgAAAABABAAiGwAAAAA9Q8cAAAABwEAAKQZAANkbAAAjHwAAAEAAAAKAAAA AQDFMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIA eQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///////// /wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAwD7YGJXlxQFAAAAAQBAAAAAAAABDAHUA cgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMA AABKAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEQJAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBl AG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwHwAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAA AAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAABUAAAAWAAAAMgAAAP//////////GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAi AAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAARQAAAP// /////////////zMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAA ABkAAAD/////QQAAAEIAAABDAAAAUAAAAP////9GAAAARwAAAEgAAABJAAAA/v///08AAAD9//// /v///04AAAD+/////v///1EAAABSAAAATQAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wEAAAACAAAAAwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAU AAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAAJAAAACUAAAD+////JwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAA ADEAAAAyAAAANQAAADQAAAD+////NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA PwAAAEAAAAD+//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////YgBqAGUAYwB0AAAABQAAAA0AAABf AEEAdQB0AGgAbwByAEUAbQBhAGkAbAAAAAAABgAAABgAAABfAEEAdQB0AGgAbwByAEUAbQBhAGkA bABEAGkAcwBwAGwAYQB5AE4AYQBtAGUAAAACAAAAsAQAABMAAAAJBAAAAwAAAOt0cp0fAAAAAQAA AAAAAAAfAAAAlAAAAEkAbgB0AGUAcgBuAGEAdABpAG8AbgBhAGwAIABDAGkAdgBpAGwAIABBAHYA aQBhAHQAaQBvAG4AIABPAHIAZwBhAG4AaQB6AGEAdABpAG8AbgAgAC0AIABXAG8AcgBrAGkAbgBn ACAARwByAG8AdQBwACAALQAgAE4ALQAxACAAUgBFACAALQAgAEEAdgBpAGEAdABpAG8AbgAgAE4A ZQB0AHcAbwByAGsAIABDAG8AbgBzAGkAZABlAHIAYQB0AGkAbwBuAHMAIAA6ACAAWwBuAGUAbQBv AF0AIABSAGUAYwBoAGEAcgB0AGUAcgAgAGkAdABlAG0AcwA6ACAAbQB1AGwAdABpAGgAbwBtAGkA bgBnACAALQAgAEgAQQBIAEEAIAA/AAAAHwAAABkAAAB0AGUAcgByAHkALgBsAC4AZABhAHYAaQBz AEAAYgBvAGUAaQBuAGcALgBjAG8AbQAAAAAAHwAAAA8AAABEAGEAdgBpAHMALAAgAFQAZQByAHIA eQAgAEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAACAGAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwACAAMAAwAEAAAALgEAAAQAAAAtAQQA BAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgpgAFUAAQAAAC2a AgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL6/wAAAAAAALwCAAAAAABAAABBcmlhbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAITAAAAMgpgAFcACAAAADEwLCAyMDA1BAADAAIAAgADAAQAAwADAAQAAAAuAQAABAAAAC0BBAAE AAAA8AEDAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cI ACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkQDAAAAAwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAA qAAAAAQAAADEAAAABgAAAMwAAAAHAAAA1AAAAAgAAADcAAAACQAAAOQAAAAKAAAA7AAAABcAAAD0 AAAACwAAAPwAAAAQAAAABAEAABMAAAAMAQAAFgAAABQBAAANAAAAHAEAAAwAAACdAgAAAgAAAOQE AAAeAAAAEAAAAE9uLXNjcmVlbiBTaG93AAAeAAAAFAAAAFRoZSBCb2VpbmcgQ29tcGFueQAAAwAA AMB8AAADAAAAHQAAAAMAAAAIAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAKgZCwALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAKAAAABgAAAEFyaWFsAA8AAABEZWZhdWx0 IERlc2lnbgA9AAAASUNBTyBBdmlhdGlvbiBDb25zaWRlcmF0aW9ucyBmb3IgIEludGVybmV0IE1v YmlsaXR5IFNlcnZpY2VzAB4AAABJQ0FPIFRlY2huaWNhbCBDb25zaWRlcmF0aW9ucwAlAAAASUNB TyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMgKGNvbnQpACUAAABJQ0FPIFRlY2huaWNhbCBDb25z aWRlcmF0aW9ucyAoY29udCkAJQAAAElDQU8gVGVjaG5pY2FsIENvbnNpZGVyYXRpb25zIChjb250 KQAlAAAASUNBTyBUZWNobmljYWwgQ29uc2lkZXJhdGlvbnMgKGNvbnQpACMAAABJQ0FPIEltcGxl bWVudGF0aW9uIENvbnNpZGVyYXRpb25zACoAAABJQ0FPIEltcGxlbWVudGF0aW9uIENvbnNpZGVy YXRpb25zIChjb250KQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAA RGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAgAAAAA9g8m AAAAFAAAAF/AkeOcfAAADgD0AwMA2jBEYXZpcywgVGVycnkgTAgAAABEAGEAdgBpAHMALAAgAFQA ZQByAHIAeQAgAEwAZW0AAAAAAAAAAAAAGAAAAAEAAAC4Ux4A5AQAAAQAAAAtAQQABAAAAPABAwAc AAAA+wL2/wAAAAAAANwCAAAIAAAAAAAAAEgAAAABAAAAJAEAAAAAAIAsAQAAAgAAADQBAAADAAAA PAEAAAQAAABIAQAABQAAAHgCAAAGAAAAtAIAAAUAAAACAAAAFAAAAF8AQQBkAEgAbwBjAFIAZQB2 AGkAZQB3AEMAeQBjAGwAZQBJAEQAAAADAAAAEAAAAF8ATgBlAHcAUgBlAHYAaQBlAHcAQwB5AGMA bABlAAAABAAAAA4AAABfAEUAbQBhAGkAbABTAHUA ------_=_NextPart_001_01C5E595.1A4E82B8-- From nemo-bounces@ietf.org Wed Nov 09 21:32:32 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 1Ea2Eq-00087d-9j; Wed, 09 Nov 2005 21:32:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2Ep-00087Y-M9 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 21:32:31 -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 VAA28427 for ; Wed, 9 Nov 2005 21:32:03 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea2Uu-0002Df-Bq for nemo@ietf.org; Wed, 09 Nov 2005 21:49:12 -0500 Received: from iseran.local (unknown [209.52.152.212]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D9B2D4C0EE for ; Thu, 10 Nov 2005 11:32:00 +0900 (JST) Date: Thu, 10 Nov 2005 11:31:42 +0900 From: Thierry Ernst To: ml-nemo Subject: Re: [nemo] Issue A14 - e-face and i-face Message-Id: <20051110113142.007c77ef.ernst@sfc.wide.ad.jp> In-Reply-To: <43729A18.4030805@motorola.com> References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> <43729A18.4030805@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: f4c2cf0bccc868e4cc88dace71fb3f44 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 I'm French and while I agree that in French or other languages we might be confused and pronounce 'e-face' when actually meaning 'i-face', I'm much more confused when pronouning or earing "ingress" vs "egress" which seems to be a problem even for English speakers. So, the voice count so far is: - no harm to keep i-face and e-face in the document as it can help: Will, Thierry. - remove Ryuji, Nicolas, Francis, Masafumi, Christophe, Alexandru There is a majority to remove, but I think it doesn't harm to keep since it also helps. I don't understand the reason to remove because it's an abbreaviation [i.,e. not a term per se], and the offical term remains 'egrees interface' and'ingress interface'. But this is just my point of view and I will range behind the majority. Thierry On Wed, 09 Nov 2005 16:53:44 -0800 Alexandru Petrescu wrote: > Francis Dupont wrote: > > In your previous mail you wrote: > > > > Can we have some comments from non-English speakers that think > > i-face and e-face are easier to understand than ingress > > interface and egress interface? This still seems awkward to me > > -- I wouldn't know what e- face and i-face mean unless I go do > > some research. > > > > => I agree with you and more, as in French the letter i is pronounce > > exactly like the letter e in English this can become a nightmare in > > its not written form! So I support TJ, PLEASE use ingress and egress > > at least! > > Non-native English speaker here. > > I second that "e" vs "i" is difficult to distinguish, as a non-native > French speaker too. > > BEsides, sounds to me like in English "e-face" is somebody with a face > of e-shape. I'll acknowledge though that e-everything seems to be > widely used. > > Alex -- 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 Wed Nov 09 21:55:20 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 1Ea2au-0006EG-RY; Wed, 09 Nov 2005 21:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2at-0006EB-ML for nemo@megatron.ietf.org; Wed, 09 Nov 2005 21:55:19 -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 VAA29578 for ; Wed, 9 Nov 2005 21:54:51 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea2r1-0002lJ-Uy for nemo@ietf.org; Wed, 09 Nov 2005 22:12:00 -0500 Received: from [203.178.139.249] (wifi-139-249.sfc.wide.ad.jp [203.178.139.249]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 98ACB4C09C for ; Thu, 10 Nov 2005 11:55:09 +0900 (JST) Message-ID: <4372B709.9070409@sfc.wide.ad.jp> Date: Thu, 10 Nov 2005 11:57:13 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] Issue A14 - e-face and i-face References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> <43729A18.4030805@motorola.com> <20051110113142.007c77ef.ernst@sfc.wide.ad.jp> In-Reply-To: <20051110113142.007c77ef.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: 41c17b4b16d1eedaa8395c26e9a251c4 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 Hello, French speaking. I also prefer ingress/egress rather than e/i for both oral and written. First because of the e/i confusion in French. And although e/i-face may just be an abreviation, I do not see the benefit to use it over ingress/egress in the text. I would prefer to stick to the defined terms to avoid confusions. Romain Thierry Ernst wrote: > I'm French and while I agree that in French or other languages we might > be confused and pronounce 'e-face' when actually meaning 'i-face', I'm > much more confused when pronouning or earing "ingress" vs "egress" which > seems to be a problem even for English speakers. > > So, the voice count so far is: > - no harm to keep i-face and e-face in the document as it can help: > Will, Thierry. > - remove > Ryuji, Nicolas, Francis, Masafumi, Christophe, Alexandru > > There is a majority to remove, but I think it doesn't harm to keep since > it also helps. I don't understand the reason to remove because it's an > abbreaviation [i.,e. not a term per se], and the offical term remains > 'egrees interface' and'ingress interface'. But this is just my point of > view and I will range behind the majority. > > > Thierry > > > On Wed, 09 Nov 2005 16:53:44 -0800 > Alexandru Petrescu wrote: > > >>Francis Dupont wrote: >> >>> In your previous mail you wrote: >>> >>> Can we have some comments from non-English speakers that think >>> i-face and e-face are easier to understand than ingress >>> interface and egress interface? This still seems awkward to me >>> -- I wouldn't know what e- face and i-face mean unless I go do >>> some research. >>> >>>=> I agree with you and more, as in French the letter i is pronounce >>>exactly like the letter e in English this can become a nightmare in >>>its not written form! So I support TJ, PLEASE use ingress and egress >>>at least! >> >>Non-native English speaker here. >> >>I second that "e" vs "i" is difficult to distinguish, as a non-native >>French speaker too. >> >>BEsides, sounds to me like in English "e-face" is somebody with a face >>of e-shape. I'll acknowledge though that e-everything seems to be >>widely used. >> >>Alex > > > -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Nov 10 01:58:42 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 1Ea6OQ-0005Hv-7c; Thu, 10 Nov 2005 01:58:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea6OO-0005H4-Of for nemo@megatron.ietf.org; Thu, 10 Nov 2005 01:58:40 -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 BAA12187 for ; Thu, 10 Nov 2005 01:58:10 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea6eV-0008WS-LH for nemo@ietf.org; Thu, 10 Nov 2005 02:15:21 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAA7AiTi013845; Thu, 10 Nov 2005 00:10:44 -0700 (MST) Received: from [144.189.72.22] (mvp-144-189-72-22.corp.mot.com [144.189.72.22]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jAA76shm017036; Thu, 10 Nov 2005 01:06:54 -0600 (CST) Message-ID: <4372EF8E.9060409@motorola.com> Date: Wed, 09 Nov 2005 22:58:22 -0800 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] NEMO for IPv4 References: <4354AA19.90701@motorola.com> <1131584589.13686.6.camel@localhost> In-Reply-To: <1131584589.13686.6.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: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , 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 Chan-Wah NG wrote: > Hello, > > I must first admit that I have not read the entire draft, this is just a > quick comment after hearing Alex's presentation today. > > On Tue, 2005-10-18 at 09:54 +0200, Alexandru Petrescu wrote: > >>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. >> > > > ..... > > >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >> +-+-+-+-+-+-+-+-+ >> > > > I am just wondering what is the reason behind starting the prefix field > at the 5th byte instea dof the normal convention of starting a field at > its proper byte-aligned boundary. I know IPv4 does not have a strict > requirement for byte-boundary alignment like IPv6, so there is no need > to create empty reserved bits just for byte-alignment. However, in this > case, a simple re-ordering of the Code / Prefix-Length / Prefix field > would achieve a natural byte alignment. So I am wondering if there is a > technical reason why that is not done. If there is no technical reason, > I would suggest the re-ordering of the fields. Right, BAsically the order of fields in the message is something we've discussed at length between authors. What we wanted at some point was to have them a little bit more aligned but we couldn't quite agree. I am not sure what order you prefer. Is the preferred order in your oppinion like Code/Prefix/PrefixLen (instead of Code/PrefixLen/Prefix) such as to have the Prefix itself on a 4-byte boundary? If yes, that sounds like a good idea to me. If no other opposition we'll do just that, sounds like a good idea: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+ Thanks, Alex From nemo-bounces@ietf.org Thu Nov 10 09:42:08 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 1EaDcu-0005vF-2M; Thu, 10 Nov 2005 09:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDcs-0005vA-Tm for nemo@megatron.ietf.org; Thu, 10 Nov 2005 09:42: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 JAA06992 for ; Thu, 10 Nov 2005 09:41:38 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaDt6-0003pj-Dl for nemo@ietf.org; Thu, 10 Nov 2005 09:58:53 -0500 Received: by wproxy.gmail.com with SMTP id i32so175885wra for ; Thu, 10 Nov 2005 06:42:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=e0I6raEE+HZeqd/Gfm9ofCiJHps/7G7pWK6i9tV6xWCVCBvKFIzN/R4kRomd9bXSuIkDdPzrvZBLVRSnm03YjE8BHYNPLiC/+dc6/FjfrD7HV4fz0DmtP99bNJqNBSvZ7RsCls4/xj/1BPI7daW/HmZptvouJM2DPyelSZsb+Vk= Received: by 10.64.10.8 with SMTP id 8mr924511qbj; Thu, 10 Nov 2005 06:42:04 -0800 (PST) Received: by 10.64.21.10 with HTTP; Thu, 10 Nov 2005 06:42:04 -0800 (PST) Message-ID: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> Date: Thu, 10 Nov 2005 20:12:04 +0530 From: Syam Madanapalli To: nemo@ietf.org Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I see there is at least one scenario where the current FMIPv6 may not be sufficient for session continuity for the nodes in the Mobile Network when the MR is moving from Home Network. When MR is moving from Home Network it is required to establish a tunnel from PAR to NAR for the Mobile Network Prefixes along with the MR's pCoA (i.e. MR's HoA). Also we can think of optimization here as PAR and Nemo HA may be on the same link and even may be on the same box, so we can eliminate the tunnel between PAR and MR, and establish the tunnel between Nemo HA and MR. This optimization may require further analysis to check for other impacts. The other scenario is where we may need updates to FMIPv6 is when MR delegates any prefixes on a Foreign Network and moves to another Foreign Network before the expiry of the prefixes delegated on the previous link. I think the problems in applying the FMIPv6 to NEMO are simple And can be easily fixed, so it is good idea to include this in the charter for known problems. I am writing a draft on this, I will let you know when I done with it. Thanks, Syam > Dear all, > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > Support ? Isn't there any other protocol we need to fx ? > > Thierry From nemo-bounces@ietf.org Thu Nov 10 12:21:26 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 1EaG74-0007RX-Kj; Thu, 10 Nov 2005 12:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaG71-0007QG-6y for nemo@megatron.ietf.org; Thu, 10 Nov 2005 12:21:25 -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 MAA19634 for ; Thu, 10 Nov 2005 12:20:54 -0500 (EST) Received: from pp107-98.bctel.ca ([209.52.107.98] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaGNG-0000zf-7I for nemo@ietf.org; Thu, 10 Nov 2005 12:38:11 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 9C1061A3C44; Fri, 11 Nov 2005 01:24:05 +0800 (SGT) Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO From: Chan-Wah NG To: Syam Madanapalli In-Reply-To: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 11 Nov 2005 01:24:04 +0800 Message-Id: <1131643445.12225.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Syam, True, as I'd mentioned in my previous response to Thierry, when the MR is a nAR or pAR, the FMIP gets very inefficient, which might defeat the purpose of having FMIP at all. However, conceiviably, that will be countered when a RO mechnaism is in place. I don't know whether we need various different optimization schemes for each protocol that will run together with NEMO-BS, or simply develop a general NEMO-RO solution. /rgds /cwng On Thu, 2005-11-10 at 20:12 +0530, Syam Madanapalli wrote: > Hi, > > I see there is at least one scenario where the current FMIPv6 > may not be sufficient for session continuity for the nodes in the > Mobile Network when the MR is moving from Home Network. > > When MR is moving from Home Network it is required to > establish a tunnel from PAR to NAR for the Mobile Network > Prefixes along with the MR's pCoA (i.e. MR's HoA). > > Also we can think of optimization here as PAR and Nemo HA > may be on the same link and even may be on the same box, > so we can eliminate the tunnel between PAR and MR, and > establish the tunnel between Nemo HA and MR. This optimization > may require further analysis to check for other impacts. > > The other scenario is where we may need updates to FMIPv6 is > when MR delegates any prefixes on a Foreign Network and moves > to another Foreign Network before the expiry of the prefixes > delegated on the previous link. > > I think the problems in applying the FMIPv6 to NEMO are simple > And can be easily fixed, so it is good idea to include this in the > charter for known problems. I am writing a draft on this, I will let > you know when I done with it. > > Thanks, > Syam > > > > Dear all, > > > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > > Support ? Isn't there any other protocol we need to fx ? > > > > Thierry > From nemo-bounces@ietf.org Thu Nov 10 13:24:47 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 1EaH6N-0000sK-0c; Thu, 10 Nov 2005 13:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaH6F-0000rB-QJ for nemo@megatron.ietf.org; Thu, 10 Nov 2005 13:24:41 -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 NAA23602 for ; Thu, 10 Nov 2005 13:24:10 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaHMV-0002q6-A4 for nemo@ietf.org; Thu, 10 Nov 2005 13:41:28 -0500 Received: by xproxy.gmail.com with SMTP id i27so688837wxd for ; Thu, 10 Nov 2005 10:24:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DSdbGqTurW9yqOBtxcQdhVtElchv/fWWRVzk5xPpj09NIlB46TDw5znofPkWghP4L3X3wgrWd0zbr7dag6NqNzE5u+2QMA6astHOptuMH3V+43hR4atelEnSkZFibkhjemUTxwZVQOHUHrg5DdK+pjSxbh9Zaq2szx2eyE2Vag0= Received: by 10.65.197.18 with SMTP id z18mr1190318qbp; Thu, 10 Nov 2005 10:24:35 -0800 (PST) Received: by 10.64.21.10 with HTTP; Thu, 10 Nov 2005 10:24:35 -0800 (PST) Message-ID: <10e14db20511101024s3315ae60i96826163e8c7f8fb@mail.gmail.com> Date: Thu, 10 Nov 2005 23:54:35 +0530 From: Syam Madanapalli To: Chan-Wah NG Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO In-Reply-To: <1131643445.12225.5.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> <1131643445.12225.5.camel@localhost> X-Spam-Score: 2.2 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Hello Wah-Wah, On 11/10/05, Chan-Wah NG wrote: > Hello Syam, > > True, as I'd mentioned in my previous response to Thierry, when the MR > is a nAR or pAR, the FMIP gets very inefficient, which might defeat the > purpose of having FMIP at all. The scenario I mentioned is about FMIPv6 Client implementation on MR. If PAR and NAR support on MRs is inefficient then one can choose not to do that. - Syam > > However, conceiviably, that will be countered when a RO mechnaism is in > place. I don't know whether we need various different optimization > schemes for each protocol that will run together with NEMO-BS, or simply > develop a general NEMO-RO solution. > > /rgds > /cwng > > On Thu, 2005-11-10 at 20:12 +0530, Syam Madanapalli wrote: > > Hi, > > > > I see there is at least one scenario where the current FMIPv6 > > may not be sufficient for session continuity for the nodes in the > > Mobile Network when the MR is moving from Home Network. > > > > When MR is moving from Home Network it is required to > > establish a tunnel from PAR to NAR for the Mobile Network > > Prefixes along with the MR's pCoA (i.e. MR's HoA). > > > > Also we can think of optimization here as PAR and Nemo HA > > may be on the same link and even may be on the same box, > > so we can eliminate the tunnel between PAR and MR, and > > establish the tunnel between Nemo HA and MR. This optimization > > may require further analysis to check for other impacts. > > > > The other scenario is where we may need updates to FMIPv6 is > > when MR delegates any prefixes on a Foreign Network and moves > > to another Foreign Network before the expiry of the prefixes > > delegated on the previous link. > > > > I think the problems in applying the FMIPv6 to NEMO are simple > > And can be easily fixed, so it is good idea to include this in the > > charter for known problems. I am writing a draft on this, I will let > > you know when I done with it. > > > > Thanks, > > Syam > > > > > > > Dear all, > > > > > > Shouldn't we take a look at how FMIPv6 should work for NEMO Basic > > > Support ? Isn't there any other protocol we need to fx ? > > > > > > Thierry > > > > > From nemo-bounces@ietf.org Thu Nov 10 13:46:01 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 1EaHQv-0007qX-OI; Thu, 10 Nov 2005 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHQt-0007qP-JH for nemo@megatron.ietf.org; Thu, 10 Nov 2005 13:45:59 -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 NAA25218 for ; Thu, 10 Nov 2005 13:45:32 -0500 (EST) Received: from pp107-98.bctel.ca ([209.52.107.98] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaHhA-0003aD-96 for nemo@ietf.org; Thu, 10 Nov 2005 14:02:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 3479A1A3C44; Fri, 11 Nov 2005 02:48:48 +0800 (SGT) Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO From: Chan-Wah NG To: Syam Madanapalli In-Reply-To: <10e14db20511101024s3315ae60i96826163e8c7f8fb@mail.gmail.com> References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> <1131643445.12225.5.camel@localhost> <10e14db20511101024s3315ae60i96826163e8c7f8fb@mail.gmail.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 11 Nov 2005 02:48:47 +0800 Message-Id: <1131648527.12225.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 On Thu, 2005-11-10 at 23:54 +0530, Syam Madanapalli wrote: > > True, as I'd mentioned in my previous response to Thierry, when the MR > > is a nAR or pAR, the FMIP gets very inefficient, which might defeat the > > purpose of having FMIP at all. > > The scenario I mentioned is about FMIPv6 Client implementation on MR. > If PAR and NAR support on MRs is inefficient then one can choose not to > do that. > Opps, sorry. Still have not receovered from the change of time-zone, I guess :) Anyway, see comments in-line. > > > I see there is at least one scenario where the current FMIPv6 > > > may not be sufficient for session continuity for the nodes in the > > > Mobile Network when the MR is moving from Home Network. > > > > > > When MR is moving from Home Network it is required to > > > establish a tunnel from PAR to NAR for the Mobile Network > > > Prefixes along with the MR's pCoA (i.e. MR's HoA). > > > > > > Also we can think of optimization here as PAR and Nemo HA > > > may be on the same link and even may be on the same box, > > > so we can eliminate the tunnel between PAR and MR, and > > > establish the tunnel between Nemo HA and MR. This optimization > > > may require further analysis to check for other impacts. > > > Is this any different from a MIPv6 mobile host leaving its home network? I can't believe FMIP has not considered it. Anycase, should one send FBU to the router on its own home link when a BU is sufficient? Make no sense to do that. > > > The other scenario is where we may need updates to FMIPv6 is > > > when MR delegates any prefixes on a Foreign Network and moves > > > to another Foreign Network before the expiry of the prefixes > > > delegated on the previous link. Maybe, if we do have a mechanism for prefix delegation from foreign network. Even assuming we do have one, I don't see any problem here. It is an implementation consideration. Implemented correctly, it will work without any need for any changes for FMIP: (a) When MR is at pAR, it has CoA=MR.pCoA. In addition, it obtains prefix P from the foreign network. (b) pAR, should now know that packets sent to P should be routed to MR.pCoA (c) When MR moves to nAR, its send FBU to pAR, setting up a binding between MR.nCoA and MR.pCoA (d) When pAR receives a packet addressed to P, it routes the packet to MR.pCoA (just like (b)). To route packet to MR.pCoA, the next hop interface is the tunnel to MR.nCoA. So, packets sent to prefix P is correctly forwarded to MR.nCoA. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 10 14:07:42 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 1EaHlu-00063U-Lc; Thu, 10 Nov 2005 14:07:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHlt-000632-Bi for nemo@megatron.ietf.org; Thu, 10 Nov 2005 14:07:41 -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 OAA26886 for ; Thu, 10 Nov 2005 14:07:11 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaI27-0004KU-0t for nemo@ietf.org; Thu, 10 Nov 2005 14:24:28 -0500 Received: by xproxy.gmail.com with SMTP id t11so560540wxc for ; Thu, 10 Nov 2005 11:07:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lT/u6PZ0FCpR/fTpOFQeE1r7T9LjTJQlABXYRmT6E7htqYypFdVTibPV8plD8LRycnLdrE/LS0PtD8a+Xp8M0NAZZ50Ekwz7DO+VxDoXPFybSHHfxRL0dxolLH4SzbvRDPMkEXd08LXOlKGX4dvr2HFv7AdAc7Zp3eajA2mnnpw= Received: by 10.65.153.12 with SMTP id f12mr1255297qbo; Thu, 10 Nov 2005 11:07:36 -0800 (PST) Received: by 10.64.21.10 with HTTP; Thu, 10 Nov 2005 11:07:36 -0800 (PST) Message-ID: <10e14db20511101107m50a5a9a5yb98f68454a97b8eb@mail.gmail.com> Date: Fri, 11 Nov 2005 00:37:36 +0530 From: Syam Madanapalli To: Chan-Wah NG Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO In-Reply-To: <1131648527.12225.22.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> <1131643445.12225.5.camel@localhost> <10e14db20511101024s3315ae60i96826163e8c7f8fb@mail.gmail.com> <1131648527.12225.22.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Hi, "Every problem in computer science can be solved by adding a level of indirection." -Kaufman I see your point. What if the routing entry expires and does not know where to send. And as you said it depends the implementation look up. Some may look for P:: finds MR is the next hop, looks for Neigbhor cahce, may not present and gives up. Tunnel look up may depends for /128 bit addresses and may be a good idea to explicity associate a prefix to the tunnel like in NEMO Basic Support. Thanks, Syam On 11/11/05, Chan-Wah NG wrote: > On Thu, 2005-11-10 at 23:54 +0530, Syam Madanapalli wrote: > > > True, as I'd mentioned in my previous response to Thierry, when the M= R > > > is a nAR or pAR, the FMIP gets very inefficient, which might defeat t= he > > > purpose of having FMIP at all. > > > > The scenario I mentioned is about FMIPv6 Client implementation on MR. > > If PAR and NAR support on MRs is inefficient then one can choose not to > > do that. > > > > Opps, sorry. Still have not receovered from the change of time-zone, I > guess :) Anyway, see comments in-line. > > > > > I see there is at least one scenario where the current FMIPv6 > > > > may not be sufficient for session continuity for the nodes in the > > > > Mobile Network when the MR is moving from Home Network. > > > > > > > > When MR is moving from Home Network it is required to > > > > establish a tunnel from PAR to NAR for the Mobile Network > > > > Prefixes along with the MR's pCoA (i.e. MR's HoA). > > > > > > > > Also we can think of optimization here as PAR and Nemo HA > > > > may be on the same link and even may be on the same box, > > > > so we can eliminate the tunnel between PAR and MR, and > > > > establish the tunnel between Nemo HA and MR. This optimization > > > > may require further analysis to check for other impacts. > > > > > > Is this any different from a MIPv6 mobile host leaving its home network? > I can't believe FMIP has not considered it. Anycase, should one send > FBU to the router on its own home link when a BU is sufficient? Make no > sense to do that. > > > > > The other scenario is where we may need updates to FMIPv6 is > > > > when MR delegates any prefixes on a Foreign Network and moves > > > > to another Foreign Network before the expiry of the prefixes > > > > delegated on the previous link. > > Maybe, if we do have a mechanism for prefix delegation from foreign > network. > > Even assuming we do have one, I don't see any problem here. It is an > implementation consideration. Implemented correctly, it will work > without any need for any changes for FMIP: > > (a) When MR is at pAR, it has CoA=3DMR.pCoA. In addition, it obtains > prefix P from the foreign network. > > (b) pAR, should now know that packets sent to P should be routed to > MR.pCoA > > (c) When MR moves to nAR, its send FBU to pAR, setting up a binding > between MR.nCoA and MR.pCoA > > (d) When pAR receives a packet addressed to P, it routes the packet to > MR.pCoA (just like (b)). To route packet to MR.pCoA, the next hop > interface is the tunnel to MR.nCoA. So, packets sent to prefix P is > correctly forwarded to MR.nCoA. > > /rgds > /cwng > > > > From nemo-bounces@ietf.org Thu Nov 10 14:33:17 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 1EaIAf-0007vl-3b; Thu, 10 Nov 2005 14:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIAd-0007tR-9F for nemo@megatron.ietf.org; Thu, 10 Nov 2005 14:33:15 -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 OAA28158 for ; Thu, 10 Nov 2005 14:32:47 -0500 (EST) Received: from pp107-98.bctel.ca ([209.52.107.98] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIOC-0005MB-Lu for nemo@ietf.org; Thu, 10 Nov 2005 14:47:17 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id DB7A31A3C44; Fri, 11 Nov 2005 03:33:13 +0800 (SGT) Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO From: Chan-Wah NG To: Syam Madanapalli In-Reply-To: <10e14db20511101107m50a5a9a5yb98f68454a97b8eb@mail.gmail.com> References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> <1131643445.12225.5.camel@localhost> <10e14db20511101024s3315ae60i96826163e8c7f8fb@mail.gmail.com> <1131648527.12225.22.camel@localhost> <10e14db20511101107m50a5a9a5yb98f68454a97b8eb@mail.gmail.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 11 Nov 2005 03:33:13 +0800 Message-Id: <1131651193.12230.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 On Fri, 2005-11-11 at 00:37 +0530, Syam Madanapalli wrote: > Hi, > > "Every problem in computer science can be solved by adding a level of > indirection." > -Kaufman > :). Sometimes adding a level of indirection IS THE solution. > I see your point. > What if the routing entry expires and does not know where to send. > And as you said it depends the implementation look up. Some may > look for P:: finds MR is the next hop, looks for Neigbhor cahce, may not > present and gives up. The foriegn network is delegating prefix to the MR. It is the responsibility of the foreign network to ensure the AR's routing table entry continues to be valid for as long as the prefix is delegated. Thus, unlikely for there to be a case where the routing entry has expired before the delegated prefix is expired. > > Tunnel look up may depends for /128 bit addresses and may be a good > idea to explicity associate a prefix to the tunnel like in NEMO Basic > Support. Of-course, I am just uncertain whether it is worth the effort to expand a protocol for this, especially when correctly implemented, the original mechanism works. Having said that, it might a good idea to wait until there is a clear prefix delegation mehcniam available at the foreign network. Because, in that case, the FMIP would most likely need to to be expanded anyway to to support the transfer of prefix from pAR to nAR, or to pre-delegate new prefix at nAR. HI and HIACK would most likely be needed to change as well. /rgds /cwng > On 11/11/05, Chan-Wah NG wrote: > > On Thu, 2005-11-10 at 23:54 +0530, Syam Madanapalli wrote: > > > > True, as I'd mentioned in my previous response to Thierry, when the MR > > > > is a nAR or pAR, the FMIP gets very inefficient, which might defeat the > > > > purpose of having FMIP at all. > > > > > > The scenario I mentioned is about FMIPv6 Client implementation on MR. > > > If PAR and NAR support on MRs is inefficient then one can choose not to > > > do that. > > > > > > > Opps, sorry. Still have not receovered from the change of time-zone, I > > guess :) Anyway, see comments in-line. > > > > > > > I see there is at least one scenario where the current FMIPv6 > > > > > may not be sufficient for session continuity for the nodes in the > > > > > Mobile Network when the MR is moving from Home Network. > > > > > > > > > > When MR is moving from Home Network it is required to > > > > > establish a tunnel from PAR to NAR for the Mobile Network > > > > > Prefixes along with the MR's pCoA (i.e. MR's HoA). > > > > > > > > > > Also we can think of optimization here as PAR and Nemo HA > > > > > may be on the same link and even may be on the same box, > > > > > so we can eliminate the tunnel between PAR and MR, and > > > > > establish the tunnel between Nemo HA and MR. This optimization > > > > > may require further analysis to check for other impacts. > > > > > > > > > Is this any different from a MIPv6 mobile host leaving its home network? > > I can't believe FMIP has not considered it. Anycase, should one send > > FBU to the router on its own home link when a BU is sufficient? Make no > > sense to do that. > > > > > > > The other scenario is where we may need updates to FMIPv6 is > > > > > when MR delegates any prefixes on a Foreign Network and moves > > > > > to another Foreign Network before the expiry of the prefixes > > > > > delegated on the previous link. > > > > Maybe, if we do have a mechanism for prefix delegation from foreign > > network. > > > > Even assuming we do have one, I don't see any problem here. It is an > > implementation consideration. Implemented correctly, it will work > > without any need for any changes for FMIP: > > > > (a) When MR is at pAR, it has CoA=MR.pCoA. In addition, it obtains > > prefix P from the foreign network. > > > > (b) pAR, should now know that packets sent to P should be routed to > > MR.pCoA > > > > (c) When MR moves to nAR, its send FBU to pAR, setting up a binding > > between MR.nCoA and MR.pCoA > > > > (d) When pAR receives a packet addressed to P, it routes the packet to > > MR.pCoA (just like (b)). To route packet to MR.pCoA, the next hop > > interface is the tunnel to MR.nCoA. So, packets sent to prefix P is > > correctly forwarded to MR.nCoA. > > > > /rgds > > /cwng > > > > > > > > > -- Chan-Wah NG Panasonic Singapore Labs From nemo-bounces@ietf.org Sat Nov 12 10:40:44 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 1EaxUi-0000kN-RA; Sat, 12 Nov 2005 10:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaxUh-0000kH-LN for nemo@megatron.ietf.org; Sat, 12 Nov 2005 10:40:43 -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 KAA08704 for ; Sat, 12 Nov 2005 10:40:14 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaxlL-0001Lh-UU for nemo@ietf.org; Sat, 12 Nov 2005 10:57:56 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 494E6C285 for ; Sat, 12 Nov 2005 10:40:32 -0500 (EST) 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 jACFeVGT021376; Sat, 12 Nov 2005 10:40:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jACFeUxV008491; Sat, 12 Nov 2005 10:40:31 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 04133-06; Sat, 12 Nov 2005 10:40:30 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jACFeT9G008482;Sat, 12 Nov 2005 10:40:29 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id B5E3334A3E; Sat, 12 Nov 2005 10:40:29 -0500 (EST) Received: from [192.168.2.30] (nolmstd-cadent1-68-71-111-134.clvdoh.adelphia.net [68.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid 76447349F4; Sat, 12 Nov 2005 10:40:15 -0500 (EST) Message-ID: <437511F1.2020208@grc.nasa.gov> Date: Fri, 11 Nov 2005 16:49:37 -0500 From: ivancic User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo X-Enigmail-Version: 0.92.0.0 OpenPGP: id=FC455475 Content-Type: text/plain; charset=windows-1252 X-imss-version: 2.034 X-imss-result: Passed X-imss-scores: Clean:11.86227 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.4 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: chanwah.ng@sg.panasonic.com Subject: [nemo] Route Optimization text X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org At the nemo working group meeting I indicated I would provide some text related to route optimization. I think this probably fits better in the route optimization problems statement draft than the analysis draft. I am certainly open for suggestions on text. Route Optimization Security Considerations rules and architectures. The security policy rules may require all traffic from the mobile node pass through the authoritative organization=92s firewalls and/or proxies in order to ensure proper control of all traffic. These rules may be in place to allow for deep packet inspection or ensure that IPsec only occurs between known approved and trusted entities. One means to ensure that all traffic passes through the authoritative organization=92s network is by forcing reverse-tunneling. Note reverse-tunneling disables route optimization. Will From nemo-bounces@ietf.org Sat Nov 12 10:40:46 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 1EaxUk-0000lo-9p; Sat, 12 Nov 2005 10:40:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaxUh-0000kM-Rr for nemo@megatron.ietf.org; Sat, 12 Nov 2005 10:40:45 -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 KAA08703 for ; Sat, 12 Nov 2005 10:40:14 -0500 (EST) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaxlL-0001Li-U2 for nemo@ietf.org; Sat, 12 Nov 2005 10:57:56 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 4A022C27E for ; Sat, 12 Nov 2005 10:40:32 -0500 (EST) 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 jACFeVGT021375; Sat, 12 Nov 2005 10:40:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jACFeUKH008492; Sat, 12 Nov 2005 10:40:31 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 20053-25; Sat, 12 Nov 2005 10:40:30 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jACFeTGH008483;Sat, 12 Nov 2005 10:40:29 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id BEC7534A3B; Sat, 12 Nov 2005 10:40:29 -0500 (EST) Received: from [192.168.2.30] (nolmstd-cadent1-68-71-111-134.clvdoh.adelphia.net [68.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid 5C90D349B9; Sat, 12 Nov 2005 10:39:58 -0500 (EST) Message-ID: <43760CC8.7050506@grc.nasa.gov> Date: Sat, 12 Nov 2005 10:39:52 -0500 From: ivancic User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo X-Enigmail-Version: 0.92.0.0 OpenPGP: id=FC455475 Content-Type: text/plain; charset=windows-1252 X-imss-version: 2.034 X-imss-result: Passed X-imss-scores: Clean:11.86227 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: chanwah.ng@sg.panasonic.com Subject: [nemo] Route Optimization text X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org At the nemo working group meeting I indicated I would provide some text related to route optimization. I think this probably fits better in the route optimization problems statement draft than the analysis draft. I am certainly open for suggestions on text. Route Optimization Security Considerations rules and architectures. The security policy rules may require all traffic from the mobile node pass through the authoritative organization=92s firewalls and/or proxies in order to ensure proper control of all traffic. These rules may be in place to allow for deep packet inspection or ensure that IPsec only occurs between known approved and trusted entities. One means to ensure that all traffic passes through the authoritative organization=92s network is by forcing reverse-tunneling. Note reverse-tunneling disables route optimization. Will From nemo-bounces@ietf.org Sun Nov 13 00:14:55 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 1EbACd-0007u7-PN; Sun, 13 Nov 2005 00:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbACc-0007u2-AU for nemo@megatron.ietf.org; Sun, 13 Nov 2005 00:14:54 -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 AAA13032 for ; Sun, 13 Nov 2005 00:14:24 -0500 (EST) 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 1EbATN-0005Zs-F0 for nemo@ietf.org; Sun, 13 Nov 2005 00:32:13 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 39C108AD12B; Sat, 12 Nov 2005 21:12:24 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22503-02; Sat, 12 Nov 2005 21:12:16 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 6E51A8AB99E; Sat, 12 Nov 2005 21:12:16 -0800 (PST) X-Spam-Score: -4.4 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 887428AB9D6; Sat, 12 Nov 2005 21:12:15 -0800 (PST) In-Reply-To: <20051110113142.007c77ef.ernst@sfc.wide.ad.jp> References: <200511092207.jA9M7quH098830@givry.rennes.enst-bretagne.fr> <43729A18.4030805@motorola.com> <20051110113142.007c77ef.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Issue A14 - e-face and i-face Date: Sat, 12 Nov 2005 21:14:29 -0800 To: Thierry Ernst X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit 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 On Nov 9, 2005, at 6:31 PM, Thierry Ernst wrote: > > I'm French and while I agree that in French or other languages we > might > be confused and pronounce 'e-face' when actually meaning 'i-face', I'm > much more confused when pronouning or earing "ingress" vs "egress" > which > seems to be a problem even for English speakers. When at the microphone, I hear speaker of other romantic languages (principally Spanish, French and Italian) pronouncing an American "E" when they mean their own "I". I don't see how this clears up the situation. > > So, the voice count so far is: > - no harm to keep i-face and e-face in the document as it can help: > Will, Thierry. > - remove > Ryuji, Nicolas, Francis, Masafumi, Christophe, Alexandru You can add my name and Romain's to the remove list. That's 8 to 2. > > There is a majority to remove, but I think it doesn't harm to keep > since > it also helps. I don't understand the reason to remove because it's an Four times as many people say it doesn't help. How do you reach this conclusion? > abbreaviation [i.,e. not a term per se], and the offical term remains > 'egrees interface' and'ingress interface'. But this is just my > point of > view and I will range behind the majority. Fair enough; remove it from the document and you can keep it as an abbreviation in your documents. Seriously, if there is a real problem of understanding what "egress" and "ingress" are that can't be cleared up by a trip to the English dictionary, then we should consider finding some new terms that are understandable and reasonable. But at this point, it would be impossible to go back and change all the documents that have already been written, so we're going to have to deal with ingress and egress for the time being. The abbreviations obfuscate things further, in my view, and at best are only abbreviating confusing terms... so let's just get rid of them for now, and figure out what to do for future versions of the doc. I think we've all spent enough time on this issue. TJ > > > Thierry > > > On Wed, 09 Nov 2005 16:53:44 -0800 > Alexandru Petrescu wrote: > >> Francis Dupont wrote: >>> In your previous mail you wrote: >>> >>> Can we have some comments from non-English speakers that think >>> i-face and e-face are easier to understand than ingress >>> interface and egress interface? This still seems awkward to me >>> -- I wouldn't know what e- face and i-face mean unless I go do >>> some research. >>> >>> => I agree with you and more, as in French the letter i is pronounce >>> exactly like the letter e in English this can become a nightmare in >>> its not written form! So I support TJ, PLEASE use ingress and egress >>> at least! >> >> Non-native English speaker here. >> >> I second that "e" vs "i" is difficult to distinguish, as a non-native >> French speaker too. >> >> BEsides, sounds to me like in English "e-face" is somebody with a >> face >> of e-shape. I'll acknowledge though that e-everything seems to be >> widely used. >> >> Alex > > > -- > 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 Mon Nov 14 11:47:52 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 1EbhUm-0005jj-HD; Mon, 14 Nov 2005 11:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhUk-0005j7-JD for nemo@megatron.ietf.org; Mon, 14 Nov 2005 11:47: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 LAA03755 for ; Mon, 14 Nov 2005 11:47:17 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebhln-0002hG-N8 for nemo@ietf.org; Mon, 14 Nov 2005 12:05:29 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAEH079M021598; Mon, 14 Nov 2005 10:00:07 -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 jAEGuugC019184; Mon, 14 Nov 2005 10:56:56 -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 BCE45865980; Mon, 14 Nov 2005 17:47:38 +0100 (CET) Message-ID: <4378BFAA.3030102@motorola.com> Date: Mon, 14 Nov 2005 17:47:38 +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: Syam Madanapalli Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> In-Reply-To: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Syam Madanapalli wrote: > Hi, > > I see there is at least one scenario where the current FMIPv6 may not > be sufficient for session continuity for the nodes in the Mobile > Network when the MR is moving from Home Network. > > When MR is moving from Home Network it is required to establish a > tunnel from PAR to NAR for the Mobile Network Prefixes along with the > MR's pCoA (i.e. MR's HoA). Is it "required"? It is sufficient for the PAR to establish a tunnel from PAR to NAR about the MR's pCoA and MR's nCoA, no need to establish a tunnel for each LFN's address (and not any address from that MNP), right? Because packets from HA to LFN are encapsulated to MR's CoA (not to LFN's address), so it is sufficient for PAR and NAR to deal with that MR's CoA and packets do arrive fast at LFN's HoA. > Also we can think of optimization here as PAR and Nemo HA may be on > the same link and even may be on the same box, so we can eliminate > the tunnel between PAR and MR, and establish the tunnel between Nemo > HA and MR. This optimization may require further analysis to check > for other impacts. If the NEMO HA is co-located with a PAR then it means that only one handover can happen fast: between home and the next AR; all the other handovers (between various ARs) will not benefit from this enhancement, right? > The other scenario is where we may need updates to FMIPv6 is when MR > delegates any prefixes on a Foreign Network and moves to another > Foreign Network before the expiry of the prefixes delegated on the > previous link. MR wouldn't delegate any prefix to the Foreign Network. Do you mean that the Foreign Network delegates prefixes to MR? > I think the problems in applying the FMIPv6 to NEMO are simple And > can be easily fixed, so it is good idea to include this in the > charter for known problems. I am writing a draft on this, I will let > you know when I done with it. Would it be possible to clarify a little bit more here before making it into a draft? Alex From nemo-bounces@ietf.org Tue Nov 15 00:06:44 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 1Ebt1o-0007b3-5p; Tue, 15 Nov 2005 00:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebt1n-0007aL-4K for nemo@megatron.ietf.org; Tue, 15 Nov 2005 00:06:43 -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 AAA29808 for ; Tue, 15 Nov 2005 00:06:10 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbtIw-0006GF-DN for nemo@ietf.org; Tue, 15 Nov 2005 00:24:28 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8D581EC8E7; Tue, 15 Nov 2005 14:06:14 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id E508FEC8E6; Tue, 15 Nov 2005 14:06:13 +0900 (JST) Received: from [IPv6:2001:200:601:200:5d85:17d2:c9e4:adc3] (unknown [IPv6:2001:200:601:200:5d85:17d2:c9e4:adc3]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 2F60C2E032; Tue, 15 Nov 2005 14:05:16 +0900 (JST) Message-ID: <43796DA7.3090507@kddilabs.jp> Date: Tue, 15 Nov 2005 14:09:59 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> In-Reply-To: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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, I apologize if this is a bit too late to give comments on this, but I belive this draft was silent for some time and so with an attempt to raise some discussion, here are the ones that concerns me. Issue A16: [VALIDATE B4 CLOSING 0510] NEMO-link vs mobile subnet/link Proposition: By Thierry 0410: Since we agreed to keep MNP instead of NEMO-prefix, I think it would be consistent to keep mobile subnet or mobile link instead of NEMO-link. Comments ? I agree with this. Not just keeping it consistent with MNP, the term NEMO-link is hard to grasp. I would suggent MNL as Mobile Network Link, however I don't see the term "NEMO-link" used in RFC 3963 so I don't know if we really need such term in the first place. Any comments ? Issue A23: [OPEN 0410] Keep nested and multihoming scenario in draft? Proposition: by Thierry: Nested and Multihomed Mobile Networks: is draft-ietf-nemo-terminology the right location to describe the two scenarios ? Yes. They are useful and are refered to by the RO drafts. Issue A22: [OPEN 0410] Add term for "Depth of a Nested-NEMO" Proposition: "Depth" may be useful to deal with Nested-NEMO Proposition: Please propose a clear definition This, I don't know. The RO drafts use "level of nesting" but I guess this is a bit different. It would be useful I guess when phrasing a MR at a specific nest level, like "A MR at depth 3". regards, watari On 2005/10/28 15:51, Thierry Ernst wrote: > 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 Tue Nov 15 00:20:32 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 1EbtFA-0003U5-2M; Tue, 15 Nov 2005 00:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtF8-0003Ty-0b for nemo@megatron.ietf.org; Tue, 15 Nov 2005 00:20:30 -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 AAA00527 for ; Tue, 15 Nov 2005 00:19:57 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbtWH-0006gY-MX for nemo@ietf.org; Tue, 15 Nov 2005 00:38:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 81F6FEC8E1; Tue, 15 Nov 2005 14:20:19 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 31465EC8DF; Tue, 15 Nov 2005 14:20:19 +0900 (JST) Received: from [IPv6:2001:200:601:200:5d85:17d2:c9e4:adc3] (unknown [IPv6:2001:200:601:200:5d85:17d2:c9e4:adc3]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 64B672E032; Tue, 15 Nov 2005 14:19:21 +0900 (JST) Message-ID: <437970F4.5090906@kddilabs.jp> Date: Tue, 15 Nov 2005 14:24:04 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ivancic Subject: Re: [nemo] Route Optimization text References: <437511F1.2020208@grc.nasa.gov> In-Reply-To: <437511F1.2020208@grc.nasa.gov> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: nemo , chanwah.ng@sg.panasonic.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, On 2005/11/12 6:49, ivancic wrote: > At the nemo working group meeting I indicated I would provide some text > related to route optimization. I think this probably fits better in the > route optimization problems statement draft than the analysis draft. I > am certainly open for suggestions on text. >=20 >=20 > Route Optimization Security Considerations >=20 > rules and architectures. The security policy rules may require all > traffic from the mobile node pass through the authoritative > organization=92s firewalls and/or proxies in order to ensure proper > control of all traffic. These rules may be in place to allow for deep > packet inspection or ensure that IPsec only occurs between known > approved and trusted entities. One means to ensure that all traffic > passes through the authoritative organization=92s network is by forcing > reverse-tunneling. Note reverse-tunneling disables route optimization. The last sentence is not always true. There is no clear definition of what route optimization is for NEMO. As we have with the RO problem statement draft, RO can be something like decreasing the number of HAs to go through when the NEMO is nested. Anyway, what you've addressed seems to fit what we already have for Section 2.5 of the problem statement draft. Is the text not sufficient? watari From nemo-bounces@ietf.org Tue Nov 15 15:24:25 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 1Ec7Lt-0001rN-0S; Tue, 15 Nov 2005 15:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7Lq-0001r7-U6 for nemo@megatron.ietf.org; Tue, 15 Nov 2005 15:24:23 -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 PAA24032 for ; Tue, 15 Nov 2005 15:23:50 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7d8-0002AH-Ac for nemo@ietf.org; Tue, 15 Nov 2005 15:42:15 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 936D5C2EB for ; Tue, 15 Nov 2005 15:24:05 -0500 (EST) 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 jAFKO4GT029668; Tue, 15 Nov 2005 15:24:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jAFKNkxl007615; Tue, 15 Nov 2005 15:23:56 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 04258-08; Tue, 15 Nov 2005 15:23:46 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id jAFKNZpc007488;Tue, 15 Nov 2005 15:23:35 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 6D28C34B32; Tue, 15 Nov 2005 15:23:35 -0500 (EST) Received: from [192.168.2.30] (nolmstd-cadent1-68-71-111-134.clvdoh.adelphia.net [68.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid AE49734B29; Tue, 15 Nov 2005 15:23:03 -0500 (EST) Message-ID: <437A43A9.802@grc.nasa.gov> Date: Tue, 15 Nov 2005 15:23:05 -0500 From: ivancic User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Route Optimization text References: <437511F1.2020208@grc.nasa.gov> <437970F4.5090906@kddilabs.jp> In-Reply-To: <437970F4.5090906@kddilabs.jp> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=FC455475 Content-Type: text/plain; charset=windows-1252 X-imss-version: 2.034 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:2 R:2 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: nemo , chanwah.ng@sg.panasonic.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Section 2.5 is similar, but not the same Section 2.5 is "Security Policy Prohibiting Traffic From Visiting Nodes" and indicates nesting of unauthorized visiting nodes may not be permitted. The statement below in two fold. First, a corresponding node outside the authoritative organization's (corporate) network may not be permitted to initiate the communication due to policy and proxies. =20 Second, bidirectional tunneling (i.e. reverse tunneling) prohibits route optimization between a corresponding node and the mobile network. So, perhaps the text should be worded as follows: 2.X Route Optimization Security Considerations The security policy rules may require all traffic from the mobile node pass through the authoritative organization=92s firewalls and/or proxies in order to ensure proper control of all traffic. These rules may be in place to allow for deep packet inspection or ensure that IPsec only occurs between known approved and trusted entities. One means to ensure that all traffic passes through the authoritative organization=92s networ= k is by forcing bidirectional tunneling (i.e. reverse-tunneling) which is the only option in NEMO basic (RFC 3963). Note bidirectional-tunneling disables route optimization between corresponding nodes and the mobile network. Will ****************************** William D. Ivancic Masafumi Watari wrote: > Hello, > > On 2005/11/12 6:49, ivancic wrote: > >> At the nemo working group meeting I indicated I would provide some tex= t >> related to route optimization. I think this probably fits better in th= e >> route optimization problems statement draft than the analysis draft. I >> am certainly open for suggestions on text. >> >> >> Route Optimization Security Considerations >> >> rules and architectures. The security policy rules may require all >> traffic from the mobile node pass through the authoritative >> organization=92s firewalls and/or proxies in order to ensure proper >> control of all traffic. These rules may be in place to allow for deep >> packet inspection or ensure that IPsec only occurs between known >> approved and trusted entities. One means to ensure that all traffic >> passes through the authoritative organization=92s network is by forcin= g >> reverse-tunneling. Note reverse-tunneling disables route optimization. > > > The last sentence is not always true. There is no clear definition of > what route optimization is for NEMO. As we have with the RO problem > statement draft, RO can be something like decreasing the number of HAs > to go through when the NEMO is nested. > > Anyway, what you've addressed seems to fit what we already have for > Section 2.5 of the problem statement draft. Is the text not sufficient= ? > > watari > > From nemo-bounces@ietf.org Tue Nov 15 22:54:09 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 1EcEN7-00085V-3l; Tue, 15 Nov 2005 22:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcEN3-000859-HQ for nemo@megatron.ietf.org; Tue, 15 Nov 2005 22:54:05 -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 WAA25898 for ; Tue, 15 Nov 2005 22:53:32 -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 1EcEeP-0000yC-Nr for nemo@ietf.org; Tue, 15 Nov 2005 23:12:02 -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 jAG3rflp010106; Wed, 16 Nov 2005 12:53:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jAG3rh415673; Wed, 16 Nov 2005 12:53:43 +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 jAG3rfw19502; Wed, 16 Nov 2005 12:53:41 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 11:50:39 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 3C08ED560C; Wed, 16 Nov 2005 12:00:12 +0800 (SGT) Subject: Re: [nemo] Route Optimization text From: Chan-Wah Ng To: ivancic In-Reply-To: <437A43A9.802@grc.nasa.gov> References: <437511F1.2020208@grc.nasa.gov> <437970F4.5090906@kddilabs.jp> <437A43A9.802@grc.nasa.gov> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 12:00:12 +0800 Message-Id: <1132113612.26013.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 16 Nov 2005 03:50:39.0636 (UTC) FILETIME=[E8F99D40:01C5EA60] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable 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 William, Thanks for the text. I am, however, unsure where the text should be placed. Your text seems to suggest that the organization has policy that disallow RO for MNN, because the organization wishes to enforce the rule that all traffic into or out of the NEMO be inspected by the organization firewall. This is as opposed to Section 2.5, which only says that such security policy is preventing VMN's traffic. For Section 2.5, it is a motivation for deploying RO, Because with certain types of RO, it is conceivable that the VMN's traffic need not pass through the firewall in the MR's home network. My opinion is that the text below is a consideration for NEMO RO solution. However, it is not a problem statement for NEMO-RO. SO, I would be more inclined to place this text somewhere in Section 4 of nemo-ro-space-analysis draft rather than nemo-ro-problem-statement draft. Do you agree? /rgds /cwng On Tue, 2005-11-15 at 15:23 -0500, ivancic wrote: > Section 2.5 is similar, but not the same Section 2.5 is "Security > Policy Prohibiting Traffic From Visiting Nodes" and indicates nesting of > unauthorized visiting nodes may not be permitted. >=20 > The statement below in two fold. First, a corresponding node outside > the authoritative organization's (corporate) network may not be > permitted to initiate the communication due to policy and proxies. =20 > Second, bidirectional tunneling (i.e. reverse tunneling) prohibits route > optimization between a corresponding node and the mobile network. So, > perhaps the text should be worded as follows: >=20 > 2.X Route Optimization Security Considerations >=20 > The security policy rules may require all traffic from the mobile node > pass through the authoritative organization=E2=80=99s firewalls and/or pr= oxies > in order to ensure proper control of all traffic. These rules may be in > place to allow for deep packet inspection or ensure that IPsec only > occurs between known approved and trusted entities. One means to ensure > that all traffic passes through the authoritative organization=E2=80=99s = network > is by forcing bidirectional tunneling (i.e. reverse-tunneling) which is > the only option in NEMO basic (RFC 3963). Note bidirectional-tunneling > disables route optimization between corresponding nodes and the mobile > network. >=20 > Will >=20 > ****************************** > William D. Ivancic >=20 >=20 >=20 >=20 > Masafumi Watari wrote: >=20 > > Hello, > > > > On 2005/11/12 6:49, ivancic wrote: > > > >> At the nemo working group meeting I indicated I would provide some tex= t > >> related to route optimization. I think this probably fits better in th= e > >> route optimization problems statement draft than the analysis draft. I > >> am certainly open for suggestions on text. > >> > >> > >> Route Optimization Security Considerations > >> > >> rules and architectures. The security policy rules may require all > >> traffic from the mobile node pass through the authoritative > >> organization=E2=80=99s firewalls and/or proxies in order to ensure pro= per > >> control of all traffic. These rules may be in place to allow for deep > >> packet inspection or ensure that IPsec only occurs between known > >> approved and trusted entities. One means to ensure that all traffic > >> passes through the authoritative organization=E2=80=99s network is by = forcing > >> reverse-tunneling. Note reverse-tunneling disables route optimization. > > > > > > The last sentence is not always true. There is no clear definition of > > what route optimization is for NEMO. As we have with the RO problem > > statement draft, RO can be something like decreasing the number of HAs > > to go through when the NEMO is nested. > > > > Anyway, what you've addressed seems to fit what we already have for > > Section 2.5 of the problem statement draft. Is the text not sufficient= ? > > > > watari > > > > >=20 From nemo-bounces@ietf.org Tue Nov 15 23:35:36 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 1EcF1E-0002cD-Hv; Tue, 15 Nov 2005 23:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcF1C-0002aS-A9 for nemo@megatron.ietf.org; Tue, 15 Nov 2005 23:35:34 -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 XAA27997 for ; Tue, 15 Nov 2005 23:35:01 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcFIY-00022D-Aa for nemo@ietf.org; Tue, 15 Nov 2005 23:53:31 -0500 Received: by wproxy.gmail.com with SMTP id i12so40240wra for ; Tue, 15 Nov 2005 20:35:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gizjiiORmx1z3wSVtV+NQPHVUYSfXmkad3YEROZJ0Hblihjm+o0yOTVCRbIZrZn1/NM6CXdb+q+Us+kjMYykGKCEut/zZ3y0gBF53TPZ0uy2BKNyP55GPdGBgc9vCbz1FnfKy67t7b1a2+tKVhAUxtkAiWfqRSoET+HDoLfzoxk= Received: by 10.65.197.18 with SMTP id z18mr4714109qbp; Tue, 15 Nov 2005 20:35:31 -0800 (PST) Received: by 10.64.21.10 with HTTP; Tue, 15 Nov 2005 20:35:31 -0800 (PST) Message-ID: <10e14db20511152035s3b6f384ehf6b04b8250368a96@mail.gmail.com> Date: Wed, 16 Nov 2005 10:05:31 +0530 From: Syam Madanapalli To: Alexandru Petrescu Subject: Re: [nemo] Rechartering: FMIPv6 for NEMO In-Reply-To: <4378BFAA.3030102@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10e14db20511100642k5c23e41bp262dc3a9c9db3c01@mail.gmail.com> <4378BFAA.3030102@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Hi Alex, > > > > I see there is at least one scenario where the current FMIPv6 may not > > be sufficient for session continuity for the nodes in the Mobile > > Network when the MR is moving from Home Network. > > > > When MR is moving from Home Network it is required to establish a > > tunnel from PAR to NAR for the Mobile Network Prefixes along with the > > MR's pCoA (i.e. MR's HoA). > > Is it "required"? It is sufficient for the PAR to establish a tunnel > from PAR to NAR about the MR's pCoA and MR's nCoA, no need to establish > a tunnel for each LFN's address (and not any address from that MNP), righ= t? > > Because packets from HA to LFN are encapsulated to MR's CoA (not to > LFN's address), so it is sufficient for PAR and NAR to deal with that > MR's CoA and packets do arrive fast at LFN's HoA. The scenario I was talking about is when MR is moving from Home Network (HN) to Foreign Network (FN). Even in this scenario, if implemented correctly i.e. PAR looks up the routi= ng for the packet destined to an LFN, finds that next-hop is MR, and then it m= ust find that any packet destined to MR needs to be tunneled to MR's NCoA, then there is no problem in applying FMIP. I > > > Also we can think of optimization here as PAR and Nemo HA may be on > > the same link and even may be on the same box, so we can eliminate > > the tunnel between PAR and MR, and establish the tunnel between Nemo > > HA and MR. This optimization may require further analysis to check > > for other impacts. > > If the NEMO HA is co-located with a PAR then it means that only one > handover can happen fast: between home and the next AR; all the other > handovers (between various ARs) will not benefit from this enhancement, > right? That's right. Also if HA and AR are the same link we can apply this but one may loose some packets that might have already arrived at AR. I think in most cases, the movement between HN and FN happens frequently than FN to FN. > > > The other scenario is where we may need updates to FMIPv6 is when MR > > delegates any prefixes on a Foreign Network and moves to another > > Foreign Network before the expiry of the prefixes delegated on the > > previous link. > > MR wouldn't delegate any prefix to the Foreign Network. Do you mean > that the Foreign Network delegates prefixes to MR? Yes Thanks, Syam From nemo-bounces@ietf.org Wed Nov 16 06:44:13 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 1EcLi1-00048J-US; Wed, 16 Nov 2005 06:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcLhz-00048B-EY for nemo@megatron.ietf.org; Wed, 16 Nov 2005 06:44:11 -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 GAA18944 for ; Wed, 16 Nov 2005 06:43:37 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcLzN-0004u0-KJ for nemo@ietf.org; Wed, 16 Nov 2005 07:02:12 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0753AEC833; Wed, 16 Nov 2005 20:43:36 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 3B87CEC829; Wed, 16 Nov 2005 20:43:35 +0900 (JST) Received: from [IPv6:2001:200:601:200:cd27:a296:f51f:5764] (unknown [IPv6:2001:200:601:200:cd27:a296:f51f:5764]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id A10A12E032; Wed, 16 Nov 2005 20:42:30 +0900 (JST) Message-ID: <437B1C42.8090209@kddilabs.jp> Date: Wed, 16 Nov 2005 20:47:14 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Route Optimization text References: <437511F1.2020208@grc.nasa.gov> <437970F4.5090906@kddilabs.jp> <437A43A9.802@grc.nasa.gov> <1132113612.26013.11.camel@localhost> In-Reply-To: <1132113612.26013.11.camel@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: nemo , ivancic X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org So this is like a tradeoff of having RO or being able control traffic through the HA. I'm not seeing the whole picture yet, but is this something specific to NEMO or the same with MIP6? If it's something specific to NEMO, I'd agree it would go in the analysis draft, probably in Section 4.8 where we discuss security concerns. However, again, the use of MRHA tunnel can still provide optimization as done by RRH, by decreasing the number of HAs on the path. regards, watari On 2005/11/16 13:00, Chan-Wah Ng wrote: > Hello William, >=20 > Thanks for the text. I am, however, unsure where the text should be > placed. >=20 > Your text seems to suggest that the organization has policy that > disallow RO for MNN, because the organization wishes to enforce the rul= e > that all traffic into or out of the NEMO be inspected by the > organization firewall. >=20 > This is as opposed to Section 2.5, which only says that such security > policy is preventing VMN's traffic. For Section 2.5, it is a motivatio= n > for deploying RO, Because with certain types of RO, it is conceivable > that the VMN's traffic need not pass through the firewall in the MR's > home network. >=20 > My opinion is that the text below is a consideration for NEMO RO > solution. However, it is not a problem statement for NEMO-RO. SO, I > would be more inclined to place this text somewhere in Section 4 of > nemo-ro-space-analysis draft rather than nemo-ro-problem-statement > draft. >=20 > Do you agree? >=20 > /rgds > /cwng >=20 >=20 > On Tue, 2005-11-15 at 15:23 -0500, ivancic wrote: >=20 >>Section 2.5 is similar, but not the same Section 2.5 is "Security >>Policy Prohibiting Traffic From Visiting Nodes" and indicates nesting o= f >>unauthorized visiting nodes may not be permitted. >> >>The statement below in two fold. First, a corresponding node outside >>the authoritative organization's (corporate) network may not be >>permitted to initiate the communication due to policy and proxies. =20 >>Second, bidirectional tunneling (i.e. reverse tunneling) prohibits rout= e >>optimization between a corresponding node and the mobile network. So, >>perhaps the text should be worded as follows: >> >>2.X Route Optimization Security Considerations >> >>The security policy rules may require all traffic from the mobile node >>pass through the authoritative organization=92s firewalls and/or proxie= s >>in order to ensure proper control of all traffic. These rules may be in >>place to allow for deep packet inspection or ensure that IPsec only >>occurs between known approved and trusted entities. One means to ensure >>that all traffic passes through the authoritative organization=92s netw= ork >>is by forcing bidirectional tunneling (i.e. reverse-tunneling) which is >>the only option in NEMO basic (RFC 3963). Note bidirectional-tunneling >>disables route optimization between corresponding nodes and the mobile >>network. >> >>Will >> >>****************************** >>William D. Ivancic >> >> >> >> >>Masafumi Watari wrote: >> >> >>>Hello, >>> >>>On 2005/11/12 6:49, ivancic wrote: >>> >>> >>>>At the nemo working group meeting I indicated I would provide some te= xt >>>>related to route optimization. I think this probably fits better in t= he >>>>route optimization problems statement draft than the analysis draft. = I >>>>am certainly open for suggestions on text. >>>> >>>> >>>>Route Optimization Security Considerations >>>> >>>>rules and architectures. The security policy rules may require all >>>>traffic from the mobile node pass through the authoritative >>>>organization=92s firewalls and/or proxies in order to ensure proper >>>>control of all traffic. These rules may be in place to allow for deep >>>>packet inspection or ensure that IPsec only occurs between known >>>>approved and trusted entities. One means to ensure that all traffic >>>>passes through the authoritative organization=92s network is by forci= ng >>>>reverse-tunneling. Note reverse-tunneling disables route optimization= . >>> >>> >>>The last sentence is not always true. There is no clear definition of >>>what route optimization is for NEMO. As we have with the RO problem >>>statement draft, RO can be something like decreasing the number of HAs >>>to go through when the NEMO is nested. >>> >>>Anyway, what you've addressed seems to fit what we already have for >>>Section 2.5 of the problem statement draft. Is the text not sufficien= t? >>> >>>watari >>> >>> >> > From nemo-bounces@ietf.org Wed Nov 16 12:35:50 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 1EcRCI-0007su-8e; Wed, 16 Nov 2005 12:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRCH-0007so-8h for nemo@megatron.ietf.org; Wed, 16 Nov 2005 12:35:49 -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 MAA12089 for ; Wed, 16 Nov 2005 12:35:15 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcRTj-0001V8-WC for nemo@ietf.org; Wed, 16 Nov 2005 12:53:53 -0500 Received: from venus.office (chiba.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 79A44150C9 for ; Wed, 16 Nov 2005 18:35:38 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 18:35:38 +0100 Message-ID: Thread-Topic: Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQ From: "Roberto Baldessari" To: "nemo" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: [nemo] Distributing the Mobile Prefix in the visited network X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I'm new of this mailing list. I have a question related to the Basic NEMO Protocol. The RFC says: " A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network) " How should this be inteded? In case a MR distributes the Mobile Prefix in the visited network, in a way that the Mobile Network is routable directly from the visited network, is the MR non-standard? Thanks in advance. Roberto =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Roberto Baldessari Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-67 Fax: +49 (0)6221 90511-55 e-mail: roberto.baldessari@netlab.nec.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 From nemo-bounces@ietf.org Wed Nov 16 12:49:45 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 1EcRPl-0002o4-CN; Wed, 16 Nov 2005 12:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRPk-0002nu-LE for nemo@megatron.ietf.org; Wed, 16 Nov 2005 12:49:44 -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 MAA12923 for ; Wed, 16 Nov 2005 12:49:10 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcRhD-00020B-Bs for nemo@ietf.org; Wed, 16 Nov 2005 13:07:48 -0500 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 jAGHnHs03534; Wed, 16 Nov 2005 18:49:17 +0100 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 jAGHnHRO052606; Wed, 16 Nov 2005 18:49:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511161749.jAGHnHRO052606@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Roberto Baldessari" Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network In-reply-to: Your message of Wed, 16 Nov 2005 18:35:38 +0100. Date: Wed, 16 Nov 2005 18:49:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 In your previous mail you wrote: I have a question related to the Basic NEMO Protocol. The RFC says: " A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network) " How should this be inteded? => I can see two reasons for this constraint: - security: all the traffic for the Mobile Network is assumed to come through the HA-MR tunnel, in particular it always goes through the MR - handoff survivability: the short path has to be dismount when the MR leaves the visited network. In fact, this is simply a special case of Routing Optimization which is still in design and will address these two issues. Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Thu Nov 17 04:52:20 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 1EcgRH-0004EW-Uz; Thu, 17 Nov 2005 04:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgRF-0004EN-Pq for nemo@megatron.ietf.org; Thu, 17 Nov 2005 04:52:17 -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 EAA10226 for ; Thu, 17 Nov 2005 04:51:44 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecgip-0002V1-Vu for nemo@ietf.org; Thu, 17 Nov 2005 05:10:30 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 558344C5CC for ; Thu, 17 Nov 2005 18:51:43 +0900 (JST) Date: Thu, 17 Nov 2005 18:51:34 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20051117185134.544451e2.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Sub-optimal 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 My take on this issue: 1. I would like to add the agreed term in draft terminology. I've added an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ 2. Several terms have been listed and here is my summary: - sub-optimal routing: very generic - triangular / dog-leg routing: very specific (MIP6 scenario) - multi-angular - pin-ball routing is inappropriate - telescopic: why not periscope ? ;-) - nested-tunnel I think that: - if no term is required to describe what happen in a nested NEMO, we should stick to something generic i.e. "sub-optimal routing". If we what something in line with the term usually used in MIP6 scenario (triangular), I would vote for "multi-angular". If we need something that doesn't describe what happens to the route, but rather to the tunnel inefficiencies, I would vote for "nested tunnel". On the overall, I would vote for "multi-angular" and if needed I would add a 2nd term "nested tunnels". For a 1st April RFC, I would vote for "Periscope" ;-) Thierry. On Tue, 8 Nov 2005 17:27:05 +0100 "Pascal Thubert \(pthubert\)" wrote: > > > >-----Original Message----- > >From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] > >Sent: Tuesday, November 08, 2005 5:08 PM > >To: Pascal Thubert (pthubert) > >Cc: Alexandru Petrescu; Masafumi Watari; IETF NEMO WG; T.J. Kniveton > >Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D > ACTION:draft-ietf-nemo-ro-problem- > >statement-01.txt) > > > > > >Pascal Thubert (pthubert) wrote: > >> There is a topological view, where pinball routing and > >multi-angular > are > >> contenders, and there is a tunnel view, for which we'd need a term > like > >> telescopic or something. Any idea? > >> > > > >Hi, > > > >Is the term "nested tunnels" not the one we used to use? > [] Yes, it is. > > But that term, like suboptimal, is very generic. > > Now we are considering RO and finding more specific terms which would > be more uniquely associated to our problem would be nice, but if we > don't, I agree we have a default. > > It could be also useful to distinguish when one side ends multiple > layers of tunneling, like a HA does if you form a nested structure of > MRs that depend on that same HA. > > Any idea? > > Pascal From nemo-bounces@ietf.org Thu Nov 17 05:06:01 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 1EcgeX-0007Ip-RZ; Thu, 17 Nov 2005 05:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgeW-0007Ij-8X for nemo@megatron.ietf.org; Thu, 17 Nov 2005 05:06:00 -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 FAA10905 for ; Thu, 17 Nov 2005 05:05:26 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecgw5-0002xE-Kh for nemo@ietf.org; Thu, 17 Nov 2005 05:24:13 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2005 02:05:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,340,1125903600"; d="scan'208"; a="15399923:sNHT22443520" Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAHA5Ulx015906; Thu, 17 Nov 2005 05:05:45 -0500 (EST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Nov 2005 11:05:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Sub-optimal Terminology Date: Thu, 17 Nov 2005 11:05:17 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC017D13C0@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Sub-optimal Terminology Thread-Index: AcXrXO5I7LkiKqqcRJaiingaMxuO1gAAWqVQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "ml-nemo" X-OriginalArrivalTime: 17 Nov 2005 10:05:21.0136 (UTC) FILETIME=[6B680700:01C5EB5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Thierry: Note that there's a word for multiangular, I think it's polygone :) Pascam >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst >Sent: Thursday, November 17, 2005 10:52 AM >To: ml-nemo >Subject: [nemo] Re: Sub-optimal Terminology > > > >My take on this issue: > >1. I would like to add the agreed term in draft terminology. I've added >an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ > >2. Several terms have been listed and here is my summary: > >- sub-optimal routing: very generic >- triangular / dog-leg routing: very specific (MIP6 scenario) >- multi-angular >- pin-ball routing is inappropriate >- telescopic: why not periscope ? ;-) >- nested-tunnel > >I think that: >- if no term is required to describe what happen in a nested NEMO, we >should stick to something generic i.e. "sub-optimal routing". If we what >something in line with the term usually used in MIP6 scenario >(triangular), I would vote for "multi-angular". If we need something >that doesn't describe what happens to the route, but rather to the >tunnel inefficiencies, I would vote for "nested tunnel". > >On the overall, I would vote for "multi-angular" and if needed I would >add a 2nd term "nested tunnels". > >For a 1st April RFC, I would vote for "Periscope" ;-) >Thierry. > > > > > > > >On Tue, 8 Nov 2005 17:27:05 +0100 >"Pascal Thubert \(pthubert\)" wrote: > >> >> >> >-----Original Message----- >> >From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] >> >Sent: Tuesday, November 08, 2005 5:08 PM >> >To: Pascal Thubert (pthubert) >> >Cc: Alexandru Petrescu; Masafumi Watari; IETF NEMO WG; T.J. Kniveton >> >Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D >> ACTION:draft-ietf-nemo-ro-problem- >> >statement-01.txt) >> > >> > >> >Pascal Thubert (pthubert) wrote: >> >> There is a topological view, where pinball routing and >> >multi-angular >> are >> >> contenders, and there is a tunnel view, for which we'd need a term >> like >> >> telescopic or something. Any idea? >> >> >> > >> >Hi, >> > >> >Is the term "nested tunnels" not the one we used to use? >> [] Yes, it is. >> >> But that term, like suboptimal, is very generic. >> >> Now we are considering RO and finding more specific terms which would >> be more uniquely associated to our problem would be nice, but if we >> don't, I agree we have a default. >> >> It could be also useful to distinguish when one side ends multiple >> layers of tunneling, like a HA does if you form a nested structure of >> MRs that depend on that same HA. >> >> Any idea? >> >> Pascal From nemo-bounces@ietf.org Thu Nov 17 05:15:00 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 1EcgnE-0000Ux-PL; Thu, 17 Nov 2005 05:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgnC-0000Uj-O7 for nemo@megatron.ietf.org; Thu, 17 Nov 2005 05:14:58 -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 FAA11458 for ; Thu, 17 Nov 2005 05:14:25 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ech4n-0003GH-L5 for nemo@ietf.org; Thu, 17 Nov 2005 05:33:11 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 68A674CBA1 for ; Thu, 17 Nov 2005 19:14:47 +0900 (JST) Date: Thu, 17 Nov 2005 19:14:48 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology Message-Id: <20051117191448.461c9854.ernst@sfc.wide.ad.jp> In-Reply-To: <43796DA7.3090507@kddilabs.jp> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <43796DA7.3090507@kddilabs.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: b7b9551d71acde901886cc48bfc088a6 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 Watari, Thanks for your feedback on this. > I apologize if this is a bit too late to give comments on this, but > I belive this draft was silent for some time and so with an attempt to > raise some discussion, here are the ones that concerns me. > > Issue A16: [VALIDATE B4 CLOSING 0510] NEMO-link vs mobile > subnet/link Proposition: By Thierry 0410: Since we agreed to keep > MNP instead of NEMO-prefix, I think it would be consistent to keep > mobile subnet or mobile link instead of NEMO-link. Comments ? > > I agree with this. Not just keeping it consistent with MNP, the term > NEMO-link is hard to grasp. I would suggent MNL as Mobile Network > Link, however I don't see the term "NEMO-link" used in RFC 3963 > so I don't know if we really need such term in the first place. > Any comments ? What I didn't like in the term "MNP" is the wording "mobile network" (many people are still confused with cellular networks for mobile devices), but since we agreed to keep MNP, MNL would make sense, but it's easily misstyped to MNP ... So, let's not introduce new term, either we use NEMO-link or mobile-subnet (mobile-link should be disqualified because a NEMO can be made of severals links). Is anyone ever seen NEMO-link used in IETF documents ? If not, let's remove it. > Issue A23: [OPEN 0410] Keep nested and multihoming scenario in > draft? Proposition: by Thierry: Nested and Multihomed Mobile > Networks: is draft-ietf-nemo-terminology the right location to > describe the two scenarios ? > > Yes. They are useful and are refered to by the RO drafts. OK, conclusion is "keep". > Issue A22: [OPEN 0410] Add term for "Depth of a Nested-NEMO" > Proposition: "Depth" may be useful to deal with Nested-NEMO > Proposition: Please propose a clear definition > > This, I don't know. The RO drafts use "level of nesting" but I guess > this is a bit different. It would be useful I guess when phrasing > a MR at a specific nest level, like "A MR at depth 3". I think "level of nesting" and "depth" are the same. I think "depth" may be better. We could say: Depth: indicates the number of sub-MRs a packet as to cross between a MNN and the root-MR. But, this is tricky: a NEMO multihomed behind several root-MRs may be a different depths according to the exit root-MR used by the packet. On the overall, I'm quite in favor of adding it if the word is used in some documents like the RO drafts. Will you use "depth" with the above definition ? One thing you didn't mention Watari: In draft-ietf-nemo-ro-space-analysis-01 section 1.0 it is written: "the term "Route Optimization" is accepted in a broader sense than already defined for IPv6 Host Mobility in [3], to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node." If everyone agree, I would like to add in draft-terminology the following term (it was discussed in slide 7 of my presentation in Vancouver): Routing Optimization: Refers to any approach that optimizes the transmission of packets between a MNN and a CN Thierry. > > From nemo-bounces@ietf.org Thu Nov 17 05:17:42 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 1Ecgpq-0001bm-3h; Thu, 17 Nov 2005 05:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgpo-0001bf-5C for nemo@megatron.ietf.org; Thu, 17 Nov 2005 05:17:40 -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 FAA11638 for ; Thu, 17 Nov 2005 05:17:06 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ech7P-0003MD-Ch for nemo@ietf.org; Thu, 17 Nov 2005 05:35:53 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id jAHAQ9lY029440; Thu, 17 Nov 2005 03:26:09 -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 jAHARckd027334; Thu, 17 Nov 2005 04:27:39 -0600 (CST) Received: from [10.161.201.129] (zfr01-2129.crm.mot.com [10.161.201.129]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D40FF865980; Thu, 17 Nov 2005 11:17:26 +0100 (CET) Message-ID: <437C58B5.6040104@motorola.com> Date: Thu, 17 Nov 2005 11:17:25 +0100 From: Christophe Janneteau User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> In-Reply-To: <20051117185134.544451e2.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit 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 I agree with Thierry. We can always use the term sub-optimal routing whenever needed. But it also makes sense to have more specific terms for characterizing the sub-optimality: o for routing: I vote for "multi-angular", which makes more sense to me than the dog-leg, pin-ball, or telescopic terms etc... o for the tunnels: "nested tunnels" has my vote. BTW, I think those two terms have been already used by many people in the past, and we (NEMO community) somehow get used to them now :) Christophe. Thierry Ernst wrote: > > My take on this issue: > > 1. I would like to add the agreed term in draft terminology. I've added > an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ > > 2. Several terms have been listed and here is my summary: > > - sub-optimal routing: very generic > - triangular / dog-leg routing: very specific (MIP6 scenario) > - multi-angular > - pin-ball routing is inappropriate > - telescopic: why not periscope ? ;-) > - nested-tunnel > > I think that: > - if no term is required to describe what happen in a nested NEMO, we > should stick to something generic i.e. "sub-optimal routing". If we what > something in line with the term usually used in MIP6 scenario > (triangular), I would vote for "multi-angular". If we need something > that doesn't describe what happens to the route, but rather to the > tunnel inefficiencies, I would vote for "nested tunnel". > > On the overall, I would vote for "multi-angular" and if needed I would > add a 2nd term "nested tunnels". > > For a 1st April RFC, I would vote for "Periscope" ;-) > Thierry. > > > > > > > > On Tue, 8 Nov 2005 17:27:05 +0100 > "Pascal Thubert \(pthubert\)" wrote: > >> >>> -----Original Message----- >>> From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] >>> Sent: Tuesday, November 08, 2005 5:08 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Alexandru Petrescu; Masafumi Watari; IETF NEMO WG; T.J. Kniveton >>> Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D >> ACTION:draft-ietf-nemo-ro-problem- >>> statement-01.txt) >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> There is a topological view, where pinball routing and >>> multi-angular >> are >>>> contenders, and there is a tunnel view, for which we'd need a term >> like >>>> telescopic or something. Any idea? >>>> >>> Hi, >>> >>> Is the term "nested tunnels" not the one we used to use? >> [] Yes, it is. >> >> But that term, like suboptimal, is very generic. >> >> Now we are considering RO and finding more specific terms which would >> be more uniquely associated to our problem would be nice, but if we >> don't, I agree we have a default. >> >> It could be also useful to distinguish when one side ends multiple >> layers of tunneling, like a HA does if you form a nested structure of >> MRs that depend on that same HA. >> >> Any idea? >> >> Pascal > > From nemo-bounces@ietf.org Thu Nov 17 05:28:11 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 1Ecgzz-0006w3-H7; Thu, 17 Nov 2005 05:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgzx-0006vy-Uj for nemo@megatron.ietf.org; Thu, 17 Nov 2005 05:28:09 -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 FAA12097 for ; Thu, 17 Nov 2005 05:27:36 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchHa-0003if-2p for nemo@ietf.org; Thu, 17 Nov 2005 05:46:22 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D0B074C7C0 for ; Thu, 17 Nov 2005 19:27:59 +0900 (JST) Date: Thu, 17 Nov 2005 19:27:50 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology Message-Id: <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> In-Reply-To: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> References: <20051028155154.719167e5.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: 34d35111647d654d033d58d318c0d21a 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, Thanks to all who have commented on the terminology. Following the discussion at 64th IETF Vancouver (see slides NEMO WG "Terminology and Requirements" https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64) and on the ML, I've definitely closed issues: - A13 (improved figures) - A14 (normative references) - A15 (removed abbreviation i-face and e-face) - A17 (more text in definition of mobile network) - A18 (former definition of NEMO-link) - A19 (RO: keep definition of CR) - A23 (keep nested and multihoming SCENARIOS) - A20 (remove miscellaneous section) - A27 (clarify definitions of the Home Network Model terms) Still open are: - A16+A24 (NEMO-link) - A22 (depth) - A25 (split NEMO) - A26 (RO term "Routing Optimization") New one is: - A28 (RO term for sub-optimal routing) Issue List: http://www.sfc.wide.ad.jp/~ernst/nemo/ Current draft -05pre: http://www.sfc.wide.ad.jp/~ernst/nemo/draft-ietf-nemo-terminology-05pre.html http://www.sfc.wide.ad.jp/~ernst/nemo/draft-ietf-nemo-terminology-05pre.txt Changes include: - removed i-face and e-face - added a referenre to PhD dissertation in the ACK section The document will be sent to the IESG as soon as all issues are closed. Thierry. On Fri, 28 Oct 2005 15:51:54 +0900 Thierry Ernst wrote: > > 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 Thu Nov 17 06:23:02 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 1Echr4-0000cP-IZ; Thu, 17 Nov 2005 06:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Echr2-0000cK-8d for nemo@megatron.ietf.org; Thu, 17 Nov 2005 06:23:00 -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 GAA15016 for ; Thu, 17 Nov 2005 06:22:26 -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 1Eci8e-0005bx-0U for nemo@ietf.org; Thu, 17 Nov 2005 06:41:13 -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 jAHBMllp024938; Thu, 17 Nov 2005 20:22:47 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAHBMnw09987; Thu, 17 Nov 2005 20:22:49 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id jAHBMjp14725; Thu, 17 Nov 2005 20:22:46 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 19:19:40 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 64981D560C; Thu, 17 Nov 2005 19:29:24 +0800 (SGT) Subject: Re: [nemo] Re: Sub-optimal Terminology From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051117185134.544451e2.ernst@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 17 Nov 2005 19:29:23 +0800 Message-Id: <1132226964.19162.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 17 Nov 2005 11:19:40.0142 (UTC) FILETIME=[CD2E58E0:01C5EB68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit 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 On Thu, 2005-11-17 at 18:51 +0900, Thierry Ernst wrote: > > My take on this issue: > > 1. I would like to add the agreed term in draft terminology. I've added > an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ > 2. Several terms have been listed and here is my summary: > > - sub-optimal routing: very generic > - triangular / dog-leg routing: very specific (MIP6 scenario) > - multi-angular > - pin-ball routing is inappropriate Why is pinball routing inappropriate? I thought it draw a very vivid picture of the routing phenomenon quite well. > - telescopic: why not periscope ? ;-) > - nested-tunnel > I don't think telescopic is appropriate, since not all telescopes have multiple cylinders that can be nested within one another. I think nested tunnel is good enough. And I don't think we need a term to specifically differentiate the case of nested tunnels where the tunnel end points are all different as opposed to when some of tunnel end-points are the same node. /rgds /cwng > I think that: > - if no term is required to describe what happen in a nested NEMO, we > should stick to something generic i.e. "sub-optimal routing". If we what > something in line with the term usually used in MIP6 scenario > (triangular), I would vote for "multi-angular". If we need something > that doesn't describe what happens to the route, but rather to the > tunnel inefficiencies, I would vote for "nested tunnel". > > On the overall, I would vote for "multi-angular" and if needed I would > add a 2nd term "nested tunnels". > For a 1st April RFC, I would vote for "Periscope" ;-) :) From nemo-bounces@ietf.org Thu Nov 17 06:46:06 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 1EciDO-0000H4-Cz; Thu, 17 Nov 2005 06:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciDM-0000GY-L4 for nemo@megatron.ietf.org; Thu, 17 Nov 2005 06:46:04 -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 GAA16514 for ; Thu, 17 Nov 2005 06:45:30 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EciUy-0006QR-OB for nemo@ietf.org; Thu, 17 Nov 2005 07:04:18 -0500 Received: from venus.office (venus.office [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 12736DC31; Thu, 17 Nov 2005 12:45:52 +0100 (CET) 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] Distributing the Mobile Prefix in the visited network Date: Thu, 17 Nov 2005 12:45:51 +0100 Message-ID: Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXq3ElhA+l3zf/YT52g6s5rcYzLKgAjtuBQ From: "Roberto Baldessari" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable 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 Hi Francis, thank you for your answer. I fully agree with the reasons behind the constraint, but I didn't find any explicit "MUST NOT" in the RFC about distributing the MN prefix in the visited network. Am I wrong? Is it planned to introduce such a restriction in the future steps? I haven't had a look to the Route Optimization proposals yet. Regards Roberto =20 -----Original Message----- From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-bretagne.fr]=20 Sent: Wednesday, November 16, 2005 6:49 PM To: Roberto Baldessari Cc: nemo Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network=20 In your previous mail you wrote: I have a question related to the Basic NEMO Protocol. The RFC says: =20 " A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network) " =20 How should this be inteded? =3D> I can see two reasons for this constraint: - security: all the traffic for the Mobile Network is assumed to come through the HA-MR tunnel, in particular it always goes through the MR - handoff survivability: the short path has to be dismount when the MR leaves the visited network. In fact, this is simply a special case of Routing Optimization which is still in design and will address these two issues. Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Thu Nov 17 07:09:57 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 1EciaT-00077P-4a; Thu, 17 Nov 2005 07:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciaR-00077K-58 for nemo@megatron.ietf.org; Thu, 17 Nov 2005 07:09:55 -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 HAA17764 for ; Thu, 17 Nov 2005 07:09:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecis3-0007AF-G4 for nemo@ietf.org; Thu, 17 Nov 2005 07:28:08 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2005 04:09:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,342,1125903600"; d="scan'208"; a="15414633:sNHT21530380" Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAHC9Ue1022335; Thu, 17 Nov 2005 07:09:42 -0500 (EST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Nov 2005 13:09:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network Date: Thu, 17 Nov 2005 13:09:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC018111C7@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQACjfTeA= From: "Pascal Thubert \(pthubert\)" To: "Roberto Baldessari" , "nemo" X-OriginalArrivalTime: 17 Nov 2005 12:09:33.0262 (UTC) FILETIME=[C53836E0:01C5EB6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Roberto Baldessari >Sent: Wednesday, November 16, 2005 6:36 PM >To: nemo >Subject: [nemo] Distributing the Mobile Prefix in the visited network > >Hi all, > >I'm new of this mailing list. >I have a question related to the Basic NEMO Protocol. >The RFC says: > >" A Mobile Router does not distribute the > Mobile Network routes to the infrastructure at its point of > attachment (i.e., in the visited network) " > >How should this be inteded? In case a MR distributes the Mobile Prefix >in the visited network, in a way that the Mobile Network is routable >directly from the visited network, is the MR non-standard? > [] The goal in NEMO was to move prefix around without any route injection in the infrastructure. But there is no MUST or MUST NOT the text you mention.=20 Francis provided good reasons why this is not done, in general. The spec does not provide the means for doing it, does not discuss the risks and the consequences if this is done. It's just completely out of scope. But it does not say, never to do it, either. An example where you might do it is MANEMO, when MRs form a MANET for such purposes as route optimization. Pascal From nemo-bounces@ietf.org Thu Nov 17 07:52:31 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 1EcjFf-0003g7-Qv; Thu, 17 Nov 2005 07:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjFf-0003g1-44 for nemo@megatron.ietf.org; Thu, 17 Nov 2005 07:52:31 -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 HAA20474 for ; Thu, 17 Nov 2005 07:51:56 -0500 (EST) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcjXF-0000I3-PL for nemo@ietf.org; Thu, 17 Nov 2005 08:10:45 -0500 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5A688382BA; Thu, 17 Nov 2005 13:52:05 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2866F382BE; Thu, 17 Nov 2005 13:52:05 +0100 (CET) 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 ECE5537E5A; Thu, 17 Nov 2005 13:52:04 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EcjFE-0001I9-40; Thu, 17 Nov 2005 13:52:04 +0100 Message-ID: <437C7CF4.3070601@levkowetz.com> Date: Thu, 17 Nov 2005 13:52:04 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> In-Reply-To: <20051117185134.544451e2.ernst@sfc.wide.ad.jp> 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit 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 on 2005-11-17 10:51 Thierry Ernst said the following: > > My take on this issue: > > 1. I would like to add the agreed term in draft terminology. I've added > an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ > > 2. Several terms have been listed and here is my summary: > > - sub-optimal routing: very generic > - triangular / dog-leg routing: very specific (MIP6 scenario) > - multi-angular > - pin-ball routing is inappropriate > - telescopic: why not periscope ? ;-) > - nested-tunnel > > I think that: > - if no term is required to describe what happen in a nested NEMO, we > should stick to something generic i.e. "sub-optimal routing". Sounds good. > If we what > something in line with the term usually used in MIP6 scenario > (triangular), I would vote for "multi-angular". If we need something > that doesn't describe what happens to the route, but rather to the > tunnel inefficiencies, I would vote for "nested tunnel". > > On the overall, I would vote for "multi-angular" and if needed I would > add a 2nd term "nested tunnels". Multi-angular already exists as a word, used in the sense "Viewed from multiple angles (directions)". You shouldn't use that one here. I actually like "pin-ball route" (rather than routing) - it is nicely colourful, and quite descriptive -- unless it's already used in a conflicting sense in other RFCs. As alternatives for your consideration, what about: * Nested triangular * Nested dog-leg * Compound triangular * Compound dog-leg > For a 1st April RFC, I would vote for "Periscope" ;-) > Thierry. Waiting to read that one :-) Henrik > > > > > > > > On Tue, 8 Nov 2005 17:27:05 +0100 > "Pascal Thubert \(pthubert\)" wrote: > >> >> >> >-----Original Message----- >> >From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] >> >Sent: Tuesday, November 08, 2005 5:08 PM >> >To: Pascal Thubert (pthubert) >> >Cc: Alexandru Petrescu; Masafumi Watari; IETF NEMO WG; T.J. Kniveton >> >Subject: Re: Sub-optimal Terminology (was Re: [nemo]Re: I-D >> ACTION:draft-ietf-nemo-ro-problem- >> >statement-01.txt) >> > >> > >> >Pascal Thubert (pthubert) wrote: >> >> There is a topological view, where pinball routing and >> >multi-angular >> are >> >> contenders, and there is a tunnel view, for which we'd need a term >> like >> >> telescopic or something. Any idea? >> >> >> > >> >Hi, >> > >> >Is the term "nested tunnels" not the one we used to use? >> [] Yes, it is. >> >> But that term, like suboptimal, is very generic. >> >> Now we are considering RO and finding more specific terms which would >> be more uniquely associated to our problem would be nice, but if we >> don't, I agree we have a default. >> >> It could be also useful to distinguish when one side ends multiple >> layers of tunneling, like a HA does if you form a nested structure of >> MRs that depend on that same HA. >> >> Any idea? >> >> Pascal > > > > From nemo-bounces@ietf.org Thu Nov 17 09:20:43 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 1Eckd1-0008AW-KH; Thu, 17 Nov 2005 09:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eckcz-0008AR-TV for nemo@megatron.ietf.org; Thu, 17 Nov 2005 09:20:41 -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 JAA26568 for ; Thu, 17 Nov 2005 09:20:06 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eckud-0003ez-Iy for nemo@ietf.org; Thu, 17 Nov 2005 09:38:56 -0500 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A94BA14FEB for ; Thu, 17 Nov 2005 15:20:31 +0100 (CET) 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] Distributing the Mobile Prefix in the visited network Date: Thu, 17 Nov 2005 15:20:30 +0100 Message-ID: Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQACjfTeAABC8RsA== From: "Roberto Baldessari" To: "nemo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org =20 Pascal, thank you. It seems like the MANEMO matches what we are interested in. How is the status of that? I didn't find material about. Regards Roberto -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, November 17, 2005 1:09 PM To: Roberto Baldessari; nemo Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Roberto Baldessari >Sent: Wednesday, November 16, 2005 6:36 PM >To: nemo >Subject: [nemo] Distributing the Mobile Prefix in the visited network > >Hi all, > >I'm new of this mailing list. >I have a question related to the Basic NEMO Protocol. >The RFC says: > >" A Mobile Router does not distribute the > Mobile Network routes to the infrastructure at its point of > attachment (i.e., in the visited network) " > >How should this be inteded? In case a MR distributes the Mobile Prefix=20 >in the visited network, in a way that the Mobile Network is routable=20 >directly from the visited network, is the MR non-standard? > [] The goal in NEMO was to move prefix around without any route injection in the infrastructure. But there is no MUST or MUST NOT the text you mention.=20 Francis provided good reasons why this is not done, in general. The spec does not provide the means for doing it, does not discuss the risks and the consequences if this is done. It's just completely out of scope. But it does not say, never to do it, either. An example where you might do it is MANEMO, when MRs form a MANET for such purposes as route optimization. Pascal From nemo-bounces@ietf.org Thu Nov 17 12:12:19 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 1EcnJ5-0001nH-Lg; Thu, 17 Nov 2005 12:12:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcnJ3-0001l2-9N for nemo@megatron.ietf.org; Thu, 17 Nov 2005 12:12:17 -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 MAA07268 for ; Thu, 17 Nov 2005 12:11:42 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecnaf-0001Pp-Do for nemo@ietf.org; Thu, 17 Nov 2005 12:30:33 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA10516; Thu, 17 Nov 2005 09:11:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAHHBtY17946; Thu, 17 Nov 2005 11:11:56 -0600 (CST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 09:11:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network Date: Thu, 17 Nov 2005 09:11:47 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A621F3D@XCH-NW-8V1.nw.nos.boeing.com> Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXq3ElhA+l3zf/YT52g6s5rcYzLKgAjtuBQAAuZxUA= From: "Davis, Terry L" To: "Roberto Baldessari" , X-OriginalArrivalTime: 17 Nov 2005 17:11:50.0166 (UTC) FILETIME=[FFA82360:01C5EB99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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 Roberto/Francis Just as an FYI, our commercial mobility implementation for aircraft in IP-v4 does distribute its route at the ground station that it is attached to. Take care Terry -----Original Message----- From: Roberto Baldessari [mailto:Roberto.Baldessari@netlab.nec.de]=20 Sent: Thursday, November 17, 2005 3:46 AM To: Francis.Dupont@enst-bretagne.fr Cc: nemo Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network=20 Hi Francis, thank you for your answer. I fully agree with the reasons behind the constraint, but I didn't find any explicit "MUST NOT" in the RFC about distributing the MN prefix in the visited network. Am I wrong? Is it planned to introduce such a restriction in the future steps? I haven't had a look to the Route Optimization proposals yet. Regards Roberto =20 -----Original Message----- From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-bretagne.fr]=20 Sent: Wednesday, November 16, 2005 6:49 PM To: Roberto Baldessari Cc: nemo Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network=20 In your previous mail you wrote: I have a question related to the Basic NEMO Protocol. The RFC says: =20 " A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network) " =20 How should this be inteded? =3D> I can see two reasons for this constraint: - security: all the traffic for the Mobile Network is assumed to come through the HA-MR tunnel, in particular it always goes through the MR - handoff survivability: the short path has to be dismount when the MR leaves the visited network. In fact, this is simply a special case of Routing Optimization which is still in design and will address these two issues. Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Thu Nov 17 20:49:44 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 1EcvNo-0006hY-HE; Thu, 17 Nov 2005 20:49:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcvNn-0006hQ-ER for nemo@megatron.ietf.org; Thu, 17 Nov 2005 20:49:43 -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 UAA11518 for ; Thu, 17 Nov 2005 20:49:08 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcvfX-0003M2-Dm for nemo@ietf.org; Thu, 17 Nov 2005 21:08:04 -0500 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 27A024C68D for ; Fri, 18 Nov 2005 10:49:13 +0900 (JST) Message-ID: <437D339F.3010305@sfc.wide.ad.jp> Date: Fri, 18 Nov 2005 10:51:27 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> In-Reply-To: <20051117192750.7b7688d8.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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Hello, Thierry Ernst wrote: > - A25 (split NEMO) I propose the following draft definition: A split NEMO occurs when a single mobile subnet connected to multiple Mobile Routers, or multiple mobile subnets interconnected with routers, become two or more independant mobile subnets. | | | | MR1 MR2 MR1 MR2 | | -> | | ---------- ----- ----- | | | | MR1 Router MR2 MR1 MR2 | | | | -> | | -------- ------- ----- ----- Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Nov 17 21:20:18 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 1EcvrO-0000Zh-K9; Thu, 17 Nov 2005 21:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcvrN-0000Zc-4C for nemo@megatron.ietf.org; Thu, 17 Nov 2005 21:20:17 -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 VAA12955 for ; Thu, 17 Nov 2005 21:19:41 -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 1Ecw96-0004GB-MC for nemo@ietf.org; Thu, 17 Nov 2005 21:38:38 -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 jAI2K3FM003680; Fri, 18 Nov 2005 11:20:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAI2K5V16761; Fri, 18 Nov 2005 11:20:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id jAI2K1308419; Fri, 18 Nov 2005 11:20:02 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 10:16:58 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id B8BA6D560C; Fri, 18 Nov 2005 10:26:47 +0800 (SGT) Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <437D339F.3010305@sfc.wide.ad.jp> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Nov 2005 10:26:47 +0800 Message-Id: <1132280807.4927.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 18 Nov 2005 02:16:58.0258 (UTC) FILETIME=[2732E720:01C5EBE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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-11-18 at 10:51 +0900, Romain KUNTZ wrote: > Hello, > > Thierry Ernst wrote: > > - A25 (split NEMO) > > I propose the following draft definition: > > A split NEMO occurs when a single mobile subnet connected to multiple > Mobile Routers, or multiple mobile subnets interconnected with routers, > become two or more independant mobile subnets. "independent". Anyway, "multiple mobile subnets interconnected with routers" is not very accurate and leads to controversy. Consider MR1 MR1 | | ---+-+--- => --+--- MR2 | | MR2 --+-- | ---+---- It fits your definition but does not falls into the normal sense of split NEMO. > > | | | | > MR1 MR2 MR1 MR2 > | | -> | | > ---------- ----- ----- > The above I agree, the one below needs a bit of further exploration. > > | | | | > MR1 Router MR2 MR1 MR2 > | | | | -> | | > -------- ------- ----- ----- > With a router, presumably a LFR, in between, the two links are separate subnets. So, MR1 and MR2 are handling different prefixes. When the two links goes separate way, what would happens is that the LFR would no longer function as a router, since it loses its at least one of its link for forwarding. As far as NEMO-BS is concerned, this situation also does not fall into the normal sense of split-NEMO problem, because MR1 and MR2 are handling different prefixes, even when they split, there is no ambiguity in the HA(s) on who to forward a packet destined for one of the MNPs to. Unless the router in the figure is not a router but a bridge/switch/..., a layer 2 device. Which should not reflected, and thus reducing this case to be equivalent to the first diagram you draw, from a layer 3 perspective. It all depends on what is the motivation for the inclusion of the split-NEMO definition. I thought the motivation was to assist in illustrating the problem of split NEMO as documented in draft-ietf-nemo-multihoming-issues. If this is indeed the case, then the definition of split-NEMO should define cases only when the problem of split NEMO occurs. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 17 21:56:36 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 1EcwQW-0007Zp-Ef; Thu, 17 Nov 2005 21:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcwQU-0007ZZ-Pr for nemo@megatron.ietf.org; Thu, 17 Nov 2005 21:56:34 -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 VAA14899 for ; Thu, 17 Nov 2005 21:55:59 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcwiE-0005Hp-DG for nemo@ietf.org; Thu, 17 Nov 2005 22:14:56 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C92F94C584 for ; Fri, 18 Nov 2005 11:56:16 +0900 (JST) Date: Fri, 18 Nov 2005 11:56:07 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network Message-Id: <20051118115607.6c782f6a.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC018111C7@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC018111C7@xmb-ams-337.emea.cisco.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: 9ed51c9d1356100bce94f1ae4ec616a9 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 > >I'm new of this mailing list. > >I have a question related to the Basic NEMO Protocol. > >The RFC says: > > > >" A Mobile Router does not distribute the > > Mobile Network routes to the infrastructure at its point of > > attachment (i.e., in the visited network) " > > > >How should this be inteded? In case a MR distributes the Mobile > >Prefix in the visited network, in a way that the Mobile Network is > >routable directly from the visited network, is the MR non-standard? > > > [] The goal in NEMO was to move prefix around without any route > injection in the infrastructure. But there is no MUST or MUST NOT the > text you mention. > > Francis provided good reasons why this is not done, in general. The > spec does not provide the means for doing it, does not discuss the > risks and the consequences if this is done. It's just completely out > of scope. > > But it does not say, never to do it, either. An example where you > might do it is MANEMO, when MRs form a MANET for such purposes as > route optimization. The text is not explicit, but there is no point to do it WITH NEMO BASIC SUPPORT RFC 3963 because "network basic support" has been designed with some goals in mind, and with specific requirements (see http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt section 4) Particularly: R03: All traffic exchanged between an MNN and a CN in the global Internet MUST transit through the bi-directional MRHA tunnel. But, if you want to do something else than network mobiliy support, there is no restrictions, currently. Thierry From nemo-bounces@ietf.org Fri Nov 18 02:30:11 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 1Ed0hH-0005j1-DG; Fri, 18 Nov 2005 02:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed0hF-0005it-Gb for nemo@megatron.ietf.org; Fri, 18 Nov 2005 02:30:09 -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 CAA27933 for ; Fri, 18 Nov 2005 02:29:34 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed0z0-0004mL-PT for nemo@ietf.org; Fri, 18 Nov 2005 02:48:33 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 729F0EC8F4; Fri, 18 Nov 2005 16:29:39 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5D08BEC8F3; Fri, 18 Nov 2005 16:29:38 +0900 (JST) Received: from [IPv6:2001:200:601:200:395b:785e:e01e:9eaf] (unknown [IPv6:2001:200:601:200:395b:785e:e01e:9eaf]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 6E7B82E032; Fri, 18 Nov 2005 16:28:23 +0900 (JST) Message-ID: <437D83C4.4070703@kddilabs.jp> Date: Fri, 18 Nov 2005 16:33:24 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <43796DA7.3090507@kddilabs.jp> <20051117191448.461c9854.ernst@sfc.wide.ad.jp> In-Reply-To: <20051117191448.461c9854.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Thierry, On 2005/11/17 19:14, Thierry Ernst wrote: > Hi Watari, > > Thanks for your feedback on this. > >>I apologize if this is a bit too late to give comments on this, but >>I belive this draft was silent for some time and so with an attempt to >>raise some discussion, here are the ones that concerns me. >> >> Issue A16: [VALIDATE B4 CLOSING 0510] NEMO-link vs mobile >> subnet/link Proposition: By Thierry 0410: Since we agreed to keep >> MNP instead of NEMO-prefix, I think it would be consistent to keep >> mobile subnet or mobile link instead of NEMO-link. Comments ? >> >>I agree with this. Not just keeping it consistent with MNP, the term >>NEMO-link is hard to grasp. I would suggent MNL as Mobile Network >>Link, however I don't see the term "NEMO-link" used in RFC 3963 >>so I don't know if we really need such term in the first place. >>Any comments ? > > What I didn't like in the term "MNP" is the wording "mobile network" > (many people are still confused with cellular networks for mobile > devices), but since we agreed to keep MNP, MNL would make sense, but > it's easily misstyped to MNP ... So, let's not introduce new term, > either we use NEMO-link or mobile-subnet (mobile-link should be > disqualified because a NEMO can be made of severals links). You're saying that you don't like MNL because people would miss-type as MNP? I don't buy that... NEMO-link is alreay a new term anyway, and I've seen *very few* documents that uses such term. > Is anyone ever seen NEMO-link used in IETF documents ? If not, let's > remove it. I haven't seen it in any documents other than yours :) So when is it really useful? >> Issue A23: [OPEN 0410] Keep nested and multihoming scenario in >> draft? Proposition: by Thierry: Nested and Multihomed Mobile >> Networks: is draft-ietf-nemo-terminology the right location to >> describe the two scenarios ? >> >>Yes. They are useful and are refered to by the RO drafts. > > OK, conclusion is "keep". > >> Issue A22: [OPEN 0410] Add term for "Depth of a Nested-NEMO" >> Proposition: "Depth" may be useful to deal with Nested-NEMO >> Proposition: Please propose a clear definition >> >>This, I don't know. The RO drafts use "level of nesting" but I guess >>this is a bit different. It would be useful I guess when phrasing >>a MR at a specific nest level, like "A MR at depth 3". > > I think "level of nesting" and "depth" are the same. I think "depth" may > be better. We could say: > > Depth: indicates the number of sub-MRs a packet as to cross between a > MNN and the root-MR. > > But, this is tricky: a NEMO multihomed behind several root-MRs may be a > different depths according to the exit root-MR used by the packet. > > On the overall, I'm quite in favor of adding it if the word is used in > some documents like the RO drafts. Will you use "depth" with the above > definition ? s/as/has/ Maybe it could be rephrased a little. I will try and think of another one. > One thing you didn't mention Watari: > > In draft-ietf-nemo-ro-space-analysis-01 section 1.0 it is written: > > "the term "Route Optimization" is accepted in a > broader sense than already defined for IPv6 Host Mobility in [3], to > loosely refer to any approach that optimizes the transmission of > packets between a Mobile Network Node and a Correspondent Node." > > If everyone agree, I would like to add in draft-terminology the > following term (it was discussed in slide 7 of my presentation in > Vancouver): > > Routing Optimization: > > Refers to any approach that optimizes the transmission of packets > between a MNN and a CN I would agree. Actually, I like it as is. Route Optimization: "the term "Route Optimization" is accepted in a broader sense than already defined for IPv6 Host Mobility in [3], to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node." regards, watari From nemo-bounces@ietf.org Fri Nov 18 10:07: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 1Ed7qA-0005R1-VI; Fri, 18 Nov 2005 10:07:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7q9-0005Ih-84 for nemo@megatron.ietf.org; Fri, 18 Nov 2005 10:07:49 -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 KAA22577 for ; Fri, 18 Nov 2005 10:07:13 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed87y-0002xQ-Sv for nemo@ietf.org; Fri, 18 Nov 2005 10:26:17 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAIFK88t014892; Fri, 18 Nov 2005 08:20:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jAIFIYTn011014; Fri, 18 Nov 2005 09:18:34 -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 09425865980; Fri, 18 Nov 2005 16:07:34 +0100 (CET) Message-ID: <437DEE35.2020703@motorola.com> Date: Fri, 18 Nov 2005 16:07:33 +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: Thierry Ernst Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <43796DA7.3090507@kddilabs.jp> <20051117191448.461c9854.ernst@sfc.wide.ad.jp> In-Reply-To: <20051117191448.461c9854.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: e1e48a527f609d1be2bc8d8a70eb76cb 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: > Hi Watari, > > Thanks for your feedback on this. > > >> I apologize if this is a bit too late to give comments on this, but >> I belive this draft was silent for some time and so with an >> attempt to raise some discussion, here are the ones that concerns >> me. >> >> Issue A16: [VALIDATE B4 CLOSING 0510] NEMO-link vs mobile >> subnet/link Proposition: By Thierry 0410: Since we agreed to keep >> MNP instead of NEMO-prefix, I think it would be consistent to keep >> mobile subnet or mobile link instead of NEMO-link. Comments ? >> >> I agree with this. Not just keeping it consistent with MNP, the >> term NEMO-link is hard to grasp. I would suggent MNL as Mobile >> Network Link, however I don't see the term "NEMO-link" used in RFC >> 3963 so I don't know if we really need such term in the first >> place. Any comments ? > > > What I didn't like in the term "MNP" is the wording "mobile network" > (many people are still confused with cellular networks for mobile > devices), Probably use "moving network" instead of "mobile network"? MNP: moving network prefix? > VMN: assigned to a home link that doesn't belong to the mobile network VMN: its HA is different than MR's and is not on any link of that MR. draft nit: > Its address is located within an MNP. "Derived from the MNP"? Alex From nemo-bounces@ietf.org Fri Nov 18 11:49:47 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 1Ed9Qp-0007RV-Q2; Fri, 18 Nov 2005 11:49:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Qn-0007GQ-Ad for nemo@megatron.ietf.org; Fri, 18 Nov 2005 11:49:45 -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 LAA28160 for ; Fri, 18 Nov 2005 11:49:10 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9ie-0005z0-MS for nemo@ietf.org; Fri, 18 Nov 2005 12:08:14 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2005 17:49:35 +0100 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 jAIGmtB3001099; Fri, 18 Nov 2005 17:49:30 +0100 (MET) 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); Fri, 18 Nov 2005 17:49:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Sub-optimal Terminology Date: Fri, 18 Nov 2005 17:49:19 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC018116EA@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Sub-optimal Terminology Thread-Index: AcXrdf3HdR0L7vqKSe6wzwPyeO8RzQA6aOnw From: "Pascal Thubert \(pthubert\)" To: "Henrik Levkowetz" , "Thierry Ernst" X-OriginalArrivalTime: 18 Nov 2005 16:49:25.0359 (UTC) FILETIME=[08809FF0:01C5EC60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable 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 >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Henrik Levkowetz >Sent: Thursday, November 17, 2005 1:52 PM >To: Thierry Ernst >Cc: ml-nemo >Subject: Re: [nemo] Re: Sub-optimal Terminology > > > >on 2005-11-17 10:51 Thierry Ernst said the following: >> >> My take on this issue: >> >> 1. I would like to add the agreed term in draft terminology. I've added >> an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ >> >> 2. Several terms have been listed and here is my summary: >> >> - sub-optimal routing: very generic >> - triangular / dog-leg routing: very specific (MIP6 scenario) >> - multi-angular >> - pin-ball routing is inappropriate >> - telescopic: why not periscope ? ;-) >> - nested-tunnel >> >> I think that: >> - if no term is required to describe what happen in a nested NEMO, we >> should stick to something generic i.e. "sub-optimal routing". > >Sounds good. > >> If we what >> something in line with the term usually used in MIP6 scenario >> (triangular), I would vote for "multi-angular". If we need something >> that doesn't describe what happens to the route, but rather to the >> tunnel inefficiencies, I would vote for "nested tunnel". >> >> On the overall, I would vote for "multi-angular" and if needed I would >> add a 2nd term "nested tunnels". > >Multi-angular already exists as a word, used in the sense "Viewed >from multiple angles (directions)". You shouldn't use that one here. > >I actually like "pin-ball route" (rather than routing) - it is >nicely colourful, and quite descriptive -- unless it's already >used in a conflicting sense in other RFCs. [] I agree with Henrik on all this. Whether we adopt pinball or not at the end, it's not routing but route, or path. The word bouncing might be useful as well, either in terminology or just in the description text. Pascal From nemo-bounces@ietf.org Fri Nov 18 12:17:01 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 1Ed9rB-0003DJ-32; Fri, 18 Nov 2005 12:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9r9-00037r-B7 for nemo@megatron.ietf.org; Fri, 18 Nov 2005 12:16:59 -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 MAA29946 for ; Fri, 18 Nov 2005 12:16:23 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdA8z-0006qS-I6 for nemo@ietf.org; Fri, 18 Nov 2005 12:35:27 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2005 18:16:47 +0100 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 jAIHGgAV006918; Fri, 18 Nov 2005 18:16:44 +0100 (MET) 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); Fri, 18 Nov 2005 18:16:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network Date: Fri, 18 Nov 2005 18:16:37 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0181170B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQACjfTeAABC8RsAA46Ryg From: "Pascal Thubert \(pthubert\)" To: "Roberto Baldessari" , "nemo" X-OriginalArrivalTime: 18 Nov 2005 17:16:43.0140 (UTC) FILETIME=[D8B22C40:01C5EC63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Roberto: There is a MANEMO list http://www.mobileip.jp/mailman/listinfo/manemo But we did not start a BOF yet. I guess it's a matter of raising interest and relating the effort with NEMO. The more people show interest, the better off we are :) Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Roberto Baldessari >Sent: Thursday, November 17, 2005 3:21 PM >To: nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network > > >Pascal, > >thank you. It seems like the MANEMO matches what we are interested in. >How is the status of that? I didn't find material about. > >Regards > >Roberto > > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Thursday, November 17, 2005 1:09 PM >To: Roberto Baldessari; nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited >network > > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of >Roberto Baldessari >>Sent: Wednesday, November 16, 2005 6:36 PM >>To: nemo >>Subject: [nemo] Distributing the Mobile Prefix in the visited network >> >>Hi all, >> >>I'm new of this mailing list. >>I have a question related to the Basic NEMO Protocol. >>The RFC says: >> >>" A Mobile Router does not distribute the >> Mobile Network routes to the infrastructure at its point of >> attachment (i.e., in the visited network) " >> >>How should this be inteded? In case a MR distributes the Mobile Prefix >>in the visited network, in a way that the Mobile Network is routable >>directly from the visited network, is the MR non-standard? >> >[] The goal in NEMO was to move prefix around without any route >injection in the infrastructure. But there is no MUST or MUST NOT the >text you mention. > >Francis provided good reasons why this is not done, in general. The spec >does not provide the means for doing it, does not discuss the risks and >the consequences if this is done. It's just completely out of scope. > >But it does not say, never to do it, either. An example where you might >do it is MANEMO, when MRs form a MANET for such purposes as route >optimization. > >Pascal From nemo-bounces@ietf.org Fri Nov 18 12:27: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 1EdA1D-0005m2-Af; Fri, 18 Nov 2005 12:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdA1B-0005ca-Ex for nemo@megatron.ietf.org; Fri, 18 Nov 2005 12:27:21 -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 MAA00439 for ; Fri, 18 Nov 2005 12:26:46 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdAJ1-000768-AJ for nemo@ietf.org; Fri, 18 Nov 2005 12:45:50 -0500 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jAIHp9gn009931; Fri, 18 Nov 2005 10:51:10 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jAIHejbY024496; Fri, 18 Nov 2005 11:40:46 -0600 (CST) Message-ID: <437E0EE6.8080804@motorola.com> Date: Fri, 18 Nov 2005 18:27:02 +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: Roberto Baldessari Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network 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: cf4fa59384e76e63313391b70cd0dd25 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 Roberto Baldessari wrote: > > Pascal, > > thank you. It seems like the MANEMO matches what we are interested in. > How is the status of that? I didn't find material about. Would dhcpv6-pd draft-ietf-nemo-dhcpv6-pd-00.txt match the interest? The draft has text in it about AR distributing prefixes to a moving MR. It's not clear though whether session continuity is required. Are you interested in session continuity at LFN when MR gets a new prefix? Alex From nemo-bounces@ietf.org Fri Nov 18 13:02:43 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 1EdAZP-0006zr-Pe; Fri, 18 Nov 2005 13:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAZO-0006sF-Al for nemo@megatron.ietf.org; Fri, 18 Nov 2005 13:02:42 -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 NAA02057 for ; Fri, 18 Nov 2005 13:02:07 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdArG-0007sL-D9 for nemo@ietf.org; Fri, 18 Nov 2005 13:21:11 -0500 Received: from venus.office (chiba.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2F42F14FF5 for ; Fri, 18 Nov 2005 19:02:13 +0100 (CET) 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] Distributing the Mobile Prefix in the visited network Date: Fri, 18 Nov 2005 19:02:12 +0100 Message-ID: Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQACjfTeAABC8RsAA46RygAAAhndA= From: "Roberto Baldessari" To: "nemo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org =20 Thanks Pascal, I have already subscribed the list and had a look to the mail archive. It seems like you are searching for concrete scenarios, and you already mentioned what we also are dealing with, i.e. car to car communication. We are considering different strategies and we could contribute to this starting group. But first we need to gather some information more. Actually we are not interested in routing protocols, because we assume the MANET already provided with that. Best regrards. Roberto -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Friday, November 18, 2005 6:17 PM To: Roberto Baldessari; nemo Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network Hi Roberto: There is a MANEMO list http://www.mobileip.jp/mailman/listinfo/manemo But we did not start a BOF yet. I guess it's a matter of raising interest and relating the effort with NEMO. The more people show interest, the better off we are :) Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Roberto Baldessari >Sent: Thursday, November 17, 2005 3:21 PM >To: nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network > > >Pascal, > >thank you. It seems like the MANEMO matches what we are interested in. >How is the status of that? I didn't find material about. > >Regards > >Roberto > > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Thursday, November 17, 2005 1:09 PM >To: Roberto Baldessari; nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited=20 >network > > > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of >Roberto Baldessari >>Sent: Wednesday, November 16, 2005 6:36 PM >>To: nemo >>Subject: [nemo] Distributing the Mobile Prefix in the visited network >> >>Hi all, >> >>I'm new of this mailing list. >>I have a question related to the Basic NEMO Protocol. >>The RFC says: >> >>" A Mobile Router does not distribute the >> Mobile Network routes to the infrastructure at its point of >> attachment (i.e., in the visited network) " >> >>How should this be inteded? In case a MR distributes the Mobile Prefix >>in the visited network, in a way that the Mobile Network is routable=20 >>directly from the visited network, is the MR non-standard? >> >[] The goal in NEMO was to move prefix around without any route=20 >injection in the infrastructure. But there is no MUST or MUST NOT the=20 >text you mention. > >Francis provided good reasons why this is not done, in general. The spec >does not provide the means for doing it, does not discuss the risks and >the consequences if this is done. It's just completely out of scope. > >But it does not say, never to do it, either. An example where you might >do it is MANEMO, when MRs form a MANET for such purposes as route=20 >optimization. > >Pascal From nemo-bounces@ietf.org Fri Nov 18 13:34:22 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 1EdB42-0006F0-Lw; Fri, 18 Nov 2005 13:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdB41-0006Es-8V for nemo@megatron.ietf.org; Fri, 18 Nov 2005 13:34:21 -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 NAA03396 for ; Fri, 18 Nov 2005 13:33:45 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBLt-000072-Gp for nemo@ietf.org; Fri, 18 Nov 2005 13:52:50 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAIIkdr2022524; Fri, 18 Nov 2005 11:46:39 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jAIIgsOb003462; Fri, 18 Nov 2005 12:42:55 -0600 (CST) Message-ID: <437E1E9D.4050809@motorola.com> Date: Fri, 18 Nov 2005 19:34:05 +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: Henrik Levkowetz Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> <437C7CF4.3070601@levkowetz.com> In-Reply-To: <437C7CF4.3070601@levkowetz.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Henrik Levkowetz wrote: > Multi-angular already exists as a word, used in the sense "Viewed > from multiple angles (directions)". Oh, I didn't know that. > I actually like "pin-ball route" (rather than routing) - it is nicely > colourful, and quite descriptive -- unless it's already used in a > conflicting sense in other RFCs. "internet pinball machine" in Internet Monthly Report 8912, yr1989, for SNTP. An MR with SNTP syncing cache at HAs may "pinball" among strata. Otherwise no "pinball" nor "pin-ball" in RFCs; but often used in casual routing discussions, not necessarily NEMO. Google finds many hits for "pinball routing" in NEMO texts, so it could be considered an established term as well. > As alternatives for your consideration, what about: * Nested > triangular * Nested dog-leg * Compound triangular * Compound dog-leg "dog-leg" can have only three segments (bones). zigzag. I'm fine with any in the end. Alex From nemo-bounces@ietf.org Fri Nov 18 13:51:41 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 1EdBKn-0004ez-JO; Fri, 18 Nov 2005 13:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBKm-0004eu-Jg for nemo@megatron.ietf.org; Fri, 18 Nov 2005 13:51:40 -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 NAA04169 for ; Fri, 18 Nov 2005 13:51:05 -0500 (EST) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBce-0000Ux-5Y for nemo@ietf.org; Fri, 18 Nov 2005 14:10:10 -0500 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 80295380DF; Fri, 18 Nov 2005 19:41:48 +0100 (CET) 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 5CB1E37E62; Fri, 18 Nov 2005 19:41:48 +0100 (CET) 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 B76D137E43; Fri, 18 Nov 2005 19:51:23 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EdBKV-0005jV-AK; Fri, 18 Nov 2005 19:51:23 +0100 Message-ID: <437E22AB.6090908@levkowetz.com> Date: Fri, 18 Nov 2005 19:51:23 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> <437C7CF4.3070601@levkowetz.com> <437E1E9D.4050809@motorola.com> In-Reply-To: <437E1E9D.4050809@motorola.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: 93238566e09e6e262849b4f805833007 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 on 2005-11-18 19:34 Alexandru Petrescu said the following: [...] > Google finds many hits for "pinball routing" in NEMO texts, so it could > be considered an established term as well. Ah, Ok. >> As alternatives for your consideration, what about: * Nested >> triangular * Nested dog-leg * Compound triangular * Compound dog-leg > > "dog-leg" can have only three segments (bones). Yes. But in nested dog-legs you may have one bone contain a dog-leg? (I don't like this a lot myself, though...) > zigzag. That's pretty good. I like that. Henrik From nemo-bounces@ietf.org Sun Nov 20 21:40:30 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 1Ee1ba-00008y-GB; Sun, 20 Nov 2005 21:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1bZ-00008s-3s for nemo@megatron.ietf.org; Sun, 20 Nov 2005 21:40:29 -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 VAA27425 for ; Sun, 20 Nov 2005 21:39:52 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee1tu-0003Yz-Jw for nemo@ietf.org; Sun, 20 Nov 2005 21:59:28 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id DDD444C182 for ; Mon, 21 Nov 2005 11:40:00 +0900 (JST) Date: Mon, 21 Nov 2005 11:39:50 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: Sub-optimal Terminology Message-Id: <20051121113950.0d7497fc.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC018116EA@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC018116EA@xmb-ams-337.emea.cisco.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: c3a18ef96977fc9bcc21a621cbf1174b 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 Please not that I'm in the process of finishing the terminology document, so it's fine to propose some new terms as long: - a definition is proposed - it is definitely used in some documents - there is a general agreement on the need for the new term, and it's definition. So, would you propose the definition for "pin-ball routing" and whatever other proposed terms ? Please do so in the next couple of days, after it's too late. Thierry On Fri, 18 Nov 2005 17:49:19 +0100 "Pascal Thubert \(pthubert\)" wrote: > > > >-----Original Message----- > >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > >Of > Henrik Levkowetz > >Sent: Thursday, November 17, 2005 1:52 PM > >To: Thierry Ernst > >Cc: ml-nemo > >Subject: Re: [nemo] Re: Sub-optimal Terminology > > > > > > > >on 2005-11-17 10:51 Thierry Ernst said the following: > >> > >> My take on this issue: > >> > >> 1. I would like to add the agreed term in draft terminology. I've > added > >> an issue A28, see http://www.sfc.wide.ad.jp/~ernst/nemo/ > >> > >> 2. Several terms have been listed and here is my summary: > >> > >> - sub-optimal routing: very generic > >> - triangular / dog-leg routing: very specific (MIP6 scenario) > >> - multi-angular > >> - pin-ball routing is inappropriate > >> - telescopic: why not periscope ? ;-) > >> - nested-tunnel > >> > >> I think that: > >> - if no term is required to describe what happen in a nested NEMO, > >we> should stick to something generic i.e. "sub-optimal routing". > > > >Sounds good. > > > >> If we what > >> something in line with the term usually used in MIP6 scenario > >> (triangular), I would vote for "multi-angular". If we need > >something> that doesn't describe what happens to the route, but > >rather to the> tunnel inefficiencies, I would vote for "nested > >tunnel".> > >> On the overall, I would vote for "multi-angular" and if needed I > would > >> add a 2nd term "nested tunnels". > > > >Multi-angular already exists as a word, used in the sense "Viewed > >from multiple angles (directions)". You shouldn't use that one here. > > > >I actually like "pin-ball route" (rather than routing) - it is > >nicely colourful, and quite descriptive -- unless it's already > >used in a conflicting sense in other RFCs. > > > [] I agree with Henrik on all this. Whether we adopt pinball or > not at the end, it's not routing but route, or path. The word bouncing > might be useful as well, either in terminology or just in the > description text. -- 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 Sun Nov 20 21:45:27 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 1Ee1gN-0000sX-UL; Sun, 20 Nov 2005 21:45:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1gM-0000rx-ST for nemo@megatron.ietf.org; Sun, 20 Nov 2005 21:45:26 -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 VAA27694 for ; Sun, 20 Nov 2005 21:44:50 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee1yh-0003gO-MO for nemo@ietf.org; Sun, 20 Nov 2005 22:04:26 -0500 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C33104CAFA for ; Mon, 21 Nov 2005 11:45:14 +0900 (JST) Message-ID: <43813545.9070804@sfc.wide.ad.jp> Date: Mon, 21 Nov 2005 11:47:33 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> In-Reply-To: <1132280807.4927.14.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Hello Chan-Wah, Chan-Wah Ng wrote: >>A split NEMO occurs when a single mobile subnet connected to multiple >>Mobile Routers, or multiple mobile subnets interconnected with routers, >>become two or more independant mobile subnets. > > > "independent". > > Anyway, "multiple mobile subnets interconnected with routers" is not > very accurate and leads to controversy. Consider > > MR1 MR1 > | | > ---+-+--- => --+--- MR2 > | | > MR2 --+-- > | > ---+---- > > It fits your definition but does not falls into the normal sense of > split NEMO. That's right. >> | | | | >> MR1 Router MR2 MR1 MR2 >> | | | | -> | | >> -------- ------- ----- ----- >> > > > With a router, presumably a LFR, in between, the two links are separate > subnets. So, MR1 and MR2 are handling different prefixes. When the > two links goes separate way, what would happens is that the LFR would no > longer function as a router, since it loses its at least one of its link > for forwarding. > > As far as NEMO-BS is concerned, this situation also does not fall into > the normal sense of split-NEMO problem, because MR1 and MR2 are handling > different prefixes, even when they split, there is no ambiguity in the > HA(s) on who to forward a packet destined for one of the MNPs to. Correct. I do not know what I had in mind when drawing this :-) I was thinking about MR2 registering some of MR1 prefixes for redundancy purposes, but this has no relations with current NEMO-BS. > It all depends on what is the motivation for the inclusion of the > split-NEMO definition. I thought the motivation was to assist in > illustrating the problem of split NEMO as documented in > draft-ietf-nemo-multihoming-issues. If this is indeed the case, then > the definition of split-NEMO should define cases only when the problem > of split NEMO occurs. I agree. So do you see other case than (n,1,1) with the following topology: | | | | MR1 MR2 MR1 MR2 | | -> | | ---------- ----- ----- (ie multiple MRs attached to the same mobile subnet on their ingress interface, registering the same prefix to the same HA) where split NEMO is a problem? Romain From nemo-bounces@ietf.org Sun Nov 20 21:47:57 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 1Ee1in-0001LJ-0S; Sun, 20 Nov 2005 21:47:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1ii-0001Fu-0t for nemo@megatron.ietf.org; Sun, 20 Nov 2005 21:47:56 -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 VAA27768 for ; Sun, 20 Nov 2005 21:47:15 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee214-0003jK-No for nemo@ietf.org; Sun, 20 Nov 2005 22:06:51 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 50FE94CBC9 for ; Mon, 21 Nov 2005 11:47:42 +0900 (JST) Date: Mon, 21 Nov 2005 11:47:32 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology Message-Id: <20051121114732.45c25787.ernst@sfc.wide.ad.jp> In-Reply-To: <437DEE35.2020703@motorola.com> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <43796DA7.3090507@kddilabs.jp> <20051117191448.461c9854.ernst@sfc.wide.ad.jp> <437DEE35.2020703@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: 0a7aa2e6e558383d84476dc338324fab 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 Alex, > >> I apologize if this is a bit too late to give comments on this, but > >> I belive this draft was silent for some time and so with an > >> attempt to raise some discussion, here are the ones that concerns > >> me. > >> > >> Issue A16: [VALIDATE B4 CLOSING 0510] NEMO-link vs mobile > >> subnet/link Proposition: By Thierry 0410: Since we agreed to keep > >> MNP instead of NEMO-prefix, I think it would be consistent to keep > >> mobile subnet or mobile link instead of NEMO-link. Comments ? > >> > >> I agree with this. Not just keeping it consistent with MNP, the > >> term NEMO-link is hard to grasp. I would suggent MNL as Mobile > >> Network Link, however I don't see the term "NEMO-link" used in RFC > >> 3963 so I don't know if we really need such term in the first > >> place. Any comments ? > > > > > > What I didn't like in the term "MNP" is the wording "mobile network" > > (many people are still confused with cellular networks for mobile > > devices), > > Probably use "moving network" instead of "mobile network"? > MNP: moving network prefix? This term cannot be changed. (see RFC 3753) > > VMN: assigned to a home link that doesn't belong to the mobile > > network > > VMN: its HA is different than MR's and is not on any link of that MR. Not necessarily. The VMN and the MR can be on the same home link, and in this case the VMN doesn't belong to the MR-administered area. In any case, as long as the MNN does need to obtain a CoA, it is considered a VMN. > draft nit: > > Its address is located within an MNP. > > "Derived from the MNP"? Do you propose a new definition ? If yes, can you state is fully, and can we get people to agree / disagree ? Before you do this, is this needed, I mean please think to yourself how much it does improve the definition (if it does). Thierry -- 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 Sun Nov 20 22:05:22 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 1Ee1ze-0003bo-FI; Sun, 20 Nov 2005 22:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1zc-0003be-KH for nemo@megatron.ietf.org; Sun, 20 Nov 2005 22:05: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 WAA28567 for ; Sun, 20 Nov 2005 22:04:43 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee2Hx-00049E-Tw for nemo@ietf.org; Sun, 20 Nov 2005 22:24:20 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6609E4CC73 for ; Mon, 21 Nov 2005 12:05:09 +0900 (JST) Date: Mon, 21 Nov 2005 12:04:58 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: Sub-optimal Terminology Message-Id: <20051121120458.450b11d2.ernst@sfc.wide.ad.jp> In-Reply-To: <437E22AB.6090908@levkowetz.com> References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> <437C7CF4.3070601@levkowetz.com> <437E1E9D.4050809@motorola.com> <437E22AB.6090908@levkowetz.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: c1c65599517f9ac32519d043c37c5336 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 > > Henrik Levkowetz wrote: > > > Multi-angular already exists as a word, used in the sense "Viewed > > > from multiple angles (directions)". > > Oh, I didn't know that. That's not an IETF definition, so I don't see the point to stick to it. Otherwise, how would you define triangular ? "Viewed from tri angles (directions)" ? My point was that since "triangular" is used to describe the MIP6 problem, it makes "multiangular" a good term to describe the NEMO term. The other proposed term are "exotic" from the perspective of consistency with older terms used in the mobility literature. > on 2005-11-18 19:34 Alexandru Petrescu said the following: > [...] > > Google finds many hits for "pinball routing" in NEMO texts, so it > > could be considered an established term as well. > > Ah, Ok. Definition ? > > >> As alternatives for your consideration, what about: * Nested > >> triangular * Nested dog-leg * Compound triangular * Compound > >dog-leg > > > > "dog-leg" can have only three segments (bones). Yes, and besides this is really not a nice term, IMHO. > Yes. But in nested dog-legs you may have one bone contain a dog-leg? > > (I don't like this a lot myself, though...) > > > zigzag. > > That's pretty good. I like that. With what definition ? I prefer pinball because there is a long history of using it. Thierry. From nemo-bounces@ietf.org Sun Nov 20 22:12:30 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 1Ee26Y-0004an-KI; Sun, 20 Nov 2005 22:12:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee26X-0004ai-MD for nemo@megatron.ietf.org; Sun, 20 Nov 2005 22:12:29 -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 WAA28809 for ; Sun, 20 Nov 2005 22:11:52 -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 1Ee2Ot-0004HU-I4 for nemo@ietf.org; Sun, 20 Nov 2005 22:31:29 -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 jAL3BqtN005739; Mon, 21 Nov 2005 12:11:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAL3BsZ23216; Mon, 21 Nov 2005 12:11:54 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id jAL3Bnu26927; Mon, 21 Nov 2005 12:11:49 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 11:08:45 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 193E1D54FC; Mon, 21 Nov 2005 11:16:31 +0800 (SGT) Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <43813545.9070804@sfc.wide.ad.jp> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Nov 2005 11:16:31 +0800 Message-Id: <1132542991.31961.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 21 Nov 2005 03:08:45.0426 (UTC) FILETIME=[E2745D20:01C5EE48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Mon, 2005-11-21 at 11:47 +0900, Romain KUNTZ wrote: > Hello Chan-Wah, > > Chan-Wah Ng wrote: > >>A split NEMO occurs when a single mobile subnet connected to multiple > >>Mobile Routers, or multiple mobile subnets interconnected with routers, > >>become two or more independant mobile subnets. > > > > It all depends on what is the motivation for the inclusion of the > > split-NEMO definition. I thought the motivation was to assist in > > illustrating the problem of split NEMO as documented in > > draft-ietf-nemo-multihoming-issues. If this is indeed the case, then > > the definition of split-NEMO should define cases only when the problem > > of split NEMO occurs. > > I agree. So do you see other case than (n,1,1) with the following topology: > > > | | | | > MR1 MR2 MR1 MR2 > | | -> | | > ---------- ----- ----- > > (ie multiple MRs attached to the same mobile subnet on their ingress > interface, registering the same prefix to the same HA) > > where split NEMO is a problem? > No, I do not at this moment. Although strictly speaking , all (n,>=1,>=1) networks will face the same problem, but these can always be decomposed to multiple (n,1,1)s. Hence, I would modify the definition of split-NEMO to: Split-NEMO refers to case where a mobile network that has multiple mobile routers handling the same MNP (or MNPs) becoming two or more independent mobile networks. One can go on to be more specific, such as adding "where the aforementioned group of mobile routers handling the same MNP(s) are no longer all residing in the same mobile network". That may seems messy, but is more accurate. The above definition avoids the use of mobile subnet, in case someone in the future, against all odds, come up with a split-NEMO configuration that has a LFR in between, the definition still fits :). /rgds /cwng From nemo-bounces@ietf.org Mon Nov 21 04:31:11 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 1Ee811-0006wT-Dl; Mon, 21 Nov 2005 04:31:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee810-0006wH-72 for nemo@megatron.ietf.org; Mon, 21 Nov 2005 04:31:10 -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 EAA16150 for ; Mon, 21 Nov 2005 04:30:32 -0500 (EST) Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee8JP-0004qN-Cv for nemo@ietf.org; Mon, 21 Nov 2005 04:50:12 -0500 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5404237E4D; Mon, 21 Nov 2005 10:30:46 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 24F9D37E43; Mon, 21 Nov 2005 10:30:46 +0100 (CET) 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 11B5F37E45; Mon, 21 Nov 2005 10:30:45 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1Ee80a-0000rd-1y; Mon, 21 Nov 2005 10:30:44 +0100 Message-ID: <438193C3.8070309@levkowetz.com> Date: Mon, 21 Nov 2005 10:30:43 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> <437C7CF4.3070601@levkowetz.com> <437E1E9D.4050809@motorola.com> <437E22AB.6090908@levkowetz.com> <20051121120458.450b11d2.ernst@sfc.wide.ad.jp> In-Reply-To: <20051121120458.450b11d2.ernst@sfc.wide.ad.jp> 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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-11-21 04:04 Thierry Ernst said the following: >> > Henrik Levkowetz wrote: >> > > Multi-angular already exists as a word, used in the sense "Viewed >> > > from multiple angles (directions)". >> > Oh, I didn't know that. > > That's not an IETF definition, so I don't see the point to stick to it. > Otherwise, how would you define triangular ? "Viewed from tri angles > (directions)" ? My point was that since "triangular" is used to describe > the MIP6 problem, it makes "multiangular" a good term to describe the > NEMO term. No! Triangular _does not_ mean viewed from 3 angles, it means having 3 line joins (corners); but multi-angular _does_ mean viewed from multiple angles. Never underestimate the idiosyncrasies of the English language ;-) If you use this, you are going to confuse people needlessly. > The other proposed term are "exotic" from the perspective of consistency > with older terms used in the mobility literature. > >> on 2005-11-18 19:34 Alexandru Petrescu said the following: >> [...] >> > Google finds many hits for "pinball routing" in NEMO texts, so it >> > could be considered an established term as well. >> >> Ah, Ok. > > Definition ? > >> >> >> As alternatives for your consideration, what about: * Nested >> >> triangular * Nested dog-leg * Compound triangular * Compound >> >dog-leg >> > >> > "dog-leg" can have only three segments (bones). > > Yes, and besides this is really not a nice term, IMHO. > >> Yes. But in nested dog-legs you may have one bone contain a dog-leg? >> >> (I don't like this a lot myself, though...) >> >> > zigzag. >> >> That's pretty good. I like that. > > With what definition ? I prefer pinball because there is a long history > of using it. "Pinball route" works for me. Henrik From nemo-bounces@ietf.org Mon Nov 21 05:48:48 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 1Ee9E8-0002tI-Tv; Mon, 21 Nov 2005 05:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee9E5-0002tA-Dm for nemo@megatron.ietf.org; Mon, 21 Nov 2005 05:48:47 -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 FAA20208 for ; Mon, 21 Nov 2005 05:48:07 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee9WU-0006qu-4C for nemo@ietf.org; Mon, 21 Nov 2005 06:07:48 -0500 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jALB19o4006591; Mon, 21 Nov 2005 04:01:09 -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 jALAwrPl012365; Mon, 21 Nov 2005 04:58:54 -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 9B12A865980; Mon, 21 Nov 2005 11:48:30 +0100 (CET) Message-ID: <4381A5FE.7070801@motorola.com> Date: Mon, 21 Nov 2005 11:48:30 +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: Thierry Ernst Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <43796DA7.3090507@kddilabs.jp> <20051117191448.461c9854.ernst@sfc.wide.ad.jp> <437DEE35.2020703@motorola.com> <20051121114732.45c25787.ernst@sfc.wide.ad.jp> In-Reply-To: <20051121114732.45c25787.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: 21c69d3cfc2dd19218717dbe1d974352 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 Thierry, Thierry Ernst wrote: >>>What I didn't like in the term "MNP" is the wording "mobile network" >>>(many people are still confused with cellular networks for mobile >>>devices), >> >>Probably use "moving network" instead of "mobile network"? > >>MNP: moving network prefix? > > This term cannot be changed. (see RFC 3753) Ok. >>>VMN: assigned to a home link that doesn't belong to the mobile >>>network >> >>VMN: its HA is different than MR's and is not on any link of that MR. > > Not necessarily. The VMN and the MR can be on the same home link, and > in this case the VMN doesn't belong to the MR-administered area. In any > case, as long as the MNN does need to obtain a CoA, it is considered a > VMN. Ok. >>draft nit: >> >>>Its address is located within an MNP. >> >>"Derived from the MNP"? > > > Do you propose a new definition ? If yes, can you state is fully, and > can we get people to agree / disagree ? Before you do this, is this > needed, I mean please think to yourself how much it does improve the > definition (if it does). It's not a new definition, it's a draft nit. Within the draft the phrase "Its address is located within an MNP" appears. It could be re-phrased into "Its address is derived from the...". Alex From nemo-bounces@ietf.org Mon Nov 21 06:37:29 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 1Ee9zF-00018W-3V; Mon, 21 Nov 2005 06:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee9zD-00017j-9n for nemo@megatron.ietf.org; Mon, 21 Nov 2005 06:37:27 -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 GAA22370 for ; Mon, 21 Nov 2005 06:36:49 -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 1EeAHd-0007ww-IG for nemo@ietf.org; Mon, 21 Nov 2005 06:56:31 -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/jazz) with ESMTP id jALBbD4Y024321; Mon, 21 Nov 2005 20:37:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jALBbEN08274; Mon, 21 Nov 2005 20:37:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id jALBbF700601; Mon, 21 Nov 2005 20:37:15 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 19:34:11 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 1B6F0D54FC; Mon, 21 Nov 2005 19:42:01 +0800 (SGT) Subject: Re: [nemo] Re: Sub-optimal Terminology From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051121120458.450b11d2.ernst@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC0178AB21@xmb-ams-337.emea.cisco.com> <20051117185134.544451e2.ernst@sfc.wide.ad.jp> <437C7CF4.3070601@levkowetz.com> <437E1E9D.4050809@motorola.com> <437E22AB.6090908@levkowetz.com> <20051121120458.450b11d2.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Nov 2005 19:42:00 +0800 Message-Id: <1132573321.31961.35.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 21 Nov 2005 11:34:11.0504 (UTC) FILETIME=[7E34A300:01C5EE8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 On Mon, 2005-11-21 at 12:04 +0900, Thierry Ernst wrote: > > on 2005-11-18 19:34 Alexandru Petrescu said the following: > > [...] > > > Google finds many hits for "pinball routing" in NEMO texts, so it > > > could be considered an established term as well. > > > > Ah, Ok. > > Definition ? > My attempt at one, to close this promptly: A pinball route refers to the non-direct path taken by packets sent between a MNN and a CN which is routed through one on more home agents. If necessary, the following sentence may be appended to add more flavor: A packet following a pinball route would appear like a ball bouncing off one or more home agents before reaching its final destination. /rgds /cwng From nemo-bounces@ietf.org Mon Nov 21 08:28:29 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 1EeBif-0001d5-OF; Mon, 21 Nov 2005 08:28:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBie-0001cv-PW for nemo@megatron.ietf.org; Mon, 21 Nov 2005 08:28:28 -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 IAA29819 for ; Mon, 21 Nov 2005 08:27:50 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeC16-0002sv-5L for nemo@ietf.org; Mon, 21 Nov 2005 08:47:33 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2005 14:28:19 +0100 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 jALDS2Ab000909; Mon, 21 Nov 2005 14:28:14 +0100 (MET) 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, 21 Nov 2005 14:27:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Sub-optimal Terminology Date: Mon, 21 Nov 2005 14:27:34 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01811BDB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Sub-optimal Terminology Thread-Index: AcXukJOwWQHVA0RSTwWxuzoULiWhpgADcSGg From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Thierry Ernst" X-OriginalArrivalTime: 21 Nov 2005 13:27:40.0492 (UTC) FILETIME=[58ADC0C0:01C5EE9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 >> > >My attempt at one, to close this promptly: > > A pinball route refers to the non-direct path taken by packets > sent between a MNN and a CN which is routed through one on more > home agents. [] I like this. It could refer to why packets are bouncing all over the Internet, because of the nested NEMO. What do you think of: A pinball route refers to the non-direct path taken by packets,=20 which are routed via one on more Home Agents, as they transit between a MNN in a nested NEMO and a correspondent. > >If necessary, the following sentence may be appended to add more flavor: > > A packet following a pinball route would appear like a ball > bouncing off one or more home agents before reaching its final > destination. > [] This is neat :) Pascal From nemo-bounces@ietf.org Mon Nov 21 21:13:45 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 1EeNfF-0006da-B9; Mon, 21 Nov 2005 21:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNfB-0006dC-5X for nemo@megatron.ietf.org; Mon, 21 Nov 2005 21:13:43 -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 VAA19697 for ; Mon, 21 Nov 2005 21:13:02 -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 1EeNxj-0007P6-3B for nemo@ietf.org; Mon, 21 Nov 2005 21:32: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/kings) with ESMTP id jAM2DREH026181; Tue, 22 Nov 2005 11:13:27 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jAM2DS102475; Tue, 22 Nov 2005 11:13:28 +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 jAM2DQY03983; Tue, 22 Nov 2005 11:13:27 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 10:10:22 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id 26A39D54FC; Tue, 22 Nov 2005 10:18:17 +0800 (SGT) Subject: RE: [nemo] Re: Sub-optimal Terminology From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01811BDB@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC01811BDB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 22 Nov 2005 10:18:16 +0800 Message-Id: <1132625896.31961.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 22 Nov 2005 02:10:22.0684 (UTC) FILETIME=[E51219C0:01C5EF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Mon, 2005-11-21 at 14:27 +0100, Pascal Thubert (pthubert) wrote: > >> > > > >My attempt at one, to close this promptly: > > > > A pinball route refers to the non-direct path taken by packets > > sent between a MNN and a CN which is routed through one on more > > home agents. > > [] I like this. It could refer to why packets are bouncing all over > the Internet, because of the nested NEMO. What do you think of: > > > A pinball route refers to the non-direct path taken by packets, > which are routed via one on more Home Agents, as they transit > between a MNN in a nested NEMO and a correspondent. > > The question is whether we want to restrict "pinball route" to nested NEMO, or generalize it to include the so-called "triangular routing" as well. If you want a general term, than I would modify Pascal's definition to look a bit more like mine: A pinball route refers to the non-direct path taken by packets, which are routed via one or more Home Agents, as they transit between a Mobile Network Node and a Correspondent Node. By the way, use "pinball" or "pin-ball" as you see fit, but I think "pinball" is the prevalent one. /rgds /cwng > > > >If necessary, the following sentence may be appended to add more > flavor: > > > > A packet following a pinball route would appear like a ball > > bouncing off one or more home agents before reaching its final > > destination. > > > > [] This is neat :) > > Pascal > From nemo-bounces@ietf.org Mon Nov 21 23:00:20 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 1EePKN-0005hI-Ub; Mon, 21 Nov 2005 23:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EePKM-0005h6-Ce for nemo@megatron.ietf.org; Mon, 21 Nov 2005 23:00:18 -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 WAA29762 for ; Mon, 21 Nov 2005 22:59:40 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EePcv-0002hd-Aw for nemo@ietf.org; Mon, 21 Nov 2005 23:19:30 -0500 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 130544CA55; Tue, 22 Nov 2005 12:59:48 +0900 (JST) Message-ID: <43829840.4090501@sfc.wide.ad.jp> Date: Tue, 22 Nov 2005 13:02:08 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> In-Reply-To: <1132542991.31961.14.camel@localhost> 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 Cc: Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: >>I agree. So do you see other case than (n,1,1) with the following topology: >> >> >> | | | | >> MR1 MR2 MR1 MR2 >> | | -> | | >> ---------- ----- ----- >> >>(ie multiple MRs attached to the same mobile subnet on their ingress >>interface, registering the same prefix to the same HA) >> >>where split NEMO is a problem? >> > > > No, I do not at this moment. Although strictly speaking , all > (n,>=1,>=1) networks will face the same problem, but these can always be > decomposed to multiple (n,1,1)s. > > Hence, I would modify the definition of split-NEMO to: > > Split-NEMO refers to case where a mobile network that has > multiple mobile routers handling the same MNP (or MNPs) becoming > two or more independent mobile networks. > > One can go on to be more specific, such as adding "where the > aforementioned group of mobile routers handling the same MNP(s) are no > longer all residing in the same mobile network". That may seems messy, > but is more accurate. IMHO it is good to be accurate, in order to identify when the problem occurs. So what about this one: Split-NEMO refers to the case where a mobile network that has multiple mobile routers handling the same MNP (or MNPs) becomes two or more independent mobile networks, where the same MNP(s) are no longer advertised in the same mobile network. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Tue Nov 22 01:45: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 1EeRtu-0005yr-7g; Tue, 22 Nov 2005 01:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRnY-0003vb-6A for nemo@megatron.ietf.org; Tue, 22 Nov 2005 01:38:37 -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 BAA05426 for ; Tue, 22 Nov 2005 01:37:55 -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 1EeRrv-0003Y3-RS for nemo@ietf.org; Tue, 22 Nov 2005 01:43:09 -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 jAM6NhEH002787; Tue, 22 Nov 2005 15:23:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAM6Nh108643; Tue, 22 Nov 2005 15:23:43 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id jAM6Nhm20529; Tue, 22 Nov 2005 15:23:43 +0900 (JST) Received: from bach.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 14:20:38 +0800 Received: by bach.psl.com.sg (Postfix, from userid 1000) id E5918D54FC; Tue, 22 Nov 2005 14:28:33 +0800 (SGT) Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <43829840.4090501@sfc.wide.ad.jp> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> <43829840.4090501@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 22 Nov 2005 14:28:33 +0800 Message-Id: <1132640913.31961.67.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 22 Nov 2005 06:20:38.0403 (UTC) FILETIME=[DB22FD30:01C5EF2C] 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 Tue, 2005-11-22 at 13:02 +0900, Romain KUNTZ wrote: > Chan-Wah Ng wrote: > >>I agree. So do you see other case than (n,1,1) with the following topology: > >> > >> > >> | | | | > >> MR1 MR2 MR1 MR2 > >> | | -> | | > >> ---------- ----- ----- > >> > >>(ie multiple MRs attached to the same mobile subnet on their ingress > >>interface, registering the same prefix to the same HA) > >> > >>where split NEMO is a problem? > >> > > > > > > No, I do not at this moment. Although strictly speaking , all > > (n,>=1,>=1) networks will face the same problem, but these can always be > > decomposed to multiple (n,1,1)s. > > > > Hence, I would modify the definition of split-NEMO to: > > > > Split-NEMO refers to case where a mobile network that has > > multiple mobile routers handling the same MNP (or MNPs) becoming > > two or more independent mobile networks. > > > > One can go on to be more specific, such as adding "where the > > aforementioned group of mobile routers handling the same MNP(s) are no > > longer all residing in the same mobile network". That may seems messy, > > but is more accurate. > > IMHO it is good to be accurate, in order to identify when the problem > occurs. So what about this one: > > Split-NEMO refers to the case where a mobile network that has > multiple mobile routers handling the same MNP (or MNPs) becomes > two or more independent mobile networks, where the same MNP(s) > are no longer advertised in the same mobile network. > Hmm, I am doubtful about the last sentence, especially the last few words "same mobile networks". The problem with split-NEMO is that the MRs cannot announce the same MNP to different NEMO. May I offer an entirely different definition: Split-NEMO refers to the case where a mobile network becomes two or more independent mobile networks due to the separation of Mobile Routers which are handling the same MNP (or MNPs) in the original mobile network before separation. /rgds /cwng From nemo-bounces@ietf.org Tue Nov 22 04:04:42 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 1EeU4w-0000fl-71; Tue, 22 Nov 2005 04:04:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeU4v-0000fd-9L for nemo@megatron.ietf.org; Tue, 22 Nov 2005 04:04:41 -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 EAA19719 for ; Tue, 22 Nov 2005 04:04:01 -0500 (EST) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeUNU-0007CJ-Ti for nemo@ietf.org; Tue, 22 Nov 2005 04:23:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B8151EC8EA; Tue, 22 Nov 2005 18:04:01 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5C090EC8E9; Tue, 22 Nov 2005 18:04:01 +0900 (JST) Received: from [IPv6:2001:200:601:200:31ce:7e27:e9bc:fd57] (unknown [IPv6:2001:200:601:200:31ce:7e27:e9bc:fd57]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 242322E032; Tue, 22 Nov 2005 18:02:26 +0900 (JST) Message-ID: <4382DFEA.2030604@kddilabs.jp> Date: Tue, 22 Nov 2005 18:07:54 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: Sub-optimal Terminology References: <7892795E1A87F04CADFCCF41FADD00FC01811BDB@xmb-ams-337.emea.cisco.com> <1132625896.31961.42.camel@localhost> In-Reply-To: <1132625896.31961.42.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On 2005/11/22 11:18, Chan-Wah Ng wrote: > On Mon, 2005-11-21 at 14:27 +0100, Pascal Thubert (pthubert) wrote: > >>>My attempt at one, to close this promptly: >>> >>> A pinball route refers to the non-direct path taken by packets >>> sent between a MNN and a CN which is routed through one on more >>> home agents. >> >>[] I like this. It could refer to why packets are bouncing all over >>the Internet, because of the nested NEMO. What do you think of: >> >> A pinball route refers to the non-direct path taken by packets, >> which are routed via one on more Home Agents, as they transit >> between a MNN in a nested NEMO and a correspondent. > > The question is whether we want to restrict "pinball route" to nested > NEMO, or generalize it to include the so-called "triangular routing" as > well. If you want a general term, than I would modify Pascal's > definition to look a bit more like mine: > > A pinball route refers to the non-direct path taken by packets, > which are routed via one or more Home Agents, as they transit > between a Mobile Network Node and a Correspondent Node. The term should not be limited to nested topology, so this fits better I think. > By the way, use "pinball" or "pin-ball" as you see fit, but I think > "pinball" is the prevalent one. > >>>If necessary, the following sentence may be appended to add more >> >>flavor: >> >>> A packet following a pinball route would appear like a ball >>> bouncing off one or more home agents before reaching its final >>> destination. >>> >> >>[] This is neat :) I suggest we keep it. watari From nemo-bounces@ietf.org Tue Nov 22 09:31:31 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 1EeZBD-0002Rd-NU; Tue, 22 Nov 2005 09:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZBB-0002RG-MZ for nemo@megatron.ietf.org; Tue, 22 Nov 2005 09:31:30 -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 JAA23579 for ; Tue, 22 Nov 2005 09:30:50 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZTp-0006HU-By for nemo@ietf.org; Tue, 22 Nov 2005 09:50:47 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2005 15:31:19 +0100 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 jAMEVBAV010300; Tue, 22 Nov 2005 15:31:15 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Nov 2005 15:31:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network Date: Tue, 22 Nov 2005 15:31:07 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0181210B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXqo40Do6Plc/6iStuw6hiomGMBGQAKBKpQACjfTeAABC8RsAA46RygAAAhndAAw0NPMA== From: "Pascal Thubert \(pthubert\)" To: "Roberto Baldessari" , "nemo" X-OriginalArrivalTime: 22 Nov 2005 14:31:11.0380 (UTC) FILETIME=[628EDD40:01C5EF71] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: manemo@mobileip.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Roberto.=20 You're welcome in :) It seems that you can at least help in securing the requirements and writing a charter, to make sure that your interests are covered. For instance, you expect the MANET to be there, but which properties do you assume in the MANET? Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Roberto Baldessari >Sent: Friday, November 18, 2005 7:02 PM >To: nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited network > > >Thanks Pascal, > >I have already subscribed the list and had a look to the mail archive. >It seems like you are searching for concrete scenarios, and you already >mentioned what we also are dealing with, i.e. car to car communication. >We are considering different strategies and we could contribute to this >starting group. But first we need to gather some information more. >Actually we are not interested in routing protocols, because we assume >the MANET already provided with that. > >Best regrards. > >Roberto > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Friday, November 18, 2005 6:17 PM >To: Roberto Baldessari; nemo >Subject: RE: [nemo] Distributing the Mobile Prefix in the visited >network > >Hi Roberto: > >There is a MANEMO list http://www.mobileip.jp/mailman/listinfo/manemo >But we did not start a BOF yet. > >I guess it's a matter of raising interest and relating the effort with >NEMO. The more people show interest, the better off we are :) > >Pascal > >>-----Original Message----- >>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of >Roberto Baldessari >>Sent: Thursday, November 17, 2005 3:21 PM >>To: nemo >>Subject: RE: [nemo] Distributing the Mobile Prefix in the visited >network >> >> >>Pascal, >> >>thank you. It seems like the MANEMO matches what we are interested in. >>How is the status of that? I didn't find material about. >> >>Regards >> >>Roberto >> >> >>-----Original Message----- >>From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>Sent: Thursday, November 17, 2005 1:09 PM >>To: Roberto Baldessari; nemo >>Subject: RE: [nemo] Distributing the Mobile Prefix in the visited >>network >> >> >> >>>-----Original Message----- >>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf >Of >>Roberto Baldessari >>>Sent: Wednesday, November 16, 2005 6:36 PM >>>To: nemo >>>Subject: [nemo] Distributing the Mobile Prefix in the visited network >>> >>>Hi all, >>> >>>I'm new of this mailing list. >>>I have a question related to the Basic NEMO Protocol. >>>The RFC says: >>> >>>" A Mobile Router does not distribute the >>> Mobile Network routes to the infrastructure at its point of >>> attachment (i.e., in the visited network) " >>> >>>How should this be inteded? In case a MR distributes the Mobile Prefix > >>>in the visited network, in a way that the Mobile Network is routable >>>directly from the visited network, is the MR non-standard? >>> >>[] The goal in NEMO was to move prefix around without any route >>injection in the infrastructure. But there is no MUST or MUST NOT the >>text you mention. >> >>Francis provided good reasons why this is not done, in general. The >spec >>does not provide the means for doing it, does not discuss the risks and > >>the consequences if this is done. It's just completely out of scope. >> >>But it does not say, never to do it, either. An example where you might > >>do it is MANEMO, when MRs form a MANET for such purposes as route >>optimization. >> >>Pascal From nemo-bounces@ietf.org Wed Nov 23 12:08:22 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 1Eey6Y-0001KZ-Gk; Wed, 23 Nov 2005 12:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eey6W-0001K3-Lr for nemo@megatron.ietf.org; Wed, 23 Nov 2005 12:08: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 MAA27809 for ; Wed, 23 Nov 2005 12:07:41 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeyPP-0006Eq-5l for nemo@ietf.org; Wed, 23 Nov 2005 12:27:52 -0500 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D46CA10ECD; Wed, 23 Nov 2005 18:08:09 +0100 (CET) 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] Distributing the Mobile Prefix in the visited network Date: Wed, 23 Nov 2005 18:08:08 +0100 Message-ID: Thread-Topic: [nemo] Distributing the Mobile Prefix in the visited network Thread-Index: AcXsZVeBsrI0oU6xSRyrl7jMxMvlkAD6aWLg From: "Roberto Baldessari" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable 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 Alexandru, thanks for your feedback. The dhcpv6 prefix delegation doesn't seem to match our needs. This draft relies on the MR-HA tunnel to exchange dhcp packets. We are considering the case the MR doesn't have continuosly access to the infrastructure, but is continuosly member of a MANET. We don't consider Mobile Network Prefix' changes. Best regards Roberto -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Friday, November 18, 2005 6:27 PM To: Roberto Baldessari Cc: nemo Subject: Re: [nemo] Distributing the Mobile Prefix in the visited network Roberto Baldessari wrote: > =20 > Pascal, >=20 > thank you. It seems like the MANEMO matches what we are interested in. > How is the status of that? I didn't find material about. Would dhcpv6-pd draft-ietf-nemo-dhcpv6-pd-00.txt match the interest? The draft has text in it about AR distributing prefixes to a moving MR. It's not clear though whether session continuity is required. Are you interested in session continuity at LFN when MR gets a new prefix? Alex From nemo-bounces@ietf.org Thu Nov 24 06:32:44 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 1EfFLI-0007cN-4Z; Thu, 24 Nov 2005 06:32:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFLF-0007au-Vw for nemo@megatron.ietf.org; Thu, 24 Nov 2005 06:32:42 -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 GAA17682 for ; Thu, 24 Nov 2005 06:32:00 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfFeG-0000f8-RR for nemo@ietf.org; Thu, 24 Nov 2005 06:52:23 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 578214DCC7 for ; Thu, 24 Nov 2005 20:32:25 +0900 (JST) Date: Thu, 24 Nov 2005 20:32:13 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Message-Id: <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> In-Reply-To: <1130929567.7004.5.camel@acorde> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> 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: b94423d57458a72e07b422b40e685d94 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, I have some more comments on ROSA - see inline - but before I do so, thanks very much for the nice writing of this draft ! The only real problem I have with the document is that the draft refers to so many drafts that will be expired at some point in time but besides this I think you have performed a very good and educative work in a very limited period of time ! Network Mobility Route Optimization Solution Space Analysis draft-ietf-nemo-ro-space-analysis-01 Abstract 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 1. Introduction Network Mobility Route Optimization Problem Statement [1] describes operational limitations and overheads incurred in a deployment of Network Mobility (NEMO) Basic Support [2], which could be alleviated by a set of NEMO Route Optimization techniques to be defined. For this purpose of NEMO, the term "Route Optimization" is accepted in a broader sense than already defined for IPv6 Host Mobility in [3], to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node. The defintion of RO above will appear in the terminology document. It is expected for readers to be familiar with general terminologies s / with general terminologies / with the terminology related to mobility in [3] and [4], and NEMO related terms defined in [5]. The sentence above should better be moved to the section terminology below. In addition, it is beneficial to keep in mind the design requirements of NEMO [6]. A point to note is that since this document discusses aspects of Route Optimization, the readers may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home. Wouldn't it better to move this in a section "assumption" where it would also be stated/ re-stated that NEMO Basic Support assumes a bi-directional tunnel to be established between any pair of (MR, its HAs) ? 1.1. Terminology You should write here the sentence that the terminology is defined in [3] and [4]. The terms below should still be in this section, but you should clarify that these termed are defined in [5] and copied here for purposes of clarity / reminder. Correspondent Router (CR) This refers to the entity which is capable of terminating a Route s / entity / router ??? Optimization session on behalf of a Correspondent Node. Correspondent Entity (CE) This refers to the entity which a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity maybe a Correspondent Node or Correspondent Router. I wonder if "Mobile Entity" (MR, or MNN) wouldn't allow you to simplify things later in the document. 2. Benefits of NEMO Route Optimization As the text is written, shouldn't this rather be entitled "Design Goals of NEMO RO" ? o Greater Data Efficiency s / Greater Data Efficiency / Reduced Packet Overhead ???? Depending on the actual solution for NEMO Route Optimization, the data packets exchanged between two end nodes may not require as many levels of encapsulation as that in NEMO Basic Support. This would mean less packet overheads, and higher data efficiency. In particular, avoiding packet fragmentation that may be induced by the multiple levels of tunneling is critical for end-to-end efficiency from the viewpoints of buffering and transport protocols. o Avoiding the Bottleneck in Home Network s / in Home / in the Home NEMO Route Optimization allows traffic to by-pass the Home Agents. s / alows / would allow [in paragraphs "may", "should" etc are used] Apart from having a more direct route, this also avoids routing traffic via the home network, which may be a potential bottleneck otherwise. o Avoid the Security Policy Issue Don't you rather mean "Ingress Filtering" ? Security policy may forbid Mobile Routers from tunneling traffic of Visiting Mobile Nodes into the home network of Mobile Router. s / of Mobile / of the Mobile Route Optimization can be used to avoid this issue by forwarding traffic from Visiting Mobile Nodes directly to their destination without going through the home network of the Mobile Router. It should however be taken into consideration that a Route Optimization mechanism may not be an appropriate solution since the Mobile Router may still be held responsible for illegal traffic sent from its Mobile Network Nodes even when Route Optimization is used. In addition, there can be a variety of different policies which might cause a conflict with the deployment of Route Optimization for Visiting Mobile Nodes. Being a policy issue, solving this with a protocol at the policy plane might be more appropriate. o Avoid the Instability and Stalemate [1] described a potential stalemate situation when a Home Agent is nested within a Mobile Network. Route Optimization may circumvent such stalemate situations by directly forwarding traffic upstream. However, it should be noted that certain Route Optimization schemes may require signaling packets to be first routed via the Home Agent before an optimized route can be established. In such cases, a Route Optimization solution cannot avoid the stalemate. I'm not sure the paragraph above is clear enough. 3.1. Basic NEMO Route Optimization I would find another word instead of "Basic". What about "not nested" ? We start off with a scenario where nesting of Mobile Routers is not considered, and Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router, also known as a Correspondent Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, and therefore Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Thus, providing Route Optimization for Visiting Mobile Node is often out of scope for such scenario because such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 1. From the definition of Correspondent Router, it does not limit itself to be mobile, but can also be an entity within the fixed infrastructure with similar functionalities. As long as the To me it looks like you are taking thinkgs from the reverse order and not very logical. Why not starting with the fixed case in the first place, and later in the section explain the a CR may indeed be mobile and thus be a mobile router, etc ? This form of optimization can carry traffic both directions identical to the previous example in Figure 1, or independently for the 2 directions of traffic: s / traffic both / traffic in both can carry traffic both directions identical = ?? Please rephrase. A straight-forward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This can be viewed as a logical extension to NEMO Basic Here again, it's not very logical. Above, the term "CR" is used, so why would one use "CE" now ? Support, where the Mobile Router would send binding updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity having received the binding update, can then set up a bi-directional tunnel with the 3.2. Nested Mobility Optimization Optimization in Nested Mobility targets scenarios where a nesting of mobility management protocols is created (i.e. Mobile IPv6 enabled host inside a mobile network or multiple Mobile Routers that attach behind one another creating a nested mobile network). Note that because Mobile IPv6 defines its own Route Optimization mechanism in its base protocol suite as a standard, collaboration with this and NEMO brings various complexity. NEMO = NEMO Basic Support ? 3.3. Infrastructure based Optimization Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a mobile network prefix from the access router using DHCP Prefix Delegation >From which AR ? AR from the parent-NEMO or root-NEMO ? [14]. Each Mobile Router also autoconfigures its care-of address from this delegated prefix. In this way, the care-of addresses of each Mobile Router are all from an aggregatable address space starting from the access router. This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes. 3.4. Intra-NEMO Optimization Another possibility is for the "Basic NEMO Route Optimization" technique (see Section 3.1) to be applied here. Using the same example of communication between MNN1 and MNN2, both MR3 and MR2 can treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1. An example of this approach is [15] which have Mobile Routers announce their Mobile Network Preifxes to other Mobile Routers in the same nested Mobile Network. s / which have / which has 4. Issues of NEMO Route Optimization Wouldn't it be better to phrase this as "requirements" rather than "issues" ? 4.3. Increased Delay during Handoff Another NEMO specific delay during handoff is that in a nested mobile network, a child Mobile Network Node may need to detect or be notified of the handoff of its parent Mobile Router so that it can begin signaling its own Correspondent Entities. Apart from the compromise of mobility awareness and location privacy, this mechanism also increases the delay during handoffs. Isn't this another issue/requirement: you are kind or releaving the "mobilty support transparency" requirement. (you may group some text from 4.3 and 4.7) Some of the solutions for Mobile IPv6, such as Fast Handoff for Mobile IPv6 [16], may be able to alleviate the increase in handoff delay. 4.4. New Functionalities Is this an issue ? Isn't there a better place ? 4.5. Detection of New Functionalities Is this an issue ? Isn't there a better place ? One issue that is related to the need for new functionalities as described in Section 4.4 is the need to detect the existence of such functionalities. In these cases, a detection mechanism might be helpful to allow the initiator of Route Optimization to detect if support of the new functionalities are available. Furthermore, it might be advantageous to have a graceful fall back procedure if the required functionalities are unavailable. 4.7. Mobility Transparency and Location Privacy One advantage of NEMO Basic Support is that the Correspondent Nodes and Mobile Network Nodes need not be aware of the actual location and mobility of the mobile network. With Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to other nodes, such as the Mobile Network Nodes or their Correspondent Nodes. This may mean a tradeoff between location privacy [17] (and mobility transparency) and Route Optimization. Agree with location privacy, but mobility may still be transparent to MNNs. You shouldn't group these issues/requirements togethers. 4.9. Support of Legacy Nodes NEMO Basic Support is designed so that all legacy Mobile Network Nodes (such as those who are not aware of the mobility of the network they are in, and those that do not understand any mobility protocols) can still reach and be reached from the Internet. Some Route Optimization shcemes, however, require that all Mobile Routers to schemes implement the same Route Optimization scheme in order for them to operate. For instance, a nested Mobile Router may not be able to achieve Route Optimization if it is attached to a legacy Local Fixed Router. I cannot find a link between the sentence "For instance ..." and the previous one. 5. Analysis of Solution Space 4. How is address of Mobile Network Node represented? s / is the address 5. How is address of Mobile Network Node bound to location of mobile network? s / is the address 6. How is signaling done? s / done / performed 7. How is data transmitted? 8. What are the security considerations? 5.1. Which Entities are Involved? There are many combinations of entities involved in Route Optimization. When considering the role each entity plays in Route Optimization, one has to bear in mind the considerations described in Section 4.4 and Section 4.5. Below is a list of combinations to be discussed in the following subsections: o Mobile Network Node and Correspondent Node o Mobile Router and Correspondent Node o Mobile Router and Correspondent Router o Entities in the Infrastructure 5.1.1. Mobile Network Node and Correspondent Node A Mobile Network Node can establish Route Optimization with its Correspondent Node, possibly the same way as a Mobile Node establishes Route Optimization with its Correspondent Node in Mobile IPv6. This would achieve the most optimal route, since the entire end-to-end path is optimized. However, there might be scalability issues since both the Mobile Network Node and the Correspondent Node To the condition the MNN knows when it is located in a nested NEMO. This is just an observation, but, from this, I came to think you may be able to draw a table issues/requirements vs scenarios 5.1.1-4. may need to maintain many Route Optimization sessions. In addition, new functionalities would be required for both the Mobile Network Node and Correspondent Node. What kind of functionalities ? In 5.1.3 you briefly detail what the functionalities should be, I think the same should be done in each section. Here there might be a need for the MNN to know its "depth" in the NEMO. 5.1.2. Mobile Router and Correspondent Node Alternatively, Mobile Router can establish Route Optimization with a s / the Mobile Router Correspondent Node on behalf of the Mobile Network Node. Since the Mobile Router is merely one hop away from the Mobile Network Node, Not in the nested case. this effectively achieves an optimal route for the entire end-to-end path as well. Compared with Section 5.1.1, the scalability issue here may be remedied since it is possible for Correspondent Node to maintain only one session with Mobile Router if it communicates with many Mobile Network Nodes associated with Mobile Router. s / with the same Mobile Router I think that in most cases the sessions would be split between several (potentialy nearby) CNs., so this observation is more realistic in the CR case. 5.2. Who and When to Initiate Route Optimization? A related question is how often signaling messages should be sent to maintain the Route Optimization session. Typically, signaling messages is likely to be sent whenever there is topological changes. The discussion in Section 4.1 should be considered. In addition, a Lifetime value is often used to indicate the period of validity for the Route Optimization session. Signaling messages would have to be sent before the Lifetime value expires in order to maintain the Route Optimization session. The choice of Lifetime value needs to balance between different considerations. On one hand, a short Lifetime value would increase the amount of signaling overhead. On the other hand, a long Lifetime value may expose the Correspondent Entity to the risk of having an obsolete binding cache entry, which creates an opportunity for an attacker to exploit. Just wondering: shouldn't the tradeoffs be discussed in section 4, in an independant paragraph ? 5.3. How to Detect Route Optimization Capability? mechanism is using in-band-signalling. s / signalling / signaling 5.4. How is Address of Mobile Network Node Represented? s / is / is the Normally, Route Optimization would mean that a binding between the address of Mobile Network Node and the location of the mobile network s / of / of a is registered at the Correspondent Entity. Before exploring into different ways of binding (see Section 5.5), one must first ask how the address of the Mobile Network Node is represented. Basically, there are two ways to represent the Mobile Network Node's address: o inferred by the use of Mobile Network Prefix, or o explicitly specifying the address of Mobile Network Node. s / of / of the Using the Mobile Network Prefix would usually mean that the initiator is the Mobile Router, and has the benefit of binding numerous Mobile Network Nodes with one signaling. However, it also means that if location privacy is compromised, the location privacy of an entire Mobile Network Prefix will be compromised. s / will / would On the other hand, using the Mobile Network Node's address would mean that the initiator is either the Mobile Network Node itself, or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node. 5.5. How is Mobile Network Node's Address Bound to Location? In order for route to be optimized, it is generally necessary for the Correspondent Entity to create a binding between the address and the location of the Mobile Network Node. This can be done in the following ways: o binding the address to the location of the parent Mobile Router; o binding the address to a sequence of locations of upstream Mobile Routers; and o binding the address to the location of the root Mobile Router Don't we need to discuss "binding a prefix" ? Also, shouldn't we use the term "locator" ? These will be described in the following sub-sections. s / will be / are 5.5.1. Binding to the Location of Parent Mobile Router o Binding Update with Mobile Network Prefix mobile network prefix will be routed through the bi-directional tunnel. s / will / would Note that in this case, the address of the Mobile Network Node is implied by the Mobile Network Prefix (see Section 5.4). o Sending Information of Parent Mobile Router This involves the Mobile Network Node sending the information of its Mobile Router to the Correspondent Entity, thus allowing the Correspondent Entity to establish a binding between the address of the Mobile Network Node to the location of the parent Mobile Router. An example of such an approach would be [10]. o Mobile Router as a Proxy Another approach is for the parent Mobile Router to act as a "proxy" for its Mobile Network Nodes. In this case, the Mobile Router uses standard Mobile IPv6 Route Optimization procedure to bind the address of a Mobile Network Node to the Mobile Router's care-of address. For instance, when the Mobile Network Node is a Local Fixed Node without Mobile IPv6 Route Optimization functionality, the Mobile Router may initiate teh Return Routability procedure with a Correspondent Node on behalf of the Local Fixed Node. An example of such an approach would be [19]. CN or CE ? 5.5.2. Binding to a Sequence of Locations of Upstream Mobile Routers One question that immediately comes to the mind is how the Mobile s / the mind / mind Network. In addition, some amount of modifications or extension to existing protocols is also required, such as a new type of IPv6 routing header, or new options in Router Advertisement messages. please choose either "singular form" or "plural form". 5.5.3. Binding to the Location of Root Mobile Router o Neighbor Discovery Proxy This approach (such as [23]) achieves Route Optimization by having Mobile Routers to act as a Neighbor Discovery [24] proxy for its s / its / their ? Mobile Network Nodes. Mobile Router will configure a care-of s / Mobile Router / the root Mobile Router ? address from the network prefix advertised by its access router, and also relay this prefix to its subnets. When a Mobile Network Node configures an address from this prefix, the Mobile Router will act as a Neighbor Discovery proxy on its behalf. In this when ... will: no future tense after "if", "when" etc. way, the entire mobile network and its access network form a logical multilink subnet, thus eliminating any nesting. This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the root Mobile Router to act as a Neighbor Discovery proxy for all the Mobile Network Nodes that are directly or indirectly attached to it. This increases the processing load of the root Mobile Router. In addition, a change in the point of attachment of the root Mobile Router will require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their care-of addresses. Not only will this cause a burst of Binding Updates where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities, it will also cause a burst of Duplicate Address Discovery messages to be exchanged between the mobile network and the access network. Furthermore, route optimization for Local Fixed Nodes is not possible without new functionalities implemented on the Local Fixed Nodes. At LFNs, these are functionalities not related to mobility support. I think we need to draw a line between mobility-related functionalities and other. The other ones could be referred to as "requirements" to distinguish between the two. o Hierarchical Registrations Hierarchical Registration involves Mobile Network Nodes (including nested Mobile Routers) to register itself with either their parent s / itself / themselves Mobile Routers, or the root Mobile Router itself. After registrations, Mobile Network Nodes would tunnel packets directly to the upstream Mobile Router they register with. At the root Mobile Router, packets tunneled from sub-Mobile Routers or Mobile Network Nodes are tunneled directly to the Correspondent Entities, thus avoiding nested tunneling. 5.6. How is Signaling Performed? An entirely different method of signaling makes use of upper layer protocol to establish the bindings between the address of a Mobile s / protocol / protocols Network Node and the location of the mobile network. Such binding information can then be passed down to the IP layer to insert the appropriate entry in the Binding Cache or routing table. An example of such mechanism is [27] which uses the Session Initiation Protocol (SIP) to relay binding information. 5.7. How is Data Transmitted? With Route Optimization established, one remaining question to be answered is how data packets can be routed to follow the optimized route. There are the following possible approaches: o Encapsulations For instance, if the Correspondent Entity knows the full sequence of points of attachment, it might be necessary for there to be multiple encapsulations in order to forward the data packet through each point of attachment. This may lead to the need for multiple tunnels and extra packet header overhead. It is possible to alleviate this by using Robust Header Compression techniques [29][30] to compress the multiple tunnel packet headers. I think draft-minaburo-rohc-nemo-01.txt should be cited here - it's not about RO but it is focused on NEMO BS. 8. Security Considerations This is an informational document that analyze the solution space of s / analyzes 10. References I've noticed that in many cases only the 1st author is mentioned. Also, when there is a published paper, wouldn't it be better in the "informative section" to provide the reference of a published paper rather than I-D which are bound to be deleted from the IETF reposirory (if not already) ? I think published papers exist for many of the references. Thierry. From nemo-bounces@ietf.org Thu Nov 24 08:17: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 1EfGyM-0005CK-82; Thu, 24 Nov 2005 08:17:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGyK-00059e-TL for nemo@megatron.ietf.org; Thu, 24 Nov 2005 08:17:08 -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 IAA28632 for ; Thu, 24 Nov 2005 08:16:29 -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 1EfHHN-00052Y-Pm for nemo@ietf.org; Thu, 24 Nov 2005 08:36:51 -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 jAODGfEH008410; Thu, 24 Nov 2005 22:16:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jAODGgb06852; Thu, 24 Nov 2005 22:16:42 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id jAODGg301909; Thu, 24 Nov 2005 22:16:42 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Nov 2005 21:13:36 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 5669FD560D; Thu, 24 Nov 2005 21:21:21 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 24 Nov 2005 21:21:20 +0800 Message-Id: <1132838480.11586.90.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 24 Nov 2005 13:13:36.0995 (UTC) FILETIME=[E1279330:01C5F0F8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 634fdbde3f75ae1fea5a01ebf03b5480 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 Thierry, thanks for the comments. See responses in-line. On Thu, 2005-11-24 at 20:32 +0900, Thierry Ernst wrote: > Hi, > > I have some more comments on ROSA - see inline - but before I do so, > thanks very much for the nice writing of this draft ! > > The only real problem I have with the document is that the draft refers > to so many drafts that will be expired at some point in time but besides > this I think you have performed a very good and educative work in a > very limited period of time ! > > > Network Mobility Route Optimization Solution Space Analysis > draft-ietf-nemo-ro-space-analysis-01 > > > > Abstract > > 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 > > > > 1. Introduction > > Network Mobility Route Optimization Problem Statement [1] describes > operational limitations and overheads incurred in a deployment of > Network Mobility (NEMO) Basic Support [2], which could be alleviated > by a set of NEMO Route Optimization techniques to be defined. For > this purpose of NEMO, the term "Route Optimization" is accepted in a > broader sense than already defined for IPv6 Host Mobility in [3], to > loosely refer to any approach that optimizes the transmission of > packets between a Mobile Network Node and a Correspondent Node. > > The defintion of RO above will appear in the terminology document. Ok, we will synchronize with the terminology draft, and see if it is necessary to modify the text here. > > It is expected for readers to be familiar with general terminologies > > s / with general terminologies / with the terminology OK. > > related to mobility in [3] and [4], and NEMO related terms defined in > [5]. > > The sentence above should better be moved to the section terminology > below. > Well, *IF* there is going to be one. It has always been our intention (or at least mine) that the terminology sub-section is a temporary one. Once the terminologies we used are in the terminology draft, I see no benefit in retaining this section. > In addition, it is beneficial to keep in mind the design > requirements of NEMO [6]. A point to note is that since this > document discusses aspects of Route Optimization, the readers may > assume that a mobile network or a mobile host is away when they are > mentioned throughout this document, unless it is explicitly specified > that they are at home. > > Wouldn't it better to move this in a section "assumption" where it would > also be stated/ re-stated that NEMO Basic Support assumes a > bi-directional tunnel to be established between any pair of (MR, its > HAs) ? > Good point. The usefulness of the "Assumption" section would depends on whether we do have any general assumptions made. > 1.1. Terminology > > You should write here the sentence that the terminology is defined in > [3] and [4]. The terms below should still be in this section, but you > should clarify that these termed are defined in [5] and copied here for > purposes of clarity / reminder. > Possibly, if we (ie WG) what to do that. > Correspondent Router (CR) > > This refers to the entity which is capable of terminating a Route > > s / entity / router ??? If this text remains, I would simply copy it from the terminology draft. If you use 'router', we would use 'router' :) > > Optimization session on behalf of a Correspondent Node. > > Correspondent Entity (CE) > > This refers to the entity which a Mobile Router or Mobile Network > Node attempts to establish a Route Optimization session with. > Depending on the Route Optimization approach, the Correspondent > Entity maybe a Correspondent Node or Correspondent Router. > > I wonder if "Mobile Entity" (MR, or MNN) wouldn't allow you to simplify > things later in the document. Hmm, possibly. Good point. Will consider that. > > 2. Benefits of NEMO Route Optimization > > As the text is written, shouldn't this rather be entitled "Design Goals > of NEMO RO" ? Possibly. I have no strong position here. > > o Greater Data Efficiency > > s / Greater Data Efficiency / Reduced Packet Overhead ???? Possibly. But that may arguably not cove rthe later sentence on e2e efficiency. > > Depending on the actual solution for NEMO Route Optimization, the > data packets exchanged between two end nodes may not require as > many levels of encapsulation as that in NEMO Basic Support. This > would mean less packet overheads, and higher data efficiency. In > particular, avoiding packet fragmentation that may be induced by > the multiple levels of tunneling is critical for end-to-end > efficiency from the viewpoints of buffering and transport > protocols. > > o Avoiding the Bottleneck in Home Network > > s / in Home / in the Home I think its should instead be a swap of the position of "the", ie "Avoiding Bottleneck in the Home Network". > > NEMO Route Optimization allows traffic to by-pass the Home Agents. > > s / alows / would allow [in paragraphs "may", "should" etc are > used] ok. > > Apart from having a more direct route, this also avoids routing > traffic via the home network, which may be a potential bottleneck > otherwise. > > o Avoid the Security Policy Issue > > Don't you rather mean "Ingress Filtering" ? > Nope. Firstly, it could simply be a policy thing without any mechanism to enforce the policy except the integrity of the owner of the MR. Thus it is not an ingress filtering problem. Secondly, even if firewall at home network does agressively filtering, it is not ingress filtering as I understand the term. Ingress filtering, as a term, has been used a long time in the IETF. A very narrow sense of interpretation, which most possibly is the prevalent one, is it refers to the filtering of packet if the source address does not fit certain criteria. However, packets from visitors would appear at the home network with source address configured from the MNP. The firewall should not discard the packet based on ingress filtering. Instead, it is because of something else that the packet got discarded (eg the existence of a Home Address Option that contains address not from the MNP, etc). > Security policy may forbid Mobile Routers from tunneling traffic > of Visiting Mobile Nodes into the home network of Mobile Router. > > s / of Mobile / of the Mobile Ok. We may need to remove an 's' from the first 'Mobile Routers' too. > > o Avoid the Instability and Stalemate > > [1] described a potential stalemate situation when a Home Agent is > nested within a Mobile Network. Route Optimization may circumvent > such stalemate situations by directly forwarding traffic upstream. > However, it should be noted that certain Route Optimization > schemes may require signaling packets to be first routed via the > Home Agent before an optimized route can be established. In such > cases, a Route Optimization solution cannot avoid the stalemate. > > I'm not sure the paragraph above is clear enough. [1] is listed as "Normative". After reading [1] and if you still feel its not clear enough, I am open to suggestions on how to improve it :) > > > 3.1. Basic NEMO Route Optimization > > I would find another word instead of "Basic". What about "not nested" ? "Non-Nested" you mean? Can, I have no strong position on this. > From the definition of Correspondent Router, it does not limit itself > to be mobile, but can also be an entity within the fixed > infrastructure with similar functionalities. As long as the > > To me it looks like you are taking thinkgs from the reverse order and > not very logical. Why not starting with the fixed case in the first > place, and later in the section explain the a CR may indeed be mobile > and thus be a mobile router, etc ? > Possibly, I will look into this. > > > This form of optimization can carry traffic both directions identical > to the previous example in Figure 1, or independently for the 2 > directions of traffic: > > s / traffic both / traffic in both OK. > > can carry traffic both directions identical = ?? Please rephrase. Opps, obviously some text get missed out by mistake. Will look into that. > > A straight-forward approach to Route Optimization in NEMO is for the > Mobile Router to attempt Route Optimization with a Correspondent > Entity. This can be viewed as a logical extension to NEMO Basic > > Here again, it's not very logical. Above, the term "CR" is used, so why > would one use "CE" now ? Because it may not be a CR, but a modified CN. > > 3.2. Nested Mobility Optimization > > Optimization in Nested Mobility targets scenarios where a nesting of > mobility management protocols is created (i.e. Mobile IPv6 enabled > host inside a mobile network or multiple Mobile Routers that attach > behind one another creating a nested mobile network). Note that > because Mobile IPv6 defines its own Route Optimization mechanism in > its base protocol suite as a standard, collaboration with this and > NEMO brings various complexity. > > NEMO = NEMO Basic Support ? I don't so. I think the text's intent was to refer to NEMO RO (and possibly Basic as well). > > 3.3. Infrastructure based Optimization > > Alternatively, another approach is to use prefix delegation. Here, > each Mobile Router in a nested mobile network is delegated a mobile > network prefix from the access router using DHCP Prefix Delegation > > >From which AR ? AR from the parent-NEMO or root-NEMO ? No restriction, both ways could be done. > > [14]. Each Mobile Router also autoconfigures its care-of address > from this delegated prefix. In this way, the care-of addresses of > each Mobile Router are all from an aggregatable address space > starting from the access router. This may be used to eliminate the > multiple tunnels caused by nesting of Mobile Nodes. > > 3.4. Intra-NEMO Optimization > > Another possibility is for the "Basic NEMO Route Optimization" > technique (see Section 3.1) to be applied here. Using the same > example of communication between MNN1 and MNN2, both MR3 and MR2 can > treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and > MR2 as Correspondent Routers for MNN1. An example of this approach > is [15] which have Mobile Routers announce their Mobile Network > Preifxes to other Mobile Routers in the same nested Mobile Network. > > s / which have / which has ok. > > 4. Issues of NEMO Route Optimization > > Wouldn't it be better to phrase this as "requirements" rather than > "issues" ? Nope, this is not a requirements draft, I would avoid the term "Requirement" as much as I can. I could call it "Tradeoffs" but not all items are tradeoff per se. I could call it "General Consideration for NEMO Roue Optimization", but that is as bad as "Issues". > > 4.3. Increased Delay during Handoff > > Another NEMO specific delay during handoff is that in a nested mobile > network, a child Mobile Network Node may need to detect or be > notified of the handoff of its parent Mobile Router so that it can > begin signaling its own Correspondent Entities. Apart from the > compromise of mobility awareness and location privacy, this mechanism > also increases the delay during handoffs. > > Isn't this another issue/requirement: you are kind or releaving the > "mobilty support transparency" requirement. (you may group some text > from 4.3 and 4.7) I believe a simply reference to the later sub-section would suffice. > > Some of the solutions for Mobile IPv6, such as Fast Handoff for > Mobile IPv6 [16], may be able to alleviate the increase in handoff > delay. > > 4.4. New Functionalities > > Is this an issue ? Isn't there a better place ? > Of-course it is. It is one of the main point of arguments: whether CN is touched or not, whether LFN are touched or not. > > 4.5. Detection of New Functionalities > > Is this an issue ? Isn't there a better place ? Like? > One issue that is related to the need for new functionalities as > described in Section 4.4 is the need to detect the existence of such > functionalities. In these cases, a detection mechanism might be > helpful to allow the initiator of Route Optimization to detect if > support of the new functionalities are available. Furthermore, it > might be advantageous to have a graceful fall back procedure if the > required functionalities are unavailable. > > 4.7. Mobility Transparency and Location Privacy > > One advantage of NEMO Basic Support is that the Correspondent Nodes > and Mobile Network Nodes need not be aware of the actual location and > mobility of the mobile network. With Route Optimization, it might be > necessary to reveal the point of attachment of the Mobile Router to > other nodes, such as the Mobile Network Nodes or their Correspondent > Nodes. This may mean a tradeoff between location privacy [17] (and > mobility transparency) and Route Optimization. > > Agree with location privacy, but mobility may still be transparent to > MNNs. You shouldn't group these issues/requirements togethers. > The previous sentence read "necessary to reveal ... such as the MNNs or their CNs". For MNNs, its mobility transparency. For CNs, its location privacy. We could of-course break it into two parts, but they stamped from the same thing: requiring the MR reveal its location to some other nodes. > > 4.9. Support of Legacy Nodes > > NEMO Basic Support is designed so that all legacy Mobile Network > Nodes (such as those who are not aware of the mobility of the network > they are in, and those that do not understand any mobility protocols) > can still reach and be reached from the Internet. Some Route > Optimization shcemes, however, require that all Mobile Routers to > > schemes Opps, how could aspell not catch that!!!! > > implement the same Route Optimization scheme in order for them to > operate. For instance, a nested Mobile Router may not be able to > achieve Route Optimization if it is attached to a legacy Local Fixed > Router. > > I cannot find a link between the sentence "For instance ..." and the > previous one. > Hmm..., perhaps "s/For instance/Thus" would be better? > > 5. Analysis of Solution Space > > 4. How is address of Mobile Network Node represented? > > s / is the address OK. > > 5. How is address of Mobile Network Node bound to location of mobile > network? > > s / is the address OK > > 6. How is signaling done? > > s / done / performed > OK > 5.1.1. Mobile Network Node and Correspondent Node > > A Mobile Network Node can establish Route Optimization with its > Correspondent Node, possibly the same way as a Mobile Node > establishes Route Optimization with its Correspondent Node in Mobile > IPv6. This would achieve the most optimal route, since the entire > end-to-end path is optimized. However, there might be scalability > issues since both the Mobile Network Node and the Correspondent Node > > To the condition the MNN knows when it is located in a nested NEMO. > This is just an observation, but, from this, I came to think you may be > able to draw a table issues/requirements vs scenarios 5.1.1-4. > > may need to maintain many Route Optimization sessions. In addition, > new functionalities would be required for both the Mobile Network > Node and Correspondent Node. > > What kind of functionalities ? In 5.1.3 you briefly detail what the > functionalities should be, I think the same should be done in each > section. Here there might be a need for the MNN to know its "depth" in > the NEMO. Possibly. That is the thin line we are trying to thread here. On one hand, we want to give details to provide a complete analysis. On the other hand, we don't want to go into too much specifics, else it we would be making too much assumptions about the approach. In this case, however, I agree we could go into slight more detail such as what new functionalities are required and all that. > > 5.1.2. Mobile Router and Correspondent Node > > Alternatively, Mobile Router can establish Route Optimization with a > > s / the Mobile Router > OK. > Correspondent Node on behalf of the Mobile Network Node. Since the > Mobile Router is merely one hop away from the Mobile Network Node, > > Not in the nested case. True, let see how we can rephrase it. How about: Since all packets from/to the MNN must transit the MR, ... > > this effectively achieves an optimal route for the entire end-to-end > path as well. Compared with Section 5.1.1, the scalability issue > here may be remedied since it is possible for Correspondent Node to > maintain only one session with Mobile Router if it communicates with > many Mobile Network Nodes associated with Mobile Router. > > s / with the same Mobile Router OK. > > I think that in most cases the sessions would be split between several > (potentialy nearby) CNs., so this observation is more realistic in the > CR case. > Possibly. However, there are examples for a single CN. (imagine all MNNs in a corporate mobile network accessing the corporate mail server). > > 5.2. Who and When to Initiate Route Optimization? > > > A related question is how often signaling messages should be sent to > maintain the Route Optimization session. Typically, signaling > messages is likely to be sent whenever there is topological changes. > The discussion in Section 4.1 should be considered. In addition, a > Lifetime value is often used to indicate the period of validity for > the Route Optimization session. Signaling messages would have to be > sent before the Lifetime value expires in order to maintain the Route > Optimization session. The choice of Lifetime value needs to balance > between different considerations. On one hand, a short Lifetime > value would increase the amount of signaling overhead. On the other > hand, a long Lifetime value may expose the Correspondent Entity to > the risk of having an obsolete binding cache entry, which creates an > opportunity for an attacker to exploit. > > Just wondering: shouldn't the tradeoffs be discussed in section 4, in an > independant paragraph ? Possibly, but we feel that it is too in depth more suitable for an analysis section. > > > 5.3. How to Detect Route Optimization Capability? > > mechanism is using in-band-signalling. > > s / signalling / signaling OK. (Just Rambling: Why can't we just have one ENGLISH :<). > > 5.4. How is Address of Mobile Network Node Represented? > > s / is / is the OK. > > Normally, Route Optimization would mean that a binding between the > address of Mobile Network Node and the location of the mobile network > > s / of / of a OK. > > is registered at the Correspondent Entity. Before exploring into > different ways of binding (see Section 5.5), one must first ask how > the address of the Mobile Network Node is represented. Basically, > there are two ways to represent the Mobile Network Node's address: > > o inferred by the use of Mobile Network Prefix, or > > o explicitly specifying the address of Mobile Network Node. > > s / of / of the OK. > > Using the Mobile Network Prefix would usually mean that the initiator > is the Mobile Router, and has the benefit of binding numerous Mobile > Network Nodes with one signaling. However, it also means that if > location privacy is compromised, the location privacy of an entire > Mobile Network Prefix will be compromised. > > s / will / would > That is subjective I think. But no harm changing :) > On the other hand, using the Mobile Network Node's address would mean > that the initiator is either the Mobile Network Node itself, or the > Mobile Router is initiating Route Optimization on behalf of the > Mobile Network Node. Initiation by the Mobile Network Node itself > means that the Mobile Network Node must have new functionalities > implemented, while initiation by the Mobile Router means that the > Mobile Router must maintain some Route Optimization states for each > Mobile Network Node. > > 5.5. How is Mobile Network Node's Address Bound to Location? > > In order for route to be optimized, it is generally necessary for the > Correspondent Entity to create a binding between the address and the > location of the Mobile Network Node. This can be done in the > following ways: > > > o binding the address to the location of the parent Mobile Router; > > o binding the address to a sequence of locations of upstream Mobile > Routers; and > > o binding the address to the location of the root Mobile Router > > Don't we need to discuss "binding a prefix" ? Also, shouldn't we > use the term "locator" ? Obviously you missed the debate between Alex and myself :) Binding address and binding prefix is the same thing, just that you bind more than one address at the same time with a prefix. That's why there is no "binding a prefix". 5.5.1 do go into detail of binding a prefix, though. As for locator, is that a useful term without the accompanying term -- identity? I mean, without mentioning identifier, what is difference between a locator and an address? > > These will be described in the following sub-sections. > > s / will be / are For a reader reading sequentially, "will be" is correct :) But I agree on changing to "are",. "Will be" is more suited for something that is more distant. > > 5.5.1. Binding to the Location of Parent Mobile Router > > > o Binding Update with Mobile Network Prefix > > mobile network prefix will be routed through the bi-directional > tunnel. > > s / will / would OK. > > > o Mobile Router as a Proxy > > Another approach is for the parent Mobile Router to act as a > "proxy" for its Mobile Network Nodes. In this case, the Mobile > Router uses standard Mobile IPv6 Route Optimization procedure to > bind the address of a Mobile Network Node to the Mobile Router's > care-of address. For instance, when the Mobile Network Node is a > Local Fixed Node without Mobile IPv6 Route Optimization > functionality, the Mobile Router may initiate teh Return > Routability procedure with a Correspondent Node on behalf of the > Local Fixed Node. An example of such an approach would be [19]. > > CN or CE ? Yep, CE is more correct. > > > 5.5.2. Binding to a Sequence of Locations of Upstream Mobile Routers > > > One question that immediately comes to the mind is how the Mobile > > s / the mind / mind ok. > > Network. In addition, some amount of modifications or extension to > existing protocols is also required, such as a new type of IPv6 > routing header, or new options in Router Advertisement messages. > please choose either "singular form" or "plural form". ok. > > 5.5.3. Binding to the Location of Root Mobile Router > > o Neighbor Discovery Proxy > > This approach (such as [23]) achieves Route Optimization by having > Mobile Routers to act as a Neighbor Discovery [24] proxy for its > > s / its / their ? > > Mobile Network Nodes. Mobile Router will configure a care-of > s / Mobile Router / the root Mobile Router ? > I think we will stick to singular ... > address from the network prefix advertised by its access router, > and also relay this prefix to its subnets. When a Mobile Network > Node configures an address from this prefix, the Mobile Router > will act as a Neighbor Discovery proxy on its behalf. In this > > when ... will: no future tense after "if", "when" etc. That is new. You sure? I think is more of whether you want to emphasize something. > > way, the entire mobile network and its access network form a > logical multilink subnet, thus eliminating any nesting. > > This approach has the advantage of keeping the implementations of > Correspondent Nodes unchanged. However, it requires the root > Mobile Router to act as a Neighbor Discovery proxy for all the > Mobile Network Nodes that are directly or indirectly attached to > it. This increases the processing load of the root Mobile Router. > In addition, a change in the point of attachment of the root > Mobile Router will require every nested Mobile Router (and > possibly Visiting Mobile Nodes) to change their care-of addresses. > Not only will this cause a burst of Binding Updates where every > Mobile Router and every Visiting Mobile Node start sending Binding > Updates to their Correspondent Entities, it will also cause a > burst of Duplicate Address Discovery messages to be exchanged > between the mobile network and the access network. Furthermore, > route optimization for Local Fixed Nodes is not possible without > new functionalities implemented on the Local Fixed Nodes. > > At LFNs, these are functionalities not related to mobility support. > I think we need to draw a line between mobility-related functionalities > and other. The other ones could be referred to as "requirements" to > distinguish between the two. > What are functionalities required for mobility support then? > > o Hierarchical Registrations > > Hierarchical Registration involves Mobile Network Nodes (including > nested Mobile Routers) to register itself with either their parent > > s / itself / themselves OK. > > Mobile Routers, or the root Mobile Router itself. After > registrations, Mobile Network Nodes would tunnel packets directly > to the upstream Mobile Router they register with. At the root > Mobile Router, packets tunneled from sub-Mobile Routers or Mobile > Network Nodes are tunneled directly to the Correspondent Entities, > thus avoiding nested tunneling. > > 5.6. How is Signaling Performed? > > An entirely different method of signaling makes use of upper layer > protocol to establish the bindings between the address of a Mobile > > s / protocol / protocols OK. > > Network Node and the location of the mobile network. Such binding > information can then be passed down to the IP layer to insert the > appropriate entry in the Binding Cache or routing table. An example > of such mechanism is [27] which uses the Session Initiation Protocol > (SIP) to relay binding information. > > 5.7. How is Data Transmitted? > > With Route Optimization established, one remaining question to be > answered is how data packets can be routed to follow the optimized > route. There are the following possible approaches: > > o Encapsulations > > For instance, if the Correspondent Entity knows the full sequence > of points of attachment, it might be necessary for there to be > multiple encapsulations in order to forward the data packet > through each point of attachment. This may lead to the need for > multiple tunnels and extra packet header overhead. It is possible > to alleviate this by using Robust Header Compression techniques > [29][30] to compress the multiple tunnel packet headers. > > I think draft-minaburo-rohc-nemo-01.txt should be cited here - it's not > about RO but it is focused on NEMO BS. OK. > > 8. Security Considerations > > This is an informational document that analyze the solution space of > > s / analyzes > OK. > 10. References > > I've noticed that in many cases only the 1st author is mentioned. That you have to complain to the maintainer of xml2rfc. > Also, > when there is a published paper, wouldn't it be better in the > "informative section" to provide the reference of a published paper > rather than I-D which are bound to be deleted from the IETF reposirory > (if not already) ? I think published papers exist for many of the > references. > Possibly ... but the fact is I am lazy. It is easy to do a "touch reference.xxx.xml; wget ...", especially when its is scripted, compared to creating an xml reference for that paper from scratch :). Will do what I can. Thank you once again for your detailed comments. /rgds /cwng From nemo-bounces@ietf.org Fri Nov 25 02:48:38 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 1EfYJy-0000sI-AS; Fri, 25 Nov 2005 02:48:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYJw-0000sC-SM for nemo@megatron.ietf.org; Fri, 25 Nov 2005 02:48:36 -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 CAA22762 for ; Fri, 25 Nov 2005 02:47:56 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfYdA-00033o-3z for nemo@ietf.org; Fri, 25 Nov 2005 03:08:29 -0500 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 699664DF73 for ; Fri, 25 Nov 2005 16:48:01 +0900 (JST) Message-ID: <4386C241.2030204@sfc.wide.ad.jp> Date: Fri, 25 Nov 2005 16:50:25 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> <43829840.4090501@sfc.wide.ad.jp> <1132640913.31961.67.camel@localhost> In-Reply-To: <1132640913.31961.67.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Hello Chan-Wah, Sorry for the delay ! Chan-Wah Ng wrote: >>IMHO it is good to be accurate, in order to identify when the problem >>occurs. So what about this one: >> >> Split-NEMO refers to the case where a mobile network that has >> multiple mobile routers handling the same MNP (or MNPs) becomes >> two or more independent mobile networks, where the same MNP(s) >> are no longer advertised in the same mobile network. >> > > > Hmm, I am doubtful about the last sentence, especially the last few > words "same mobile networks". The problem with split-NEMO is that the > MRs cannot announce the same MNP to different NEMO. > > > May I offer an entirely different definition: > > Split-NEMO refers to the case where a mobile network becomes > two or more independent mobile networks due to the separation > of Mobile Routers which are handling the same MNP (or MNPs) > in the original mobile network before separation. Actually, I wonder if Split-NEMO should only refer to the case where split is a problem, or to any kind of split. draft-ietf-nemo-terminology is a terminology document and thus should be silent on the problems or specific scenario. Other documents such as draft-ietf-nemo-multihoming-issues-02 can then refer to Split-NEMO and describe the problems that may occur when a split occurs (and actually it already has a section about that). What is your opinion? Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Fri Nov 25 03:41:59 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 1EfZ9a-0003Af-Up; Fri, 25 Nov 2005 03:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZ9Z-0003AU-3V for nemo@megatron.ietf.org; Fri, 25 Nov 2005 03:41:57 -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 DAA26710 for ; Fri, 25 Nov 2005 03:41:16 -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 1EfZSk-0004cp-Oy for nemo@ietf.org; Fri, 25 Nov 2005 04:01:49 -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 jAP8fHhN014814 for ; Fri, 25 Nov 2005 17:41:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAP8fHb20007 for ; Fri, 25 Nov 2005 17:41:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id jAP8fH316475 for ; Fri, 25 Nov 2005 17:41:17 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 16:38:10 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 14447D560D; Fri, 25 Nov 2005 16:46:02 +0800 (SGT) Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: <4386C241.2030204@sfc.wide.ad.jp> References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> <43829840.4090501@sfc.wide.ad.jp> <1132640913.31961.67.camel@localhost> <4386C241.2030204@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Nov 2005 16:46:01 +0800 Message-Id: <1132908361.11586.126.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 25 Nov 2005 08:38:10.0833 (UTC) FILETIME=[91352010:01C5F19B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Hello, Romain, On Fri, 2005-11-25 at 16:50 +0900, Romain KUNTZ wrote: > Hello Chan-Wah, > > Sorry for the delay ! > I have no problem at all with that ... but I don't know about Thierry. He may be anxious to get this resolved. :) > Chan-Wah Ng wrote: > >>IMHO it is good to be accurate, in order to identify when the problem > >>occurs. So what about this one: > >> > >> Split-NEMO refers to the case where a mobile network that has > >> multiple mobile routers handling the same MNP (or MNPs) becomes > >> two or more independent mobile networks, where the same MNP(s) > >> are no longer advertised in the same mobile network. > >> > > > > > > Hmm, I am doubtful about the last sentence, especially the last few > > words "same mobile networks". The problem with split-NEMO is that the > > MRs cannot announce the same MNP to different NEMO. > > > > > > May I offer an entirely different definition: > > > > Split-NEMO refers to the case where a mobile network becomes > > two or more independent mobile networks due to the separation > > of Mobile Routers which are handling the same MNP (or MNPs) > > in the original mobile network before separation. > > Actually, I wonder if Split-NEMO should only refer to the case where > split is a problem, or to any kind of split. draft-ietf-nemo-terminology > is a terminology document and thus should be silent on the problems or > specific scenario. Other documents such as > draft-ietf-nemo-multihoming-issues-02 can then refer to Split-NEMO and > describe the problems that may occur when a split occurs (and actually > it already has a section about that). > > What is your opinion? > Ah, which was why I first asked what is the purpose of having the split-NEMO terminology. IMHO, its only useful for the case where there is problem. Where else would such a terminology be useful? I mean when two mobile routers previously on the same link go separate way, you simply say "they go separate way" or "they got separated" or "they separated". There is no need to create a special term for that. To me split-NEMO means that a logically single entity got separated. It warrants some configurations changes. Like MNP needs to be broken into two parts etc, etc, which is what my latest proposal is trying to convey. I agree with you that the terminology (and definition) itself should not contains hints of a problem. That is the job of a problem statement. But the terminology is created so that we can refer to the scenario where the problem occurs. "Split-NEMO" as a term is pretty much like "pinball route" to me in nature. It is created to help describe a problem. /rgds /cwng From nemo-bounces@ietf.org Fri Nov 25 04:28:27 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 1EfZsZ-00048q-0B; Fri, 25 Nov 2005 04:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZsW-00048l-Ah for nemo@megatron.ietf.org; Fri, 25 Nov 2005 04:28:24 -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 EAA01310 for ; Fri, 25 Nov 2005 04:27:43 -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 1EfaBj-0006O5-Px for nemo@ietf.org; Fri, 25 Nov 2005 04:48:17 -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 jAP9SBip026224; Fri, 25 Nov 2005 18:28:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jAP9SD701125; Fri, 25 Nov 2005 18:28:13 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id jAP9SC322393; Fri, 25 Nov 2005 18:28:12 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 17:25:05 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 4ED8DD560D; Fri, 25 Nov 2005 17:32:57 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <1132838480.11586.90.camel@localhost> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Nov 2005 17:32:57 +0800 Message-Id: <1132911177.11586.140.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 25 Nov 2005 09:25:05.0748 (UTC) FILETIME=[1F071140:01C5F1A2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Pardon me for replying to my own post, but I have additional responses while compiling the issues list for this mail. I 'll snip out the less important ones. On Thu, 2005-11-24 at 21:21 +0800, Chan-Wah Ng wrote: > On Thu, 2005-11-24 at 20:32 +0900, Thierry Ernst wrote: > > o Mobile Router as a Proxy > > > > Another approach is for the parent Mobile Router to act as a > > "proxy" for its Mobile Network Nodes. In this case, the Mobile > > Router uses standard Mobile IPv6 Route Optimization procedure to > > bind the address of a Mobile Network Node to the Mobile Router's > > care-of address. For instance, when the Mobile Network Node is a > > Local Fixed Node without Mobile IPv6 Route Optimization > > functionality, the Mobile Router may initiate teh Return > > Routability procedure with a Correspondent Node on behalf of the > > Local Fixed Node. An example of such an approach would be [19]. > > > > CN or CE ? > > Yep, CE is more correct. > Sorry, on second thought, CN is correct. The LFN will be communicating with a CN, so MR is sending MIPv6 RO to a CN. There is no CR for MIPv6 RO, so it is not necessary to use the CE generalization. > > Also, > > when there is a published paper, wouldn't it be better in the > > "informative section" to provide the reference of a published paper > > rather than I-D which are bound to be deleted from the IETF reposirory > > (if not already) ? I think published papers exist for many of the > > references. > > > > Possibly ... but the fact is I am lazy. It is easy to do a "touch > reference.xxx.xml; wget ...", especially when its is scripted, compared > to creating an xml reference for that paper from scratch :). > > Will do what I can. While I will try to add in the paper references I know of, I am just wondering what is the normal IET/RFC-Editor position on referencing expired drafts. There are bound to be previous cases where an RFC have to reference an expiring or expired I-D. /rgds /cwng From nemo-bounces@ietf.org Fri Nov 25 05:01:27 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 1EfaOV-0008UP-2O; Fri, 25 Nov 2005 05:01:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaOT-0008UK-Oa for nemo@megatron.ietf.org; Fri, 25 Nov 2005 05:01:25 -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 FAA04893 for ; Fri, 25 Nov 2005 05:00:44 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efahh-0007iV-Jc for nemo@ietf.org; Fri, 25 Nov 2005 05:21:19 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 360784DFD2 for ; Fri, 25 Nov 2005 19:01:09 +0900 (JST) Date: Fri, 25 Nov 2005 19:00:58 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Message-Id: <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> In-Reply-To: <1132838480.11586.90.camel@localhost> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.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: f5932bfc8385127f631fc458a872feb1 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 > > > > > related to mobility in [3] and [4], and NEMO related terms > > defined in[5]. > > > > The sentence above should better be moved to the section terminology > > below. > > > > Well, *IF* there is going to be one. It has always been our intention > (or at least mine) that the terminology sub-section is a temporary > one. Once the terminologies we used are in the terminology draft, I > see no benefit in retaining this section. Unfortunately, you didn't comment this on my most important comment which was: 1.1. Terminology You should write here the sentence that the terminology is defined in [3] and [4]. The terms below should still be in this section, but you should clarify that these termed are defined in [5] and copied here for purposes of clarity / reminder. Conclusion: don't dismiss the section; as discussed for other documents, the doc should be self-contained. I don't mean to copy all terms, but to keep in the present the new terms, while the original defintion would be in draft-ietf-nemo-terminology. > > Correspondent Router (CR) > > > > This refers to the entity which is capable of terminating a > > Route > > > > s / entity / router ??? > > If this text remains, I would simply copy it from the terminology > draft. If you use 'router', we would use 'router' :) This doesn't help me with the document I have myself to take care about. The term come from this draft authors, so please tell me what is the conclusion, and not the other way round ;-) > > 3.1. Basic NEMO Route Optimization > > > > I would find another word instead of "Basic". What about "not > > nested" ? > > "Non-Nested" you mean? Can, I have no strong position on this. Yes, I meant "non-nested". > > A straight-forward approach to Route Optimization in NEMO is for > > the Mobile Router to attempt Route Optimization with a > > Correspondent Entity. This can be viewed as a logical extension > > to NEMO Basic > > > > Here again, it's not very logical. Above, the term "CR" is used, so > > why would one use "CE" now ? > > Because it may not be a CR, but a modified CN. The point is that you may use CE more constantly (unless you really need to make a distinction between the 2) > > because Mobile IPv6 defines its own Route Optimization mechanism > > in its base protocol suite as a standard, collaboration with this > > and NEMO brings various complexity. > > > > NEMO = NEMO Basic Support ? > > I don't so. I think the text's intent was to refer to NEMO RO (and > possibly Basic as well). So, you may write "NEMO RO" not just "NEMO". > > 4.3. Increased Delay during Handoff > > > > Another NEMO specific delay during handoff is that in a nested > > mobile network, a child Mobile Network Node may need to detect or > > be notified of the handoff of its parent Mobile Router so that it > > can begin signaling its own Correspondent Entities. Apart from > > the compromise of mobility awareness and location privacy, this > > mechanism also increases the delay during handoffs. > > > > Isn't this another issue/requirement: you are kind or releaving the > > "mobilty support transparency" requirement. (you may group some text > > from 4.3 and 4.7) > > I believe a simply reference to the later sub-section would suffice. Actually, this is linked with my comment on section 4.7. I think "mobility support transparency" deserves an independant paragraph. > > 4.4. New Functionalities > > > > Is this an issue ? Isn't there a better place ? > > > > Of-course it is. It is one of the main point of arguments: whether CN > is touched or not, whether LFN are touched or not. 4.5 says "Detection of New Functionalities" so here you may write "4.4 Extending Nodes with New Functionalities". > > > > 4.5. Detection of New Functionalities > > > > Is this an issue ? Isn't there a better place ? > > Like? For me it looks more like a requirement than an issue. > > 4.7. Mobility Transparency and Location Privacy > > > > One advantage of NEMO Basic Support is that the Correspondent > > Nodes and Mobile Network Nodes need not be aware of the actual > > location and mobility of the mobile network. With Route > > Optimization, it might be necessary to reveal the point of > > attachment of the Mobile Router to other nodes, such as the > > Mobile Network Nodes or their Correspondent Nodes. This may mean > > a tradeoff between location privacy [17] (and mobility > > transparency) and Route Optimization. > > > > Agree with location privacy, but mobility may still be transparent > > to MNNs. You shouldn't group these issues/requirements togethers. > > > > The previous sentence read "necessary to reveal ... such as the MNNs > or their CNs". For MNNs, its mobility transparency. For CNs, its > location privacy. We could of-course break it into two parts, but > they stamped from the same thing: requiring the MR reveal its location > to some other nodes. I don't buy that "location privacy" is defined the way you seem to define it. Location Privacy is about not providing my location to my peers, not about not knowing where I am ! I advocate an independent paragraph on "mobility transparency" with text taken from 4.7 and 4.3. > > > I think that in most cases the sessions would be split between > > several(potentialy nearby) CNs., so this observation is more > > realistic in the CR case. > > > > Possibly. However, there are examples for a single CN. (imagine all > MNNs in a corporate mobile network accessing the corporate mail > server). I agree with you (of course). You may just point to the fact it's just an example. > > Using the Mobile Network Prefix would usually mean that the > > initiator is the Mobile Router, and has the benefit of binding > > numerous Mobile Network Nodes with one signaling. However, it > > also means that if location privacy is compromised, the location > > privacy of an entire Mobile Network Prefix will be compromised. > > > > s / will / would > > > > That is subjective I think. But no harm changing :) Native English speakers will correct me if I'm wrong but I've learnt that the future tense cannot be used after words like "if, when, after, .." etc. > > 5.5. How is Mobile Network Node's Address Bound to Location? > > > > In order for route to be optimized, it is generally necessary for > > the Correspondent Entity to create a binding between the address > > and the location of the Mobile Network Node. This can be done in > > the following ways: > > > > > > o binding the address to the location of the parent Mobile > > Router; > > > > o binding the address to a sequence of locations of upstream > > Mobile > > Routers; and > > > > o binding the address to the location of the root Mobile Router > > > > Don't we need to discuss "binding a prefix" ? Also, shouldn't we > > use the term "locator" ? > > Obviously you missed the debate between Alex and myself :) Didn't see a discussion on this ;-) > Binding address and binding prefix is the same thing, just that you > bind more than one address at the same time with a prefix. That's why > there is no "binding a prefix". Sure, but if you write "address" you kind of limit the scope of what you are writing, no ? > 5.5.1 do go into detail of binding a prefix, though. Yes, I've seen this, but the itemized text doesn't give a hint to this. > As for locator, is that a useful term without the accompanying term -- > identity? I mean, without mentioning identifier, what is difference > between a locator and an address? > > > > These will be described in the following sub-sections. > > > > s / will be / are > > For a reader reading sequentially, "will be" is correct :) > > But I agree on changing to "are",. "Will be" is more suited for > something that is more distant. I might be wrong and this is something only a native English speaker could correct, but I think than in the situation where the text "one is going to read" is just right after, the present tense is more appropriate. > > > when ... will: no future tense after "if", "when" etc. > > That is new. You sure? > I think is more of whether you want to emphasize something. Let me know the final answer so that I can embrace or complain to my past English teachers ;-) > > This approach has the advantage of keeping the implementations > > of Correspondent Nodes unchanged. However, it requires the > > root Mobile Router to act as a Neighbor Discovery proxy for > > all the Mobile Network Nodes that are directly or indirectly > > attached to it. This increases the processing load of the > > root Mobile Router. In addition, a change in the point of > > attachment of the root Mobile Router will require every nested > > Mobile Router (and possibly Visiting Mobile Nodes) to change > > their care-of addresses. Not only will this cause a burst of > > Binding Updates where every Mobile Router and every Visiting > > Mobile Node start sending Binding Updates to their > > Correspondent Entities, it will also cause a burst of > > Duplicate Address Discovery messages to be exchanged between > > the mobile network and the access network. Furthermore, route > > optimization for Local Fixed Nodes is not possible without new > > functionalities implemented on the Local Fixed Nodes. > > > > At LFNs, these are functionalities not related to mobility support. > > I think we need to draw a line between mobility-related > > functionalities and other. The other ones could be referred to as > > "requirements" to distinguish between the two. > > > > What are functionalities required for mobility support then? A mechanism to send a BU is a mobility support functionality. A DHCP functionality is not a mobility support functionality. DHCP is useful for any node, fixed or mobile, in a fixed network or a mobile network which needs a dynamic address. > > 10. References > > > > I've noticed that in many cases only the 1st author is mentioned. > > That you have to complain to the maintainer of xml2rfc. Well, in the 1st place, did you include all the authors in the .xml file ? > > Also, > > when there is a published paper, wouldn't it be better in the > > "informative section" to provide the reference of a published paper > > rather than I-D which are bound to be deleted from the IETF > > reposirory(if not already) ? I think published papers exist for > > many of the references. > > > > Possibly ... but the fact is I am lazy. It is easy to do a "touch > reference.xxx.xml; wget ...", especially when its is scripted, > compared to creating an xml reference for that paper from scratch :). > > Will do what I can. I recommend this - when you have one valid one, of course. It would be nice from solution draft authors cited in ROSA to provide a better published reference rather than for ROSA authors to seek for this by themselves. Thierry From nemo-bounces@ietf.org Fri Nov 25 05:05:54 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 1EfaSo-0002hs-I9; Fri, 25 Nov 2005 05:05:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaSn-0002hn-SN for nemo@megatron.ietf.org; Fri, 25 Nov 2005 05:05:53 -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 FAA05194 for ; Fri, 25 Nov 2005 05:05:12 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efam3-0007rL-0G for nemo@ietf.org; Fri, 25 Nov 2005 05:25:47 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6D1C24DFDA for ; Fri, 25 Nov 2005 19:05:44 +0900 (JST) Date: Fri, 25 Nov 2005 19:05:33 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20051125190533.7801d3a5.ernst@sfc.wide.ad.jp> In-Reply-To: <1132911177.11586.140.camel@localhost> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <1132911177.11586.140.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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [nemo] Published work for RO solutions referenced in ROSA sought X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > > Also, > > > when there is a published paper, wouldn't it be better in the > > > "informative section" to provide the reference of a published > > > paper rather than I-D which are bound to be deleted from the IETF > > > reposirory(if not already) ? I think published papers exist for > > > many of the references. > > > > > > > Possibly ... but the fact is I am lazy. It is easy to do a "touch > > reference.xxx.xml; wget ...", especially when its is scripted, > > compared to creating an xml reference for that paper from scratch > > :). > > > > Will do what I can. > > While I will try to add in the paper references I know of, I am just > wondering what is the normal IET/RFC-Editor position on referencing > expired drafts. There are bound to be previous cases where an RFC > have to reference an expiring or expired I-D. For the RFC editor it doesn't matter when refs are "informational" but for the reader it does matter when one cannot find a referred document which is needed to understand what ROSA is talking about. I know that many authors have written papers, so they could do their part of the work by providing their references. Thierry. From nemo-bounces@ietf.org Fri Nov 25 05:34:50 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 1Efauo-0004cj-L1; Fri, 25 Nov 2005 05:34:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efaun-0004cV-1F for nemo@megatron.ietf.org; Fri, 25 Nov 2005 05:34:49 -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 FAA08189 for ; Fri, 25 Nov 2005 05:34:07 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbE2-0000QR-6B for nemo@ietf.org; Fri, 25 Nov 2005 05:54:42 -0500 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5C4654DFD7 for ; Fri, 25 Nov 2005 19:34:39 +0900 (JST) Message-ID: <4386E94E.7090305@sfc.wide.ad.jp> Date: Fri, 25 Nov 2005 19:37:02 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology References: <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> <43829840.4090501@sfc.wide.ad.jp> <1132640913.31961.67.camel@localhost> <4386C241.2030204@sfc.wide.ad.jp> <1132908361.11586.126.camel@localhost> In-Reply-To: <1132908361.11586.126.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 Chan-Wah Ng wrote: >>>May I offer an entirely different definition: >>> >>> Split-NEMO refers to the case where a mobile network becomes >>> two or more independent mobile networks due to the separation >>> of Mobile Routers which are handling the same MNP (or MNPs) >>> in the original mobile network before separation. >> >>Actually, I wonder if Split-NEMO should only refer to the case where >>split is a problem, or to any kind of split. draft-ietf-nemo-terminology >>is a terminology document and thus should be silent on the problems or >>specific scenario. Other documents such as >>draft-ietf-nemo-multihoming-issues-02 can then refer to Split-NEMO and >>describe the problems that may occur when a split occurs (and actually >>it already has a section about that). >> >>What is your opinion? >> > > Ah, which was why I first asked what is the purpose of having the > split-NEMO terminology. IMHO, its only useful for the case where there > is problem. Where else would such a terminology be useful? I mean when > two mobile routers previously on the same link go separate way, you > simply say "they go separate way" or "they got separated" or "they > separated". There is no need to create a special term for that. Thinking about that, a split-NEMO is basically a problem because MNNs may also suffer from that, even if 2 different MNPs are advertised by the 2 different MR that have splitted. So defining split-NEMO to any kind of split might be useful for people who want to use a generic term in their documents. > To me split-NEMO means that a logically single entity got separated. It > warrants some configurations changes. Like MNP needs to be broken into > two parts etc, etc, which is what my latest proposal is trying to > convey. > > I agree with you that the terminology (and definition) itself should not > contains hints of a problem. That is the job of a problem statement. > But the terminology is created so that we can refer to the scenario > where the problem occurs. > > "Split-NEMO" as a term is pretty much like "pinball route" to me in > nature. It is created to help describe a problem. Not necessarily. IMHO if we define a term, then it's better than everyone (people who wants to describe a problem, or people who just want to refer to a separation) use the same term. Regards, Romain From nemo-bounces@ietf.org Fri Nov 25 06:05:36 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 1EfbOa-0000Ti-Me; Fri, 25 Nov 2005 06:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbOY-0000TX-R5 for nemo@megatron.ietf.org; Fri, 25 Nov 2005 06:05:34 -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 GAA11033 for ; Fri, 25 Nov 2005 06:04:53 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efbho-0001aE-G5 for nemo@ietf.org; Fri, 25 Nov 2005 06:25:28 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2005 12:05:25 +0100 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 jAPB4eB7011450; Fri, 25 Nov 2005 12:05:23 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Nov 2005 12:05:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Published work for RO solutions referenced in ROSA sought Date: Fri, 25 Nov 2005 12:05:16 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC018597AF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Published work for RO solutions referenced in ROSA sought Thread-Index: AcXxqDSTi/pIoI86SUePcLx9c74oQQAB5oiQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 25 Nov 2005 11:05:20.0080 (UTC) FILETIME=[1FD94D00:01C5F1B0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Actually, most papers are still available from mobilenetworks.org, and it's fair that all referenced draft get an equal chance of audience. So we sort them, refer to them, and hope some people read them. I hope TJK keeps maintaining the site; it is really useful for that type of purpose. Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst >Sent: Friday, November 25, 2005 11:06 AM >To: nemo@ietf.org >Subject: [nemo] Published work for RO solutions referenced in ROSA sought > > >> > > Also, >> > > when there is a published paper, wouldn't it be better in the >> > > "informative section" to provide the reference of a published >> > > paper rather than I-D which are bound to be deleted from the IETF >> > > reposirory(if not already) ? I think published papers exist for >> > > many of the references. >> > > >> > >> > Possibly ... but the fact is I am lazy. It is easy to do a "touch >> > reference.xxx.xml; wget ...", especially when its is scripted, >> > compared to creating an xml reference for that paper from scratch >> > :). >> > >> > Will do what I can. >> >> While I will try to add in the paper references I know of, I am just >> wondering what is the normal IET/RFC-Editor position on referencing >> expired drafts. There are bound to be previous cases where an RFC >> have to reference an expiring or expired I-D. > >For the RFC editor it doesn't matter when refs are "informational" but >for the reader it does matter when one cannot find a referred document >which is needed to understand what ROSA is talking about. > >I know that many authors have written papers, so they could do their >part of the work by providing their references. > >Thierry. From nemo-bounces@ietf.org Fri Nov 25 06:06:07 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 1EfbP5-0000UV-3G; Fri, 25 Nov 2005 06:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbP2-0000UO-Ts for nemo@megatron.ietf.org; Fri, 25 Nov 2005 06:06: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 GAA11046 for ; Fri, 25 Nov 2005 06:05:23 -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 1EfbiH-0001ai-T3 for nemo@ietf.org; Fri, 25 Nov 2005 06:25:58 -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 jAPB5phN014335; Fri, 25 Nov 2005 20:05:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAPB5sb10363; Fri, 25 Nov 2005 20:05:54 +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 jAPB5qY03987; Fri, 25 Nov 2005 20:05:52 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 19:02:46 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 6B988D560D; Fri, 25 Nov 2005 19:10:38 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Nov 2005 19:10:36 +0800 Message-Id: <1132917036.11586.207.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 25 Nov 2005 11:02:46.0698 (UTC) FILETIME=[C46D10A0:01C5F1AF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 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 On Fri, 2005-11-25 at 19:00 +0900, Thierry Ernst wrote: > > > > > > > > related to mobility in [3] and [4], and NEMO related terms > > > defined in[5]. > > > > > > The sentence above should better be moved to the section terminology > > > below. > > > > > > > Well, *IF* there is going to be one. It has always been our intention > > (or at least mine) that the terminology sub-section is a temporary > > one. Once the terminologies we used are in the terminology draft, I > > see no benefit in retaining this section. > > Unfortunately, you didn't comment this on my most important comment > which was: I thought I commented (i.e. the text you quoted above) :) > > 1.1. Terminology > > You should write here the sentence that the terminology is defined in > [3] and [4]. The terms below should still be in this section, but you > should clarify that these termed are defined in [5] and copied here for > purposes of clarity / reminder. > > Conclusion: don't dismiss the section; as discussed for other documents, > the doc should be self-contained. I don't mean to copy all terms, but to > keep in the present the new terms, while the original defintion would be > in draft-ietf-nemo-terminology. I see. I recall there is a discussion few years back on whether the terms should be kept all in one place or something like that. If the decision was to have draft-ietf-nemo-terminology contains all terms, and each individual contain a sub-set of these terms that are relevant to their subject matters, than I'll be happy to oblige. > > > > > Correspondent Router (CR) > > > > > > This refers to the entity which is capable of terminating a > > > Route > > > > > > s / entity / router ??? > > > > If this text remains, I would simply copy it from the terminology > > draft. If you use 'router', we would use 'router' :) > > This doesn't help me with the document I have myself to take care about. > The term come from this draft authors, so please tell me what is the > conclusion, and not the other way round ;-) > Ah, opps. Stalemate :) Ok, I will fix it to "router". > > > A straight-forward approach to Route Optimization in NEMO is for > > > the Mobile Router to attempt Route Optimization with a > > > Correspondent Entity. This can be viewed as a logical extension > > > to NEMO Basic > > > > > > Here again, it's not very logical. Above, the term "CR" is used, so > > > why would one use "CE" now ? > > > > Because it may not be a CR, but a modified CN. > > The point is that you may use CE more constantly (unless you really need > to make a distinction between the 2) This I humbly disagree, though I am not too strongly positioned about it. My view is that as much as possible we should be specific. Use CN/CR instead of CE, unless there it is clearly that either will do. However, your point is taken (since it will leads to less error). > > > > because Mobile IPv6 defines its own Route Optimization mechanism > > > in its base protocol suite as a standard, collaboration with this > > > and NEMO brings various complexity. > > > > > > NEMO = NEMO Basic Support ? > > > > I don't so. I think the text's intent was to refer to NEMO RO (and > > possibly Basic as well). > > So, you may write "NEMO RO" not just "NEMO". I need the co-author who wrote this text to confirm, but if the intention was indeed to imply NEMO-RO and NEMO Basic, then I will keep NEMO. If it was only one of them, of-course we would switch to that. > > > > 4.3. Increased Delay during Handoff > > > > > > Another NEMO specific delay during handoff is that in a nested > > > mobile network, a child Mobile Network Node may need to detect or > > > be notified of the handoff of its parent Mobile Router so that it > > > can begin signaling its own Correspondent Entities. Apart from > > > the compromise of mobility awareness and location privacy, this > > > mechanism also increases the delay during handoffs. > > > > > > Isn't this another issue/requirement: you are kind or releaving the > > > "mobilty support transparency" requirement. (you may group some text > > > from 4.3 and 4.7) > > > > I believe a simply reference to the later sub-section would suffice. > > Actually, this is linked with my comment on section 4.7. I think > "mobility support transparency" deserves an independant paragraph. > See below. > > > > 4.4. New Functionalities > > > > > > Is this an issue ? Isn't there a better place ? > > > > > > > Of-course it is. It is one of the main point of arguments: whether CN > > is touched or not, whether LFN are touched or not. > > 4.5 says "Detection of New Functionalities" so here you may write "4.4 > Extending Nodes with New Functionalities". OK. > > > > > > > > 4.5. Detection of New Functionalities > > > > > > Is this an issue ? Isn't there a better place ? > > > > Like? > > For me it looks more like a requirement than an issue. > I am unwillingly to write a "Requirements" section, for fear of being accused trying to sneak in requirements for RO in a problem statement draft. I would have it remained in the "Issues" section. If you feel that "Issue" has a more specific meaning, then I would change the title of this section to "General Considerations". > > > > 4.7. Mobility Transparency and Location Privacy > > > > > > One advantage of NEMO Basic Support is that the Correspondent > > > Nodes and Mobile Network Nodes need not be aware of the actual > > > location and mobility of the mobile network. With Route > > > Optimization, it might be necessary to reveal the point of > > > attachment of the Mobile Router to other nodes, such as the > > > Mobile Network Nodes or their Correspondent Nodes. This may mean > > > a tradeoff between location privacy [17] (and mobility > > > transparency) and Route Optimization. > > > > > > Agree with location privacy, but mobility may still be transparent > > > to MNNs. You shouldn't group these issues/requirements togethers. > > > > > > > The previous sentence read "necessary to reveal ... such as the MNNs > > or their CNs". For MNNs, its mobility transparency. For CNs, its > > location privacy. We could of-course break it into two parts, but > > they stamped from the same thing: requiring the MR reveal its location > > to some other nodes. > > I don't buy that "location privacy" is defined the way you seem to > define it. Location Privacy is about not providing my location to my > peers, not about not knowing where I am ! I don't see the difference between your interpretation and mine. "Location Privacy is about not providing my location to my peers" is equivalent to how I see it: "For CNs, its location privacy". "about not knowing where I am" is equivalent to how I see it "For MNN, its mobility transparency". > > I advocate an independent paragraph on "mobility transparency" with text > taken from 4.7 and 4.3. > I could attempt a split and get back to you. My feeling is that the text will be largely similar (which is why I made the editorial decision not to split). Please note that we are NOT trying to say location privacy = mobility transparency. They are clearly distinct considerations. It is just that I feel that the text describing the two has so much overlapping that I grouped them into one sub-section. In the text, we have clearly use the terms location privacy and mobility transparent distinctly so that it shouldn't create the impression that they are the same thing (which apparently, we failed, judging on your comments). > > > > > I think that in most cases the sessions would be split between > > > several(potentialy nearby) CNs., so this observation is more > > > realistic in the CR case. > > > > > > > Possibly. However, there are examples for a single CN. (imagine all > > MNNs in a corporate mobile network accessing the corporate mail > > server). > > I agree with you (of course). You may just point to the fact it's just > an example. OK. > > > > Using the Mobile Network Prefix would usually mean that the > > > initiator is the Mobile Router, and has the benefit of binding > > > numerous Mobile Network Nodes with one signaling. However, it > > > also means that if location privacy is compromised, the location > > > privacy of an entire Mobile Network Prefix will be compromised. > > > > > > s / will / would > > > > > > > That is subjective I think. But no harm changing :) > > Native English speakers will correct me if I'm wrong but I've learnt > that the future tense cannot be used after words like "if, when, after, > .." etc. > I am not a native english speaker, but I think I have heard expressions such as "if you XXX, I will kill you!" numerous times :). I think your rule refers to the "XXX" part (e.g. there is no "If you will do ..."), not the "then" part. > > > 5.5. How is Mobile Network Node's Address Bound to Location? > > > > > > In order for route to be optimized, it is generally necessary for > > > the Correspondent Entity to create a binding between the address > > > and the location of the Mobile Network Node. This can be done in > > > the following ways: > > > > > > > > > o binding the address to the location of the parent Mobile > > > Router; > > > > > > o binding the address to a sequence of locations of upstream > > > Mobile > > > Routers; and > > > > > > o binding the address to the location of the root Mobile Router > > > > > > Don't we need to discuss "binding a prefix" ? Also, shouldn't we > > > use the term "locator" ? > > > > Obviously you missed the debate between Alex and myself :) > > Didn't see a discussion on this ;-) Its ISSUE #12. > > > Binding address and binding prefix is the same thing, just that you > > bind more than one address at the same time with a prefix. That's why > > there is no "binding a prefix". > > Sure, but if you write "address" you kind of limit the scope of what > you are writing, no ? > Which is why there is a sub-section "5.4" that explains the case when a MNN's address can be derived from a prefix. > > 5.5.1 do go into detail of binding a prefix, though. > > Yes, I've seen this, but the itemized text doesn't give a hint to this. > Do you think it better to add a bullet on "binding a prefix", making it four bullets where there is only three sub-sub-sections? > > > > > > These will be described in the following sub-sections. > > > > > > s / will be / are > > > > For a reader reading sequentially, "will be" is correct :) > > > > But I agree on changing to "are",. "Will be" is more suited for > > something that is more distant. > > I might be wrong and this is something only a native English speaker > could correct, but I think than in the situation where the text "one is > going to read" is just right after, the present tense is more > appropriate. > You are not wrong. This is precisely what I mean by "more distant" :). I am guilty of writing the text as if I am speaking to an audience. It is not uncommon in speech for you to say "I will next describe foo and bar". > > > This approach has the advantage of keeping the implementations > > > of Correspondent Nodes unchanged. However, it requires the > > > root Mobile Router to act as a Neighbor Discovery proxy for > > > all the Mobile Network Nodes that are directly or indirectly > > > attached to it. This increases the processing load of the > > > root Mobile Router. In addition, a change in the point of > > > attachment of the root Mobile Router will require every nested > > > Mobile Router (and possibly Visiting Mobile Nodes) to change > > > their care-of addresses. Not only will this cause a burst of > > > Binding Updates where every Mobile Router and every Visiting > > > Mobile Node start sending Binding Updates to their > > > Correspondent Entities, it will also cause a burst of > > > Duplicate Address Discovery messages to be exchanged between > > > the mobile network and the access network. Furthermore, route > > > optimization for Local Fixed Nodes is not possible without new > > > functionalities implemented on the Local Fixed Nodes. > > > > > > At LFNs, these are functionalities not related to mobility support. > > > I think we need to draw a line between mobility-related > > > functionalities and other. The other ones could be referred to as > > > "requirements" to distinguish between the two. > > > > > > > What are functionalities required for mobility support then? > > A mechanism to send a BU is a mobility support functionality. A DHCP > functionality is not a mobility support functionality. DHCP is useful > for any node, fixed or mobile, in a fixed network or a mobile network > which needs a dynamic address. Agree, but the text is about mechanism to send BU for LFN. Sure , for ND-proxy, you can always used DHCP or similar to have the LFN change their addreses. That is not mobility. However, this defeats the purpose of NEMO. The ideal of NEMO is so that MNNs can retain their original source address. So, the LFN we have would need some mobility management functionality in order to enjoy the benefits of RO, which is precise what we meant by "Furthermore, route optimization for Local Fixed Nodes is not possible without new functionalities implemented on the Local Fixed Nodes". > > > > 10. References > > > > > > I've noticed that in many cases only the 1st author is mentioned. > > > > That you have to complain to the maintainer of xml2rfc. > > Well, in the 1st place, did you include all the authors in the .xml file > ? > I most certainly did not, since I downloaded the xml files from xml.resource.org. Sorry, I meant "you have to complain to the maintainer of xml.resource.org" instead of "xml2rfc" in my original response. But I concede that it is my job to ensure that the resources I am using are functioning within normal parameters. Will try to do what I can. > > > Also, > > > when there is a published paper, wouldn't it be better in the > > > "informative section" to provide the reference of a published paper > > > rather than I-D which are bound to be deleted from the IETF > > > reposirory(if not already) ? I think published papers exist for > > > many of the references. > > > > > > > Possibly ... but the fact is I am lazy. It is easy to do a "touch > > reference.xxx.xml; wget ...", especially when its is scripted, > > compared to creating an xml reference for that paper from scratch :). > > > > Will do what I can. > > I recommend this - when you have one valid one, of course. > > It would be nice from solution draft authors cited in ROSA to provide a > better published reference rather than for ROSA authors to seek for this > by themselves. > Yes, authors please do so. /rgds /cwng From nemo-bounces@ietf.org Fri Nov 25 08:18:16 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 1EfdSy-0006BU-C9; Fri, 25 Nov 2005 08:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdSw-00066I-DT for nemo@megatron.ietf.org; Fri, 25 Nov 2005 08:18:14 -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 IAA23879 for ; Fri, 25 Nov 2005 08:17:31 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfdmC-0006AR-Ku for nemo@ietf.org; Fri, 25 Nov 2005 08:38:09 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAPDUZYj005307; Fri, 25 Nov 2005 06:30:35 -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 jAPDQot3027568; Fri, 25 Nov 2005 07:26:50 -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 38B52865980; Fri, 25 Nov 2005 14:17:49 +0100 (CET) Message-ID: <43870EFC.5090100@motorola.com> Date: Fri, 25 Nov 2005 14:17:48 +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> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> In-Reply-To: <1132838480.11586.90.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: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > Hello Thierry, [...] >> o Avoid the Instability and Stalemate >> >> [1] described a potential stalemate situation when a Home Agent is >> nested within a Mobile Network. Route Optimization may circumvent >> such stalemate situations by directly forwarding traffic upstream. >> However, it should be noted that certain Route Optimization >> schemes may require signaling packets to be first routed via the >> Home Agent before an optimized route can be established. In such >> cases, a Route Optimization solution cannot avoid the stalemate. >> >> I'm not sure the paragraph above is clear enough. > > [1] is listed as "Normative". After reading [1] and if you still > feel its not clear enough, I am open to suggestions on how to improve > it :) About the "stalemate" problem. [1] is the ro problem statement draft, which in turn cites the home network models draft which cites back the ro problem statement draft. For example, the home network models draft says: > But note that SFO should never attach to one of its own Cabs. This > would create a stalemate situation, as documented in the NEMO RO > problem statement [11]. ... which leaves one wonder what exactly is the "stalemate" situation. So one goes to the ro ps draft and reads: > Several configurations for the Home Network are described in [9] > [home net models]. In particular, there is a mobile home scenario > where a (parent) Mobile Router is also a Home Agent for its mobile > network. In other words, the mobile network is itself an aggregation > of Mobile Network Prefixes assigned to (children) Mobile Routers. > > A stalemate situation exists in the case where the parent Mobile > Router visits one of its children. The child Mobile Router cannot > find its Home Agent in the Internet and thus cannot establish its > MRHA tunnel and forward the visitors traffic. The traffic from the > parent is thus blocked from reaching the Internet and it will never > bind to its own (grand parent) Home Agent. This last paragraph in the ro ps draft is the essence of the "stalemate" problem. If that paragraph is not enough for clear explanation, here's more detailed text about how the "stalemate" situation may occur (substitute "stalemate" for "cross-over tunnels": Two MR-HA tunnels are "crossing over" each other when the path between one tunnel's endpoints includes only one of the other tunnel's endpoints. Support of nested mobile networks is possible only when the path from MR2 to MR1's HA does not go through MR1 (path considered when both mobile routers are at home and no tunnels are in place). Consider a mobility configuration depicted below. MR1 is served by HA1/BR and MR2 is served by HA2. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent. /-----CN ----------/ home link1 ------- | | -----------------------| HA1/BR|---| Internet | | ------- | | | ---------- ----- ----- | MR1 | | HA2 | ----- ----- | | -------------mobile network 1 / home link2 | ----- ----- | MR2 | | LFN | ----- ----- | | ------------mobile network 2 In the picture above, communication between CN and LFN follows a direct path as lons as both MR1 and MR2 are positioned at home. No encapsulation intervenes. In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in the figure below: /-----CN ----------/ home link 1 ------- | | ---------------| HA1/BR|---| Internet | | ------- | | ----- ----- ----------\ | MR1 | | HA2 | \ ----- ----- ----- | | | AR | ------------mobile net 1 ----- home link2 | ----- ----- | MR2 | | LFN | ----- ----- | | mobile net 2------------ Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck to MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. After the tunnel MR2HA2 has been set up, the path taken by a packet from CN towards LFN can be summarized as: CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. Non-encapsulated packets are marked "->" while encapsulated packets are marked "=>". Consider next the attachment of the first mobile network under the second mobile network, like in the figure below: /-----CN ----------/ ------- | | | HA1/BR|---| Internet | ------- | | ----------\ \ ----- | AR | ----- | ----- ----- | MR2 | | LFN | ----- ----- | | mobile net 2------------ | ----- ----- | MR1 | | HA2 | ----- ----- | | mobile net 1------------ After this movement, MR1 acquires a CoA valid in the second mobile network. Subsequently, it sends a BU message addressed to HA1. This BU is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible, due to the fact that the tunnel between MR2 and HA2 has been previously torn down (when the mobile net 1 has moved from home). The communication between CN and LFN stops, even though both mobile networks are connected to the Internet. If both tunnels between MR1 and HA1, and between MR2 and HA2 were up simultaneously, they would have "crossed over" each other. If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture, it could be noticed that the path of the tunnel MR1-HA1 includes only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels are crossing over each other if the IP path between two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming that both tunnels are up). When both endpoints of one tunnel are included in the path of the other tunnel, then tunnels are simply encapsulating each other. Alex From nemo-bounces@ietf.org Mon Nov 28 02:26:58 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 1EgdPe-0005bU-KP; Mon, 28 Nov 2005 02:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgdPc-0005bK-Pu for nemo@megatron.ietf.org; Mon, 28 Nov 2005 02:26:56 -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 CAA22449 for ; Mon, 28 Nov 2005 02:26:13 -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 1EgdjR-0001Yo-Se for nemo@ietf.org; Mon, 28 Nov 2005 02:47: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/jazz) with ESMTP id jAS7QVwS016373; Mon, 28 Nov 2005 16:26:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id jAS7QVm14608; Mon, 28 Nov 2005 16:26:31 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id jAS7QUJ20443; Mon, 28 Nov 2005 16:26:30 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 15:23:22 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id D80CED54F9; Mon, 28 Nov 2005 15:31:36 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Chan-Wah Ng To: Alexandru Petrescu In-Reply-To: <43870EFC.5090100@motorola.com> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <43870EFC.5090100@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 28 Nov 2005 15:31:36 +0800 Message-Id: <1133163096.16555.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 28 Nov 2005 07:23:22.0163 (UTC) FILETIME=[9CFDB030:01C5F3EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Pascal Thubert , 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 Hello, Alex, Thank you for the text. I am now considering which is the most appropriate place to hold the text. Currently, I am inclined to add it as an appendix to RO-PS draft. It could, also be added to the home network model draft as an appendix as well. Pascal, what do you think? /rgds /cwng On Fri, 2005-11-25 at 14:17 +0100, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: > > Hello Thierry, > [...] > >> o Avoid the Instability and Stalemate > >> > >> [1] described a potential stalemate situation when a Home Agent is > >> nested within a Mobile Network. Route Optimization may circumvent > >> such stalemate situations by directly forwarding traffic upstream. > >> However, it should be noted that certain Route Optimization > >> schemes may require signaling packets to be first routed via the > >> Home Agent before an optimized route can be established. In such > >> cases, a Route Optimization solution cannot avoid the stalemate. > >> > >> I'm not sure the paragraph above is clear enough. > > > > [1] is listed as "Normative". After reading [1] and if you still > > feel its not clear enough, I am open to suggestions on how to improve > > it :) > > About the "stalemate" problem. [1] is the ro problem statement draft, > which in turn cites the home network models draft which cites back > the ro problem statement draft. > > For example, the home network models draft says: > > But note that SFO should never attach to one of its own Cabs. This > > would create a stalemate situation, as documented in the NEMO RO > > problem statement [11]. > > ... which leaves one wonder what exactly is the "stalemate" situation. > So one goes to the ro ps draft and reads: > > Several configurations for the Home Network are described in [9] > > [home net models]. In particular, there is a mobile home scenario > > where a (parent) Mobile Router is also a Home Agent for its mobile > > network. In other words, the mobile network is itself an aggregation > > of Mobile Network Prefixes assigned to (children) Mobile Routers. > > > > A stalemate situation exists in the case where the parent Mobile > > Router visits one of its children. The child Mobile Router cannot > > find its Home Agent in the Internet and thus cannot establish its > > MRHA tunnel and forward the visitors traffic. The traffic from the > > parent is thus blocked from reaching the Internet and it will never > > bind to its own (grand parent) Home Agent. > > This last paragraph in the ro ps draft is the essence of the "stalemate" > problem. If that paragraph is not enough for clear explanation, here's > more detailed text about how the "stalemate" situation may occur > (substitute "stalemate" for "cross-over tunnels": > > Two MR-HA tunnels are "crossing over" each other when the path > between one tunnel's endpoints includes only one of the other > tunnel's endpoints. > > Support of nested mobile networks is possible only when the path > from MR2 to MR1's HA does not go through MR1 (path considered when > both mobile routers are at home and no tunnels are in place). > > Consider a mobility configuration depicted below. MR1 is served by > HA1/BR and MR2 is served by HA2. Both MR1 and MR2 are at home in > the initial step. HA2 is placed inside the first mobile network, > thus representing a "mobile" Home Agent. > > /-----CN > ----------/ > home link1 ------- | | > -----------------------| HA1/BR|---| Internet | > | ------- | | > | ---------- > ----- ----- > | MR1 | | HA2 | > ----- ----- > | | > -------------mobile network 1 / home link2 > | > ----- ----- > | MR2 | | LFN | > ----- ----- > | | > ------------mobile network 2 > > In the picture above, communication between CN and LFN follows a > direct path as lons as both MR1 and MR2 are positioned at home. No > encapsulation intervenes. > > In the next step, consider that the MR2's mobile network leaves home > and visits a foreign network, under Access Router (AR) like in the > figure below: > > /-----CN > ----------/ > home link 1 ------- | | > ---------------| HA1/BR|---| Internet | > | ------- | | > ----- ----- ----------\ > | MR1 | | HA2 | \ > ----- ----- ----- > | | | AR | > ------------mobile net 1 ----- > home link2 | > ----- ----- > | MR2 | | LFN | > ----- ----- > | | > mobile net 2------------ > > Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs > between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck to > MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. > After the tunnel MR2HA2 has been set up, the path taken by a packet > from CN towards LFN can be summarized as: > CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. Non-encapsulated packets > are marked "->" while encapsulated packets are marked "=>". > > Consider next the attachment of the first mobile network under the > second mobile network, like in the figure below: > > /-----CN > ----------/ > ------- | | > | HA1/BR|---| Internet | > ------- | | > ----------\ > \ > ----- > | AR | > ----- > | > ----- ----- > | MR2 | | LFN | > ----- ----- > | | > mobile net 2------------ > | > ----- ----- > | MR1 | | HA2 | > ----- ----- > | | > mobile net 1------------ > > After this movement, MR1 acquires a CoA valid in the second mobile > network. Subsequently, it sends a BU message addressed to HA1. > This BU is encapsulated by MR2 and sent towards HA2, which is > expected to be placed in mobile net 1 and expected to be at home. > Once HA1/BR receives this encapsulated BU, it tries to deliver to > MR1. Since MR1 is not at home, and a tunnel has not yet been set up > between MR1 and HA1, HA1 is not able to route this packet and drops > it. Thus, the tunnel establishment procedure between MR1 and HA1 is > not possible, due to the fact that the tunnel between MR2 and HA2 > has been previously torn down (when the mobile net 1 has moved from > home). The communication between CN and LFN stops, even though both > mobile networks are connected to the Internet. > > If both tunnels between MR1 and HA1, and between MR2 and HA2 > were up simultaneously, they would have "crossed over" each other. > If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture, > it could be noticed that the path of the tunnel MR1-HA1 includes > only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two > MR-HA tunnels are crossing over each other if the IP path between > two endpoints of one tunnel includes one and only one endpoint of > the other tunnel (assuming that both tunnels are up). When both > endpoints of one tunnel are included in the path of the other > tunnel, then tunnels are simply encapsulating each other. > > Alex > From nemo-bounces@ietf.org Mon Nov 28 03:30:22 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 1EgeP0-0008NB-7A; Mon, 28 Nov 2005 03:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeOw-0008My-Nm for nemo@megatron.ietf.org; Mon, 28 Nov 2005 03:30: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 DAA29254 for ; Mon, 28 Nov 2005 03:29:34 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egeim-0003hr-DZ for nemo@ietf.org; Mon, 28 Nov 2005 03:50:49 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Nov 2005 09:30:10 +0100 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 jAS8TxAX004152; Mon, 28 Nov 2005 09:30:05 +0100 (MET) 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, 28 Nov 2005 09:30:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Date: Mon, 28 Nov 2005 09:29:59 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01859B56@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Thread-Index: AcXz7RNAtmK5RSpfTJG4WubEAJYODQACB0gg From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Alexandru Petrescu" X-OriginalArrivalTime: 28 Nov 2005 08:30:02.0810 (UTC) FILETIME=[ED8FF9A0:01C5F3F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org The way I see it, it is a problem with the 'mobile home' model, and the HNM draft illustrates applications of NEMO. RO-PS lists all the problems with NEMO, that's its job. So I think the discussion is fine in RO-PS. On the side, I agree it's a bit stupid, is that it is late for Home Network model. It has passed through many reviews and is ready for IESG at this point.=20 Finally, we want the largest audience so people can react more effectively. IMHO, there are more readers to RO-PS then HNM. So I'd go for RO-PS, but I'm ready for other opinions. Pascal >-----Original Message----- >From: Chan-Wah Ng [mailto:chanwah.ng@sg.panasonic.com] >Sent: Monday, November 28, 2005 8:32 AM >To: Alexandru Petrescu >Cc: Pascal Thubert (pthubert); Thierry Ernst; nemo@ietf.org >Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt > >Hello, Alex, > >Thank you for the text. I am now considering which is the most >appropriate place to hold the text. Currently, I am inclined to add it >as an appendix to RO-PS draft. > >It could, also be added to the home network model draft as an appendix >as well. > >Pascal, what do you think? > >/rgds >/cwng > >On Fri, 2005-11-25 at 14:17 +0100, Alexandru Petrescu wrote: >> Chan-Wah Ng wrote: >> > Hello Thierry, >> [...] >> >> o Avoid the Instability and Stalemate >> >> >> >> [1] described a potential stalemate situation when a Home Agent is >> >> nested within a Mobile Network. Route Optimization may circumvent >> >> such stalemate situations by directly forwarding traffic upstream. >> >> However, it should be noted that certain Route Optimization >> >> schemes may require signaling packets to be first routed via the >> >> Home Agent before an optimized route can be established. In such >> >> cases, a Route Optimization solution cannot avoid the stalemate. >> >> >> >> I'm not sure the paragraph above is clear enough. >> > >> > [1] is listed as "Normative". After reading [1] and if you still >> > feel its not clear enough, I am open to suggestions on how to improve >> > it :) >> >> About the "stalemate" problem. [1] is the ro problem statement draft, >> which in turn cites the home network models draft which cites back >> the ro problem statement draft. >> >> For example, the home network models draft says: >> > But note that SFO should never attach to one of its own Cabs. This >> > would create a stalemate situation, as documented in the NEMO RO >> > problem statement [11]. >> >> ... which leaves one wonder what exactly is the "stalemate" situation. >> So one goes to the ro ps draft and reads: >> > Several configurations for the Home Network are described in [9] >> > [home net models]. In particular, there is a mobile home scenario >> > where a (parent) Mobile Router is also a Home Agent for its mobile >> > network. In other words, the mobile network is itself an aggregation >> > of Mobile Network Prefixes assigned to (children) Mobile Routers. >> > >> > A stalemate situation exists in the case where the parent Mobile >> > Router visits one of its children. The child Mobile Router cannot >> > find its Home Agent in the Internet and thus cannot establish its >> > MRHA tunnel and forward the visitors traffic. The traffic from the >> > parent is thus blocked from reaching the Internet and it will never >> > bind to its own (grand parent) Home Agent. >> >> This last paragraph in the ro ps draft is the essence of the "stalemate" >> problem. If that paragraph is not enough for clear explanation, here's >> more detailed text about how the "stalemate" situation may occur >> (substitute "stalemate" for "cross-over tunnels": >> >> Two MR-HA tunnels are "crossing over" each other when the path >> between one tunnel's endpoints includes only one of the other >> tunnel's endpoints. >> >> Support of nested mobile networks is possible only when the path >> from MR2 to MR1's HA does not go through MR1 (path considered when >> both mobile routers are at home and no tunnels are in place). >> >> Consider a mobility configuration depicted below. MR1 is served by >> HA1/BR and MR2 is served by HA2. Both MR1 and MR2 are at home in >> the initial step. HA2 is placed inside the first mobile network, >> thus representing a "mobile" Home Agent. >> >> /-----CN >> ----------/ >> home link1 ------- | | >> -----------------------| HA1/BR|---| Internet | >> | ------- | | >> | ---------- >> ----- ----- >> | MR1 | | HA2 | >> ----- ----- >> | | >> -------------mobile network 1 / home link2 >> | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> ------------mobile network 2 >> >> In the picture above, communication between CN and LFN follows a >> direct path as lons as both MR1 and MR2 are positioned at home. No >> encapsulation intervenes. >> >> In the next step, consider that the MR2's mobile network leaves home >> and visits a foreign network, under Access Router (AR) like in the >> figure below: >> >> /-----CN >> ----------/ >> home link 1 ------- | | >> ---------------| HA1/BR|---| Internet | >> | ------- | | >> ----- ----- ----------\ >> | MR1 | | HA2 | \ >> ----- ----- ----- >> | | | AR | >> ------------mobile net 1 ----- >> home link2 | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> mobile net 2------------ >> >> Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs >> between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck to >> MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. >> After the tunnel MR2HA2 has been set up, the path taken by a packet >> from CN towards LFN can be summarized as: >> CN->BR->MR1->HA2=3D>MR1=3D>BR=3D>AR=3D>MR2->LFN. Non-encapsulated = packets >> are marked "->" while encapsulated packets are marked "=3D>". >> >> Consider next the attachment of the first mobile network under the >> second mobile network, like in the figure below: >> >> /-----CN >> ----------/ >> ------- | | >> | HA1/BR|---| Internet | >> ------- | | >> ----------\ >> \ >> ----- >> | AR | >> ----- >> | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> mobile net 2------------ >> | >> ----- ----- >> | MR1 | | HA2 | >> ----- ----- >> | | >> mobile net 1------------ >> >> After this movement, MR1 acquires a CoA valid in the second mobile >> network. Subsequently, it sends a BU message addressed to HA1. >> This BU is encapsulated by MR2 and sent towards HA2, which is >> expected to be placed in mobile net 1 and expected to be at home. >> Once HA1/BR receives this encapsulated BU, it tries to deliver to >> MR1. Since MR1 is not at home, and a tunnel has not yet been set up >> between MR1 and HA1, HA1 is not able to route this packet and drops >> it. Thus, the tunnel establishment procedure between MR1 and HA1 is >> not possible, due to the fact that the tunnel between MR2 and HA2 >> has been previously torn down (when the mobile net 1 has moved from >> home). The communication between CN and LFN stops, even though both >> mobile networks are connected to the Internet. >> >> If both tunnels between MR1 and HA1, and between MR2 and HA2 >> were up simultaneously, they would have "crossed over" each other. >> If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture, >> it could be noticed that the path of the tunnel MR1-HA1 includes >> only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two >> MR-HA tunnels are crossing over each other if the IP path between >> two endpoints of one tunnel includes one and only one endpoint of >> the other tunnel (assuming that both tunnels are up). When both >> endpoints of one tunnel are included in the path of the other >> tunnel, then tunnels are simply encapsulating each other. >> >> Alex >> From nemo-bounces@ietf.org Wed Nov 30 22:54:48 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 1EhfWy-0002vJ-90; Wed, 30 Nov 2005 22:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhfWw-0002vB-FZ for nemo@megatron.ietf.org; Wed, 30 Nov 2005 22:54: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 WAA13017 for ; Wed, 30 Nov 2005 22:53:56 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhfrG-0004JO-Tt for nemo@ietf.org; Wed, 30 Nov 2005 23:15:48 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6B06C4D38A for ; Thu, 1 Dec 2005 12:54:11 +0900 (JST) Date: Thu, 1 Dec 2005 12:54:00 +0900 From: Thierry Ernst To: ml-nemo Subject: Re: [nemo] Published work for RO solutions referenced in ROSA sought Message-Id: <20051201125400.74ff03aa.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC018597AF@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC018597AF@xmb-ams-337.emea.cisco.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: 4b800b1eab964a31702fa68f1ff0e955 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, On Fri, 25 Nov 2005 12:05:16+0100"Pascal Thubert\(pthubert\)" wrote: > Actually, most papers are still available from mobilenetworks.org, and > it's fair that all referenced draft get an equal chance of audience. > So we sort them, refer to them, and hope some people read them. > > I hope TJK keeps maintaining the site; it is really useful for that > type of purpose. This doesn't hold. TJ and I we do maintain the site, but since it's unofficial, there is no guarantee it will be continued undefinitely. But the point is that internet-drafts are just work in progress, and are supposed to expire (otherwise they would be kept on the IETF repository). So, I sometimes doubt it's a good idea to keep expired document in a repository such like the one we maintain on mobilenetworks.org. On a general basis, if a paper is available, it's a better citation than the draft, I think. Just being curious: how many draft authors have provided a reference to their work since my post on the matter ? If none, I just wonder how much in depth these solutions referred in ROSA have been thought (note I'm not arguying about removing anyone of these). Thierry. > >-----Original Message----- > >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > >Of > Thierry Ernst > >Sent: Friday, November 25, 2005 11:06 AM > >To: nemo@ietf.org > >Subject: [nemo] Published work for RO solutions referenced in ROSA > sought > > > > > >> > > Also, > >> > > when there is a published paper, wouldn't it be better in the > >> > > "informative section" to provide the reference of a published > >> > > paper rather than I-D which are bound to be deleted from the > >IETF> > > reposirory(if not already) ? I think published papers > >exist for> > > many of the references. > >> > > > >> > > >> > Possibly ... but the fact is I am lazy. It is easy to do a > >"touch> > reference.xxx.xml; wget ...", especially when its is > >scripted,> > compared to creating an xml reference for that paper > >from scratch> > :). > >> > > >> > Will do what I can. > >> > >> While I will try to add in the paper references I know of, I am > >just> wondering what is the normal IET/RFC-Editor position on > >referencing> expired drafts. There are bound to be previous cases > >where an RFC> have to reference an expiring or expired I-D. > > > >For the RFC editor it doesn't matter when refs are "informational" > >but for the reader it does matter when one cannot find a referred > >document which is needed to understand what ROSA is talking about. > > > >I know that many authors have written papers, so they could do their > >part of the work by providing their references. > > > >Thierry.