From nemo-bounces@ietf.org Sun Aug 1 05:02:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04153 for ; Sun, 1 Aug 2004 05:02:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCBQ-0002lA-EM; Sun, 01 Aug 2004 04:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrC8n-0002Bf-8x for nemo@megatron.ietf.org; Sun, 01 Aug 2004 04:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03929 for ; Sun, 1 Aug 2004 04:56:23 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrCBO-00008m-Lx for nemo@ietf.org; Sun, 01 Aug 2004 04:59:08 -0400 Received: from iseran.local (U190184.ppp.dion.ne.jp [218.222.190.184]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id B7B985D018 for ; Sun, 1 Aug 2004 17:55:48 +0900 (JST) Date: Sun, 1 Aug 2004 17:57:12 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] comments on draft-ietf-nemo-terminology Message-Id: <20040801175712.077432bf.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0566AB@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0566AB@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Content-Transfer-Encoding: 7bit Hi Pascal, I'm not against, but it may be a bit imature (?). BTW, isn't there other terms already in wide used that are not presently in draft-terminology ? Thierry On Fri, 30 Jul 2004 20:04:31 +0200 "Pascal Thubert (pthubert)" wrote: > Hi Thierry: > > The RRH draft has a concept of 'solid' NEMO which means that a nested > structure of mobile and non mobile routers is moving as a whole with no > inner topological deformation. You may think of a term like 'plastic' > for a structure that moves as a whole but with inner movements as well, > like a swarm. I believe that such terms are useful for the RO > discussion. > > Could you consider to add them in the terminology draft? > > Pascal > > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > Of Thierry Ernst > > Sent: jeudi 29 juillet 2004 10:58 > > To: nemo@ietf.org > > Subject: Re: [nemo] comments on draft-ietf-nemo-terminology > > > > > > Hi Pascal, > > > > > We voiced things actually. I remember saying that some words have > been > > > around too long for dismissing them so easily. People use MNP and > TLMR > > > when they talk, regardless of the new official terminology. And this > > > happens outside of the WG as well as inside. Many people now know > about > > > NEMO and it's hard to get them to say root-MR or Nemo-prefix. They > had > > > trouble enough to get used to the old words in the first place and > this > > > is confusing. > > > > There are a few people that have voiced, other who are confused, some > > who used MNP and the like because it's an habbit, and those who use > the > > new terminology. > > > > But, new terms where presented at the IETF meeting, and if some people > > were not there, they could have watched the minutes and the slides. > > > > In any case, I don't mind whichever term is used, personaly, but I do > > want a RFC with no consistency between the terms. So far, it's only a > > draft, so things can be changed, and people can get used to it. After, > > that wouldn't be possible anymore. > > > > I find root-MR much clearer and consistent that TLMR ; on the other > > hand, one may argue that NEMO-prefix is longer than MNP (but > NEMO-prefix > > bring the meaning of a prefix within the mobile network). > > > > We will make a decision on these at SD, definitely. > > > > Thierry. > > > > > From mailman-bounces@ietf.org Sun Aug 1 06:58:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11648 for ; Sun, 1 Aug 2004 06:58:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCWF-0000YI-Gu for nemo-archive@lists.ietf.org; Sun, 01 Aug 2004 05:20:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:05:09 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-bounces@ietf.org Sun Aug 1 23:35:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25636 for ; Sun, 1 Aug 2004 23:35:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrTVT-0001pF-6i; Sun, 01 Aug 2004 23:28:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqe9c-0007cC-G6 for nemo@megatron.ietf.org; Fri, 30 Jul 2004 16:39:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29520 for ; Fri, 30 Jul 2004 16:38:58 -0400 (EDT) Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqeBu-0005Wp-72 for nemo@ietf.org; Fri, 30 Jul 2004 16:41:23 -0400 Received: from pwolf.WV.CC.CMU.EDU (CMU-100645.WV.CC.cmu.edu [128.2.67.159]) (user=dim mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i6UKcvkp027255 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 30 Jul 2004 16:38:58 -0400 Date: Fri, 30 Jul 2004 16:38:58 -0400 From: David Murray To: nemo@ietf.org Message-ID: Originator-Info: login-token=Mulberry:01JXM0fIncobxa97UFaq+X5q7hortn3LeaoZngbA==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 01 Aug 2004 23:28:56 -0400 Subject: [nemo] IETF Session Live Internet Broadcast (MBONE **NOT NEEDED** TO VIEW) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit For the IETF meeting coming up, a number of events (including one for this group) will be broadcast publicly via a technology called ESM through Carnegie Mellon University. To tune to any broadcasts, visit http://esm.cs.cmu.edu during the meetings (August 2-5) and click "Watch". To participate, you need a system with the following requirements: - A machine with Windows 98 or later, Linux, or Mac OS X - You need to have a DSL, Cable Modem, or better connection (you do *not* need mbone to view this event) Thanks! David Murray CMU End System Multicast Group From nemo-bounces@ietf.org Mon Aug 2 09:37:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06378 for ; Mon, 2 Aug 2004 09:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brcy2-0002Ec-2M; Mon, 02 Aug 2004 09:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrctF-0000R4-SD for nemo@megatron.ietf.org; Mon, 02 Aug 2004 09:30:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06099 for ; Mon, 2 Aug 2004 09:30:08 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brcw7-0005Pf-Ha for nemo@ietf.org; Mon, 02 Aug 2004 09:33:08 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i72DV1RC020404; Mon, 2 Aug 2004 06:31:01 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i72DStO6030331; Mon, 2 Aug 2004 08:28:55 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4FD938859AE; Mon, 2 Aug 2004 15:30:05 +0200 (CEST) Message-ID: <410E41D6.5000100@motorola.com> Date: Mon, 02 Aug 2004 15:29:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A350EF2AB4361CAF33E3635" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Ryuji Wakikawa , Masafumi Watari Subject: [nemo] Comments on ORC draft-wakikawa-nemo-orc-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A350EF2AB4361CAF33E3635 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello to authors of draft-wakikawa-nemo-orc-00.txt Ryuji and Watari :-) I've read the draft and have comments of two kinds: editorial and on the architecture, at the end. Overall, I think the draft describes a method for offering approximate RO for mobile hosts and mobile routers by placing new architectural entities supporting ORC in the Internet. (like MBone routers do bandwidth savings). The method relieves CN's from implementing any new NEMO RO protocol, thus a great advantage. It also offers a means to automatically discover the presence of CR's, which is also advantageous: ORC BU's can be triggered only when CR's are present near CN. One drawback seems to be the fact that even if shorter paths are employed through CR, there's still encapsulation (if my reading is correct); but this may probably be improved. The editorials I'm mentioning below may confuse the reader easily. They reflect the interpretation I give to some aspects, which may be not the right one, please enlighten if so. (and there are others on grammar but they're obvious so I don't mention.) > The ORC aims to manage binding information as if routing information > of each mobile network are located at special routers called > ``Correspondent Router''. Substitute "for when" for "as if". > best effect routing protocol Effort. (actually, I don't think it is very precise to say that some routing protocol is "best effort"; I guess one can say that IP routing in itself happens in a best effort manner, in that nothing guarantees delivery of fwded packets to the final destination - there's no ack. I think routing protocols do have some means of acknowledging their exchanges (e.g. BGP uses TCP), and in this sense they can't be qualified as best effort. It is also true that a path taken by packets to a certain destination is not necessarily the shortest possible, because of load balancing and other traficcy shaping if I can say so, in which case I think it's called simply "optimal", and this may better fit in your context where paths are shorter if an ORC router is present and longer otherwise. Closed parenthesis.) > Mobile router can forward any packets meant for the managed prefixes > to the correspondent router. "forward" ok yes, but maybe stress with "directly, instead of forwarding to its HA"; and stress that MR actually encapsulates, not quite simple forwarding. > The managed prefix is used when the mobile router decides which > packets are sent to which correspondent router. The Home Agent setup > forwarding for all the mobile network prefixes notified by the > mobile router. It is true that HA sets up fwding for all Mobile Network prefixes notified by the MR, but in this section we're talking about Binding Registration (btw, why not simply BU?) to the CR, not to the HA. So I assume it's the CR you're talking about in the last phrase above (not the HA), right? > next hope address Hoping the next hop forwards where it should :-) Other than editorial remarks: After reading, may I conclude that there's always encapsulation between MR and CR? So this is a sort of RO but without the benefit of not having to encapsulate? Section 2.2.2 RR invited to think it may lead to remove the encapsulation after RR, but it never says so. How is it intended? About path length. After reading, it is clear that ORC provides for shorter-than-through-HA paths between MR and CN provided a CR is close to CN. But the description gives no clue about what happens when MR and its HA are both in the CN-and-CR's domain. In this case, it may happen that the path MR-HA-CN is much shorter than MR-CR-CN. So it would be interesting to consider a sort of intelligence on MR about what to do with the discovered CR's address, maybe don't always use it. Additionally, in the case that MR has its home in the same AS as the CN and talks to CN, there is little chance for CR to "intercept" these packets, unless CR is in the path MR-CN (should it be there?). About where to put the CR. There is a sort of contradictory assumption about the placement of CR. Initially, it is said that a CR should be "scattered near the transit AS", a bit later it is said that CR is an "edge router" and could even be a "gateway" router for a network, in order to intercept packets of CN. I assume the intention of "gateway" was to say "CN's next-hop router to the Internet". If it is so, then those two claims practically bring the CN near the "transit AS". I think this is difficult to assume, since most CN's (in the form of e2e communicators), are usually at the far edges. Of course, there exist large web/ASP server farms placed somehow nearer the "transit AS", but I think they're the rare exceptions. I think it should be better clarified where exactly the CR's should be placed, and this should be suggested with respect to existing OSPF and BGP terminology (like AS, area, backbone, routing domains, border router, backbone router, AS boundary router, etc. For more fun, an OSPF "edge" is actually any link between two routers, not the "edge of the Internet" as we often talk about :-) About CR receiving identical routes towards mobile prefix, from ORC and EGP. It is good to say that the route a CR learns from a remote MR (the mobile network prefix) could be advertised by CR via an IGP in the same domain, but not via BGP. Moreover, one should say what happens when CR receives a route towards exactly same prefix, by EGP and by ORC simultaneously. Which would take precedence? About CR Discovery. It is commonly acknowledged that DHAAD is not hyper secure in the MIP6 world, and since CR Discovery is similar to MIP6 one immediately thinks about the more risks CRD involves, so how do you secure it? > The mobile router learns the correspondent router anycast address > from the correspondent node's prefix and the anycast identification. This and other places make the assumption that CN's prefix and CR's prefix match on the first 64 bits. This is also something used in "home network models". I think this is a very particular case, especially when CR is placed nearer to the centre than to the leaves... Just a thought. About ORC RO in nested aggregations of moving networks. The method with "reflective BU's" seem to make sense but immediately two questions come to mind. It is said that sub-MR learns root-MR's CoA from the RA's send by the latter to the former. But what about sub-sub-MR's? Does the sub-MR re-transmit the root-MR's CoA it receives, or does is it just transmitting its own CoA? How does an MR _know_ of being a root-MR in fact? > The correspondent router then sends a binding update message to the > root-MR for the network claimed by the correspondent router. Ok, so root-MR has some sort of a binding cache, right? This looks new? That's about my remarks, I know it's lengthy, but I find it to be a good reading of an interesting method. Thanks for all replies. Alex --------------enig9A350EF2AB4361CAF33E3635 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBDkHdMmC0w56zj54RAhm7AKDeGBYrnrXSOpe2CviCchkMEWjjTACfVaRn MxhkFipbuE/jPOJiZT7M49Q= =t8Ri -----END PGP SIGNATURE----- --------------enig9A350EF2AB4361CAF33E3635-- From nemo-bounces@ietf.org Mon Aug 2 13:00:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18899 for ; Mon, 2 Aug 2004 13:00:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brg5D-0004Ih-Jz; Mon, 02 Aug 2004 12:54:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brfpw-00063E-Jd for nemo@megatron.ietf.org; Mon, 02 Aug 2004 12:38:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17617 for ; Mon, 2 Aug 2004 12:38:54 -0400 (EDT) Received: from ns1.ntcnet.com ([65.174.170.5] helo=newport.ntcnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brfsp-0008JJ-Sx for nemo@ietf.org; Mon, 02 Aug 2004 12:41:56 -0400 Received: from SWC.critical.com by newport.ntcnet.com (8.8.8/1.1.8.2/13Jul95-1105AM) id MAA0000251965; Mon, 2 Aug 2004 12:49:29 -0400 (EDT) Message-Id: <6.1.1.1.0.20040802123955.024ce2e8@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 02 Aug 2004 12:40:47 -0400 To: IETF NEMO WG From: "Stuart W. Card" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "T.J.Kniveton" , zabele@alphatech.com, patricia.baskinger@northropgrumman.com Subject: [nemo] can't make San Diego but here's some food for thought X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 04:50 PM 7/30/2004, wrote: >... >See you in San Diego... Sadly, I will again be unable to join you. However, I would like to take this opportunity to remind you of some work we have done and issues we have identified, described in long-ago postings to the mailing list, in case any of this proves relevant during IETF60. (1) We have a very NEMO-like solution for IPv4 under Linux. It has been extensively tested, both in the lab and in the field (multiple LANs aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM radios to reach base stations). It uses MIPv4 extension type 42 to register prefixes and supports multihoming via multiple simultaneous COAs. It minimally violates the MIPv4 RFC by not merely sending redundant packets to the COAs, but rather load balancing across them with QoS reservations. That approach to forwarding is decoupled from the basic network mobility support mechanism, so the registration is 100% compliant with the RFCs as far as we know. It was designed by Dr. Steve Zabele of AlphaTech, implemented by his staff, and integrated by a Northrop Grumman led team into a DoD system. (2) We have not yet migrated to IPv6 and NEMO, partly because the lack of FAs in MIPv6 forces encapsulation over the links to the MRs. While this overhead is minor over wireline and many wireless media, it is significant over our wireless WAN links (long latency, low data rate, high error rate, due to being narrowband and traversing long ranges often including geostationary satellites). We would like to migrate to IPv6 and NEMO to be in step with the community. Are there any ideas being considered that could obviate the requirement for encapsulation over the links to the MRs, at least in some special cases that might need additional support not required by the basic support draft? (3) For the reasons cited in (2) above, we are concerned with the multiple encapsulation that may occur with nested NEMO and/or RO. We really don't care about RO in the wireline network, as our bandwidths are so many orders of magnitude smaller, but we do need to avoid any avoidable multiple trips or encapsulations over the wireless links. We believe this concern will be shared by other developers of wireless WANs, as bandwidth is inherently much more precious in the wireless WAN than the wireless LAN, as the latter spectrum can be extensively re-used in different cells, but the former cannot. (4) Assume MN1 is served by MR1 and MN2 by MR2, and that the former is the parent of the latter in a nested NEMO. If MR2 then achieves another point of attachment to the fixed infrastructure, but also retains its connectivity through MN1, MN2 is multi-homed, but MN1 is not, per the the nomenclature and multihoming drafts. This is because MNs are nominally precluded from offering transit. However, the access link between MR1 and the infrastructure may have very different QoS attributes from that directly between MR2 and the infrastructure: nodes in MN2 can choose their preference, but nodes in MN1 cannot; in some scenarios, the restriction on transit through MN2 will preclude some applications from running on nodes in MN1, even though adequate capacity and QoS would be available to them, were they only permitted to transit MN2. Setting QoS aside, MN1 and MN2 may both offer bursty traffic, with peak demand from each exceeding the capacity of its MR's direct link to the backbones, but the peak aggregate demand not exceeding their aggregated capacity; MN2 will be fine, but MN1 will suffer needless congestion induced packet loss if it is not permitted to transit MN2. We realize that transit should not be offered in general by MNs, for good and obvious reasons, but believe cases of this sort should be supported. Keep in mind that the only reason MN2 was allowed to transit MN1, and not vice versa, was the temporal order in which registrations occurred: MN2 first was attached to MN1 and then later directly to the backbones; had MN2 initially been attached to a backbone, and MN1 attached to MN2, the 'rules' as to who can transit whom would have been reversed. If anyone would like to discuss these interactively, despite my absence from the face-to-face meeting, send me an e-mail and we can arrange to speak by phone. We believe these concerns will be shared, not just by US DoD developers, but by mobile wireless WAN developers in general, so thanks for giving them some thought! Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com From nemo-bounces@ietf.org Mon Aug 2 13:18:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20067 for ; Mon, 2 Aug 2004 13:18:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgJU-00023b-74; Mon, 02 Aug 2004 13:09:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgCx-0007K2-Bo for nemo@megatron.ietf.org; Mon, 02 Aug 2004 13:02:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19063 for ; Mon, 2 Aug 2004 13:02:40 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrgFq-0000Ft-8F for nemo@ietf.org; Mon, 02 Aug 2004 13:05:43 -0400 Received: from opene-130-129-132-190.ietf60.ietf.org (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2FAC65D1C5 for ; Tue, 3 Aug 2004 02:02:07 +0900 (JST) Date: Tue, 3 Aug 2004 02:03:34 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20040803020334.5b97fa59.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [nemo] Issue Page for WG last call on Terminology and Requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, I would like to remind everyone that I've prepared an issue page for the WG last call of draft-ietf-nemo-terminology and draft-ietf-nemo-requirements. Please check http://www.sfc.wide.ad.jp/~ernst/nemo before the meeting this evening. I didn't received any comment on draft requirements. Thanks. Thierry. From nemo-bounces@ietf.org Mon Aug 2 13:18:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20142 for ; Mon, 2 Aug 2004 13:18:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgJg-00026P-Rm; Mon, 02 Aug 2004 13:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgFa-0008Gl-A1 for nemo@megatron.ietf.org; Mon, 02 Aug 2004 13:05:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19182 for ; Mon, 2 Aug 2004 13:05:23 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrgIS-0000JC-VG for nemo@ietf.org; Mon, 02 Aug 2004 13:08:26 -0400 Received: from opene-130-129-132-190.ietf60.ietf.org (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 74C545D1BB for ; Tue, 3 Aug 2004 02:04:52 +0900 (JST) Date: Tue, 3 Aug 2004 02:06:20 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20040803020620.4537a497.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [nemo] Up-to-date 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 Content-Transfer-Encoding: 7bit Please check http://www.mobilenetworks.org/nemo/ietf60/nemo-agenda-ietf60.txt for an updated agenda. NEMO chairs. From nemo-bounces@ietf.org Mon Aug 2 13:34:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20815 for ; Mon, 2 Aug 2004 13:34:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgV0-0006dE-Qn; Mon, 02 Aug 2004 13:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrfCf-0002Wu-7v for nemo@megatron.ietf.org; Mon, 02 Aug 2004 11:58:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15295 for ; Mon, 2 Aug 2004 11:58:18 -0400 (EDT) Received: from ns1.ntcnet.com ([65.174.170.5] helo=newport.ntcnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrfFW-0007eM-Ui for nemo@ietf.org; Mon, 02 Aug 2004 12:01:20 -0400 Received: from SWC.critical.com by newport.ntcnet.com (8.8.8/1.1.8.2/13Jul95-1105AM) id MAA0000244545; Mon, 2 Aug 2004 12:09:01 -0400 (EDT) Message-Id: <6.1.1.1.0.20040802105613.0242a2d8@mail.borg.com> X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 02 Aug 2004 11:59:34 -0400 To: IETF NEMO WG From: "Stuart W. Card" In-Reply-To: <0A4934ED-E26A-11D8-B489-000A95DA08F2@kniveton.com> References: <6.1.1.1.0.20040729000818.0240eec0@mail.borg.com> <0A4934ED-E26A-11D8-B489-000A95DA08F2@kniveton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Mon, 02 Aug 2004 13:21:21 -0400 Cc: "T.J.Kniveton" , zabele@alphatech.com, patricia.baskinger@northropgrumman.com Subject: [nemo] can't make San Diego but here's some food for thought X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 04:50 PM 7/30/2004, wrote: >... >See you in San Diego... Sadly, I will again be unable to join you. However, I would like to take this opportunity to remind you of some work we have done and issues we have identified, described in long-ago postings to the mailing list, in case any of this proves relevant during IETF60. (1) We have a very NEMO-like solution for IPv4 under Linux. It has been extensively tested, both in the lab and in the field (multiple LANs aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM radios to reach base stations). It uses MIPv4 extension type 42 to register prefixes and supports multihoming via multiple simultaneous COAs. It minimally violates the MIPv4 RFC by not merely sending redundant packets to the COAs, but rather load balancing across them with QoS reservations. That approach to forwarding is decoupled from the basic network mobility support mechanism, so the registration is 100% compliant with the RFCs as far as we know. It was designed by Dr. Steve Zabele of AlphaTech, implemented by his staff, and integrated by a Northrop Grumman led team into a DoD system. (2) We have not yet migrated to IPv6 and NEMO, partly because the lack of FAs in MIPv6 forces encapsulation over the links to the MRs. While this overhead is minor over wireline and many wireless media, it is significant over our wireless WAN links (long latency, low data rate, high error rate, due to being narrowband and traversing long ranges often including geostationary satellites). We would like to migrate to IPv6 and NEMO to be in step with the community. Are there any ideas being considered that could obviate the requirement for encapsulation over the links to the MRs, at least in some special cases that might need additional support not required by the basic support draft? (3) For the reasons cited in (2) above, we are concerned with the multiple encapsulation that may occur with nested NEMO and/or RO. We really don't care about RO in the wireline network, as our bandwidths are so many orders of magnitude smaller, but we do need to avoid any avoidable multiple trips or encapsulations over the wireless links. We believe this concern will be shared by other developers of wireless WANs, as bandwidth is inherently much more precious in the wireless WAN than the wireless LAN, as the latter spectrum can be extensively re-used in different cells, but the former cannot. (4) Assume MN1 is served by MR1 and MN2 by MR2, and that the former is the parent of the latter in a nested NEMO. If MR2 then achieves another point of attachment to the fixed infrastructure, but also retains its connectivity through MN1, MN2 is multi-homed, but MN1 is not, per the the nomenclature and multihoming drafts. This is because MNs are nominally precluded from offering transit. However, the access link between MR1 and the infrastructure may have very different QoS attributes from that directly between MR2 and the infrastructure: nodes in MN2 can choose their preference, but nodes in MN1 cannot; in some scenarios, the restriction on transit through MN2 will preclude some applications from running on nodes in MN1, even though adequate capacity and QoS would be available to them, were they only permitted to transit MN2. Setting QoS aside, MN1 and MN2 may both offer bursty traffic, with peak demand from each exceeding the capacity of its MR's direct link to the backbones, but the peak aggregate demand not exceeding their aggregated capacity; MN2 will be fine, but MN1 will suffer needless congestion induced packet loss if it is not permitted to transit MN2. We realize that transit should not be offered in general by MNs, for good and obvious reasons, but believe cases of this sort should be supported. Keep in mind that the only reason MN2 was allowed to transit MN1, and not vice versa, was the temporal order in which registrations occurred: MN2 first was attached to MN1 and then later directly to the backbones; had MN2 initially been attached to a backbone, and MN1 attached to MN2, the 'rules' as to who can transit whom would have been reversed. If anyone would like to discuss these interactively, despite my absence from the face-to-face meeting, send me an e-mail and we can arrange to speak by phone. We believe these concerns will be shared, not just by US DoD developers, but by mobile wireless WAN developers in general, so thanks for giving them some thought! Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com From nemo-bounces@ietf.org Mon Aug 2 14:08:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23326 for ; Mon, 2 Aug 2004 14:08:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrgvZ-0001Ct-54; Mon, 02 Aug 2004 13:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brghi-00038f-Ql for nemo@megatron.ietf.org; Mon, 02 Aug 2004 13:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20792 for ; Mon, 2 Aug 2004 13:34:29 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brgkb-0000k3-H0 for nemo@ietf.org; Mon, 02 Aug 2004 13:37:31 -0400 Received: from opene-130-129-132-190.ietf60.ietf.org (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 184AF5D1F0; Tue, 3 Aug 2004 02:33:56 +0900 (JST) Date: Tue, 3 Aug 2004 02:35:22 +0900 From: Thierry Ernst To: "Stuart W. Card" Subject: Re: [nemo] can't make San Diego but here's some food for thought Message-Id: <20040803023522.4b153ae8.ernst@sfc.wide.ad.jp> In-Reply-To: <6.1.1.1.0.20040802123955.024ce2e8@wheresmymailserver.com> References: <6.1.1.1.0.20040802123955.024ce2e8@wheresmymailserver.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.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 Cc: nemo@ietf.org, tj@kniveton.com, zabele@alphatech.com, patricia.baskinger@northropgrumman.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 Content-Transfer-Encoding: 7bit Hi Stuart, On your scenario below, what would prevent a reversal for the second mobile network MN2 (this doesn't stand for mobile node I suspect ...) serving as the parent of MN1 ? Also, we once spoke about "split network", why not about "merged networks" ? Thierry. > (4) Assume MN1 is served by MR1 and MN2 by MR2, and that > the former is the parent of the latter in a nested NEMO. If MR2 > then achieves another point of attachment to the fixed infrastructure, > but also retains its connectivity through MN1, MN2 is multi-homed, > but MN1 is not, per the the nomenclature and multihoming drafts. > This is because MNs are nominally precluded from offering transit. > However, the access link between MR1 and the infrastructure may > have very different QoS attributes from that directly between MR2 > and the infrastructure: nodes in MN2 can choose their preference, > but nodes in MN1 cannot; in some scenarios, the restriction on > transit through MN2 will preclude some applications from running > on nodes in MN1, even though adequate capacity and QoS would > be available to them, were they only permitted to transit MN2. > Setting QoS aside, MN1 and MN2 may both offer bursty traffic, > with peak demand from each exceeding the capacity of its MR's > direct link to the backbones, but the peak aggregate demand > not exceeding their aggregated capacity; MN2 will be fine, but > MN1 will suffer needless congestion induced packet loss if it is > not permitted to transit MN2. We realize that transit should not > be offered in general by MNs, for good and obvious reasons, but > believe cases of this sort should be supported. Keep in mind that > the only reason MN2 was allowed to transit MN1, and not vice versa, > was the temporal order in which registrations occurred: MN2 first was > attached to MN1 and then later directly to the backbones; had MN2 > initially been attached to a backbone, and MN1 attached to MN2, > the 'rules' as to who can transit whom would have been reversed. > > If anyone would like to discuss these interactively, despite my > absence from the face-to-face meeting, send me an e-mail and > we can arrange to speak by phone. > > We believe these concerns will be shared, not just by US DoD > developers, but by mobile wireless WAN developers in general, > so thanks for giving them some thought! > > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com > > > > From nemo-bounces@ietf.org Mon Aug 2 15:10:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27829 for ; Mon, 2 Aug 2004 15:10:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BriA9-0002qB-3a; Mon, 02 Aug 2004 15:07:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bri2i-0008JD-1L for nemo@megatron.ietf.org; Mon, 02 Aug 2004 15:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26872 for ; Mon, 2 Aug 2004 15:00:14 -0400 (EDT) Received: from salzburg.ucdavis.edu ([169.237.104.162]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bri5b-0002VR-Qu for nemo@ietf.org; Mon, 02 Aug 2004 15:03:17 -0400 Received: from adalia.ucdavis.edu (adalia.ucdavis.edu [169.237.104.182]) by salzburg.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i72Iwl9x013303; Mon, 2 Aug 2004 11:59:06 -0700 (PDT) Received: from adalia.ucdavis.edu (localhost [127.0.0.1]) by adalia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i72Iwlub029020; Mon, 2 Aug 2004 11:58:47 -0700 (PDT) Received: (from www@localhost) by adalia.ucdavis.edu (8.12.10/8.12.9/Submit) id i72Iwhsl029019; Mon, 2 Aug 2004 11:58:43 -0700 (PDT) Date: Mon, 2 Aug 2004 11:58:43 -0700 (PDT) Message-Id: <200408021858.i72Iwhsl029019@adalia.ucdavis.edu> To: "Pascal Thubert (pthubert)" , nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [130.129.132.145] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nemo] RE: RRH security draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Pascal, Some comments on the folowing text. 1. This may not work in NEMO basic support. It will also prevent using HA in the security mechanism for RRH. Also MR cannot advertise such globally unroutable prefix to MNN/LFN. 2. This also brings out the authorization issues. what prefix is MR authorized to advertise? What happens if two different MRs advertise the same prefixes? fan > - Prefixes advertised in the clear by a MR for other MRs to visit may > not be global prefixes. The MR may keep it global MNP for trusted (L2 > authenticated) users and forge the prefix on the fly, renewing it every > so often, for the visitors. As a result, the CareOf are not global but > who cares. Only the MR that forged and exposed the prefix needs to route > on it. This preserves the privacy of the visited MR the way RFC 3041 > preserves the privacy of the visitor. From nemo-bounces@ietf.org Mon Aug 2 18:56:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12496 for ; Mon, 2 Aug 2004 18:56:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brkd0-0003Cl-72; Mon, 02 Aug 2004 17:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkTa-0007FN-Bv for nemo@megatron.ietf.org; Mon, 02 Aug 2004 17:36:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07036 for ; Mon, 2 Aug 2004 17:36:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrkWV-0004xH-MZ for nemo@ietf.org; Mon, 02 Aug 2004 17:39:13 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2004 23:40:12 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i72LZWuG023625; Mon, 2 Aug 2004 23:35:33 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Aug 2004 23:30:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2004 23:35:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05685C@xmb-ams-337.emea.cisco.com> Thread-Topic: RRH security draft Thread-Index: AcR4xKY23F5nbe+hQ5+s09WK6t7YuwAEvzXg From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , X-OriginalArrivalTime: 02 Aug 2004 21:30:25.0828 (UTC) FILETIME=[ECBC4640:01C478D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: RRH security draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Fan, Thanks a lot for your interest >=20 > Some comments on the following text. > 1. This may not work in NEMO basic support. It will also prevent > using HA in the security mechanism for RRH. Also MR cannot advertise > such globally unroutable prefix to MNN/LFN. The forged MNPs are not advertised to the HA. They only work within an RRH, and are only present on that link, for a short period of time. > 2. This also brings out the authorization issues. > what prefix is MR authorized to advertise? What happens > if two different MRs advertise the same prefixes? The MR does not have to be globally authorized; it owns a link and toys with it. The careof used in the RRH will never be the real source or destination of a packet in the Internet, but always end up in a routing header; the only trick is DHAAD. You have to implement a null RRH in DHAAD messages that is reversed by the HA. This is part of the RRH support and this is how we override the deadlock problem of the HA attached to its own MR. The model I have in mind for this is a link served by a MR (like each MR has an AP). If you want to use that technique with more then one router, you have a chance out of 2^61 that they forge the same. If they are administered together, there's a way to include an short ID as part of the 61 bits.=20 > fan >=20 > > - Prefixes advertised in the clear by a MR for other MRs to visit may > > not be global prefixes. The MR may keep it global MNP for trusted (L2 > > authenticated) users and forge the prefix on the fly, renewing it every > > so often, for the visitors. As a result, the CareOf are not global but > > who cares. Only the MR that forged and exposed the prefix needs to route > > on it. This preserves the privacy of the visited MR the way RFC 3041 > > preserves the privacy of the visitor. From nemo-bounces@ietf.org Mon Aug 2 18:56:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12513 for ; Mon, 2 Aug 2004 18:56:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkiJ-0005Up-Gi; Mon, 02 Aug 2004 17:51:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkcE-0002vQ-QU for nemo@megatron.ietf.org; Mon, 02 Aug 2004 17:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07484 for ; Mon, 2 Aug 2004 17:45:04 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brkf8-00057I-Fg for nemo@ietf.org; Mon, 02 Aug 2004 17:48:09 -0400 Received: from opene-130-129-135-7.ietf60.ietf.org.sfc.wide.ad.jp (opene-130-129-135-7.ietf60.ietf.org [130.129.135.7] (may be forged)) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i72Lel4v026814; Tue, 3 Aug 2004 06:40:48 +0900 Date: Tue, 03 Aug 2004 06:43:42 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Subject: Re: [nemo] Comments on RO Taxonomy draft In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05663C@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC05663C@xmb-ams-337.emea.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Pascal MANET routing protocol can carry prefixes. ryuji At Fri, 30 Jul 2004 13:31:51 +0200, pascal wrote: > > Well, VMNs would need to participate to the routing protocol. You may > call it a MANET, and in fact it's related, but it's not one of the > experimental RFCS since we need to carry prefixes. Do I miss something? > > Pascal > > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > Of Masafumi Watari > > Sent: jeudi 29 juillet 2004 14:27 > > To: Pascal Thubert (pthubert) > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Comments on RO Taxonomy draft > > > > Hello Pascal-san, > > > > Well, for case 1 & 2, I understand that such integration may be a > > possible solution, and that alternate routes can avoid the tunnels. > > > > But I'm also concerned when the node is a VMN. If we allow VMNs to > > attach behind any nested NEMO, the VMNs will always use the > > bi-directional tunnel with it's home agent, and thus the alternative > > routes can not be utilized. > > > > So I'm not sure it works so easily with the ad-hoc routing protocols, > > and that we might need to consider other approaches to support both > > type of nodes. > > > > Even if we don't consider VMNs for now, we do need to consider case 3, > > I think. > > > > watari > > > > On Thu, 29 Jul 2004 10:41:10 +0200, > > "Pascal Thubert (pthubert)" wrote: > > > > > Hi Masafumi-san > > > > > > For case 1 & 2, I'm wondering if you're talking about a NEMO problem > > > versus a smooth integration of NEMO and a ad-hoc routing protocol > within > > > the nested structure. > > > > > > Basically, Nemo establishes a default route over a tunnel. NEMO RO > to CR > > > will establish additional routes over other (MR to CR, CR being a > subset > > > of MR)) tunnels, which you may call 'route projection' as opposed to > > > traditional route injection. > > > > > > If a routing protocol provides alternate routes within the nested > > > structure, all these tunnels are completely bypassed. This is > > > transparent to the LFNs. > > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On > Behalf > > > Of Masafumi Watari > > > > Sent: mercredi 28 juillet 2004 17:27 > > > > To: nemo@ietf.org > > > > Subject: [nemo] Comments on RO Taxonomy draft > > > > > > > > Hi all, > > > > > > > > It seems to me that many proposals on route optimization in nested > > > > NEMO are focused in the case where the correspondent nodes is > located > > > > at the infrastructure. For example, route optimization with MIP6 > > > > correspondent nodes, correspondent routers, or IPv6 nodes with > > > > forwarding to the home agent from the root MR. I think this is > also > > > > true for the taxonomy draft. > > > > > > > > However, I believe that there are other cases which we should > consider > > > > to provide a full route optimization. Precisely, the cases where > the > > > > correspondent node is also behind a nested NEMO, if its within the > > > > scope of the WG. > > > > > > > > For example, when a node is behind another nested NEMO, the > discovery > > > > becomes much more complex, since the you must also discover the > tree > > > > of the other nest. Furthermore if the solution is to use > tunneling or > > > > routing headers for each MR, this overhead become severe. > > > > > > > > Below are the cases that are in my mind for now. > > > > > > > > Case 1: Same MR, same nested NEMO > > > > Two communicating nodes are located behind the same mobile router, > and > > > > behind the same nested NEMO. > > > > > > > > Case 2: Different MR, but same nested NEMO. > > > > Two communicating nodes are located behind a different mobile > router, > > > > but each mobile router is attached behind the same nested NEMO. > > > > > > > > Case 3: Different nested NEMO. > > > > Two communicating nodes are located behind a different nested > NEMO. > > > > > > > > Furtheremore, for each case, we might need to consider the case > where > > > > the two nodes are both LFNs, both VMNs, or a LFN and a VMN. If > > > > optimization involves VMN, this could be complex even in case 1. > > > > > > > > Any comments? > > > > > > > > Best regards, > > > > watari > > > > > > > > > > From nemo-bounces@ietf.org Mon Aug 2 18:56:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12530 for ; Mon, 2 Aug 2004 18:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkxW-00054y-Cr; Mon, 02 Aug 2004 18:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrkeL-0003zO-Nn for nemo@megatron.ietf.org; Mon, 02 Aug 2004 17:47:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07672 for ; Mon, 2 Aug 2004 17:47:15 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrkhE-00059y-VN for nemo@ietf.org; Mon, 02 Aug 2004 17:50:20 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2004 23:51:18 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i72LkcuG024522; Mon, 2 Aug 2004 23:46:38 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Aug 2004 23:46:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] can't make San Diego but here's some food for thought Date: Mon, 2 Aug 2004 23:46:31 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05685D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] can't make San Diego but here's some food for thought Thread-Index: AcR4slcVzwzGCSFQSGGPm894po0zjAAJrDVQ From: "Pascal Thubert \(pthubert\)" To: "Stuart W. Card" , "IETF NEMO WG" X-OriginalArrivalTime: 02 Aug 2004 21:46:37.0871 (UTC) FILETIME=[301E43F0:01C478DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: "T.J.Kniveton" , zabele@alphatech.com, patricia.baskinger@northropgrumman.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 Content-Transfer-Encoding: quoted-printable Hi Stuart: For the multiple encapsulation problem, there's been a number of = solution proposed to what we refer to as nested RO. In particular, RRH = as a 2 year history of discussion in the ML (current version is 5); it = has been implemented and tested. I'd be glad to discuss that if you = wish. What needs to be done next is a classical header compression that = includes both the IPv6 header and the routing header over the low speed = link, and I guess that's it. http://www1.ietf.org/mail-archive/web/nemo/current/msg01306.html=20 Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Stuart W. Card > Sent: lundi 2 ao=FBt 2004 18:41 > To: IETF NEMO WG > Cc: T.J.Kniveton; zabele@alphatech.com; = patricia.baskinger@northropgrumman.com > Subject: [nemo] can't make San Diego but here's some food for thought >=20 > At 04:50 PM 7/30/2004, wrote: > >... > >See you in San Diego... >=20 > Sadly, I will again be unable to join you. However, I would like > to take this opportunity to remind you of some work we have done > and issues we have identified, described in long-ago postings to > the mailing list, in case any of this proves relevant during IETF60. >=20 > (1) We have a very NEMO-like solution for IPv4 under Linux. It has > been extensively tested, both in the lab and in the field (multiple = LANs > aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM radios > to reach base stations). It uses MIPv4 extension type 42 to register > prefixes and supports multihoming via multiple simultaneous COAs. > It minimally violates the MIPv4 RFC by not merely sending redundant > packets to the COAs, but rather load balancing across them with > QoS reservations. That approach to forwarding is decoupled from > the basic network mobility support mechanism, so the registration > is 100% compliant with the RFCs as far as we know. It was designed > by Dr. Steve Zabele of AlphaTech, implemented by his staff, and > integrated by a Northrop Grumman led team into a DoD system. >=20 > (2) We have not yet migrated to IPv6 and NEMO, partly > because the lack of FAs in MIPv6 forces encapsulation > over the links to the MRs. While this overhead is minor > over wireline and many wireless media, it is significant > over our wireless WAN links (long latency, low data rate, > high error rate, due to being narrowband and traversing > long ranges often including geostationary satellites). > We would like to migrate to IPv6 and NEMO to be in step > with the community. Are there any ideas being considered > that could obviate the requirement for encapsulation over the > links to the MRs, at least in some special cases that might > need additional support not required by the basic support draft? >=20 > (3) For the reasons cited in (2) above, we are concerned with > the multiple encapsulation that may occur with nested NEMO > and/or RO. We really don't care about RO in the wireline network, > as our bandwidths are so many orders of magnitude smaller, but > we do need to avoid any avoidable multiple trips or encapsulations > over the wireless links. We believe this concern will be shared > by other developers of wireless WANs, as bandwidth is inherently > much more precious in the wireless WAN than the wireless LAN, > as the latter spectrum can be extensively re-used in different cells, > but the former cannot. >=20 > (4) Assume MN1 is served by MR1 and MN2 by MR2, and that > the former is the parent of the latter in a nested NEMO. If MR2 > then achieves another point of attachment to the fixed infrastructure, > but also retains its connectivity through MN1, MN2 is multi-homed, > but MN1 is not, per the the nomenclature and multihoming drafts. > This is because MNs are nominally precluded from offering transit. > However, the access link between MR1 and the infrastructure may > have very different QoS attributes from that directly between MR2 > and the infrastructure: nodes in MN2 can choose their preference, > but nodes in MN1 cannot; in some scenarios, the restriction on > transit through MN2 will preclude some applications from running > on nodes in MN1, even though adequate capacity and QoS would > be available to them, were they only permitted to transit MN2. > Setting QoS aside, MN1 and MN2 may both offer bursty traffic, > with peak demand from each exceeding the capacity of its MR's > direct link to the backbones, but the peak aggregate demand > not exceeding their aggregated capacity; MN2 will be fine, but > MN1 will suffer needless congestion induced packet loss if it is > not permitted to transit MN2. We realize that transit should not > be offered in general by MNs, for good and obvious reasons, but > believe cases of this sort should be supported. Keep in mind that > the only reason MN2 was allowed to transit MN1, and not vice versa, > was the temporal order in which registrations occurred: MN2 first was > attached to MN1 and then later directly to the backbones; had MN2 > initially been attached to a backbone, and MN1 attached to MN2, > the 'rules' as to who can transit whom would have been reversed. >=20 > If anyone would like to discuss these interactively, despite my > absence from the face-to-face meeting, send me an e-mail and > we can arrange to speak by phone. >=20 > We believe these concerns will be shared, not just by US DoD > developers, but by mobile wireless WAN developers in general, > so thanks for giving them some thought! >=20 > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com >=20 >=20 >=20 From nemo-bounces@ietf.org Mon Aug 2 21:48:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21391 for ; Mon, 2 Aug 2004 21:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroNU-0004It-44; Mon, 02 Aug 2004 21:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroKg-0003CJ-KY for nemo@megatron.ietf.org; Mon, 02 Aug 2004 21:43:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21281 for ; Mon, 2 Aug 2004 21:43:12 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BroNd-0000aS-T8 for nemo@ietf.org; Mon, 02 Aug 2004 21:46:19 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 565C461ED for ; Mon, 2 Aug 2004 18:42:55 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20294-09 for ; Mon, 2 Aug 2004 18:42:54 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 7066761D4; Mon, 2 Aug 2004 18:42:54 -0700 (PDT) Received: from [130.129.132.95] (opene-130-129-132-95.ietf60.ietf.org [130.129.132.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id A54F76122 for ; Mon, 2 Aug 2004 18:42:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <72122609-E4EE-11D8-B3FA-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Mon, 2 Aug 2004 18:42:57 -0700 X-Mailer: Apple Mail (2.618) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [nemo] 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 Content-Transfer-Encoding: 7bit Hi folks, The latest version of the agenda can be found (in PDF) at: http://www.mobilenetworks.org/nemo/ietf60/nemo-ietf60-agenda.pdf TJ From nemo-bounces@ietf.org Mon Aug 2 21:55:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21708 for ; Mon, 2 Aug 2004 21:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroU4-000740-8i; Mon, 02 Aug 2004 21:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroTa-0006iu-5W for nemo@megatron.ietf.org; Mon, 02 Aug 2004 21:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21591 for ; Mon, 2 Aug 2004 21:52:24 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BroWY-0000hN-2F for nemo@ietf.org; Mon, 02 Aug 2004 21:55:31 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 0B08A6254 for ; Mon, 2 Aug 2004 18:52:17 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20627-03 for ; Mon, 2 Aug 2004 18:52:16 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 28AC4623E; Mon, 2 Aug 2004 18:52:16 -0700 (PDT) Received: from [130.129.132.95] (opene-130-129-132-95.ietf60.ietf.org [130.129.132.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 67521621F for ; Mon, 2 Aug 2004 18:52:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Mon, 2 Aug 2004 18:52:19 -0700 X-Mailer: Apple Mail (2.618) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] Jabber X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit As a reminder, anyone who is interested in participating in the meeting remotely can join the conference via Jabber at the group chat nemo@ietf.xmpp.org Instructions are here: http://xmpp.org/ietf-chat.html You can also view the meeting video/audio via the mbone, or if you don't have (or don't know what is) the mbone, check out this page: http://esm.cs.cmu.edu/ the software there will let you view our meeting, and then you can ask questions via Jabber. TJ From nemo-bounces@ietf.org Tue Aug 3 03:31:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21732 for ; Tue, 3 Aug 2004 03:31:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrtiR-0005YD-N9; Tue, 03 Aug 2004 03:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brtei-0004Gw-2B for nemo@megatron.ietf.org; Tue, 03 Aug 2004 03:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21554 for ; Tue, 3 Aug 2004 03:24:14 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brthh-00059r-7O for nemo@ietf.org; Tue, 03 Aug 2004 03:27:24 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id CAA14676; Tue, 3 Aug 2004 02:23:39 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i737NdE26269; Tue, 3 Aug 2004 00:23:39 -0700 (PDT) Received: from xch-nw-21.nw.nos.boeing.com ([192.48.4.95]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 3 Aug 2004 00:23:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 00:23:38 -0700 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E105CD3B3E@xch-nw-21.nw.nos.boeing.com> Thread-Topic: Mobile Network Conops Thread-Index: AcR4/Aaj6OTtGwnvS2qSzz6u/KhBNgAD59qw From: "Davis, Terry L" To: "T.J.Kniveton" , "Thierry Ernst" , "IETF NEMO WG" X-OriginalArrivalTime: 03 Aug 2004 07:23:38.0686 (UTC) FILETIME=[CBBB65E0:01C4792A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Subject: [nemo] Mobile Network Conops X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable TJ/Thierry Sometime it helps if you have some rough CONOP requirements for the = problem you are discussing. For the aircraft (or ship), I can give you = a bit of future view of what an aircraft CONOP requirements set "might" = include. Very little of this could be considered absolutely definite at = this time but they are topics of discussion. Some (probably most) of this does not apply to the NEMO problem space = but it will give an idea of the challenges facing mobile networks and I = think it will give you an idea why I favor HA-HA work remaining in NEMO. Take care Terry L Davis, P.E. Associate Technical Fellow Chief Network Engineer Connexion by Boeing Desk: 206-655-2359 Cell: 206-280-3716 Email: Terry.L.Davis@Boeing.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * The aircraft will typically have access to Internet connectivity via = three or more layer 2 communications. Typically these will include: = multiple satcom links, multiple wireless networks (802.11a/b/g & = 802.15/20(?)), hardwired terrestrial, or infared. * The aircraft will periodically be on the operator/owners networks, the = aircraft manufacturer's networks, multiple airline comm providers = (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair stations, multiple = regulatory control networks (FAA/JAA/CAA/Eurocontrol), and multiple = airports. It will likely be normally on three or more of these = simultaneously. * The aircraft will have continuous access to NO single layer 2 = communication link. * The aircraft will be mixed v4 and v6 systems; some offboard = communication support for both will be required. V6 will likely not = predominate until aircraft manufactured dates past 2020. * The aircraft may require specific comm types be sent over the layer 2 = links in a very specific hierarchy to meet regulatory constraints. * The aircraft operator will require specific message prioritization and = queueing by "link cost", priority, and bandwidth. * Most link connectivity points will move in hundreds or thousands of = miles when they transfer between ground stations or airports. * Security will be different for all the networks the aircraft connects = to. * Link performance characteristics and latency will be different for all = links. * The solution must provide for ground based systems to connect to the = mobile platform regardless what network it is connected to or where it = is in the world. (DNS/DHCP/etc) Current aerospace standards make this = impossible; only the aircraft can currently initiate communications. * Multiple DNS systems will be registered on the different links. In = some cases, due to the aerospace specs, link specific DNS services will = likely be required. * Security, QoS, and reachability states must be maintained across link = and ground station changes. * The aircraft will sometimes go for extended periods in hours with no = Internet connectivity. * The aircraft will encounter areas where it will FLAP routes by = crossing in and out satellite coverage fringe areas and during terminal = approach (circling) holding patterns. * The aircraft will have multiple types of onboard networks as well; = wired, wifi, infared, etc. * The aircraft may have multiple routers; each may be associated with = different links and onboard networks. * The aircraft will most likely only receive communication and network = major updates every 10 or 20 years. * There may be regulatory limitations on when and how configurations and = routing can be updated. From nemo-bounces@ietf.org Tue Aug 3 12:53:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21035 for ; Tue, 3 Aug 2004 12:53:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2QT-00022H-G1; Tue, 03 Aug 2004 12:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2It-0000iK-II for nemo@megatron.ietf.org; Tue, 03 Aug 2004 12:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19824 for ; Tue, 3 Aug 2004 12:38:16 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2Lz-0004M1-Mk for nemo@ietf.org; Tue, 03 Aug 2004 12:41:32 -0400 Received: from [130.129.132.28] (opene-130-129-132-28.ietf60.ietf.org [130.129.132.28]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i73GZD4v008164; Wed, 4 Aug 2004 01:35:15 +0900 In-Reply-To: <410E41D6.5000100@motorola.com> References: <410E41D6.5000100@motorola.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81E3718F-E56B-11D8-A5FE-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Date: Wed, 4 Aug 2004 01:38:11 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Masafumi Watari Subject: [nemo] Re: Comments on ORC draft-wakikawa-nemo-orc-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Alex. Thanks for detailed comments to this draft. On 2004/08/02, at 22:29, Alexandru Petrescu wrote: > Hello to authors of draft-wakikawa-nemo-orc-00.txt Ryuji and Watari :-) > > I've read the draft and have comments of two kinds: editorial and on > the > architecture, at the end. > > Overall, I think the draft describes a method for offering approximate > RO for mobile hosts and mobile routers by placing new architectural > entities supporting ORC in the Internet. (like MBone routers do > bandwidth savings). The method relieves CN's from implementing any new > NEMO RO protocol, thus a great advantage. It also offers a means to > automatically discover the presence of CR's, which is also > advantageous: > ORC BU's can be triggered only when CR's are present near CN. > > One drawback seems to be the fact that even if shorter paths are > employed through CR, there's still encapsulation (if my reading is > correct); but this may probably be improved. Yes. We use tunnel between MR and CR. One thing we tried to avoid is that MR modifies original packets sent by MNN by adding RTHDR, etc. Tunneling is simple way to route packets to CR without changing original packets. > The editorials I'm mentioning below may confuse the reader easily. > They > reflect the interpretation I give to some aspects, which may be not the > right one, please enlighten if so. (and there are others on grammar > but > they're obvious so I don't mention.) > >> The ORC aims to manage binding information as if routing information >> of each mobile network are located at special routers called >> ``Correspondent Router''. > > Substitute "for when" for "as if". > >> best effect routing protocol > > Effort. > > (actually, I don't think it is very precise to say that some routing > protocol is "best effort"; I guess one can say that IP routing in > itself > happens in a best effort manner, in that nothing guarantees delivery of > fwded packets to the final destination - there's no ack. I think > routing protocols do have some means of acknowledging their exchanges > (e.g. BGP uses TCP), and in this sense they can't be qualified as best > effort. It is also true that a path taken by packets to a certain > destination is not necessarily the shortest possible, because of load > balancing and other traficcy shaping if I can say so, in which case I > think it's called simply "optimal", and this may better fit in your > context where paths are shorter if an ORC router is present and longer > otherwise. Closed parenthesis.) One goal of ORC is bypassing HA on the way to HA. Except for bypassing HA, packets are routed based on existing routing mechanism. >> Mobile router can forward any packets meant for the managed prefixes >> to the correspondent router. > > "forward" ok yes, but maybe stress with "directly, instead of > forwarding > to its HA"; and stress that MR actually encapsulates, not quite simple > forwarding. I am not sure I get your point here, but MR basically encapsulates packets to HA all the time. Only the difference is the destination of outer IP packet (either HA or CR). >> The managed prefix is used when the mobile router decides which >> packets are sent to which correspondent router. The Home Agent setup >> forwarding for all the mobile network prefixes notified by the >> mobile router. > > It is true that HA sets up fwding for all Mobile Network prefixes > notified by the MR, but in this section we're talking about Binding > Registration (btw, why not simply BU?) to the CR, not to the HA. So I > assume it's the CR you're talking about in the last phrase above (not > the HA), right? > Yes, right. I will correct this in the next version. >> next hope address > > Hoping the next hop forwards where it should :-) > > Other than editorial remarks: > > After reading, may I conclude that there's always encapsulation between > MR and CR? So this is a sort of RO but without the benefit of not > having to encapsulate? Section 2.2.2 RR invited to think it may lead > to > remove the encapsulation after RR, but it never says so. How is it > intended? > RR is just used as security mechanism. We also say IPsec can be used as a security mechanism. MR must handle packets which are not originated by MR. MR should not modify original packets (adding IP options at MR). That's why we simply say using tunnel. > About path length. > > After reading, it is clear that ORC provides for > shorter-than-through-HA > paths between MR and CN provided a CR is close to CN. > yes > But the description gives no clue about what happens when MR and its HA > are both in the CN-and-CR's domain. In this case, it may happen that > the path MR-HA-CN is much shorter than MR-CR-CN. So it would be > interesting to consider a sort of intelligence on MR about what to do > with the discovered CR's address, maybe don't always use it. > Good point. However I think ORC already have two mechanisms for this. When MR operates CR discovery, it will know whether CR is located in the same network of MR or HA. Another operation is that MR can know that CR is in same domain by checking managed prefix acquired from Binding Ack. If managed prefix is same as MR belonging network, MR may not use CR (de-registration). Anyway, this is important issue. I will update this in the next version. > Additionally, in the case that MR has its home in the same AS as the CN > and talks to CN, there is little chance for CR to "intercept" these > packets, unless CR is in the path MR-CN (should it be there?). > Right. > About CR Discovery. > > It is commonly acknowledged that DHAAD is not hyper secure in the MIP6 > world, and since CR Discovery is similar to MIP6 one immediately thinks > about the more risks CRD involves, so how do you secure it? True. Anycast address can not be used with IPsec. > >> The mobile router learns the correspondent router anycast address >> from the correspondent node's prefix and the anycast identification. > > This and other places make the assumption that CN's prefix and CR's > prefix match on the first 64 bits. This is also something used in > "home > network models". I think this is a very particular case, especially > when CR is placed nearer to the centre than to the leaves... Just a > thought. > Yes, As pascal pointed out, assuming 64/ is not good idea. I will reply to the rest of your mail by separate mail. Thanks again. ryuji From nemo-bounces@ietf.org Tue Aug 3 13:16:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23032 for ; Tue, 3 Aug 2004 13:16:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2jL-00058i-3O; Tue, 03 Aug 2004 13:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2YL-0003RE-Ot for nemo@megatron.ietf.org; Tue, 03 Aug 2004 12:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21156 for ; Tue, 3 Aug 2004 12:54:15 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2bQ-0004ep-Bv for nemo@ietf.org; Tue, 03 Aug 2004 12:57:30 -0400 Received: from opene-130-129-132-190.ietf60.ietf.org (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 05ACC5D21B; Wed, 4 Aug 2004 01:53:41 +0900 (JST) Date: Wed, 4 Aug 2004 01:55:08 +0900 From: Thierry Ernst To: "Davis, Terry L" Subject: Re: [nemo] Mobile Network Conops Message-Id: <20040804015508.01ef8118.ernst@sfc.wide.ad.jp> In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E105CD3B3E@xch-nw-21.nw.nos.boeing.com> References: <6E5042539D21AF4E9C457B4DDCC3D6E105CD3B3E@xch-nw-21.nw.nos.boeing.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.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 Cc: nemo@ietf.org, tj@kniveton.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Terry, Thank for your post. Would you tell us what CONOP stands for, and would you provide the official reference so that we could Lcite the goals below ? About your goalsI'm pretty confident that these fit the objectives of the NEMO WG activity (draft-requirements and draft-multihoming-issues) as far as network mobility support is concerned. - abality to set up multiple tunnels between MR and HA pairs -> we are working to achieve this, tough we haven't yet decided which issues are relevant to the NEMO WG, and which ones are relevant to other WGs - v4/v6 interoperatbility: I don't think there is an issue; the question I would ask is "what are the plans" to v6fy the **infrastructure** (on the HA's side). It's not a problems if LFNs / VMNs do operate IPv4. On the overall, I think that what you need in aircrafts spans a large pannel of protocols (including security, AAA). So, is there any requirement document that would specify what protocols specifically would be used, and what are the missing pieces ? Is tere any community like ISO or anything else working on such architecture design ? Thierry. On Tue, 3 Aug 2004 00:23:38 -0700 "Davis, Terry L" wrote: > TJ/Thierry > > Sometime it helps if you have some rough CONOP requirements for the problem you are discussing. For the aircraft (or ship), I can give you a bit of future view of what an aircraft CONOP requirements set "might" include. Very little of this could be considered absolutely definite at this time but they are topics of discussion. > > Some (probably most) of this does not apply to the NEMO problem space but it will give an idea of the challenges facing mobile networks and I think it will give you an idea why I favor HA-HA work remaining in NEMO. > > Take care > > Terry L Davis, P.E. > > Associate Technical Fellow > Chief Network Engineer > Connexion by Boeing > > Desk: 206-655-2359 > Cell: 206-280-3716 > Email: Terry.L.Davis@Boeing.com > > > =================================================================================================================== > > * The aircraft will typically have access to Internet connectivity via three or more layer 2 communications. Typically these will include: multiple satcom links, multiple wireless networks (802.11a/b/g & 802.15/20(?)), hardwired terrestrial, or infared. > > * The aircraft will periodically be on the operator/owners networks, the aircraft manufacturer's networks, multiple airline comm providers (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair stations, multiple regulatory control networks (FAA/JAA/CAA/Eurocontrol), and multiple airports. It will likely be normally on three or more of these simultaneously. > > * The aircraft will have continuous access to NO single layer 2 communication link. > > * The aircraft will be mixed v4 and v6 systems; some offboard communication support for both will be required. V6 will likely not predominate until aircraft manufactured dates past 2020. > > * The aircraft may require specific comm types be sent over the layer 2 links in a very specific hierarchy to meet regulatory constraints. > > * The aircraft operator will require specific message prioritization and queueing by "link cost", priority, and bandwidth. > > * Most link connectivity points will move in hundreds or thousands of miles when they transfer between ground stations or airports. > > * Security will be different for all the networks the aircraft connects to. > > * Link performance characteristics and latency will be different for all links. > > * The solution must provide for ground based systems to connect to the mobile platform regardless what network it is connected to or where it is in the world. (DNS/DHCP/etc) Current aerospace standards make this impossible; only the aircraft can currently initiate communications. > > * Multiple DNS systems will be registered on the different links. In some cases, due to the aerospace specs, link specific DNS services will likely be required. > > * Security, QoS, and reachability states must be maintained across link and ground station changes. > > * The aircraft will sometimes go for extended periods in hours with no Internet connectivity. > > * The aircraft will encounter areas where it will FLAP routes by crossing in and out satellite coverage fringe areas and during terminal approach (circling) holding patterns. > > * The aircraft will have multiple types of onboard networks as well; wired, wifi, infared, etc. > > * The aircraft may have multiple routers; each may be associated with different links and onboard networks. > > * The aircraft will most likely only receive communication and network major updates every 10 or 20 years. > > * There may be regulatory limitations on when and how configurations and routing can be updated. > > > > > > > From nemo-bounces@ietf.org Tue Aug 3 13:44:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25851 for ; Tue, 3 Aug 2004 13:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2zD-0008PC-5B; Tue, 03 Aug 2004 13:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2px-0006Uu-PI for nemo@megatron.ietf.org; Tue, 03 Aug 2004 13:12:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22707 for ; Tue, 3 Aug 2004 13:12:27 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2t3-00055A-Cw for nemo@ietf.org; Tue, 03 Aug 2004 13:15:43 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA09199; Tue, 3 Aug 2004 12:11:55 -0500 (CDT) Received: from XCH-NW-13P.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i73HBsc25444; Tue, 3 Aug 2004 12:11:54 -0500 (CDT) Received: from xch-nw-21.nw.nos.boeing.com ([192.48.4.95]) by XCH-NW-13P.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6899); Tue, 3 Aug 2004 10:11:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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] Mobile Network Conops Date: Tue, 3 Aug 2004 10:11:53 -0700 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E104DD7EED@xch-nw-21.nw.nos.boeing.com> Thread-Topic: [nemo] Mobile Network Conops Thread-Index: AcR5eqZZGfkGQd6tRemKy2qdc6z03QAATfiw From: "Davis, Terry L" To: "Thierry Ernst" X-OriginalArrivalTime: 03 Aug 2004 17:11:54.0308 (UTC) FILETIME=[F98FE840:01C4797C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thierry CONOP =3D "Concept of Operation"... (I.e. How it needs to operate and = what it needs to support in an operational sense.) The aviation community will probably be another couple of years before = we solidify what the complete overall set of requirements are for an = aircraft. These will probably be developed under AEEC (Airlines = Electronic Engineering Committee) guidance through Arinc. On the v4/v6 issue, I'd lean to supporting v4 mobility via "4 over 6" = but I can't speak for anyone other than myself on that. Take care Terry -----Original Message----- From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp]=20 Sent: Tuesday, August 03, 2004 9:55 AM To: Davis, Terry L Cc: tj@kniveton.com; nemo@ietf.org Subject: Re: [nemo] Mobile Network Conops Hi Terry, Thank for your post. Would you tell us what CONOP stands for, and would you provide the = official reference so that we could Lcite the goals below ? About your goalsI'm pretty confident that these fit the objectives of = the NEMO WG activity (draft-requirements and draft-multihoming-issues) = as far as network mobility support is concerned. - abality to set up multiple tunnels between MR and HA pairs -> we are = working to achieve this, tough we haven't yet decided which issues are = relevant to the NEMO WG, and which ones are relevant to other WGs - v4/v6 interoperatbility: I don't think there is an issue; the question = I would ask is "what are the plans" to v6fy the **infrastructure** (on = the HA's side). It's not a problems if LFNs / VMNs do operate IPv4. On the overall, I think that what you need in aircrafts spans a large = pannel of protocols (including security, AAA). So, is there any = requirement document that would specify what protocols specifically = would be used, and what are the missing pieces ? Is tere any community = like ISO or anything else working on such architecture design ? Thierry. On Tue, 3 Aug 2004 00:23:38 -0700 "Davis, Terry L" wrote: > TJ/Thierry >=20 > Sometime it helps if you have some rough CONOP requirements for the=20 > problem you are discussing. For the aircraft (or ship), I can give=20 > you a bit of future view of what an aircraft CONOP requirements set=20 > "might" include. Very little of this could be considered absolutely=20 > definite at this time but they are topics of discussion. >=20 > Some (probably most) of this does not apply to the NEMO problem space=20 > but it will give an idea of the challenges facing mobile networks and=20 > I think it will give you an idea why I favor HA-HA work remaining in=20 > NEMO. >=20 > Take care >=20 > Terry L Davis, P.E. >=20 > Associate Technical Fellow > Chief Network Engineer > Connexion by Boeing >=20 > Desk: 206-655-2359 > Cell: 206-280-3716 > Email: Terry.L.Davis@Boeing.com >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > * The aircraft will typically have access to Internet connectivity via = three or more layer 2 communications. Typically these will include: = multiple satcom links, multiple wireless networks (802.11a/b/g & = 802.15/20(?)), hardwired terrestrial, or infared. >=20 > * The aircraft will periodically be on the operator/owners networks, = the aircraft manufacturer's networks, multiple airline comm providers = (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair stations, multiple = regulatory control networks (FAA/JAA/CAA/Eurocontrol), and multiple = airports. It will likely be normally on three or more of these = simultaneously. >=20 > * The aircraft will have continuous access to NO single layer 2 = communication link. >=20 > * The aircraft will be mixed v4 and v6 systems; some offboard = communication support for both will be required. V6 will likely not = predominate until aircraft manufactured dates past 2020. >=20 > * The aircraft may require specific comm types be sent over the layer = 2 links in a very specific hierarchy to meet regulatory constraints. >=20 > * The aircraft operator will require specific message prioritization = and queueing by "link cost", priority, and bandwidth. >=20 > * Most link connectivity points will move in hundreds or thousands of = miles when they transfer between ground stations or airports. >=20 > * Security will be different for all the networks the aircraft = connects to. >=20 > * Link performance characteristics and latency will be different for = all links. >=20 > * The solution must provide for ground based systems to connect to the = mobile platform regardless what network it is connected to or where it = is in the world. (DNS/DHCP/etc) Current aerospace standards make this = impossible; only the aircraft can currently initiate communications. >=20 > * Multiple DNS systems will be registered on the different links. In = some cases, due to the aerospace specs, link specific DNS services will = likely be required. >=20 > * Security, QoS, and reachability states must be maintained across = link and ground station changes. >=20 > * The aircraft will sometimes go for extended periods in hours with no = Internet connectivity. >=20 > * The aircraft will encounter areas where it will FLAP routes by = crossing in and out satellite coverage fringe areas and during terminal = approach (circling) holding patterns. >=20 > * The aircraft will have multiple types of onboard networks as well; = wired, wifi, infared, etc. >=20 > * The aircraft may have multiple routers; each may be associated with = different links and onboard networks. >=20 > * The aircraft will most likely only receive communication and network = major updates every 10 or 20 years. >=20 > * There may be regulatory limitations on when and how configurations = and routing can be updated. >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Tue Aug 3 13:47:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26060 for ; Tue, 3 Aug 2004 13:47:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2zH-0008Rm-An; Tue, 03 Aug 2004 13:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2sK-0006yI-LA for nemo@megatron.ietf.org; Tue, 03 Aug 2004 13:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22940 for ; Tue, 3 Aug 2004 13:14:53 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2vQ-00059M-Cq for nemo@ietf.org; Tue, 03 Aug 2004 13:18:10 -0400 Received: from [130.129.132.28] (opene-130-129-132-28.ietf60.ietf.org [130.129.132.28]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i73H584v008519; Wed, 4 Aug 2004 02:05:09 +0900 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0566AA@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0566AA@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Route Optimization by CR Date: Wed, 4 Aug 2004 02:08:04 +0900 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Content-Transfer-Encoding: 7bit Hello Pascal! Thanks for comments. On 2004/07/31, at 2:55, Pascal Thubert (pthubert) wrote: > Hi Ryuji: > > I liked your draft for a number of reasons; mostly because it reflects > an deep understanding of the problem statement for RO in the > infrastructure. I like the structure of the doc and the items that are > discussed and I think they are very relevant. > > I have more reserves with the solutions because: > > - Nested and infra ROs are merged in the doc but they should not since > they are different. Note that ORC in the infra is compatible with RRH > :) I agree with you. We were not sure whether we introduce the nested case in ORC draft. That is why we put the nested case in Appendix . Using RRH over ORC is interesting topic. > - the Nested RO part is not self sufficient since you need a MANET that > you do not described. I believe that the value of the draft is more in > the infra part. > OK. The important point of this ID is not around nested, but RO using CR. > - I do not believe in the assumption that there will be a CR for all > /64. Hence, we must find something else for CR discovery. Maybe some > service like DNS. Maybe some BGP extension. I hate snooping. Yes. CR discovery is one item we can not come up with a clear solution in this version of the draft. We understand that putting CR for all /64 is not so realistic. > - CR redistributes the NEMO routes it got from RO Bus into its IGP. As > a > result, the route exchange process MUST have the safety of routing > protocols in the Internet. There must be a trust chain that tells you > that this MR really owns that MNP and I believe that RR test is not > enough there. Maybe some route servers. In the current draft, we stay security as a operational decision. If CR is authorized by network administrator, the CR can redistribute NEMO routes. If not, IGP routers just ignore the redistributed routes from the CR. > Nemo allows to build a tunnel in a P2P fashion, and to exchange routes > over that tunnel. > I call that process route projection when I present it. Route > Projection > may become very important for the scalability of the Internet. I think the concept of route projection is similar to ORC. If MR supports functions of ORC router (say CR), we can provide certain level of router projection. > There are lower level details that I could discuss. Like adding text > for > topological correctness over the tunnels, things like that. Can you elaborate this. I don't get your point of the topological correctness issue. regards, ryuji From nemo-bounces@ietf.org Tue Aug 3 18:23:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17933 for ; Tue, 3 Aug 2004 18:22:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7b5-0001wY-J8; Tue, 03 Aug 2004 18:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7XA-0008UE-Hz for nemo@megatron.ietf.org; Tue, 03 Aug 2004 18:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17076 for ; Tue, 3 Aug 2004 18:13:22 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7aJ-0002Vr-7e for nemo@ietf.org; Tue, 03 Aug 2004 18:16:40 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id 7ACEA10C45C for ; Tue, 3 Aug 2004 18:12:45 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id 67B9633800F; Tue, 3 Aug 2004 18:12:45 -0400 (EDT) Received: from grc.nasa.gov (opene-130-129-129-160.ietf60.ietf.org [130.129.129.160]) by webmail.grc.nasa.gov (Postfix) with ESMTP id 2599B33800D for ; Tue, 3 Aug 2004 18:12:42 -0400 (EDT) Message-ID: <41100DCF.9020101@grc.nasa.gov> Date: Tue, 03 Aug 2004 18:12:31 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [nemo] Multihoming and Multiple Egress Interfaces X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit After reading the multihoming document (before the meeting!) and listening to the presentation yesterday, I find the multihoming docment informative, but it leaves me with a sense of incompleteness. Perhaps because I am looking for some recommendation for implementation when in fact none exists in this document. The issue I run into during deployements of mobile networks related to multihoming is "how to handle multiple egress interfaces (WANs)." I have used satellite, cellular and wifi simultaneously as egress interfaces. The multihoming document mentions this type of multihoming in the Apendix A and B and is basically a S/mP - (1,1,n). I believe S/mP - (1,n,n ) will be a very common configuration. Is there a need to standardize a mechanism for prioritizing these interfaces? The current implementation I use performs the priorities in the configuration. Second, It would be nice to have an illustration of the S/mP configuration - multiple egress links. The following site has some diagrams that are typical for the numerous egress WAN links that I have used. http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm ( Also not the use of IPv6 over IPv4 backbone) Will -- ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Lab 216-433-2620 http://roland.grc.nasa.gov/~ivancic From nemo-bounces@ietf.org Tue Aug 3 18:31:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18425 for ; Tue, 3 Aug 2004 18:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7j3-0003Wm-8g; Tue, 03 Aug 2004 18:25:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7fq-00035l-Qj for nemo@megatron.ietf.org; Tue, 03 Aug 2004 18:22:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17899 for ; Tue, 3 Aug 2004 18:22:20 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7iz-0002en-OB for nemo@ietf.org; Tue, 03 Aug 2004 18:25:39 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id A4FEA10C45C for ; Tue, 3 Aug 2004 18:21:50 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id 924AC33800F; Tue, 3 Aug 2004 18:21:50 -0400 (EDT) Received: from grc.nasa.gov (opene-130-129-129-160.ietf60.ietf.org [130.129.129.160]) by webmail.grc.nasa.gov (Postfix) with ESMTP id ABCFD33800D for ; Tue, 3 Aug 2004 18:21:48 -0400 (EDT) Message-ID: <41100FF1.5080805@grc.nasa.gov> Date: Tue, 03 Aug 2004 18:21:37 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-104.9 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [nemo] NAT/PAT transfersal over IPv4 networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Thierry and/or TJ asked if there was additional work that NEMO should address prior to closing or rechartering. I strongly believe that the group should standardize on a NAT/PAT transversal over IPv4 backbones. This will greatly increase the ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the European Nations and just about any Industrial nations is trying to help kick-start IPv6 deployments. However, the ISP's and industry do not yet have a good business case. Making the transission easier will help ALL of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with the "Doors" protocol and demonstrated this to the CIO of the US DoD. The ability to run IPv6 over IPv4 and mix networks was very very important. See: http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm Note, the "off-site demonstrations in Washington D.C. area" was for the Office of Secretary of Defense in order to show a migration path from IPv4 to IPv6. Will -- ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nas.gov/~ivancic From nemo-bounces@ietf.org Tue Aug 3 19:53:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23108 for ; Tue, 3 Aug 2004 19:53:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs94T-0004QI-Km; Tue, 03 Aug 2004 19:51:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8uI-0002Qf-3a for nemo@megatron.ietf.org; Tue, 03 Aug 2004 19:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22231 for ; Tue, 3 Aug 2004 19:41:21 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs8xQ-0003py-MW for nemo@ietf.org; Tue, 03 Aug 2004 19:44:39 -0400 Received: from opene-130-129-132-190.ietf60.ietf.org (opene-130-129-135-184.ietf60.ietf.org [130.129.135.184]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A84535D0F0 for ; Wed, 4 Aug 2004 08:40:35 +0900 (JST) Date: Wed, 4 Aug 2004 08:40:49 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks Message-Id: <20040804084049.3ca140ce.ernst@sfc.wide.ad.jp> In-Reply-To: <41100FF1.5080805@grc.nasa.gov> References: <41100FF1.5080805@grc.nasa.gov> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Will, Actually, the draft-iett-nemo-requirements mention NAT traversal and IPv4-IPv6 transitin, so that is something we do care about. This said, we concluded last year that there wasn't NEMO-specific issues. If there is one, I think the WG should defintely address it. If these are issues not specific to NEMO, we need to make sure these issues are addressed by the relefvant WG. In any case, I agree with your statement. Thierry. On Tue, 03 Aug 2004 18:21:37 -0400 ivancic wrote: > Thierry and/or TJ asked if there was additional work that NEMO should > address prior to closing or rechartering. > > I strongly believe that the group should standardize on a NAT/PAT > transversal over IPv4 backbones. This will greatly increase the > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the > European Nations and just about any Industrial nations is trying to help > kick-start IPv6 deployments. However, the ISP's and industry do not yet > have a good business case. Making the transission easier will help ALL > of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with the > "Doors" protocol and demonstrated this to the CIO of the US DoD. The > ability to run IPv6 over IPv4 and mix networks was very very important. > > See: > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > Note, the "off-site demonstrations in Washington D.C. area" was for the > Office of Secretary of Defense in order to show a migration path from > IPv4 to IPv6. > > > Will > > -- > ****************************** > William D. Ivancic > Phone 216-433-3494 > Fax 216-433-8705 > Lab 216-433-2620 > Mobile 440-503-4892 > http://roland.grc.nas.gov/~ivancic > > > From nemo-bounces@ietf.org Wed Aug 4 01:30:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12555 for ; Wed, 4 Aug 2004 01:30:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsEJO-0008Us-Un; Wed, 04 Aug 2004 01:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsEFo-00089O-HE for nemo@megatron.ietf.org; Wed, 04 Aug 2004 01:23:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12389 for ; Wed, 4 Aug 2004 01:23:55 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsEJ1-0001BH-6e for nemo@ietf.org; Wed, 04 Aug 2004 01:27:16 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2004 07:28:23 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i745NJuG016772; Wed, 4 Aug 2004 07:23:20 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Aug 2004 07:18:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] NAT/PAT transfersal over IPv4 networks Date: Wed, 4 Aug 2004 07:23:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NAT/PAT transfersal over IPv4 networks Thread-Index: AcR5tZZJsOos+FMiS/SrN8SL3fvB7wADyUQg From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 04 Aug 2004 05:18:10.0718 (UTC) FILETIME=[6F2063E0:01C479E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Content-Transfer-Encoding: quoted-printable Well, as I understand the work being done at the MIP6 or v6Ops, Doors is = not considered because of IPR. On the other hand, since the IPR = encumbering is the basically same as that of nemo basic support, doors = should be acceptable within Nemo. So there IS something that is Nemo = specific after all. There was a discussion in Seoul about NAT traversal (I asked Hesham over = the mike) - correct me if I'm wrong - they are not covering NAT in the = current ipv4/IPv6 interoperability solutions. So we end up with in one = hand a non standard thing (doors) that has now been thoroughly tested = and goes though all sorts of NAT including reverse and symmetrical, or = in the other end the beginning of what may be a MIP remake of v6ops = transition story. Could we just standardize doors so we can deliver something efficient to = our customers? And then if alternates pop up, they'll have to prove they = are better in that space. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Thierry Ernst > Sent: mercredi 4 ao=FBt 2004 01:41 > To: nemo > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >=20 >=20 > Hi Will, >=20 > Actually, the draft-iett-nemo-requirements mention NAT traversal and > IPv4-IPv6 transitin, so that is something we do care about. This said, > we concluded last year that there wasn't NEMO-specific issues. If = there > is one, I think the WG should defintely address it. If these are = issues > not specific to NEMO, we need to make sure these issues are addressed = by > the relefvant WG. >=20 > In any case, I agree with your statement. >=20 > Thierry. >=20 >=20 >=20 >=20 > On Tue, 03 Aug 2004 18:21:37 -0400 > ivancic wrote: >=20 > > Thierry and/or TJ asked if there was additional work that NEMO = should > > address prior to closing or rechartering. > > > > I strongly believe that the group should standardize on a NAT/PAT > > transversal over IPv4 backbones. This will greatly increase the > > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the > > European Nations and just about any Industrial nations is trying to = help > > kick-start IPv6 deployments. However, the ISP's and industry do not = yet > > have a good business case. Making the transission easier will help = ALL > > of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with = the > > "Doors" protocol and demonstrated this to the CIO of the US DoD. = The > > ability to run IPv6 over IPv4 and mix networks was very very = important. > > > > See: > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > Note, the "off-site demonstrations in Washington D.C. area" was for = the > > Office of Secretary of Defense in order to show a migration path = from > > IPv4 to IPv6. > > > > > > Will > > > > -- > > ****************************** > > William D. Ivancic > > Phone 216-433-3494 > > Fax 216-433-8705 > > Lab 216-433-2620 > > Mobile 440-503-4892 > > http://roland.grc.nas.gov/~ivancic > > > > > > >=20 From nemo-bounces@ietf.org Wed Aug 4 02:40:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14079 for ; Wed, 4 Aug 2004 02:40:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsFQV-0001fE-9I; Wed, 04 Aug 2004 02:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsFIi-0000dB-NP for nemo@megatron.ietf.org; Wed, 04 Aug 2004 02:31:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13379 for ; Wed, 4 Aug 2004 02:30:59 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsFLw-0002CO-Pk for nemo@ietf.org; Wed, 04 Aug 2004 02:34:21 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i746U7nE011306; Wed, 4 Aug 2004 07:30:08 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id HAA18639; Wed, 4 Aug 2004 07:30:04 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i746U3d02156; Wed, 4 Aug 2004 07:30:03 +0100 Date: Wed, 4 Aug 2004 07:30:03 +0100 From: Tim Chown To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks Message-ID: <20040804063003.GA2030@login.ecs.soton.ac.uk> References: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC071C23@xmb-ams-337.emea.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by raven.ecs.soton.ac.uk id i746U7nE011306 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: nemo , Pekka Savola , 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 Content-Transfer-Encoding: quoted-printable I think NAT is a consideration for the assisted tunneling requirements analysis that is happening in v6ops. Have you read that? http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-r= equirements-00.txt It is NAT-PT that is pushed to the "last resort" status in v6ops (there i= s a new push to write up why in an applicability statement, agreed this wee= k). I can't find any active reference to "doors" - could you provide a point= er? Looks like nemo should be talking to v6ops here :)=20 thanks, tim On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) wrote= : > Well, as I understand the work being done at the MIP6 or v6Ops, Doors i= s not considered because of IPR. On the other hand, since the IPR encumbe= ring is the basically same as that of nemo basic support, doors should be= acceptable within Nemo. So there IS something that is Nemo specific afte= r all. >=20 > There was a discussion in Seoul about NAT traversal (I asked Hesham ove= r the mike) - correct me if I'm wrong - they are not covering NAT in the = current ipv4/IPv6 interoperability solutions. So we end up with in one ha= nd a non standard thing (doors) that has now been thoroughly tested and g= oes though all sorts of NAT including reverse and symmetrical, or in the = other end the beginning of what may be a MIP remake of v6ops transition s= tory. >=20 > Could we just standardize doors so we can deliver something efficient t= o our customers? And then if alternates pop up, they'll have to prove the= y are better in that space. >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Thierry Ernst > > Sent: mercredi 4 ao=FBt 2004 01:41 > > To: nemo > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > >=20 > >=20 > > Hi Will, > >=20 > > Actually, the draft-iett-nemo-requirements mention NAT traversal and > > IPv4-IPv6 transitin, so that is something we do care about. This said= , > > we concluded last year that there wasn't NEMO-specific issues. If the= re > > is one, I think the WG should defintely address it. If these are issu= es > > not specific to NEMO, we need to make sure these issues are addressed= by > > the relefvant WG. > >=20 > > In any case, I agree with your statement. > >=20 > > Thierry. > >=20 > >=20 > >=20 > >=20 > > On Tue, 03 Aug 2004 18:21:37 -0400 > > ivancic wrote: > >=20 > > > Thierry and/or TJ asked if there was additional work that NEMO shou= ld > > > address prior to closing or rechartering. > > > > > > I strongly believe that the group should standardize on a NAT/PAT > > > transversal over IPv4 backbones. This will greatly increase the > > > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, th= e > > > European Nations and just about any Industrial nations is trying to= help > > > kick-start IPv6 deployments. However, the ISP's and industry do no= t yet > > > have a good business case. Making the transission easier will help= ALL > > > of IPv6 deployments. I used some of Pascal's IPv6 NEMO code with= the > > > "Doors" protocol and demonstrated this to the CIO of the US DoD. T= he > > > ability to run IPv6 over IPv4 and mix networks was very very import= ant. > > > > > > See: > > > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > Note, the "off-site demonstrations in Washington D.C. area" was for= the > > > Office of Secretary of Defense in order to show a migration path fr= om > > > IPv4 to IPv6. > > > > > > > > > Will > > > > > > -- > > > ****************************** > > > William D. Ivancic > > > Phone 216-433-3494 > > > Fax 216-433-8705 > > > Lab 216-433-2620 > > > Mobile 440-503-4892 > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > >=20 >=20 >=20 From nemo-bounces@ietf.org Wed Aug 4 14:59:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28860 for ; Wed, 4 Aug 2004 14:59:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQl5-0001b1-SS; Wed, 04 Aug 2004 14:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQV2-0006JS-MW for nemo@megatron.ietf.org; Wed, 04 Aug 2004 14:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26347 for ; Wed, 4 Aug 2004 14:28:27 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQYM-0005V1-9H for nemo@ietf.org; Wed, 04 Aug 2004 14:31:55 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id 1036410C45F; Wed, 4 Aug 2004 14:27:56 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id 040E733800F; Wed, 4 Aug 2004 14:27:55 -0400 (EDT) Received: from grc.nasa.gov (opene-130-129-129-160.ietf60.ietf.org [130.129.129.160]) by webmail.grc.nasa.gov (Postfix) with ESMTP id D9B7833800D; Wed, 4 Aug 2004 14:27:53 -0400 (EDT) Message-ID: <41112A9B.2000902@grc.nasa.gov> Date: Wed, 04 Aug 2004 14:27:39 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks References: <41100FF1.5080805@grc.nasa.gov> <20040804084049.3ca140ce.ernst@sfc.wide.ad.jp> In-Reply-To: <20040804084049.3ca140ce.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-104.9 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >Actually, the draft-iett-nemo-requirements mention NAT traversal and >IPv4-IPv6 transitin, so that is something we do care about. This said, >we concluded last year that there wasn't NEMO-specific issues. > Thierry, I agree that NAT traversal and IPv4-IPv6 transition are not NEMO specific. Many protocols will have this problem. However, to "seamlessly" utilize a NEMO, the problem probably has to be solved in the mobile router. For example, in MIP4, they developed a NAT transversal specification basically saying use a IP-in-UDP tunnel rather than an IP-in-IP tunnel because you need a port number for the NAT to understand the translation. This is performed in the mobile host or mobile router for Collocated Care of Address. Note, I used the "Doors" implementation, but would expect that other methods may work just as well and get around the IPR problem. I really beleive this should be solved here and may be applicable to MIP6 also. Until IPv6 is supported by the ISPs, we will need to do the 6-to-4 tunneling and until NATs misterioulsy disappear we will need to do NAT transversal. (Actually, when we used T-Mobile's links, we originally had a non-NATted pubilic address. However, they administratively filtered to stop Internet Worms. Thus, only traffic originating from T-Mobile could return (basically acting like a NAT). Thus, the NAT solution worked as you needed a port number on the tunnel for the ISP to map bidirectional transferes. Otherwise, the ipv4 NEMO would register using UDP port 434, but the tunneled data would not pass!) I reviewed the draft www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt as suggested by Tim Chown (thanks for the reference). This may (???) work. However there are some assumptions and issues. 1) Code must be deployed in a NEMO to utilize the assisted-tunneling. This code is potentailly more complex than developing our own Tunneling/NAT Transversal implementation. 2) Assisted-Tunnelling must be deployed by all ISP's one wishes to use. (Personal experinece has shown that one will wish to use any ISP they can get.) 3) The assisted-tunnelling draft is just that, a draft. When and if it will get deployed are unknows. Will From nemo-bounces@ietf.org Wed Aug 4 19:14:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18222 for ; Wed, 4 Aug 2004 19:14:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUu3-0006OG-TD; Wed, 04 Aug 2004 19:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUqp-0005cI-HW for nemo@megatron.ietf.org; Wed, 04 Aug 2004 19:07:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17874 for ; Wed, 4 Aug 2004 19:07:11 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsUuB-0002EE-5l for nemo@ietf.org; Wed, 04 Aug 2004 19:10:44 -0400 Received: from iseran.local (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A1B2E5D289 for ; Thu, 5 Aug 2004 08:05:55 +0900 (JST) Date: Thu, 5 Aug 2004 08:07:13 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks Message-Id: <20040805080713.5ddd62d5.ernst@sfc.wide.ad.jp> In-Reply-To: <41112A9B.2000902@grc.nasa.gov> References: <41100FF1.5080805@grc.nasa.gov> <20040804084049.3ca140ce.ernst@sfc.wide.ad.jp> <41112A9B.2000902@grc.nasa.gov> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Content-Transfer-Encoding: 7bit Hi, Basically, I do not oppose that this be done in the NEMO WG if this is what the WG wants to do. A first step would be to have someone writing a draft, and then we could possibly include a new WG item. My own view, Thierry, On Wed, 04 Aug 2004 14:27:39 -0400 ivancic wrote: > > Thierry Ernst wrote: > > >Actually, the draft-iett-nemo-requirements mention NAT traversal and > >IPv4-IPv6 transitin, so that is something we do care about. This said, > >we concluded last year that there wasn't NEMO-specific issues. > > > > Thierry, > > I agree that NAT traversal and IPv4-IPv6 transition are not NEMO > specific. Many protocols will have this problem. However, to > "seamlessly" utilize a NEMO, the problem probably has to be solved in > the mobile router. For example, in MIP4, they developed a NAT > transversal specification basically saying use a IP-in-UDP tunnel > rather than an IP-in-IP tunnel because you need a port number for the > NAT to understand the translation. This is performed in the mobile host > or mobile router for Collocated Care of Address. > > Note, I used the "Doors" implementation, but would expect that other > methods may work just as well and get around the IPR problem. I really > beleive this should be solved here and may be applicable to MIP6 also. > Until IPv6 is supported by the ISPs, we will need to do the 6-to-4 > tunneling and until NATs misterioulsy disappear we will need to do NAT > transversal. > > > (Actually, when we used T-Mobile's links, we originally had a non-NATted > pubilic address. However, they administratively filtered to stop > Internet Worms. Thus, only traffic originating from T-Mobile could > return (basically acting like a NAT). Thus, the NAT solution worked as > you needed a port number on the tunnel for the ISP to map bidirectional > transferes. Otherwise, the ipv4 NEMO would register using UDP port 434, > but the tunneled data would not pass!) > > > I reviewed the draft > www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt > as suggested by Tim Chown (thanks for the reference). This may (???) > work. However there are some assumptions and issues. > > 1) Code must be deployed in a NEMO to utilize the assisted-tunneling. > This code is potentailly more complex than developing our own > Tunneling/NAT Transversal implementation. > > 2) Assisted-Tunnelling must be deployed by all ISP's one wishes to use. > (Personal experinece has shown that one will wish to use any ISP they > can get.) > > 3) The assisted-tunnelling draft is just that, a draft. When and if it > will get deployed are unknows. > > > Will > > From nemo-bounces@ietf.org Wed Aug 4 19:42:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20523 for ; Wed, 4 Aug 2004 19:42:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVGh-0002R9-F1; Wed, 04 Aug 2004 19:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVBv-00015W-KE for nemo@megatron.ietf.org; Wed, 04 Aug 2004 19:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19208 for ; Wed, 4 Aug 2004 19:29:00 -0400 (EDT) Received: from opene-130-129-135-34.ietf60.ietf.org ([130.129.135.34] helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsVFH-0002aB-RT for nemo@ietf.org; Wed, 04 Aug 2004 19:32:33 -0400 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 6DD509A8CD; Thu, 5 Aug 2004 07:31:06 +0800 (SGT) Subject: Re: [nemo] Multihoming and Multiple Egress Interfaces From: Chan-Wah NG To: ivancic In-Reply-To: <41100DCF.9020101@grc.nasa.gov> References: <41100DCF.9020101@grc.nasa.gov> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1091662250.9448.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 05 Aug 2004 07:30:51 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Content-Transfer-Encoding: 7bit Hello Will, Thank you for your comments. See response in line. /rgds /cwng On Wed, 2004-08-04 at 06:12, ivancic wrote: > After reading the multihoming document (before the meeting!) and > listening to the presentation yesterday, I find the multihoming docment > informative, but it leaves me with a sense of incompleteness. Perhaps > because I am looking for some recommendation for implementation when in > fact none exists in this document. > We hope to achieve that, but would appreciate folks on the ML to contribute recommendations to known implementations for such issues. Also, note that some issues does not currently have known (at least unknwon to me) solutions. > The issue I run into during deployements of mobile networks related to > multihoming is "how to handle multiple egress interfaces (WANs)." I > have used satellite, cellular and wifi simultaneously as egress > interfaces. The multihoming document mentions this type of > multihoming in the Apendix A and B and is basically a > S/mP - (1,1,n). I believe S/mP - (1,n,n ) will be a very common > configuration. > > Is there a need to standardize a mechanism for prioritizing these > interfaces? The current implementation I use performs the priorities in > the configuration. Depends. If to achieve such prioritization, no information exchange is required between the multihomed node and other nodes (eg HA, MR, AR), then it is a question of implementation. Nothing to standardize here to ensure interoperability. (but of-course, as informational document, we could recommend a solution). On the other hand, if such prioritization requires information exchange between two nodes, then IMHO, most likely it would require standardization. > > Second, It would be nice to have an illustration of the S/mP > configuration - multiple egress links. > > The following site has some diagrams that are typical for the numerous > egress WAN links that I have used. > http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > ( Also not the use of IPv6 over IPv4 backbone) > Thank you for the links. The authors will consider if it is helpful to include them. /rgds /cwng From nemo-bounces@ietf.org Wed Aug 4 21:52:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28225 for ; Wed, 4 Aug 2004 21:52:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsXOt-00044j-He; Wed, 04 Aug 2004 21:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsXOe-0003vm-Hk for nemo@megatron.ietf.org; Wed, 04 Aug 2004 21:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28079 for ; Wed, 4 Aug 2004 21:50:18 -0400 (EDT) Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsXS2-0004zC-Dr for nemo@ietf.org; Wed, 04 Aug 2004 21:53:51 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i751er4N030162 for ; Thu, 5 Aug 2004 10:40:53 +0900 Message-Id: <200408050140.i751er4N030162@popeye.snu.ac.kr> From: "Jongkeun Na" To: Date: Thu, 5 Aug 2004 10:50:05 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C47AD9.FA9B9A50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6joecBErLGr5NTdqibvwQLrzRHA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Subject: [nemo] Generic RO Tunnel (ROT) Model X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C47AD9.FA9B9A50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, Generic RO Tunnel (ROT) Model was introduced in http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt However, unfortunately I've not received any comments on this. So I re-state the purpose of this work and once again solicit your comments. Your feedback is very important because I want to confirm that this work is directed to its right way. The draft outlines generic RO model for NEMO extended support. I think that it can provide a useful framework in that defining RO problem spaces, evaluating the existing RO solutions and discussing a bunch of related RO issues. As you know, RO problem & solution is some complex so I think we need a well defined RO model to enable us to find optimal RO solution. Also, Section 4 in the draft is mentioning on the need of a unified RO solution. I guess that this point is important in up-coming discussion of WG about RO. please don't hesitate in expressing your thought. Any feedback is welcome. Regards, Jongkeun ------=_NextPart_000_0127_01C47AD9.FA9B9A50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

Generic RO Tunnel (ROT) Model was introduced in http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.t= xt

However, unfortunately I’ve not received any comments on this. So I = re-state the purpose of this work and once again solicit your comments. Your feedback = is very important because I want to confirm that this work is directed to = its right way.

The draft outlines generic RO model for NEMO extended support. I think that = it can provide a useful framework in that defining RO problem spaces, = evaluating the existing RO solutions and discussing a bunch of related RO issues. As = you know, RO problem & solution is some complex so I think we need a well = defined RO model to enable us to find optimal RO = solution.

Also, Section 4 in the draft is mentioning on the need of a unified RO = solution. I guess that this point is important in up-coming discussion of WG about = RO. please don’t hesitate in expressing your thought. Any feedback is = welcome.

 

Regards,

Jongkeun

 

------=_NextPart_000_0127_01C47AD9.FA9B9A50-- From nemo-bounces@ietf.org Thu Aug 5 00:56:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07980 for ; Thu, 5 Aug 2004 00:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsaFM-0002NE-Qr; Thu, 05 Aug 2004 00:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsa4P-0000MT-3E for nemo@megatron.ietf.org; Thu, 05 Aug 2004 00:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07285 for ; Thu, 5 Aug 2004 00:41:34 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsa7p-0007Y3-78 for nemo@ietf.org; Thu, 05 Aug 2004 00:45:09 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2004 06:46:23 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i754f13p005673; Thu, 5 Aug 2004 06:41:02 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Aug 2004 06:41:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] NAT/PAT transfersal over IPv4 networks Date: Thu, 5 Aug 2004 06:41:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC071E0F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NAT/PAT transfersal over IPv4 networks Thread-Index: AcR57J+SmoD5IKLpSQenxVylBO7cGgAQNYsg From: "Pascal Thubert \(pthubert\)" To: "Tim Chown" X-OriginalArrivalTime: 05 Aug 2004 04:41:01.0370 (UTC) FILETIME=[68BEA1A0:01C47AA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: nemo , Pekka Savola , 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 Content-Transfer-Encoding: quoted-printable Hi Tim: The IETF effort for doors stopped at v01 and is available at: = http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-travers= al-01.txt I guess the next round would have been around compressing the IPv6 = tunnel header to save bandwidth, which is doable using well known = techniques. Pascal > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: mercredi 4 ao=FBt 2004 08:30 > To: Pascal Thubert (pthubert) > Cc: Thierry Ernst; nemo; Pekka Savola > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks >=20 > I think NAT is a consideration for the assisted tunneling requirements > analysis that is happening in v6ops. Have you read that? > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-r= equirements-00.txt >=20 > It is NAT-PT that is pushed to the "last resort" status in v6ops = (there is > a new push to write up why in an applicability statement, agreed this = week). >=20 > I can't find any active reference to "doors" - could you provide a = pointer? > Looks like nemo should be talking to v6ops here :) >=20 > thanks, > tim >=20 > On Wed, Aug 04, 2004 at 07:23:19AM +0200, Pascal Thubert (pthubert) = wrote: > > Well, as I understand the work being done at the MIP6 or v6Ops, = Doors is not considered > because of IPR. On the other hand, since the IPR encumbering is the = basically same as that of > nemo basic support, doors should be acceptable within Nemo. So there = IS something that is > Nemo specific after all. > > > > There was a discussion in Seoul about NAT traversal (I asked Hesham = over the mike) - > correct me if I'm wrong - they are not covering NAT in the current = ipv4/IPv6 interoperability > solutions. So we end up with in one hand a non standard thing (doors) = that has now been > thoroughly tested and goes though all sorts of NAT including reverse = and symmetrical, or in > the other end the beginning of what may be a MIP remake of v6ops = transition story. > > > > Could we just standardize doors so we can deliver something = efficient to our customers? And > then if alternates pop up, they'll have to prove they are better in = that space. > > > > Pascal > > > > > > > -----Original Message----- > > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On = Behalf Of Thierry Ernst > > > Sent: mercredi 4 ao=FBt 2004 01:41 > > > To: nemo > > > Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks > > > > > > > > > Hi Will, > > > > > > Actually, the draft-iett-nemo-requirements mention NAT traversal = and > > > IPv4-IPv6 transitin, so that is something we do care about. This = said, > > > we concluded last year that there wasn't NEMO-specific issues. If = there > > > is one, I think the WG should defintely address it. If these are = issues > > > not specific to NEMO, we need to make sure these issues are = addressed by > > > the relefvant WG. > > > > > > In any case, I agree with your statement. > > > > > > Thierry. > > > > > > > > > > > > > > > On Tue, 03 Aug 2004 18:21:37 -0400 > > > ivancic wrote: > > > > > > > Thierry and/or TJ asked if there was additional work that NEMO = should > > > > address prior to closing or rechartering. > > > > > > > > I strongly believe that the group should standardize on a = NAT/PAT > > > > transversal over IPv4 backbones. This will greatly increase = the > > > > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, = the > > > > European Nations and just about any Industrial nations is trying = to help > > > > kick-start IPv6 deployments. However, the ISP's and industry do = not yet > > > > have a good business case. Making the transission easier will = help ALL > > > > of IPv6 deployments. I used some of Pascal's IPv6 NEMO code = with the > > > > "Doors" protocol and demonstrated this to the CIO of the US DoD. = The > > > > ability to run IPv6 over IPv4 and mix networks was very very = important. > > > > > > > > See: > > > > = http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm > > > > Note, the "off-site demonstrations in Washington D.C. area" was = for the > > > > Office of Secretary of Defense in order to show a migration path = from > > > > IPv4 to IPv6. > > > > > > > > > > > > Will > > > > > > > > -- > > > > ****************************** > > > > William D. Ivancic > > > > Phone 216-433-3494 > > > > Fax 216-433-8705 > > > > Lab 216-433-2620 > > > > Mobile 440-503-4892 > > > > http://roland.grc.nas.gov/~ivancic > > > > > > > > > > > > > > > > > > > From nemo-bounces@ietf.org Thu Aug 5 09:11:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16057 for ; Thu, 5 Aug 2004 09:11:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BshzH-0005kb-OF; Thu, 05 Aug 2004 09:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BshxY-0005S4-7i for nemo@megatron.ietf.org; Thu, 05 Aug 2004 09:07:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15780 for ; Thu, 5 Aug 2004 09:07:01 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsi11-00063c-V2 for nemo@ietf.org; Thu, 05 Aug 2004 09:10:40 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i75D68c9027134; Thu, 5 Aug 2004 06:06:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i75D4K1q021185; Thu, 5 Aug 2004 08:04:20 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6C70A8859AE; Thu, 5 Aug 2004 15:06:04 +0200 (CEST) Message-ID: <411230B5.3080103@motorola.com> Date: Thu, 05 Aug 2004 15:05:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stuart W. Card" Subject: Re: [nemo] can't make San Diego but here's some food for thought References: <6.1.1.1.0.20040729000818.0240eec0@mail.borg.com> <0A4934ED-E26A-11D8-B489-000A95DA08F2@kniveton.com> <6.1.1.1.0.20040802105613.0242a2d8@mail.borg.com> In-Reply-To: <6.1.1.1.0.20040802105613.0242a2d8@mail.borg.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090207000800010702000006" X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: IETF NEMO WG , "T.J.Kniveton" , zabele@alphatech.com, patricia.baskinger@northropgrumman.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 This is a cryptographically signed message in MIME format. --------------ms090207000800010702000006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stuart W. Card wrote: > (1) We have a very NEMO-like solution for IPv4 under Linux. It has > been extensively tested, both in the lab and in the field (multiple > LANs aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM > radios to reach base stations). "Multiple LAN's aboard aircraft", was it like "nesting" moving networks each with its MR? Or was it like several combined subnets with a unique MR at the top-level? > It uses MIPv4 extension type 42 to register prefixes and supports > multihoming via multiple simultaneous COAs. A-ha! So a new Registration Request message type number? This should be suggested to IETF and to IANA if interoperability is important. And then maybe 35 is sufficient, no need of 43 so high (34 Foreign-Home Authentication is the last allocated, no?). > (2) We have not yet migrated to IPv6 and NEMO, partly because the > lack of FAs in MIPv6 forces encapsulation over the links to the MRs. This sounds reasonable at the first read. You seem to assume keeping FA's on the ground and thus save bandwidth between it and onboard MR. However, when accepting a visiting moving network to board the flying equipment, one should place an onboard FA too, no? One can't have a grounded FA to deal with an onboard MR behind another onboard MR. > While this overhead is minor over wireline and many wireless media, > it is significant over our wireless WAN links (long latency, low data > rate, high error rate, due to being narrowband and traversing long > ranges often including geostationary satellites). We would like to > migrate to IPv6 and NEMO to be in step with the community. Are there > any ideas being considered that could obviate the requirement for > encapsulation over the links to the MRs, at least in some special > cases that might need additional support not required by the basic > support draft? Yes, ideas there are about eliminating the HA from the LFN-CN communication path and without encapsulation. In the specific scenario that you describe, a simpler Mobile IP architecture could be engineered that eliminates that encapsulation, and doesn't employ Route Optimization techniques (which does not exist in MIP4 btw). In order to do that one should have more information about the current architecture you're considering, because it seems to me it is very much different than the architectures we commonly consider with telecom networks, wireless access networks, etc. For example, when you say LOS, beyond LOS and SATCOM, where do those links point to? Is it like all the distinctive ground stations (corresponding to LOS, beyond LOS and SATCOM) are linked together by some earth-grounded-high-speed-fiber? Or is it that those ground stations are communicating via the Internet? If they're connected together by high-speed-something then it would make little sense to have both FA's and HA's, but would make better sense to only have one FHA callit, and then never encapsulate at all towards it. This is just a possibility about how it could be made to eliminate encapsulation over the wireless links, but depends on the architecture, please provide details about it. > (3) For the reasons cited in (2) above, we are concerned with the > multiple encapsulation that may occur with nested NEMO and/or RO. We > really don't care about RO in the wireline network, as our > bandwidths are so many orders of magnitude smaller, but we do need to > avoid any avoidable multiple trips or encapsulations over the > wireless links. We believe this concern will be shared by other > developers of wireless WANs, as bandwidth is inherently much more > precious in the wireless WAN than the wireless LAN, as the latter > spectrum can be extensively re-used in different cells, but the > former cannot. > > (4) Assume MN1 is served by MR1 and MN2 by MR2, and that the former > is the parent of the latter in a nested NEMO. If MR2 then achieves > another point of attachment to the fixed infrastructure, but also > retains its connectivity through MN1, MN2 is multi-homed, So MR2 has actually three interfaces, right? The third interface was kind of dangling before achieving another point of attachment. > but MN1 is not, per the the nomenclature and multihoming drafts. This > is because MNs are nominally precluded from offering transit. One should attach a certain interpretation to the statements about moving networks being precluded to offer transit. In nested NEMO moving networks, one network transits packets of the other ok. However, in OSPF networks there are "transit" and "stub" networks and in this sense a moving network is more like an OSPF stub network and precluded to be an OSPF transit network. > However, the access link between MR1 and the infrastructure may have > very different QoS attributes from that directly between MR2 and the > infrastructure: nodes in MN2 can choose their preference, but nodes > in MN1 cannot; in some scenarios, the restriction on transit through > MN2 will preclude some applications from running on nodes in MN1, > even though adequate capacity and QoS would be available to them, > were they only permitted to transit MN2. Setting QoS aside, MN1 and > MN2 may both offer bursty traffic, with peak demand from each > exceeding the capacity of its MR's direct link to the backbones, but > the peak aggregate demand not exceeding their aggregated capacity; > MN2 will be fine, but MN1 will suffer needless congestion induced > packet loss if it is not permitted to transit MN2. We realize that > transit should not be offered in general by MNs, for good and obvious > reasons, but believe cases of this sort should be supported. Keep > in mind that the only reason MN2 was allowed to transit MN1, and not > vice versa, was the temporal order in which registrations occurred: > MN2 first was attached to MN1 and then later directly to the > backbones; had MN2 initially been attached to a backbone, and MN1 > attached to MN2, the 'rules' as to who can transit whom would have > been reversed. Yes, this requirement looks to provide value and I think moving networks as they are now (NEMO basic support is exclusively IPv6, and non-interoperable v4 implementations exist) will not accomodate the above scenario. We have identified another mobility configuration that is not supported by NEMO Basic Support and is not multi-homing either (uses a mobile HA). Alex --------------ms090207000800010702000006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MDUxMzA1NTdaMCMGCSqGSIb3DQEJBDEWBBTK6awv2Gvd+CW+4bMIBtls1oIfITBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAlApdJTkJ6pjK2RKfHQ8m2pN45gA45XmkD2G+e FZTF6Rp2o7qkJnmVUYR5adzGMhYE6HQfSL8TE4TSjfR3V9sDXdyPtCnhNz6y1AGjGdGfM7Ae 4LMR92U9RQPzfqefXRj1TJZunIOJ9kMBKdZFtmnInGOt+OFF9BZFeZlliqtuAAAAAAAAAA== --------------ms090207000800010702000006-- From nemo-bounces@ietf.org Thu Aug 5 09:16:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16305 for ; Thu, 5 Aug 2004 09:16:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsi5C-0006iK-2b; Thu, 05 Aug 2004 09:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsi3S-0006RL-Ju for nemo@megatron.ietf.org; Thu, 05 Aug 2004 09:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16145 for ; Thu, 5 Aug 2004 09:13:08 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsi6w-00069h-JP for nemo@ietf.org; Thu, 05 Aug 2004 09:16:47 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i75DDC3a025163; Thu, 5 Aug 2004 06:13:13 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i75DCGRi001015; Thu, 5 Aug 2004 08:12:17 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2B19D8859AE; Thu, 5 Aug 2004 15:12:16 +0200 (CEST) Message-ID: <4112322A.8070303@motorola.com> Date: Thu, 05 Aug 2004 15:12:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] can't make San Diego but here's some food for thought References: <7892795E1A87F04CADFCCF41FADD00FC05685D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05685D@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000408030505060700000706" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: "Stuart W. Card" , IETF NEMO WG , "T.J.Kniveton" , zabele@alphatech.com, patricia.baskinger@northropgrumman.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 This is a cryptographically signed message in MIME format. --------------ms000408030505060700000706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > For the multiple encapsulation problem, there's been a number of > solution proposed to what we refer to as nested RO. In particular, > RRH as a 2 year history of discussion in the ML (current version is > 5); it has been implemented and tested. I'd be glad to discuss that > if you wish. > > What needs to be done next is a classical header compression that > includes both the IPv6 header and the routing header over the low > speed link, and I guess that's it. > > http://www1.ietf.org/mail-archive/web/nemo/current/msg01306.html Pascal, are you sure that RRH is well adapted to Stuart's scenario? Seems that that secnario uses Linux and I understand RRH is prototyped only under Cisco routers, right? Pascal, do you know what kind of network topology the Card/Zabele/DoD demo was using? Do you know whether all the ground stations are linked together with fast links or via ISP/Internet? I strongly doubt that any of the currently proposed RO schemes was done with the kind of architecture in mind that Card/Zabele is talking about. I mean there might be other simpler ways to get rid of the encapsulation overhead if we know the architecture; RRH is kind of like for very wide-area and numerous-hosts Internet architecture. Alex --------------ms000408030505060700000706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MDUxMzEyMTBaMCMGCSqGSIb3DQEJBDEWBBTExH7MCYw6T5a1QCkFKivroC+v8zBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBg1W/z9rOL2+AIl0XmsYSPy5PsQrprZYZqBPDp vs7obKkgWu+BlBH3HhMwHeMXfThlCFqeRwVxvecbwk0S8wdMTqv96FUkWbSFGV1pS0ybtoqM Bm8G7GQp318bQI8LvyDTY4NfXuXX+T/hm67RwYp16PYLIWdqJB5tzgnhZ0poTQAAAAAAAA== --------------ms000408030505060700000706-- From nemo-bounces@ietf.org Thu Aug 5 09:41:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17490 for ; Thu, 5 Aug 2004 09:41:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsiRJ-0001Jv-NS; Thu, 05 Aug 2004 09:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsiIn-0000AN-KL for nemo@megatron.ietf.org; Thu, 05 Aug 2004 09:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16930 for ; Thu, 5 Aug 2004 09:28:59 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsiMI-0006ND-PE for nemo@ietf.org; Thu, 05 Aug 2004 09:32:39 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i75DMtQR016816; Thu, 5 Aug 2004 06:22:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i75DSfda027254; Thu, 5 Aug 2004 08:28:41 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id EF5308859AE; Thu, 5 Aug 2004 15:28:54 +0200 (CEST) Message-ID: <41123610.7020301@motorola.com> Date: Thu, 05 Aug 2004 15:28:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Davis, Terry L" Subject: Re: [nemo] Mobile Network Conops References: <6E5042539D21AF4E9C457B4DDCC3D6E105CD3B3E@xch-nw-21.nw.nos.boeing.com> In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E105CD3B3E@xch-nw-21.nw.nos.boeing.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA838BB0B450898D11B4EAF13" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: IETF NEMO WG , "T.J.Kniveton" , 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA838BB0B450898D11B4EAF13 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Davis, Terry L wrote: > Sometime it helps if you have some rough CONOP requirements for the > problem you are discussing. Absolutely. > For the aircraft (or ship), I can give you a bit of future view of > what an aircraft CONOP requirements set "might" include. Very little > of this could be considered absolutely definite at this time but > they are topics of discussion. Terry, do these CONOP's relate somehow to the Card/Zabele/DoD demo mentioned previously on this list? They also talk aircraft and LOS. > Some (probably most) of this does not apply to the NEMO problem space > but it will give an idea of the challenges facing mobile networks > and I think it will give you an idea why I favor HA-HA work remaining > in NEMO. Yes, HAHA is intriguing. [CONOPS] Thanks for providing these requirements. I think there is a need for an additional CONOP that says that there are times when all wireless links of an airplane (except the ultra-urgent) should be turned off (not just lowered its QoS, but switched off), I think. > * The aircraft will typically have access to Internet connectivity > via three or more layer 2 communications. Typically these will > include: multiple satcom links, multiple wireless networks > (802.11a/b/g & 802.15/20(?)), hardwired terrestrial, or infared. > > * The aircraft will periodically be on the operator/owners networks, > the aircraft manufacturer's networks, multiple airline comm > providers (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair > stations, multiple regulatory control networks > (FAA/JAA/CAA/Eurocontrol), and multiple airports. It will likely be > normally on three or more of these simultaneously. Are all those networks connected together in a sort of mesh of high-speed links? Or is each one of them connecting to the Internet via its own ISP? Can the HAHA concept help with this sort of deployment mentioned above? How? Is there anything missing in HAHA that needs improvement? > > * The aircraft will have continuous access to NO single layer 2 > communication link. > > * The aircraft will be mixed v4 and v6 systems; some offboard > communication support for both will be required. V6 will likely not > predominate until aircraft manufactured dates past 2020. > > * The aircraft may require specific comm types be sent over the layer > 2 links in a very specific hierarchy to meet regulatory constraints. > > > > * The aircraft operator will require specific message prioritization > and queueing by "link cost", priority, and bandwidth. > > * Most link connectivity points will move in hundreds or thousands of > miles when they transfer between ground stations or airports. > > * Security will be different for all the networks the aircraft > connects to. > > * Link performance characteristics and latency will be different for > all links. > > * The solution must provide for ground based systems to connect to > the mobile platform regardless what network it is connected to or > where it is in the world. (DNS/DHCP/etc) Current aerospace > standards make this impossible; only the aircraft can currently > initiate communications. > > * Multiple DNS systems will be registered on the different links. In > some cases, due to the aerospace specs, link specific DNS services > will likely be required. > > * Security, QoS, and reachability states must be maintained across > link and ground station changes. > > * The aircraft will sometimes go for extended periods in hours with > no Internet connectivity. > > * The aircraft will encounter areas where it will FLAP routes by > crossing in and out satellite coverage fringe areas and during > terminal approach (circling) holding patterns. > > * The aircraft will have multiple types of onboard networks as well; > wired, wifi, infared, etc. > > * The aircraft may have multiple routers; each may be associated with > different links and onboard networks. > > * The aircraft will most likely only receive communication and > network major updates every 10 or 20 years. > > * There may be regulatory limitations on when and how configurations > and routing can be updated. This should be a bit re-formulated. "Routing" and "regulatory body" don't quite match. Alex --------------enigA838BB0B450898D11B4EAF13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBEjYWMmC0w56zj54RAtSzAKDTCNUWct6Pp7j+5iIWJNgyhjJtJQCfW7Lv OvB2DmRhvjejzSHzpU2gXXc= =v9Jr -----END PGP SIGNATURE----- --------------enigA838BB0B450898D11B4EAF13-- From nemo-bounces@ietf.org Thu Aug 5 09:43:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17652 for ; Thu, 5 Aug 2004 09:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsiRx-0001Uu-I9; Thu, 05 Aug 2004 09:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsiOB-0000tu-Ix for nemo@megatron.ietf.org; Thu, 05 Aug 2004 09:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17186 for ; Thu, 5 Aug 2004 09:34:33 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsiRf-0006Sz-Nh for nemo@ietf.org; Thu, 05 Aug 2004 09:38:13 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i75DYVYI025385; Thu, 5 Aug 2004 06:34:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i75DQpUe010611; Thu, 5 Aug 2004 08:26:52 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id BB5F08859AE; Thu, 5 Aug 2004 15:34:28 +0200 (CEST) Message-ID: <4112375E.8000108@motorola.com> Date: Thu, 05 Aug 2004 15:34:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ivancic Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks References: <41100FF1.5080805@grc.nasa.gov> In-Reply-To: <41100FF1.5080805@grc.nasa.gov> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090306060301040904020004" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms090306060301040904020004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ivancic wrote: > I strongly believe that the group should standardize on a NAT/PAT > transversal over IPv4 backbones. This will greatly increase the > ability to deploy NEMO IPv6 networks. The US DoD, Japan, Korea, the > European Nations and just about any Industrial nations is trying to > help kick-start IPv6 deployments. However, the ISP's and industry do > not yet have a good business case. Making the transission easier > will help ALL of IPv6 deployments. Yes I agree with this. As you say, in addition to Doors which is not standardized, we also have a different method IPv6-in-UDPv4 that was prototyped and demonstrated and not standardized. > I used some of Pascal's IPv6 NEMO code with the "Doors" protocol and > demonstrated this to the CIO of the US DoD. Sidenote on this DoD demo. Will, does this demo relate anyhow to the Card/Zabele/DoD Linux demo and to the Connexion by Boeing CONOPS mentioned previously on this list? Alex --------------ms090306060301040904020004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MDUxMzM0MjJaMCMGCSqGSIb3DQEJBDEWBBTZPqZwgojjN+KnJv8bn5rHDnmrEzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYACDbXuOcoL7vCjiBfPXg3lCOKdpBLB8z8JCVei pVr1+T3lKyEzbZSpeHtoNgG8lt18M5XQKZBOHR15GmMKr6aqs+ux8+o+X37i+fqaxs0pc9o7 KLrnGKxDnDU2surhG9daatL9inmGMB4l77cm5j5jTFNra9s4JoOt6TJfnvZjGAAAAAAAAA== --------------ms090306060301040904020004-- From nemo-bounces@ietf.org Thu Aug 5 09:59:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18417 for ; Thu, 5 Aug 2004 09:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsiht-0004JT-Em; Thu, 05 Aug 2004 09:54:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsifu-0003ev-3J for nemo@megatron.ietf.org; Thu, 05 Aug 2004 09:52:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18101 for ; Thu, 5 Aug 2004 09:52:52 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsijO-0006i6-2f for nemo@ietf.org; Thu, 05 Aug 2004 09:56:31 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i75Dqnc9016679; Thu, 5 Aug 2004 06:52:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i75DqlUI024328; Thu, 5 Aug 2004 08:52:48 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6F4388859AE; Thu, 5 Aug 2004 15:52:47 +0200 (CEST) Message-ID: <41123BA4.7070700@motorola.com> Date: Thu, 05 Aug 2004 15:52:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Re: Comments on ORC draft-wakikawa-nemo-orc-00.txt References: <410E41D6.5000100@motorola.com> <81E3718F-E56B-11D8-A5FE-000D936735C4@sfc.wide.ad.jp> In-Reply-To: <81E3718F-E56B-11D8-A5FE-000D936735C4@sfc.wide.ad.jp> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF89B9B4FC3A96558B9D9E6E2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF NEMO WG , Masafumi Watari X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF89B9B4FC3A96558B9D9E6E2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >>> Mobile router can forward any packets meant for the managed prefixes >>> to the correspondent router. >> >> "forward" ok yes, but maybe stress with "directly, instead of forwarding >> to its HA"; and stress that MR actually encapsulates, not quite simple >> forwarding. > > I am not sure I get your point here, but MR basically encapsulates > packets to HA all the time. > Only the difference is the destination of outer IP packet (either HA or > CR). Ok. It is not very important. (using the word "forward" leaves place to misinterpretaion when tunnelling). >> But the description gives no clue about what happens when MR and its HA >> are both in the CN-and-CR's domain. In this case, it may happen that >> the path MR-HA-CN is much shorter than MR-CR-CN. So it would be >> interesting to consider a sort of intelligence on MR about what to do >> with the discovered CR's address, maybe don't always use it. >> > Good point. However I think ORC already have two mechanisms for this. > > When MR operates CR discovery, it will know > whether CR is located in the same network of MR or HA. How? Also by assuming always 64-bit prefix length? >> It is commonly acknowledged that DHAAD is not hyper secure in the MIP6 >> world, and since CR Discovery is similar to MIP6 one immediately thinks >> about the more risks CRD involves, so how do you secure it? > > True. Anycast address can not be used with IPsec. Maybe msec has something to help mip6 to help orc here? Alex --------------enigF89B9B4FC3A96558B9D9E6E2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBEjuvMmC0w56zj54RAkI+AJ9Ck3xXs/cEA/8e/hSNS9KN01eCLQCgrbYn 8kgtWrDO9yttxMPIvTnkFwE= =aVOU -----END PGP SIGNATURE----- --------------enigF89B9B4FC3A96558B9D9E6E2-- From nemo-bounces@ietf.org Thu Aug 5 10:59:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22658 for ; Thu, 5 Aug 2004 10:59:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsjfh-0007oU-F2; Thu, 05 Aug 2004 10:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsjcl-0004lt-9K for nemo@megatron.ietf.org; Thu, 05 Aug 2004 10:53:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22350 for ; Thu, 5 Aug 2004 10:53:40 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsjgG-0007UL-0F for nemo@ietf.org; Thu, 05 Aug 2004 10:57:21 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i75ErecJ024470; Thu, 5 Aug 2004 07:53:40 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i75Epn1q020847; Thu, 5 Aug 2004 09:51:50 -0500 Message-ID: <411249E6.4070309@motorola.com> Date: Thu, 05 Aug 2004 16:53:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jongkeun Na Subject: Re: [nemo] Generic RO Tunnel (ROT) Model References: <200408050140.i751er4N030162@popeye.snu.ac.kr> In-Reply-To: <200408050140.i751er4N030162@popeye.snu.ac.kr> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E2AAAEF82923A275FAF0890" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E2AAAEF82923A275FAF0890 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jongkeun Na wrote: > Generic RO Tunnel (ROT) Model was introduced in > _http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt_ > > > However, unfortunately I’ve not received any comments on this. So I > re-state the purpose of this work and once again solicit your > comments. Your feedback is very important because I want to confirm > that this work is directed to its right way. Hello Jongkeun, Thanks to you and co-authors (Seongho Cho, Chongkwon Kim, Changhoi Koo) for providing this generic RO model. I've just read through it. The draft assumes that RO can only be achieved by using tunnels of some sort. It proposes a generic architecture (boxes, functions and tunnel types) of Tunnel Endpoints, Switchers and Relays. These - still generic - boxes can perform generic functions/attributes such as Initiator, Responder, Trigger Source, Discovery and, moreover, tunnels can be of several types: Simple, Switched and Relayed. It subsequently maps RRH, HMIPv6, VIP, PCH, ORC, ARO and other RO schemes on this conceptual architecture. So this may be a useful RO taxonomy. I do not understand why is it assumed (as ORC does) that after RO there will still be encapsulation. I thought one of the main goals of employing RO is to eliminate encapsulation altogether. I may be wrong. > [achieve] unified RO in NEMO I'd say "interoperable" RO for MR, instead of "unified". > spaces, evaluating the existing RO solutions and discussing a bunch > of related RO issues. As you know, RO problem & solution is some > complex so I think it would be useful to define the RO problem itself first, and what would an RO solution do. Even define what "route" is in this context, what an "optimal route" is, etc. For example: route: a sequence of IP hops between LFN and CN. optimal route: a route shorter than through-HA route. shortest route: the smallest number of IP hops. The optimal route is not necessarily the optimal route. RO problem: find an optimal route. RO solution for NEMO: a set of protocol message exchanges after which LFN and CN securely communicate at application level over optimal routes (no encapsulation and not through HA). Or something like that. > I think we need a well defined RO model to enable us to find optimal > RO solution. Yes. Alex --------------enig5E2AAAEF82923A275FAF0890 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBEknsMmC0w56zj54RAsK6AJ4zJprjCaAZSsdT1lRO+CPV55vnHQCdEgah EU5Zehe3gqy7FHQDsj0oa9Y= =O5yH -----END PGP SIGNATURE----- --------------enig5E2AAAEF82923A275FAF0890-- From nemo-bounces@ietf.org Thu Aug 5 11:32:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24445 for ; Thu, 5 Aug 2004 11:32:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsk8X-00013L-LH; Thu, 05 Aug 2004 11:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsk6i-0000ai-MU for nemo@megatron.ietf.org; Thu, 05 Aug 2004 11:24:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24049 for ; Thu, 5 Aug 2004 11:24:37 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BskAD-0007yu-Iv for nemo@ietf.org; Thu, 05 Aug 2004 11:28:19 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA29508; Thu, 5 Aug 2004 10:24:07 -0500 (CDT) Received: from XCH-NW-13P.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i75FO6c26248; Thu, 5 Aug 2004 10:24:06 -0500 (CDT) Received: from xch-nw-21.nw.nos.boeing.com ([192.48.4.95]) by XCH-NW-13P.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6899); Thu, 5 Aug 2004 08:24:05 -0700 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] Mobile Network Conops X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 5 Aug 2004 08:24:04 -0700 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E104DD7EF2@xch-nw-21.nw.nos.boeing.com> Thread-Topic: [nemo] Mobile Network Conops Thread-Index: AcR68E8IBIXiFe7xRvOAyESY5+GbkAADaVDg From: "Davis, Terry L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Aug 2004 15:24:05.0011 (UTC) FILETIME=[3E630630:01C47B00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J.Kniveton" , 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 Content-Transfer-Encoding: quoted-printable Alex -----Original Message----- From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 Sent: Thursday, August 05, 2004 6:29 AM To: Davis, Terry L Cc: T.J.Kniveton; Thierry Ernst; IETF NEMO WG Subject: Re: [nemo] Mobile Network Conops Davis, Terry L wrote: > Sometime it helps if you have some rough CONOP requirements for the > problem you are discussing. Absolutely. > For the aircraft (or ship), I can give you a bit of future view of > what an aircraft CONOP requirements set "might" include. Very little > of this could be considered absolutely definite at this time but > they are topics of discussion. Terry, do these CONOP's relate somehow to the Card/Zabele/DoD demo = mentioned previously on this list? They also talk aircraft and LOS. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D I missed the Card/Zabele/DoD demo list mail. Although they may be = similar, these are around discussions for commercial service. Network = Centric Operations certainly have=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 > Some (probably most) of this does not apply to the NEMO problem space = > but it will give an idea of the challenges facing mobile networks and=20 > I think it will give you an idea why I favor HA-HA work remaining in=20 > NEMO. Yes, HAHA is intriguing. [CONOPS] Thanks for providing these requirements. I think there is a need for an additional CONOP that says that there are = times when all wireless links of an airplane (except the ultra-urgent) = should be turned off (not just lowered its QoS, but switched off), I = think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Possibly for passengers, maybe for crew but some links will be up = whenever they are available. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > * The aircraft will typically have access to Internet connectivity=20 > via three or more layer 2 communications. Typically these will > include: multiple satcom links, multiple wireless networks=20 > (802.11a/b/g & 802.15/20(?)), hardwired terrestrial, or infared. >=20 > * The aircraft will periodically be on the operator/owners networks, > the aircraft manufacturer's networks, multiple airline comm providers = > (Arinc, Sita, Inmarsat, CBB, etc), maintenance repair stations,=20 > multiple regulatory control networks (FAA/JAA/CAA/Eurocontrol), and=20 > multiple airports. It will likely be normally on three or more of=20 > these simultaneously. Are all those networks connected together in a sort of mesh of = high-speed links? Or is each one of them connecting to the Internet via = its own ISP? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Some may be, some definitely will not be interconnected. I would = envision that all of the onboard networks would have the ability to = connect to multiple providers; some commercial, some aviation or air = traffic control specific. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Can the HAHA concept help with this sort of deployment mentioned above? How? Is there anything missing in HAHA that needs improvement? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We will probaly figure that out as we actually see initial versions run. = I do believe there is need for some informational RFC's to be developed = for mobile networks to cover what it takes to build a full mobile = network infrastructure; I tend to refer to it as "Internet docking" to = cover mobility, security, QoS, etc. =3D=3D=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 > * The aircraft will have continuous access to NO single layer 2=20 > communication link. >=20 > * The aircraft will be mixed v4 and v6 systems; some offboard=20 > communication support for both will be required. V6 will likely not =20 > predominate until aircraft manufactured dates past 2020. >=20 > * The aircraft may require specific comm types be sent over the layer > 2 links in a very specific hierarchy to meet regulatory constraints. >=20 >=20 >=20 > * The aircraft operator will require specific message prioritization > and queueing by "link cost", priority, and bandwidth. >=20 > * Most link connectivity points will move in hundreds or thousands of > miles when they transfer between ground stations or airports. >=20 > * Security will be different for all the networks the aircraft=20 > connects to. >=20 > * Link performance characteristics and latency will be different for > all links. >=20 > * The solution must provide for ground based systems to connect to=20 > the mobile platform regardless what network it is connected to or > where it is in the world. (DNS/DHCP/etc) Current aerospace=20 > standards make this impossible; only the aircraft can currently=20 > initiate communications. >=20 > * Multiple DNS systems will be registered on the different links. In > some cases, due to the aerospace specs, link specific DNS services > will likely be required. >=20 > * Security, QoS, and reachability states must be maintained across=20 > link and ground station changes. >=20 > * The aircraft will sometimes go for extended periods in hours with=20 > no Internet connectivity. >=20 > * The aircraft will encounter areas where it will FLAP routes by=20 > crossing in and out satellite coverage fringe areas and during > terminal approach (circling) holding patterns. >=20 > * The aircraft will have multiple types of onboard networks as well; > wired, wifi, infared, etc. >=20 > * The aircraft may have multiple routers; each may be associated with > different links and onboard networks. >=20 > * The aircraft will most likely only receive communication and=20 > network major updates every 10 or 20 years. >=20 > * There may be regulatory limitations on when and how configurations > and routing can be updated. This should be a bit re-formulated. "Routing" and "regulatory body" = don't quite match. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Unfortunately they do match since it is not clear what part of the = onboard configurations can be dynamically changed without = re-certification. Changing the aviation industry from being 429/629-bus = based with hard (permanent) configs is challenging. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Alex From nemo-bounces@ietf.org Thu Aug 5 14:31:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04986 for ; Thu, 5 Aug 2004 14:31:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsmuZ-00026C-Gf; Thu, 05 Aug 2004 14:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsmp1-00010b-UX for nemo@megatron.ietf.org; Thu, 05 Aug 2004 14:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04080 for ; Thu, 5 Aug 2004 14:18:33 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsmsY-0002FT-81 for nemo@ietf.org; Thu, 05 Aug 2004 14:22:15 -0400 Received: from iseran.local (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1482F5D11F for ; Fri, 6 Aug 2004 03:18:01 +0900 (JST) Date: Fri, 6 Aug 2004 03:19:29 +0900 From: Thierry Ernst To: nemo Message-Id: <20040806031929.47f927d4.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [nemo] IRTF slides X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, I made a short presentation about RO in mobile networks at the IRTF Routing Research Group. You can find slides at http://www.nautilus6.org/doc/tr-nemo-ro-20040804-IRTF-ErnstT.pdf This represents my own views. A conclusion of this presentation is that the IRTF WG would be willing to open itself to work on new models for RO in mobile networks if people are willing to. The IRTF is focusing on research issues whereas the IETF (i.e. NEMO WG in the case that concerns us) is focusing on engineering. Thierry. From nemo-bounces@ietf.org Thu Aug 5 19:41:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26766 for ; Thu, 5 Aug 2004 19:41:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsrnG-00083r-O0; Thu, 05 Aug 2004 19:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsrhG-0006qp-3U for nemo@megatron.ietf.org; Thu, 05 Aug 2004 19:30:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25936 for ; Thu, 5 Aug 2004 19:30:50 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsrkp-0007xe-4o for nemo@ietf.org; Thu, 05 Aug 2004 19:34:36 -0400 Received: from iseran.local (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E2D835D021 for ; Fri, 6 Aug 2004 08:30:18 +0900 (JST) Date: Fri, 6 Aug 2004 08:31:47 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Generic RO Tunnel (ROT) Model Message-Id: <20040806083147.05f0a0d0.ernst@sfc.wide.ad.jp> In-Reply-To: <411249E6.4070309@motorola.com> References: <200408050140.i751er4N030162@popeye.snu.ac.kr> <411249E6.4070309@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Content-Transfer-Encoding: quoted-printable Dear all, I personaly find the draft and the model interesting from an analytical point of view, but I'm not sure it would be a useful model for the analysis that we need to carry on in this WG. But let's see. Would you motivate the need for such an abstraction model in this WG ? How would you use it ? What are you plans in using this model ? Why do you compare VIP ? (if you want to compare host mobility support, there are tons if them, so why VIP and not other ? > > Generic RO Tunnel (ROT) Model was introduced in=20 > > _http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt_ > >=20 > >=20 > > However, unfortunately I=92ve not received any comments on this. So I=20 > > re-state the purpose of this work and once again solicit your=20 > > comments. Your feedback is very important because I want to confirm=20 > > that this work is directed to its right way. Defining a model is good idea and would help. However, I'm concerned that this model focuses too much on tunneling and on MIP6-based solutons.So, it might be generic for solutions that use tunneling, but not generic enough for solutions that don't rely on tunneling (RO between 2 VMNs in the same NEMO for instance). So, we miss the complete picture. =20 =20 > Hello Jongkeun, >=20 > Thanks to you and co-authors (Seongho Cho, Chongkwon Kim, Changhoi Koo) > for providing this generic RO model. I've just read through it. >=20 > The draft assumes that RO can only be achieved by using tunnels of some > sort. >=20 > It proposes a generic architecture (boxes, functions and tunnel types) > of Tunnel Endpoints, Switchers and Relays. These - still generic - > boxes can perform generic functions/attributes such as Initiator, > Responder, Trigger Source, Discovery and, moreover, tunnels can be of > several types: Simple, Switched and Relayed. >=20 > It subsequently maps RRH, HMIPv6, VIP, PCH, ORC, ARO and other RO > schemes on this conceptual architecture. So this may be a useful RO > taxonomy. >=20 > I do not understand why is it assumed (as ORC does) that after RO there > will still be encapsulation. I thought one of the main goals of > employing RO is to eliminate encapsulation altogether. I may be wrong. >=20 > > [achieve] unified RO in NEMO >=20 > I'd say "interoperable" RO for MR, instead of "unified". Well, unified would be a nice goal. But I doubt it could be achieved easily. In any case, we need to define the RO problem first. Where do we ne= ed RO ? > > spaces, evaluating the existing RO solutions and discussing a bunch=20 > > of related RO issues. As you know, RO problem & solution is some=20 > > complex so >=20 > I think it would be useful to define the RO problem itself first, and > what would an RO solution do. >=20 > Even define what "route" is in this context, what an "optimal route" is, > etc. >=20 > For example: >=20 > route: a sequence of IP hops between LFN and CN. >=20 > optimal route: a route shorter than through-HA route. >=20 > shortest route: the smallest number of IP hops. The optimal route is > not necessarily the optimal route. >=20 > RO problem: find an optimal route. >=20 > RO solution for NEMO: a set of protocol message exchanges after which > LFN and CN securely communicate at application level over optimal routes > (no encapsulation and not through HA). >=20 > Or something like that. I agree that would help to define the problem statement that we are still lacking in the NEMO WG. > > I think we need a well defined RO model to enable us to find optimal=20 > > RO solution. Agree. Before analyzing the solution space, we need to analyze the problem space. Where do we need RO ? Actualy, Watari provided good input in his presentation. Thierry. From nemo-bounces@ietf.org Thu Aug 5 20:06:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27931 for ; Thu, 5 Aug 2004 20:06:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BssB3-0003C7-VS; Thu, 05 Aug 2004 20:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bss9f-0002z8-Fe for nemo@megatron.ietf.org; Thu, 05 Aug 2004 20:00:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27648 for ; Thu, 5 Aug 2004 20:00:13 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BssDF-0000CR-HM for nemo@ietf.org; Thu, 05 Aug 2004 20:03:58 -0400 Received: from iseran.local (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E27EB5D098 for ; Fri, 6 Aug 2004 08:59:41 +0900 (JST) Date: Fri, 6 Aug 2004 09:01:10 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] can't make San Diego but here's some food for thought Message-Id: <20040806090110.54a22663.ernst@sfc.wide.ad.jp> In-Reply-To: <411230B5.3080103@motorola.com> References: <6.1.1.1.0.20040729000818.0240eec0@mail.borg.com> <0A4934ED-E26A-11D8-B489-000A95DA08F2@kniveton.com> <6.1.1.1.0.20040802105613.0242a2d8@mail.borg.com> <411230B5.3080103@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Content-Transfer-Encoding: 7bit Hi Alex, See below. > > (3) For the reasons cited in (2) above, we are concerned with the > > multiple encapsulation that may occur with nested NEMO and/or RO. We > > really don't care about RO in the wireline network, as our > > bandwidths are so many orders of magnitude smaller, but we do need to > > avoid any avoidable multiple trips or encapsulations over the > > wireless links. We believe this concern will be shared by other > > developers of wireless WANs, as bandwidth is inherently much more > > precious in the wireless WAN than the wireless LAN, as the latter > > spectrum can be extensively re-used in different cells, but the > > former cannot. > > > > (4) Assume MN1 is served by MR1 and MN2 by MR2, and that the former > > is the parent of the latter in a nested NEMO. If MR2 then achieves > > another point of attachment to the fixed infrastructure, but also > > retains its connectivity through MN1, MN2 is multi-homed, > > So MR2 has actually three interfaces, right? The third interface was > kind of dangling before achieving another point of attachment. > > > but MN1 is not, per the the nomenclature and multihoming drafts. This > > is because MNs are nominally precluded from offering transit. > > One should attach a certain interpretation to the statements about > moving networks being precluded to offer transit. In nested NEMO moving > networks, one network transits packets of the other ok. However, in OSPF > networks there are "transit" and "stub" networks and in this sense a > moving network is more like an OSPF stub network and precluded to be an > OSPF transit network. > > > However, the access link between MR1 and the infrastructure may have > > very different QoS attributes from that directly between MR2 and the > > infrastructure: nodes in MN2 can choose their preference, but nodes > > in MN1 cannot; in some scenarios, the restriction on transit through > > MN2 will preclude some applications from running on nodes in MN1, > > even though adequate capacity and QoS would be available to them, > > were they only permitted to transit MN2. Setting QoS aside, MN1 and > > MN2 may both offer bursty traffic, with peak demand from each > > exceeding the capacity of its MR's direct link to the backbones, but > > the peak aggregate demand not exceeding their aggregated capacity; > > MN2 will be fine, but MN1 will suffer needless congestion induced > > packet loss if it is not permitted to transit MN2. We realize that > > transit should not be offered in general by MNs, for good and obvious > > reasons, but believe cases of this sort should be supported. Keep > > in mind that the only reason MN2 was allowed to transit MN1, and not > > vice versa, was the temporal order in which registrations occurred: > > MN2 first was attached to MN1 and then later directly to the > > backbones; had MN2 initially been attached to a backbone, and MN1 > > attached to MN2, the 'rules' as to who can transit whom would have > > been reversed. > > Yes, this requirement looks to provide value and I think moving networks > as they are now (NEMO basic support is exclusively IPv6, and > non-interoperable v4 implementations exist) will not accomodate the > above scenario. > > We have identified another mobility configuration that is not supported > by NEMO Basic Support and is not multi-homing either (uses a mobile HA). What do you mean by new configuration ? The HA would be 1. in the aircraft or 2 in the infrastructure ? If 1, this falls into the nested case (offering service to LMNs). In both cases, we are talking about multiple HAs, don't we ? Thierry From nemo-bounces@ietf.org Thu Aug 5 22:19:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04586 for ; Thu, 5 Aug 2004 22:19:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsuIN-0005oX-FO; Thu, 05 Aug 2004 22:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsuI1-0005iv-64 for nemo@megatron.ietf.org; Thu, 05 Aug 2004 22:17:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04445 for ; Thu, 5 Aug 2004 22:16:58 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsuLZ-0002K6-41 for nemo@ietf.org; Thu, 05 Aug 2004 22:20:45 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D37A12A12C; Fri, 6 Aug 2004 04:16:24 +0200 (CEST) Received: from [130.129.65.71] (unknown [130.129.65.71]) by smtp03.uc3m.es (Postfix) with ESMTP id BE0CB2A123; Fri, 6 Aug 2004 04:16:23 +0200 (CEST) Subject: Re: [nemo] Generic RO Tunnel (ROT) Model From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jongkeun Na In-Reply-To: <200408050140.i751er4N030162@popeye.snu.ac.kr> References: <200408050140.i751er4N030162@popeye.snu.ac.kr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MpPr3jN7t4Q19zTc5Cih" Organization: Universidad Carlos III de Madrid Message-Id: <1091758590.2522.31.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 06 Aug 2004 04:16:30 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 --=-MpPr3jN7t4Q19zTc5Cih Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jongkeun, Thanks for providing this draft. I think that's very important to have some previous analysis of the RO problem if we finally face it. Some comments (actually some - if not all - have been already pointed by Alex and Thierry): - I think that a RO solution in NEMO is not restricted to two entities establishing a tunnel between them. At this point of time, in which it is not very clear how to provide RO in NEMO (IMHO because it is not completely clear in which situations we need/it's worth to have RO), we should not restrict us to a certain type of solutions. IMHO, being so focused in RO provided by some kind of IP tunnel, also makes the terminology difficult to understand in the first look at the draft. Maybe it could be redefined or simplified. - IMHO a model should be more general, more abstract, not so specific. I think that it would be easier to understand the problem and find the solutions if they were presented in a more abstract way. - As Thierry has said, I think that it's more important to have a clear view of the problem space prior to trying to handle the solution space. IMHO the problem space should take also into account the scenarios in which NEMO is expected to be involved to, I mean, we can make a sort of taxonomy of situations in which RO would be needed (LFN talking to a CN outside the NEMO, LFN talking to another LFN in a different NEMO, nesting, and so on...), but I think that it's also important to evaluate which of these situations are more likely to happen. Thanks, C.J. P.S. How are you edited/generated the i-d. I don't know if it only happens to me, but it seems that the left margin is bigger than it should be. If I try to print it, it looks weird, and difficult to read. El jue, 05-08-2004 a las 03:50, Jongkeun Na escribi=C3=B3: > Hello, >=20 > =20 >=20 > Generic RO Tunnel (ROT) Model was introduced in > http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt >=20 > However, unfortunately I=E2=80=99ve not received any comments on this. So= I > re-state the purpose of this work and once again solicit your > comments. Your feedback is very important because I want to confirm > that this work is directed to its right way. >=20 > The draft outlines generic RO model for NEMO extended support. I think > that it can provide a useful framework in that defining RO problem > spaces, evaluating the existing RO solutions and discussing a bunch of > related RO issues. As you know, RO problem & solution is some complex > so I think we need a well defined RO model to enable us to find > optimal RO solution. >=20 > Also, Section 4 in the draft is mentioning on the need of a unified RO > solution. I guess that this point is important in up-coming discussion > of WG about RO. please don=E2=80=99t hesitate in expressing your thought.= Any > feedback is welcome.=20 >=20 > =20 >=20 > Regards, >=20 > Jongkeun >=20 > =20 --=20 Carlos Jes=C3=BAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-MpPr3jN7t4Q19zTc5Cih Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBEun85vKyPtrWqkARAnIXAKCFG2cZbi6PrDf87/hy1pKcV4FX9QCZASQr bGzYmZn/r4p9db/Q8lYN5mo= =JJmg -----END PGP SIGNATURE----- --=-MpPr3jN7t4Q19zTc5Cih-- From nemo-bounces@ietf.org Fri Aug 6 00:01:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10265 for ; Fri, 6 Aug 2004 00:01:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsvpw-0000bB-5z; Thu, 05 Aug 2004 23:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsvhM-0007uV-KM for nemo@megatron.ietf.org; Thu, 05 Aug 2004 23:47:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09739 for ; Thu, 5 Aug 2004 23:47:13 -0400 (EDT) Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsvky-0003rP-94 for nemo@ietf.org; Thu, 05 Aug 2004 23:51:01 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i763bt4N005492; Fri, 6 Aug 2004 12:37:55 +0900 Message-Id: <200408060337.i763bt4N005492@popeye.snu.ac.kr> From: "Jongkeun Na" To: "'Alexandru Petrescu'" Subject: RE: [nemo] Generic RO Tunnel (ROT) Model Date: Fri, 6 Aug 2004 12:47:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <411249E6.4070309@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6+rWT4Gk3Zz66T5+HYkSn7hzWXAAYvzGQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Content-Transfer-Encoding: 7bit Hi Alex, Thank you for your comments. See my response in line. > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: Thursday, August 05, 2004 11:53 PM > To: Jongkeun Na > Cc: nemo@ietf.org > Subject: Re: [nemo] Generic RO Tunnel (ROT) Model > > Jongkeun Na wrote: > > Generic RO Tunnel (ROT) Model was introduced in > > _http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt_ > > > > > > However, unfortunately I've not received any comments on this. So I > > re-state the purpose of this work and once again solicit your > > comments. Your feedback is very important because I want to confirm > > that this work is directed to its right way. > > Hello Jongkeun, > > Thanks to you and co-authors (Seongho Cho, Chongkwon Kim, Changhoi Koo) > for providing this generic RO model. I've just read through it. > > The draft assumes that RO can only be achieved by using tunnels of some > sort. > > It proposes a generic architecture (boxes, functions and tunnel types) > of Tunnel Endpoints, Switchers and Relays. These - still generic - > boxes can perform generic functions/attributes such as Initiator, > Responder, Trigger Source, Discovery and, moreover, tunnels can be of > several types: Simple, Switched and Relayed. > > It subsequently maps RRH, HMIPv6, VIP, PCH, ORC, ARO and other RO > schemes on this conceptual architecture. So this may be a useful RO > taxonomy. > > I do not understand why is it assumed (as ORC does) that after RO there > will still be encapsulation. I thought one of the main goals of > employing RO is to eliminate encapsulation altogether. I may be wrong. > IP tunneling is a basic mechanism to re-route packets at some intermediate points without any modification on the original packets. I thought that it can well express the purpose of RO such as packet redirection service. And, the tunneling contains most of procedures involved in RO, negotiation between two entities, the method of transferring packets, etc. So, I think that eliminating encapsulation or other optimizations can be considered under the concept of IP tunneling. > > [achieve] unified RO in NEMO > > I'd say "interoperable" RO for MR, instead of "unified". Okay, it is not bad to me. But, I saw we can make a universal solution in working on the unified RO for some main RO problems like RO in the infrastructure, nested RO. Our another draft addresses this point. This is still not discussed in NEMO ML, but here are some parts of content for your understanding: "we propose a route optimization scheme based on PCH(Path Control Header) piggybacking by HA. The scheme is a unified solution that can solve a several types of route optimization problem with applying the same principle to the routing facilities such as HA, MR and Correspondent Router(CR). In the proposed scheme, HA does piggyback PCH on the packet which is reversely forwarded from MR through bi-directional MR-HA tunnel. PCH is a hop-by-hop option header so that it can be processed by all of the routing facilities on the path that is from HA to CN. HA forwards the packet with PCH to CN for the route optimization. CR on the path makes a RO(Route Optimization) tunnel between MR and itself using the information which is the CoA of MR that is contained in PCH." Please see http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt for details. > > > spaces, evaluating the existing RO solutions and discussing a bunch > > of related RO issues. As you know, RO problem & solution is some > > complex so > > I think it would be useful to define the RO problem itself first, and > what would an RO solution do. > > Even define what "route" is in this context, what an "optimal route" is, > etc. Good point, I'd like to share with you. We need some terminologies & basic performance metrics to discuss RO problems, evaluate RO solutions. > > For example: > > route: a sequence of IP hops between LFN and CN. > > optimal route: a route shorter than through-HA route. > > shortest route: the smallest number of IP hops. The optimal route is > not necessarily the optimal route. > > RO problem: find an optimal route. > > RO solution for NEMO: a set of protocol message exchanges after which > LFN and CN securely communicate at application level over optimal routes > (no encapsulation and not through HA). > > Or something like that. > Good example. IMHO, definitely defining some of those things is a base work that is required to elaborate our RO work. Thanks. > > I think we need a well defined RO model to enable us to find optimal > > RO solution. > > Yes. > > Alex From nemo-bounces@ietf.org Fri Aug 6 01:11:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15594 for ; Fri, 6 Aug 2004 01:11:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bswtj-0004TG-7D; Fri, 06 Aug 2004 01:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bswsn-0004L1-Eu for nemo@megatron.ietf.org; Fri, 06 Aug 2004 01:03:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15262 for ; Fri, 6 Aug 2004 01:03:08 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BswwQ-0005X6-G6 for nemo@ietf.org; Fri, 06 Aug 2004 01:06:54 -0400 Received: from iseran.local (unknown [2001:240:5bf:128:20a:95ff:fef5:49a5]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0BAE55D0A0 for ; Fri, 6 Aug 2004 14:02:36 +0900 (JST) Date: Fri, 6 Aug 2004 14:04:05 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20040806140405.16c64e08.ernst@sfc.wide.ad.jp> In-Reply-To: <3C174B4E-D96E-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <3C174B4E-D96E-11D8-A131-000D93ACD0FE@it.uc3m.es> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Subject: [nemo] Terminology [was Draft Agenda and CFP] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear all, particularly Marcelo and Vijay, Have you found the answers to your concerns appropriate, together with my modifications in the text ? Thierry. On Mon, 19 Jul 2004 12:27:28 +0200 marcelo bagnulo braun wrote: > Hi Thierry, T.J., >=20 > El 12/07/2004, a las 11:47, Thierry Ernst escribi=F3: >=20 > > > > > > Dear all, > > > > The San Diego meeting is fast approaching. The NEMO WG is scheduled on > > Monday 2nd August. > > > >> ---------- Drafty Draft Agenda > > > > > > During that meeting, we will > > definitely speak about: > > - status of the WG and WG documents > > - WG charter and WG direction > > - Results of WG Last Call for draft-ietf-nemo-terminology > > >=20 > When did the last call ended? >=20 > i couldn't find it in the archives... >=20 > i sent some comments a while ago, but i didn't receive any answer >=20 > You can find them at: > http://www1.ietf.org/mail-archive/web/nemo/current/msg00910.html >=20 > regards, marcelo >=20 > > - Results of WG Last Call for draft-ietf-nemo-equirements > > - Multihoming Problem Statement (draft-ietf-nemo-multihoming) > > > > > > Other topics on which we wish to have contributions: > > - MIB for NEMO Basic Support > > - Securiry Threat Analysis > > - Analysis of the Solution Space for Route Optimization > > - Prefix Delegation for Mobile Networks > > - NEMO Home Network models (draft-ietf-nemo-home-network-models-00) > > > >> ----------- Call for Participation > > > > If you intend to request a slot for a topic related with the above > > listed topic, or to add an item, please send your request to both=20 > > chairs > > by July 20th. Requests must be justified and will be accepted based the > > priorities of the WG and time allowed during our slot. > > > >> ----------- Submitted Drafts > > > > Also, if you have submitted a new draft since last meeting, or intend=20 > > to > > submit one before the deadline, please inform TJ and myself so that we > > can list all the ACTIVE drafts in the reading list. > > > > Note that I've seen a couple of drafts passing on the IETF-Announce > > Mailing List, but these drafts were usually not announced on the NEMO > > ML. According to the new secretariat policy, it's now the=20 > > responsability > > of the author to send a note to the NEMO ML. > > > > Regards, > > NEMO Chairs. > > > > >=20 >=20 From nemo-bounces@ietf.org Fri Aug 6 01:55:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19483 for ; Fri, 6 Aug 2004 01:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsxc5-0003AR-5b; Fri, 06 Aug 2004 01:49:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsxTt-0001mQ-ND for nemo@megatron.ietf.org; Fri, 06 Aug 2004 01:41:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18643 for ; Fri, 6 Aug 2004 01:41:29 -0400 (EDT) Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsxXW-0006Ft-21 for nemo@ietf.org; Fri, 06 Aug 2004 01:45:15 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i765W54N006107; Fri, 6 Aug 2004 14:32:05 +0900 Message-Id: <200408060532.i765W54N006107@popeye.snu.ac.kr> From: "Jongkeun Na" To: "'Thierry Ernst'" Subject: RE: [nemo] Generic RO Tunnel (ROT) Model Date: Fri, 6 Aug 2004 14:41:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040806083147.05f0a0d0.ernst@sfc.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR7RJFc6RFqoY7MSlWME9OWFAV+LwAKdBOQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Content-Transfer-Encoding: 7bit Hi Thierry, Thank you for your comments. Some thoughts are in line. > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > Thierry Ernst > Sent: Friday, August 06, 2004 8:32 AM > To: nemo@ietf.org > Subject: Re: [nemo] Generic RO Tunnel (ROT) Model > > > Dear all, > > I personaly find the draft and the model interesting from an analytical > point of view, but I'm not sure it would be a useful model for the > analysis that we need to carry on in this WG. But let's see. > > Would you motivate the need for such an abstraction model in this WG ? IMHO, it is to see a forest, not a tree. RO problem has various situations to be fixed to diminish inefficient IP routing incurred by mobility. Case-by-case approach in handling RO problem & solution is not enough to get a big picture. > > How would you use it ? In my opinion, we can use it as a descriptive framework to describe some sort of things like which situation want RO, which entities involved in RO, how RO can be achieved, etc. Second, it could be used to evaluate some existing RO solutions, in what range does it support RO, does it satisfy the minimum requirement in performance or some operational restrictions. Lastly, it can inspire new universal RO solution. > > What are you plans in using this model ? Frankly speaking, currently not planed but I think we need to come up with on what plan is useful to WG together. > > Why do you compare VIP ? (if you want to compare host mobility support, > there are tons if them, so why VIP and not other ? I don't understand what's your point. > > > > > Generic RO Tunnel (ROT) Model was introduced in > > > _http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt_ > > > > > > > > > However, unfortunately I've not received any comments on this. So I > > > re-state the purpose of this work and once again solicit your > > > comments. Your feedback is very important because I want to confirm > > > that this work is directed to its right way. > > Defining a model is good idea and would help. However, I'm concerned > that this model focuses too much on tunneling and on MIP6-based > solutons.So, it might be generic for solutions that use tunneling, but > not generic enough for solutions that don't rely on tunneling (RO > between 2 VMNs in the same NEMO for instance). So, we miss the complete > picture. IMHO, the same principle & structure can be applied into ROT model if VMN or CN can be a Tunnel Endpoint. But, personally RO for CN including VMN in NEMO could be approached by MIPv6 RO. Still it's not clear to me. Can you show me an example like MIPv6 RO can't be applied to CN or VMN? > > > > Hello Jongkeun, > > > > Thanks to you and co-authors (Seongho Cho, Chongkwon Kim, Changhoi Koo) > > for providing this generic RO model. I've just read through it. > > > > The draft assumes that RO can only be achieved by using tunnels of some > > sort. > > > > It proposes a generic architecture (boxes, functions and tunnel types) > > of Tunnel Endpoints, Switchers and Relays. These - still generic - > > boxes can perform generic functions/attributes such as Initiator, > > Responder, Trigger Source, Discovery and, moreover, tunnels can be of > > several types: Simple, Switched and Relayed. > > > > It subsequently maps RRH, HMIPv6, VIP, PCH, ORC, ARO and other RO > > schemes on this conceptual architecture. So this may be a useful RO > > taxonomy. > > > > I do not understand why is it assumed (as ORC does) that after RO there > > will still be encapsulation. I thought one of the main goals of > > employing RO is to eliminate encapsulation altogether. I may be wrong. > > > > > [achieve] unified RO in NEMO > > > > I'd say "interoperable" RO for MR, instead of "unified". > > Well, unified would be a nice goal. But I doubt it could be achieved > easily. In any case, we need to define the RO problem first. Where do we need > RO ? > > > > > spaces, evaluating the existing RO solutions and discussing a bunch > > > of related RO issues. As you know, RO problem & solution is some > > > complex so > > > > I think it would be useful to define the RO problem itself first, and > > what would an RO solution do. > > > > Even define what "route" is in this context, what an "optimal route" is, > > etc. > > > > For example: > > > > route: a sequence of IP hops between LFN and CN. > > > > optimal route: a route shorter than through-HA route. > > > > shortest route: the smallest number of IP hops. The optimal route is > > not necessarily the optimal route. > > > > RO problem: find an optimal route. > > > > RO solution for NEMO: a set of protocol message exchanges after which > > LFN and CN securely communicate at application level over optimal routes > > (no encapsulation and not through HA). > > > > Or something like that. > > I agree that would help to define the problem statement that we are > still lacking in the NEMO WG. > > > > I think we need a well defined RO model to enable us to find optimal > > > RO solution. > > Agree. Before analyzing the solution space, we need to analyze the > problem space. Where do we need RO ? Actualy, Watari provided good input > in his presentation. > > Thierry. > > > > From nemo-bounces@ietf.org Fri Aug 6 02:21:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04549 for ; Fri, 6 Aug 2004 02:21:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsxy9-0001wH-OY; Fri, 06 Aug 2004 02:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsxwB-00019C-M4 for nemo@megatron.ietf.org; Fri, 06 Aug 2004 02:10:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00507 for ; Fri, 6 Aug 2004 02:10:42 -0400 (EDT) Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsxzp-0006hz-9v for nemo@ietf.org; Fri, 06 Aug 2004 02:14:30 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i7661N4N006263; Fri, 6 Aug 2004 15:01:24 +0900 Message-Id: <200408060601.i7661N4N006263@popeye.snu.ac.kr> From: "Jongkeun Na" To: "'Carlos Jesus Bernardos Cano'" Subject: RE: [nemo] Generic RO Tunnel (ROT) Model Date: Fri, 6 Aug 2004 15:10:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1091758590.2522.31.camel@acorde> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR7WqimOzNgOoUHSIuTx1lxIeu4fAAHZTzw X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Content-Transfer-Encoding: quoted-printable Hi Carlos,=20 Thank you for your comments. See below inline. > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of > Carlos Jesus Bernardos Cano > Sent: Friday, August 06, 2004 11:17 AM > To: Jongkeun Na > Cc: nemo@ietf.org > Subject: Re: [nemo] Generic RO Tunnel (ROT) Model >=20 > Hi Jongkeun, >=20 > Thanks for providing this draft. I think that's very important to have > some previous analysis of the RO problem if we finally face it. Some > comments (actually some - if not all - have been already pointed by = Alex > and Thierry): >=20 > - I think that a RO solution in NEMO is not restricted to two entities > establishing a tunnel between them. At this point of time, in which it > is not very clear how to provide RO in NEMO (IMHO because it is not > completely clear in which situations we need/it's worth to have RO), = we > should not restrict us to a certain type of solutions. IMHO, being so > focused in RO provided by some kind of IP tunnel, also makes the > terminology difficult to understand in the first look at the draft. > Maybe it could be redefined or simplified. As you know, ROT model was focused on Tunnel-based RO. So it explicitly = does not include the considerations of other RO approach that do not need any tunnel. I will try to include other RO types in ROT model by extending = some attributes if it is possible. >=20 > - IMHO a model should be more general, more abstract, not so specific. > I think that it would be easier to understand the problem and find the > solutions if they were presented in a more abstract way. Okay, I agree with you. >=20 > - As Thierry has said, I think that it's more important to have a clear > view of the problem space prior to trying to handle the solution = space. > IMHO the problem space should take also into account the scenarios in > which NEMO is expected to be involved to, I mean, we can make a sort = of > taxonomy of situations in which RO would be needed (LFN talking to a = CN > outside the NEMO, LFN talking to another LFN in a different NEMO, > nesting, and so on...), but I think that it's also important to = evaluate > which of these situations are more likely to happen. ROT model looks like RO scope limited. Also, it lacks of some other RO situations that you and Thierry have pointed out. More elaboration is required. Thanks. >=20 > Thanks, >=20 > C.J. >=20 > P.S. How are you edited/generated the i-d. I don't know if it only > happens to me, but it seems that the left margin is bigger than it > should be. If I try to print it, it looks weird, and difficult to = read. >=20 >=20 > El jue, 05-08-2004 a las 03:50, Jongkeun Na escribi=F3: > > Hello, > > > > > > > > Generic RO Tunnel (ROT) Model was introduced in > > = http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt > > > > However, unfortunately I=92ve not received any comments on this. So = I > > re-state the purpose of this work and once again solicit your > > comments. Your feedback is very important because I want to confirm > > that this work is directed to its right way. > > > > The draft outlines generic RO model for NEMO extended support. I = think > > that it can provide a useful framework in that defining RO problem > > spaces, evaluating the existing RO solutions and discussing a bunch = of > > related RO issues. As you know, RO problem & solution is some = complex > > so I think we need a well defined RO model to enable us to find > > optimal RO solution. > > > > Also, Section 4 in the draft is mentioning on the need of a unified = RO > > solution. I guess that this point is important in up-coming = discussion > > of WG about RO. please don=92t hesitate in expressing your thought. = Any > > feedback is welcome. > > > > > > > > Regards, > > > > Jongkeun > > > > > -- > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Fri Aug 6 04:34:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12322 for ; Fri, 6 Aug 2004 04:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt05C-0007Dm-Lg; Fri, 06 Aug 2004 04:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt015-0006Um-Bh for nemo@megatron.ietf.org; Fri, 06 Aug 2004 04:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11671 for ; Fri, 6 Aug 2004 04:23:53 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt04j-0000Z3-LQ for nemo@ietf.org; Fri, 06 Aug 2004 04:27:43 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i768Okxl016862; Fri, 6 Aug 2004 01:24:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i768MdOK020362; Fri, 6 Aug 2004 03:22:40 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E386A8859AE; Fri, 6 Aug 2004 10:23:49 +0200 (CEST) Message-ID: <4113400F.401@motorola.com> Date: Fri, 06 Aug 2004 10:23:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst References: <6.1.1.1.0.20040729000818.0240eec0@mail.borg.com> <0A4934ED-E26A-11D8-B489-000A95DA08F2@kniveton.com> <6.1.1.1.0.20040802105613.0242a2d8@mail.borg.com> <411230B5.3080103@motorola.com> <20040806090110.54a22663.ernst@sfc.wide.ad.jp> In-Reply-To: <20040806090110.54a22663.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0474DD4276C113254506577" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] Re: non-working configurations (was: can't make San Diego but here's some food for thought) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0474DD4276C113254506577 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >>> (4) Assume MN1 is served by MR1 and MN2 by MR2, and that the >>> former is the parent of the latter in a nested NEMO. If MR2 then >>> achieves another point of attachment to the fixed >>> infrastructure, but also retains its connectivity through MN1, >>> MN2 is multi-homed, [...] >>> However, the access link between MR1 and the infrastructure may >>> have very different QoS attributes from that directly between MR2 >>> and the infrastructure: nodes in MN2 can choose their >>> preference, but nodes in MN1 cannot; in some scenarios, the >>> restriction on transit through MN2 will preclude some >>> applications from running on nodes in MN1, even though adequate >>> capacity and QoS would be available to them, were they only >>> permitted to transit MN2. Setting QoS aside, MN1 and MN2 may both >>> offer bursty traffic, with peak demand from each exceeding the >>> capacity of its MR's direct link to the backbones, but the peak >>> aggregate demand not exceeding their aggregated capacity; MN2 >>> will be fine, but MN1 will suffer needless congestion induced >>> packet loss if it is not permitted to transit MN2. We realize >>> that transit should not be offered in general by MNs, for good >>> and obvious reasons, but believe cases of this sort should be >>> supported. Keep in mind that the only reason MN2 was allowed to >>> transit MN1, and not vice versa, was the temporal order in which >>> registrations occurred: MN2 first was attached to MN1 and then >>> later directly to the backbones; had MN2 initially been attached >>> to a backbone, and MN1 attached to MN2, the 'rules' as to who can >>> transit whom would have been reversed. > >> We have identified another mobility configuration that is not >> supported by NEMO Basic Support and is not multi-homing either >> (uses a mobile HA). > > What do you mean by new configuration ? Our NEMO-unsupported configuration was the one presented at a previous IETF - "cross-over tunnels" - and I think it's not multi-homed because although there are multiple HA's (one in a moving network and one in the infrastructure), each MR only has a unique egress interface in that scenario. The Card/Zabele/DoD demo is different than our non-working configuration and fails to work for other reasons than ours (tunnels that would "cross-over" do not help solve their problem, while it would solve ours). The problem in the Card/Zabele/DoD demo is that LFN in MovingNetwork1 will not be able to change its default route towards MR2 when MR1 gets disconnected and MR2 attaches its third interface to a new wireless access system. MR2 does not send RA's on any of its egress interface so LFN (which sits above MR2) can not configure a default route towards MR2. I do not know whether it's a new RO mechanism or an existing RP (routing protocol) and traffic shaping that could help solve both these issues, or a combination of the two. > The HA would be 1. in the aircraft or 2 in the infrastructure ? If 1, > this falls into the nested case (offering service to LMNs). In both > cases, we are talking about multiple HAs, don't we ? Ah sorry, so it is agreed that when there are multiple HA's there's actually "multi-homing" taking place? This would mean that most times when there are nested networks there's actually "multi-homing"? Alex --------------enigC0474DD4276C113254506577 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBE0AVMmC0w56zj54RAmGHAJ9Lm38buD061oGMihUGkl5sl42I2ACgkfx9 Lh/ObzggKk5SHNY4vl+6/FI= =yHAV -----END PGP SIGNATURE----- --------------enigC0474DD4276C113254506577-- From nemo-bounces@ietf.org Fri Aug 6 05:36:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14514 for ; Fri, 6 Aug 2004 05:36:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt17D-0000F0-Vp; Fri, 06 Aug 2004 05:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt16z-000093-Om for nemo@megatron.ietf.org; Fri, 06 Aug 2004 05:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14455 for ; Fri, 6 Aug 2004 05:34:03 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt1Ae-0001Z3-L6 for nemo@ietf.org; Fri, 06 Aug 2004 05:37:53 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i769Y2vh022029; Fri, 6 Aug 2004 02:34:02 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i769QMUe011080; Fri, 6 Aug 2004 04:26:22 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1F81F8859AE; Fri, 6 Aug 2004 11:33:59 +0200 (CEST) Message-ID: <41135081.1040307@motorola.com> Date: Fri, 06 Aug 2004 11:33:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Davis, Terry L" Subject: Re: [nemo] Mobile Network Conops References: <6E5042539D21AF4E9C457B4DDCC3D6E104DD7EF2@xch-nw-21.nw.nos.boeing.com> In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E104DD7EF2@xch-nw-21.nw.nos.boeing.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig391F5AD60AE3AE3AFEE3539C" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF NEMO WG , "T.J.Kniveton" , 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig391F5AD60AE3AE3AFEE3539C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Davis, Terry L wrote: > I missed the Card/Zabele/DoD demo list mail. Maybe here http://www1.ietf.org/mail-archive/web/nemo/current/msg01419.html > Although they may be similar, these are around discussions for > commercial service. Network Centric Operations certainly have I guess they have :-) I think interoperable commercial services are a very good thing and we're kind of interested by more details about how could v4/v6 NEMO moving networks be applied to the mentioned CONOPS. > =========================== Some may be, some definitely will not be > interconnected. I would envision that all of the onboard networks > would have the ability to connect to multiple providers; some > commercial, some aviation or air traffic control specific. Do you have a slide showing specific cases of a commercial provider and of an aviation/air traffic control provider? > Can the HAHA concept help with this sort of deployment mentioned > above? How? Is there anything missing in HAHA that needs > improvement? > =========================== We will probaly figure that out as we > actually see initial versions run. I do believe there is need for > some informational RFC's to be developed for mobile networks to cover > what it takes to build a full mobile network infrastructure; I tend > to refer to it as "Internet docking" to cover mobility, security, > QoS, etc. So "Internet Docking" would be a specific local infrastructure of several providers to which moving networks can seamlessly attach and maintain ongoing sessions. Local: would all the provider networks be connected tightly to one another (local) or would each of those providers be at different points across the Internet. > ==================================== Unfortunately they do match > since it is not clear what part of the onboard configurations can be > dynamically changed without re-certification. Changing the aviation > industry from being 429/629-bus based with hard (permanent) configs > is challenging. ==================================== I understand. Similar concerns are expressed with respect to the CAN buses for vehicular. Anyone proposed IP-over-ARINC-629 already? (just like they have IP over infiniband, ipoib WG). Alex --------------enig391F5AD60AE3AE3AFEE3539C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBE1CGMmC0w56zj54RAoIlAKDj1P4mWXt6EChoyFLldyLj9NXq4ACdHAbn 9sDeKfODFNbG08x0IBmQvVw= =P6Du -----END PGP SIGNATURE----- --------------enig391F5AD60AE3AE3AFEE3539C-- From nemo-bounces@ietf.org Fri Aug 6 06:15:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16700 for ; Fri, 6 Aug 2004 06:15:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt1jQ-0005Mm-Qy; Fri, 06 Aug 2004 06:13:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt1fG-00048i-G7 for nemo@megatron.ietf.org; Fri, 06 Aug 2004 06:09:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16181 for ; Fri, 6 Aug 2004 06:09:28 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt1iv-00025d-Ex for nemo@ietf.org; Fri, 06 Aug 2004 06:13:18 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i76A59BP013453; Fri, 6 Aug 2004 03:05:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i76A9OUI003977; Fri, 6 Aug 2004 05:09:24 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E868F8859AE; Fri, 6 Aug 2004 12:09:23 +0200 (CEST) Message-ID: <411358C8.9080307@motorola.com> Date: Fri, 06 Aug 2004 12:09:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jongkeun Na Subject: Re: [nemo] Generic RO Tunnel (ROT) Model References: <200408060337.i763bt4N005492@popeye.snu.ac.kr> In-Reply-To: <200408060337.i763bt4N005492@popeye.snu.ac.kr> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5920C9A311CF782C0D6D6FE" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5920C9A311CF782C0D6D6FE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jongkeun Na wrote: >> I do not understand why is it assumed (as ORC does) that after RO >> there will still be encapsulation. I thought one of the main goals >> of employing RO is to eliminate encapsulation altogether. I may >> be wrong. >> > IP tunneling is a basic mechanism to re-route packets at some > intermediate points without any modification on the original packets. > I thought that it can well express the purpose of RO such as packet > redirection service. And, the tunneling contains most of procedures > involved in RO, negotiation between two entities, the method of > transferring packets, etc. So, I think that eliminating encapsulation > or other optimizations can be considered under the concept of IP > tunneling. So we basically have two competing types of RO solutions here: -RO eliminating all the encapsulating tunnels, a.k.a MIP6 RO -RO reducing some of the tunnels encapsulations and further relying on IP tunneling techniques to reduce the encapsulations, like RRH. Maybe even add ROHC. Or maybe we need to better define what "encapsulating" means. One can have encapsulated packets with full new base headers (and trailers in case of ESP) or encapsulation with only extension headers like RH. Do you mean "encapsulation" to interpret both the cases where new base headers are added and the cases where only RH is added? Or only base header? And the "encapsulating" case with RH can actually be only a 1-address RH, like the MIP6 RH Type 2, so multiple "encapsulating" is not quite possible in this way. > Okay, it is not bad to me. But, I saw we can make a universal > solution in working on the unified RO for some main RO problems like > RO in the infrastructure, nested RO. So we basically have three other sorts of RO techniques: -RO for nested aggregation (RRH) -RO for the infrastructure (MIP6 RO) -RO Unified, a combination of the above, and PCH Or? Alex --------------enigF5920C9A311CF782C0D6D6FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBE1jTMmC0w56zj54RAu11AKD2bWZGKl+sXlywtN+a1l/b57CuQgCgr2hB pG9bl7a7DZz/hQd2ok8d7ms= =+680 -----END PGP SIGNATURE----- --------------enigF5920C9A311CF782C0D6D6FE-- From nemo-bounces@ietf.org Fri Aug 6 06:39:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18051 for ; Fri, 6 Aug 2004 06:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt24O-0008G7-7K; Fri, 06 Aug 2004 06:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt23w-00089N-5I for nemo@megatron.ietf.org; Fri, 06 Aug 2004 06:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17803 for ; Fri, 6 Aug 2004 06:34:57 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt27b-0002Tu-GS for nemo@ietf.org; Fri, 06 Aug 2004 06:38:48 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i76AYpc9022070; Fri, 6 Aug 2004 03:34:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i768Ygoa010342; Fri, 6 Aug 2004 03:34:42 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2F3A28859AE; Fri, 6 Aug 2004 12:34:49 +0200 (CEST) Message-ID: <41135EC3.9020506@motorola.com> Date: Fri, 06 Aug 2004 12:34:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst References: <200408050140.i751er4N030162@popeye.snu.ac.kr> <411249E6.4070309@motorola.com> <20040806083147.05f0a0d0.ernst@sfc.wide.ad.jp> In-Reply-To: <20040806083147.05f0a0d0.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6EA82BC38B520303BD77A1F" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nemo@ietf.org Subject: [nemo] Re: When is RO needed (Was: Generic RO Tunnel (ROT) Model) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6EA82BC38B520303BD77A1F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Well, unified would be a nice goal. But I doubt it could be achieved > easily. In any case, we need to define the RO problem first. Where do > we need RO ? RO may be needed when: -certain mobility configurations are not supported by NEMO Basic, e.g. the "cross-over" tunnels stuff and the Card/Zabele demo (sorry, I don't have a tech name for that issue, maybe one can find one). If RO solves any of those issues, and if OSPF, AODV are not capable of solving them, then RO is definitely needed. -the IP route LFN-MR-CN is significantly shorter than LFN-MR-HA-CN (note the length LFN-MR-CN and LFN-MR-HA-CN are not always very significantly different). I would not run 7packet RO exchanges when MR is close to its HA, much closer than where CN is with respect to HA. -the gain of eliminating a number of encapsulating headers over certain low-MTU, low-bdwth, assymmetric wireless links is significant in terms of improving e2e application performance (note MR performs RO but it's not for itself, it's for the sake of LFN-CN communications). But I would not add 7packet RO secure message exchanges only to find out that a LFN-CN e2e application does not induce any user-perceptible improvement for a video stream. Alex --------------enigE6EA82BC38B520303BD77A1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBE17JMmC0w56zj54RArccAKDoRDBVdFT1X7rmeEYI0ivWfU3E5QCg2H13 TDWTKdKTtLVq7sBGAcmB8Q0= =hJtH -----END PGP SIGNATURE----- --------------enigE6EA82BC38B520303BD77A1F-- From nemo-bounces@ietf.org Fri Aug 6 09:22:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25677 for ; Fri, 6 Aug 2004 09:22:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt4ZV-0001nC-JK; Fri, 06 Aug 2004 09:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt4Xm-0001Yw-OC for nemo@megatron.ietf.org; Fri, 06 Aug 2004 09:13:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25184 for ; Fri, 6 Aug 2004 09:13:57 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt4bT-0004yp-BP for nemo@ietf.org; Fri, 06 Aug 2004 09:17:48 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id 9502710C466; Fri, 6 Aug 2004 09:13:25 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id 8882833800F; Fri, 6 Aug 2004 09:13:25 -0400 (EDT) Received: from grc.nasa.gov (68-233-171-129.clvdoh.adelphia.net [68.233.171.129]) by webmail.grc.nasa.gov (Postfix) with ESMTP id C1AD833800D; Fri, 6 Aug 2004 09:13:23 -0400 (EDT) Message-ID: <411383DF.1020006@grc.nasa.gov> Date: Fri, 06 Aug 2004 09:13:03 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu , nemo Subject: Re: [nemo] can't make San Diego but here's some food for thought References: <4112322A.8070303@motorola.com> In-Reply-To: <4112322A.8070303@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-102.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS,USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > ........Pascal, do you know what kind of network topology the > Card/Zabele/DoD >demo was using? Do you know whether all the ground stations are linked >together with fast links or via ISP/Internet? > >I strongly doubt that any of the currently proposed RO schemes was done >with the kind of architecture in mind that Card/Zabele is talking about. > > > > IMHO writing or even considering a protocol optimized for a specific architecture is a costly endevor. It is a proprietrary solution. Something the FAA and other Government organizations are use to investing in as DoD and Aerospace companies like proprietary solutions. Once you get in the door, you have no competition. Thus the airline service providers (United, Quantas, Contiental, Delta, etc....) should be pushing for an IETF standards solution to control costs. Hopefully, Stewart can get develop his ideas and, if deemed reasonable, get them incorporated in the IETF standards. Will From nemo-bounces@ietf.org Fri Aug 6 09:37:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26311 for ; Fri, 6 Aug 2004 09:37:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt4pK-0003f0-3l; Fri, 06 Aug 2004 09:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt4mw-0003LX-4y for nemo@megatron.ietf.org; Fri, 06 Aug 2004 09:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26009 for ; Fri, 6 Aug 2004 09:29:36 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt4qe-0005FH-AW for nemo@ietf.org; Fri, 06 Aug 2004 09:33:28 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i76DUKxl015688; Fri, 6 Aug 2004 06:30:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i76BTGoa004666; Fri, 6 Aug 2004 06:29:17 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 99B798859AE; Fri, 6 Aug 2004 15:29:23 +0200 (CEST) Message-ID: <411387AC.7050000@motorola.com> Date: Fri, 06 Aug 2004 15:29:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ivancic Subject: Re: [nemo] can't make San Diego but here's some food for thought References: <4112322A.8070303@motorola.com> <411383DF.1020006@grc.nasa.gov> In-Reply-To: <411383DF.1020006@grc.nasa.gov> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig880C096299A22D8BA13C883D" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig880C096299A22D8BA13C883D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ivancic wrote: >> ........Pascal, do you know what kind of network topology the >> Card/Zabele/DoD > >> demo was using? Do you know whether all the ground stations are >> linked together with fast links or via ISP/Internet? >> >> I strongly doubt that any of the currently proposed RO schemes was >> done with the kind of architecture in mind that Card/Zabele is >> talking about. >> > IMHO writing or even considering a protocol optimized for a specific > architecture is a costly endevor. It is a proprietrary solution. > Something the FAA and other Government organizations are use to > investing in as DoD and Aerospace companies like proprietary > solutions. Once you get in the door, you have no competition. Thus > the airline service providers (United, Quantas, Contiental, Delta, > etc....) should be pushing for an IETF standards solution to control > costs. Hopefully, Stewart can get develop his ideas and, if deemed > reasonable, get them incorporated in the IETF standards. I kind of noticed this. The "proprietary" "closed" systems discussion is not always black and white to me. Motorola has a proprietary closed system within which Mobile IP is used as per RFC, but that does not mean this protocol is well adapted to that particular closed situation. Much better could have been done with simpler and more cost-effective than Mobile IP. I was trying to say that Mobile IP in general has a very typical architecture in mind (i.e. mobile device connecting at the edges of the Internet, to wireless ISP's) which is somehow restrictive in nature, especially when considering the airborne stuff mentioned, or even the coast guard stuff in one of your papers. I was thinking to take the opportunity to learn about this variety of "alternative" architectures if I can say so, 3 were mentioned, and see whether better than Mobile IP can be done. But, as you say, this may be a too costly endeavour. At the same time, seeing Mobile IP deployed in closed systems (3GPP is another one) is really sometimes so performance-consuming, and giving place to so difficult to understand designs such as HAHA that, I don't know... Maybe this is about IRTF... Alex --------------enig880C096299A22D8BA13C883D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBE4ezMmC0w56zj54RAm7RAJ4qKvqOALSHCvD1tMlogOGIrXmSYwCffb7+ sIQ+ct7CPEAzneBMaUWqjVo= =Wz+4 -----END PGP SIGNATURE----- --------------enig880C096299A22D8BA13C883D-- From nemo-bounces@ietf.org Fri Aug 6 10:40:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01301 for ; Fri, 6 Aug 2004 10:40:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt5oG-0002V6-UP; Fri, 06 Aug 2004 10:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt5k3-0001rq-Cq for nemo@megatron.ietf.org; Fri, 06 Aug 2004 10:30:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00276 for ; Fri, 6 Aug 2004 10:30:41 -0400 (EDT) Received: from seraph7.grc.nasa.gov ([128.156.10.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt5nl-0006G7-RM for nemo@ietf.org; Fri, 06 Aug 2004 10:34:34 -0400 Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by seraph7.grc.nasa.gov (Postfix) with ESMTP id 06C0B10C467; Fri, 6 Aug 2004 10:30:12 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501) id E885A33800F; Fri, 6 Aug 2004 10:30:11 -0400 (EDT) Received: from grc.nasa.gov (68-233-171-129.clvdoh.adelphia.net [68.233.171.129]) by webmail.grc.nasa.gov (Postfix) with ESMTP id E890233800D; Fri, 6 Aug 2004 10:30:10 -0400 (EDT) Message-ID: <411395DE.7090203@grc.nasa.gov> Date: Fri, 06 Aug 2004 10:29:50 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] NAT/PAT transfersal over IPv4 networks References: <41100FF1.5080805@grc.nasa.gov> <4112375E.8000108@motorola.com> In-Reply-To: <4112375E.8000108@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ragnarok.grc.nasa.gov X-Spam-Status: No, hits=-102.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS,USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > ivancic wrote: > ........ > >> I used some of Pascal's IPv6 NEMO code with the "Doors" protocol and >> demonstrated this to the CIO of the US DoD. > > > Sidenote on this DoD demo. Will, does this demo relate anyhow to the > Card/Zabele/DoD Linux demo and to the Connexion by Boeing CONOPS > mentioned previously on this list? > > Alex Alex, Yes and No. Yes, in the fact that NASA, the DoD, and the FAA are all trying to get their hands around Network Centric Architectures and the potential to improve operations. DoD is far far far ahead of the other agencies. NASA and FAA are extremely conservative. NASA and FAA communications for air (or space) to ground is largely point-to-point and circuit based. The techniques and technology that are in place were developed in the 50's, 60's and maybe even into the 70's. The decision makers really do not understand networking. The FAA and NASA also have this idea that space and aeronautics is somehow unique. However, one usually does not have to look far to similar problems in terrestial networks (delay, high BER, need for low power devices, intemitant connectivity, etc....). Most of the FAA's and ICOA's (International Civil Aviation Organisation) needs can be met more than adequately with today's technology. However, in order to deploy solutions, the aerospace community needs to be educated in what can be done with networking and shown that thier concerns have been addressed. The other area that is of even greater importance, is the need to change policy. POLICY drives everything. If regulations say that I cannot send command and control data through someone elses network over a 2 Mbps, but rather, I have to send it over a low-rate 8 kbps shared link(VHF radio link) that is easily jammed or congested, I have no choice even though the 2 Mbps may be far supperior. If I am told that I must be able to do policy-based routing in order to ensure that command and control goes over the VHF or INMARSAT Aero-H link, then I am force to design a system that meets these mandates. Note, the intentions are good, but the requirements are overspecifed. Telling someone how do something versus telling someone what needs have to be fulfilled may result in drastically different implementations. For example, requireing command and control to have highest priority and guarenteed delirery of 99.999% of all command and control messages within 2 seconds is far different than requireing that command and control be sent over a particular link. The world is changing rapidly, and the Aeronautics community my well be forced to catch up. The FAA and ICAO what to go digital voice and command, but the currently do not authenticate or encrypt such messages. I sincerely doubt that they have the necessary bandwidth in the VHF spectrum. So, something will have to be done. Hopefully in a proactive manner, rather than reactive. Stewart has to make money for his company regarding the Air Traffic Management system. Thus, he is forced to meet thier requirements and mandates. The aerospace industry is also very "code" consious. They would like to have comfort that all code is fully tested for every possible case. This is obviously desirable, but gets much more difficult in a network centric environment as one cannot predict how the network will evolve. Thus, IMHO this POLICY will have to be modified somewhat in future systems deploying Commercial Off The Shelf (COTS) solutions. NO, in that I am pushing for a fully standards-based solution for Air Traffic Management, Aerospace, Space (Near-Planetary) and DoD. I believe that having hundreds of thousands of man-hours in code development and millions of users testing the code via daily use in an unimaginable amount of architectures and environments is probably more robust then have 6 of the smartest people in the world writing a piece of code and then testing it in as many environments and they can think of (and afford to put together) for 6 months. For example, I am working jointly on space-based research with Cisco. They put a 3250 PC-104 router in Low Earth Orbit. The network connections are located at Glenn Research Center. The router is working and configured for both static routing and mobile networking using IPv4. If we did not have the entire IOS stack onboard, it would have been very difficult to configure and debug the system. Note, I had 5 to 8 minute passes, 2 to 3 times per week and about 5 weeks to configure and validate the entire secure network. The router was launched with the most basic of configurations - for the most part, unconfigured. Having standard-based tools enabled us to be successful. I did not have access to this router until May and we did a demonstration of Network Centric Warfare June 7-16. (Please note, this is not intended as a commercial, rather it is intended to show what is possible when you stick to the standards.) http://www.lompocrecord.com/articles/2004/06/16/news/news03.prt Next goal is to move to IPv6. Will PS. I am working on an internal paper with all the details. Once that is completed, it needs to be sanitized for public distribution. So, it will be a few months before I can release anything. Sorry, but I have to protect the interestes of all parites that worked this including Surrey Satellite Technology Ltd, Cisco, General Dynamics, the Army and Air Force Battle Labs and Universal Space Networks. From nemo-bounces@ietf.org Mon Aug 9 01:41:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19617 for ; Mon, 9 Aug 2004 01:41:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu2sz-0000Ws-3u; Mon, 09 Aug 2004 01:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu2ld-0008M4-W7 for nemo@megatron.ietf.org; Mon, 09 Aug 2004 01:32:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19244 for ; Mon, 9 Aug 2004 01:32:16 -0400 (EDT) Received: from [202.141.25.89] (helo=cello.cs.iitm.ernet.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bu2pf-0006Xo-56 for nemo@ietf.org; Mon, 09 Aug 2004 01:36:43 -0400 Received: from rts.cs.iitm.ernet.in (rts.cs.iitm.ernet.in [10.6.6.3]) by cello.cs.iitm.ernet.in (8.12.11/8.12.11) with ESMTP id i795dhf2001935 for ; Mon, 9 Aug 2004 11:09:43 +0530 Date: Mon, 9 Aug 2004 10:10:55 +0530 (IST) From: "B. S. Manoj" To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [nemo] A New Book on Ad Hoc Wireless Networks from PH PTR X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: Please accept my apologies if you have already received this mail or the information contained herein. For those researchers/students who are in search of a good book on ad hoc wireless networks, a new book on Ad Hoc Wireless Networks titled "Ad Hoc Wireless Networks: Architectures and Protocols" published by Prentice Hall PTR is available now. TOC is given below for those who are interested. Table of Contents ----------------- Preface. 1. Introduction. Fundamentals of Wireless Communication Technology. The Electromagnetic Spectrum. Radio Propagation Mechanisms. Characteristics of the Wireless Channel. ModulationTechniques. Multiple Access Techniques. Voice Coding. Error Control. Computer Networks. Computer Network Software. Computer Network Architecture. IEEE 802 Networking Standard. Wireless Networks and Book Overview. Summary. Problems. Bibliography. 2. Wireless LANS and PANS. Introduction. Fundamentals of WLANs. IEEE 802.11 Standard. HIPERLAN Standard. Bluetooth. HomeRF. Summary. Problems. Bibliography. 3. Wireless WANS AND MANS. Introduction. The Cellular Concept. Cellular Architecture. The First-Generation Cellular Systems. The Second-Generation Cellular Systems. The Third-Generation Cellular Systems. Wireless in Local Loop. Wireless ATM. IEEE 802.16 Standard. HIPERACCESS. Summary. Problems. Bibliography. 4. Wireless Internet. Introduction. What Is Wireless Internet? Mobile IP. TCP in Wireless Domain. WAP. Optimizing Web Over Wireless. Summary. Problems. Bibliography. 5. Ad Hoc Wireless Networks. Introduction. Issues in Ad Hoc Wireless Networks. Ad Hoc Wireless Internet. Summary. Problems. Bibliography. 6. MAC Protocols for Ad Hoc Wireless Networks. Introduction. Issues in Designing a MAC Protocol for Ad Hoc Wireless Networks. Design Goals of a MAC Protocol for Ad Hoc Wireless Networks. Classifications of MAC Protocols. Contention-Based Protocols. Contention-Based Protocols with Reservation Mechanisms. Contention-Based MAC Protocols with Scheduling Mechanisms. MAC Protocols That Use Directional Antennas. Other MAC Protocols. Summary. Problems. Bibliography. 7. Routing Protocols for Ad Hoc Wireless Networks. Introduction. Issues in Designing a Routing Protocol for Ad Hoc Wireless Networks. Classifi cations of Routing Protocols. Table-Driven Routing Protocols. On-Demand Routing Protocols. Hybrid Routing Protocols. Routing Protocols with Efficient Flooding Mechanisms. Hierarchical Routing Protocols. Power-Aware Routing Protocols. Summary. Problems. Bibliography. 8. Multicastrouting in Ad Hoc Wireless Networks. Introduction. Issues in Designing a Multicast Routing Protocol. Operation of Multicast Routing Protocols. An Architecture Reference Model for Multicast Routing Protocols. Classifications of Multicast Routing Protocols. Tree-Based Multicast Routing Protocols. Mesh-Based Multicast Routing Protocols. Summary of Tree-and Mesh-Based Protocols. Energy-Efficient Multicasting. Multicasting with Quality of Service Guarantees. Application-Dependent Multicast Routing. Summary. Problems. Bibliography. 9. Transport Layer and Security Protocols for Ad Hoc Wireless Networks. Introduction. Issues in Designing a Transport Layer Protocol for Ad Hoc Wireless Networks. Design Goals of a Transport Layer Protocol for Ad Hoc Wireless Networks. Classification of Transport Layer Solutions. TCP Over Ad Hoc Wireless Networks. Other Transport Layer Protocols for Ad Hoc Wireless Networks. Security in Ad Hoc Wireless Networks. Network Security Requirements. Issues and Challenges in Security Provisioning. Network Security Attacks. Key Management. Secure Routing in Ad Hoc Wireless Networks. Summary. Problems. Bibliography. 10. Quality of Service in Ad Hoc Wireless Networks. Introduction. Issues and Challenges in Providing QoS in Ad Hoc Wireless Networks. Classifications of QoS Solutions. MAC Layer Solutions. Network Layer Solutions. QoS Frameworks for Ad Hoc Wireless Networks. Summary. Problems. Bibliography. 11. Energy Management in Ad Hoc Wireless Networks. Introduction. Need for Energy Management in Ad Hoc Wireless Networks. Classification of Energy Management Schemes. Battery Management Schemes. Transmission Power Management Schemes. System Power Management Schemes. Summary. Problems. Bibliography. 12. Wireless Sensor Networks. Introduction. Sensor Network Architecture. Data Dissemination. Data Gathering. MAC Protocols for Sensor Networks. Location Discovery. Quality of a Sensor Network. Evolving Standards. Other Issues. Summary. Problems. Bibliography. 13. Hybrid Wireless Networks. Introduction. Next-Generation Hybrid Wireless Architectures. Routing in Hybrid Wireless Networks. Pricing in Multi-Hop Wireless Networks. Power Control Schemes in Hybrid Wireless Networks. Load Balancing in Hybrid Wireless Networks. Summary. Problems. Bibliography. 14. Recent Advances in Wireless Networks. Introduction. Ultra-Wide-Band Radio Communication. Wireless Fidelity Systems. Optical Wireless Networks. The Multimode 802.11 -IEEE 802.11a/b/g. The Meghadoot Architecture. Summary. Problems. Bibliography. Abbreviations. Index. See the following link for details at amazon.com. http://www.amazon.com/exec/obidos/tg/detail/-/013147023X/qid=1091947540/sr=8-2/ref=sr_8_xs_ap_i2_xgl14/104-8275811-3764727?v=glance&s=books&n=507846 Also see the following PHPTR link for TOC. http://vig.prenhall.com/catalog/academic/product/0,1144,013147023X-TOC,00.html -bsm.. B.S.Manoj, Project Officer, High Performance Computing and Networking Lab, CSE Dept., IIT Madras, India, Ph: +91-94441 69471 (Mobile). -------------------------------------------------------------------------- From nemo-bounces@ietf.org Tue Aug 10 05:23:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06141 for ; Tue, 10 Aug 2004 05:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuSnR-000544-F0; Tue, 10 Aug 2004 05:19:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuSkq-0004ZY-9N for nemo@megatron.ietf.org; Tue, 10 Aug 2004 05:17:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05797 for ; Tue, 10 Aug 2004 05:17:09 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuSpK-0008J1-LT for nemo@ietf.org; Tue, 10 Aug 2004 05:21:52 -0400 Received: from galibier.nautilus6.org (unknown [2001:200:0:8400:206:5bff:fe73:439f]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1C0115D09E for ; Tue, 10 Aug 2004 18:16:38 +0900 (JST) Date: Tue, 10 Aug 2004 18:16:33 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20040810181633.2a0f372a.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) 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] SD Slides X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, You can find all the SD meeting slides on your additional web site: http://www.mobilenetworks.org/nemo/ietf60/ Thierry. From nemo-bounces@ietf.org Tue Aug 10 23:17:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28604 for ; Tue, 10 Aug 2004 23:17:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bujan-0005CT-7O; Tue, 10 Aug 2004 23:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BujY4-0004d0-Uk for nemo@megatron.ietf.org; Tue, 10 Aug 2004 23:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28320 for ; Tue, 10 Aug 2004 23:13:06 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bujcj-00052E-4E for nemo@ietf.org; Tue, 10 Aug 2004 23:17:58 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id BE39C5D021; Wed, 11 Aug 2004 12:12:34 +0900 (JST) Date: Wed, 11 Aug 2004 12:10:10 +0900 (JST) Message-Id: <20040811.121010.122125539.watari@sfc.wide.ad.jp> To: Alexandru.Petrescu@motorola.com From: Masafumi Watari In-Reply-To: <410E41D6.5000100@motorola.com> References: <410E41D6.5000100@motorola.com> Organization: Keio University X-Mailer: Mew version 4.0.66 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, ryuji@sfc.wide.ad.jp Subject: [nemo] Re: Comments on ORC draft-wakikawa-nemo-orc-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Alex, On Mon, 02 Aug 2004 15:29:58 +0200, Alexandru Petrescu wrote: > > best effect routing protocol > > Effort. Right... > (actually, I don't think it is very precise to say that some routing > protocol is "best effort"; I guess one can say that IP routing in itself > happens in a best effort manner, in that nothing guarantees delivery of > fwded packets to the final destination - there's no ack. I think > routing protocols do have some means of acknowledging their exchanges > (e.g. BGP uses TCP), and in this sense they can't be qualified as best > effort. It is also true that a path taken by packets to a certain > destination is not necessarily the shortest possible, because of load > balancing and other traficcy shaping if I can say so, in which case I > think it's called simply "optimal", and this may better fit in your > context where paths are shorter if an ORC router is present and longer > otherwise. Closed parenthesis.) Yes, I think I understand what you mean. We can rephrase the word. > About ORC RO in nested aggregations of moving networks. > > The method with "reflective BU's" seem to make sense but immediately two > questions come to mind. It is said that sub-MR learns root-MR's CoA > from the RA's send by the latter to the former. But what about > sub-sub-MR's? Does the sub-MR re-transmit the root-MR's CoA it > receives, or does is it just transmitting its own CoA? How does an MR > _know_ of being a root-MR in fact? I didn't mention explicitly in the draft, but the sub-MRs should learn the CoA of the MR which it is attached to. By each MR doing the same operation, the CR and the MRs will eventually have all the bindings for the MNN. For the MR knowing whether being the root or not can be achieved with the tree discovery. > > The correspondent router then sends a binding update message to the > > root-MR for the network claimed by the correspondent router. > > Ok, so root-MR has some sort of a binding cache, right? This looks new? Yes. I'm hoping it would give a new thoughts. The good thing about this is that it does not require location management of the sub-MRs at the root-MR. Masafumi Watari From nemo-bounces@ietf.org Wed Aug 11 11:37:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13120 for ; Wed, 11 Aug 2004 11:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buv1h-0003Fk-36; Wed, 11 Aug 2004 11:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buuzj-0002sP-I0 for nemo@megatron.ietf.org; Wed, 11 Aug 2004 11:26:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12421 for ; Wed, 11 Aug 2004 11:26:23 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buv4R-0001Il-0Y for nemo@ietf.org; Wed, 11 Aug 2004 11:31:22 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7BFRGxl018083; Wed, 11 Aug 2004 08:27:16 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i7BFQI2e012446; Wed, 11 Aug 2004 10:26:18 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DA60488CF72; Wed, 11 Aug 2004 17:26:17 +0200 (CEST) Message-ID: <411A3A92.8020300@motorola.com> Date: Wed, 11 Aug 2004 17:26:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Re: Comments on ORC draft-wakikawa-nemo-orc-00.txt References: <410E41D6.5000100@motorola.com> <20040811.121010.122125539.watari@sfc.wide.ad.jp> In-Reply-To: <20040811.121010.122125539.watari@sfc.wide.ad.jp> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA7BF6EC0831EEFD2CFA309F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nemo@ietf.org, ryuji@sfc.wide.ad.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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEA7BF6EC0831EEFD2CFA309F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Masafumi Watari wrote: >> The method with "reflective BU's" seem to make sense but >> immediately two questions come to mind. It is said that sub-MR >> learns root-MR's CoA from the RA's send by the latter to the >> former. But what about sub-sub-MR's? Does the sub-MR re-transmit >> the root-MR's CoA it receives, or does is it just transmitting its >> own CoA? How does an MR _know_ of being a root-MR in fact? > > I didn't mention explicitly in the draft, but the sub-MRs should > learn the CoA of the MR which it is attached to. By each MR doing > the same operation, the CR and the MRs will eventually have all the > bindings for the MNN. I want to be sure the following is avoided. Assume a 3-level nested MR's and LFN deepest. LFN and its immediately above MR's would make CR believe what you say and route-optimize. But all communication would goes through TLMR's HA. >>> The correspondent router then sends a binding update message to >>> the root-MR for the network claimed by the correspondent router. >> >> Ok, so root-MR has some sort of a binding cache, right? This looks >> new? > > Yes. I'm hoping it would give a new thoughts. The good thing about > this is that it does not require location management of the sub-MRs > at the root-MR. CR sending BU's is just like CR being actually an MR, no? What is "location management"? Alex --------------enigEA7BF6EC0831EEFD2CFA309F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBGjqZMmC0w56zj54RAnT7AJ9X3gXXzA5toumqy2D5xLIxCDo9gACgkN0R ySxI6/FMyf6f7bLlH5pUpC4= =Qvqx -----END PGP SIGNATURE----- --------------enigEA7BF6EC0831EEFD2CFA309F-- From nemo-bounces@ietf.org Wed Aug 11 23:43:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12726 for ; Wed, 11 Aug 2004 23:43:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv6Tg-000723-0w; Wed, 11 Aug 2004 23:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv6OD-00060Q-5d for nemo@megatron.ietf.org; Wed, 11 Aug 2004 23:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12407 for ; Wed, 11 Aug 2004 23:36:26 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv6T4-0001r0-Nl for nemo@ietf.org; Wed, 11 Aug 2004 23:41:32 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2176F5D0A1; Thu, 12 Aug 2004 12:35:53 +0900 (JST) Date: Thu, 12 Aug 2004 12:33:25 +0900 (JST) Message-Id: <20040812.123325.52841290.watari@sfc.wide.ad.jp> To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] Re: Comments on ORC draft-wakikawa-nemo-orc-00.txt From: Masafumi Watari In-Reply-To: <411A3A92.8020300@motorola.com> References: <410E41D6.5000100@motorola.com> <20040811.121010.122125539.watari@sfc.wide.ad.jp> <411A3A92.8020300@motorola.com> Organization: Keio University X-Mailer: Mew version 4.0.66 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, ryuji@sfc.wide.ad.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 Content-Transfer-Encoding: 7bit Hello, On Wed, 11 Aug 2004 17:26:10 +0200, Alexandru Petrescu wrote: > Masafumi Watari wrote: > >> The method with "reflective BU's" seem to make sense but > >> immediately two questions come to mind. It is said that sub-MR > >> learns root-MR's CoA from the RA's send by the latter to the > >> former. But what about sub-sub-MR's? Does the sub-MR re-transmit > >> the root-MR's CoA it receives, or does is it just transmitting its > >> own CoA? How does an MR _know_ of being a root-MR in fact? > > > > I didn't mention explicitly in the draft, but the sub-MRs should > > learn the CoA of the MR which it is attached to. By each MR doing > > the same operation, the CR and the MRs will eventually have all the > > bindings for the MNN. > > I want to be sure the following is avoided. > > Assume a 3-level nested MR's and LFN deepest. LFN and its immediately > above MR's would make CR believe what you say and route-optimize. But > all communication would goes through TLMR's HA. Yes, this is avoided. It may go throught the root-MR's HA for a while, but eventually CR would have the binding for the sub-MR. I can be more clear on this, but since the ORC is focused on the notion of the CR, we may separte this part on the next version of our draft. > >>> The correspondent router then sends a binding update message to > >>> the root-MR for the network claimed by the correspondent router. > >> > >> Ok, so root-MR has some sort of a binding cache, right? This looks > >> new? > > > > Yes. I'm hoping it would give a new thoughts. The good thing about > > this is that it does not require location management of the sub-MRs > > at the root-MR. > > CR sending BU's is just like CR being actually an MR, no? Yes, correct, which allows route optimization between two distinct nests. > What is "location management"? I was refering to the case where management of some sort of status is required at MRs for the sub-MRs attached behind it. For some reason I thought it was well known term. Sorry. Regards, Masafumi Watari From nemo-bounces@ietf.org Fri Aug 13 16:31:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16324 for ; Fri, 13 Aug 2004 16:31:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvia3-0008Rq-Av; Fri, 13 Aug 2004 16:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BviNp-0001n1-DY for nemo@megatron.ietf.org; Fri, 13 Aug 2004 16:10:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14861 for ; Fri, 13 Aug 2004 16:10:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BviT2-0006yw-U0 for nemo@ietf.org; Fri, 13 Aug 2004 16:16:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7DK9kY12068 for ; Fri, 13 Aug 2004 13:09:46 -0700 X-mProtect: <200408132009> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnuIzFk; Fri, 13 Aug 2004 13:09:44 PDT Message-ID: <411D220D.9040507@iprg.nokia.com> Date: Fri, 13 Aug 2004 13:18:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [nemo] Including prefix information in BU in explicit mode X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi all, Pascal brought this issue up. In the explicit mode, can the MR avoid including prefix information in binding updates that just refresh an existing binding cache entry? a brief summary of the discussion is at http://people.nokia.net/vijayd/nemo/issue42.txt we have 2 options. 1. mandate that the MR include prefix information in every BU in explicit mode. the prefix information should only contain those prefixes for which the MR wants forwarding setup. 2. the MR can avoid including prefix information in the BU, if it is not updating the list of prefixes for which it needs forwarding setup at the HA. if it is updating (removing a prefix or adding a prefix), then it needs to include the prefix information in the BU. option 1) is simpler for the Home Agent, but option 2) saves bits over the air. comments are welcome. Vijay From nemo-bounces@ietf.org Sat Aug 14 02:47:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27587 for ; Sat, 14 Aug 2004 02:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvsI5-0006Tg-9Y; Sat, 14 Aug 2004 02:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvsGJ-00062F-Ke for nemo@megatron.ietf.org; Sat, 14 Aug 2004 02:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27410 for ; Sat, 14 Aug 2004 02:43:30 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvsLc-0007MR-Fd for nemo@ietf.org; Sat, 14 Aug 2004 02:49:02 -0400 Received: from [192.168.0.4] (70.184.210.220.dy.bbexcite.jp [220.210.184.70]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7E6dm4v022860; Sat, 14 Aug 2004 15:39:49 +0900 In-Reply-To: <411D220D.9040507@iprg.nokia.com> References: <411D220D.9040507@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F577998-EDBD-11D8-988A-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Including prefix information in BU in explicit mode Date: Sat, 14 Aug 2004 15:43:27 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Content-Transfer-Encoding: 7bit Hello Vijay I support option-1. If MR-HA want to save bits over the air, please simply use implicit mode :-) The problem of option-2 is when MR sends BU w/out prefix option, but HA already discards binding for the MR. In such case, HA does not have any prefix information for the MR and it returns BA with 143 status code. After MR receiving the BA, it'll try to register another HA. We can also say that R-bit cannot be set in BU when there is no mobile network prefix in explicit mode. As alex pointed out, HA always knows explicit or implicit by checking R bit and prefix options. regards, ryuji On 2004/08/14, at 5:18, Vijay Devarapalli wrote: > hi all, > > Pascal brought this issue up. > > In the explicit mode, can the MR avoid including prefix information > in binding updates that just refresh an existing binding cache entry? > > a brief summary of the discussion is at > http://people.nokia.net/vijayd/nemo/issue42.txt > > we have 2 options. > > 1. mandate that the MR include prefix information in every BU in > explicit mode. the prefix information should only contain those > prefixes for which the MR wants forwarding setup. > > 2. the MR can avoid including prefix information in the BU, if > it is not updating the list of prefixes for which it needs > forwarding setup at the HA. if it is updating (removing a prefix > or adding a prefix), then it needs to include the prefix > information in the BU. > > option 1) is simpler for the Home Agent, but option 2) saves bits > over the air. > > comments are welcome. > > Vijay From nemo-bounces@ietf.org Sun Aug 15 15:13:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14492 for ; Sun, 15 Aug 2004 15:13:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwQQ4-0002gU-Uh; Sun, 15 Aug 2004 15:11:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwQL8-0000VE-0j for nemo@megatron.ietf.org; Sun, 15 Aug 2004 15:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13863 for ; Sun, 15 Aug 2004 15:06:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwQQk-0000Wt-Te for nemo@ietf.org; Sun, 15 Aug 2004 15:12:36 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Aug 2004 21:14:47 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7FJ69uS021174; Sun, 15 Aug 2004 21:06:09 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 15 Aug 2004 21:06:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nemo] Including prefix information in BU in explicit mode Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 15 Aug 2004 21:05:50 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0A2904@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Including prefix information in BU in explicit mode Thread-Index: AcSBdL2fDURp5CxUT82Em/L74FBSQgBhhD4w From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 15 Aug 2004 19:06:08.0889 (UTC) FILETIME=[EC2AF690:01C482FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Content-Transfer-Encoding: quoted-printable If we go 2) I suggest we add a bit saying same as last. I prefer 1) :) > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Vijay Devarapalli > Sent: vendredi 13 ao=FBt 2004 22:18 > To: nemo@ietf.org > Subject: [nemo] Including prefix information in BU in explicit mode >=20 > hi all, >=20 > Pascal brought this issue up. >=20 > In the explicit mode, can the MR avoid including prefix information > in binding updates that just refresh an existing binding cache entry? >=20 > a brief summary of the discussion is at > http://people.nokia.net/vijayd/nemo/issue42.txt >=20 > we have 2 options. >=20 > 1. mandate that the MR include prefix information in every BU in > explicit mode. the prefix information should only contain those > prefixes for which the MR wants forwarding setup. >=20 > 2. the MR can avoid including prefix information in the BU, if > it is not updating the list of prefixes for which it needs > forwarding setup at the HA. if it is updating (removing a prefix > or adding a prefix), then it needs to include the prefix > information in the BU. >=20 > option 1) is simpler for the Home Agent, but option 2) saves bits > over the air. >=20 > comments are welcome. >=20 > Vijay From nemo-bounces@ietf.org Mon Aug 16 04:38:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18228 for ; Mon, 16 Aug 2004 04:38:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwcwN-0006LP-2z; Mon, 16 Aug 2004 04:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwcqh-0005Og-Ij for nemo@megatron.ietf.org; Mon, 16 Aug 2004 04:28:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17265 for ; Mon, 16 Aug 2004 04:28:09 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwcwH-0004YO-1O for nemo@ietf.org; Mon, 16 Aug 2004 04:34:08 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7G8RvWR016573 for ; Mon, 16 Aug 2004 10:27:57 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 10:27:57 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR20NS0Q; Mon, 16 Aug 2004 10:27:57 +0200 Message-ID: <4120700D.3040903@ericsson.com> Date: Mon, 16 Aug 2004 10:27:57 +0200 X-Sybari-Trust: 5278e13e 74470f8f f8f433dd 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Including prefix information in BU in explicit mode References: <411D220D.9040507@iprg.nokia.com> In-Reply-To: <411D220D.9040507@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2004 08:27:57.0774 (UTC) FILETIME=[EF4C3EE0:01C4836A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi all, > > we have 2 options. > > 1. mandate that the MR include prefix information in every BU in > explicit mode. the prefix information should only contain those > prefixes for which the MR wants forwarding setup. > > 2. the MR can avoid including prefix information in the BU, if > it is not updating the list of prefixes for which it needs > forwarding setup at the HA. if it is updating (removing a prefix > or adding a prefix), then it needs to include the prefix > information in the BU. > I prefer 1. /Mattias From nemo-bounces@ietf.org Mon Aug 16 14:13:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19518 for ; Mon, 16 Aug 2004 14:13:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwlti-00024Q-JB; Mon, 16 Aug 2004 14:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwld8-0007rz-Eq for nemo@megatron.ietf.org; Mon, 16 Aug 2004 13:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17756 for ; Mon, 16 Aug 2004 13:50:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwliw-0005Ti-KD for nemo@ietf.org; Mon, 16 Aug 2004 13:56:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7GHni131902; Mon, 16 Aug 2004 10:49:44 -0700 X-mProtect: <200408161749> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4yy8De; Mon, 16 Aug 2004 10:49:43 PDT Message-ID: <4120F5C6.3010204@iprg.nokia.com> Date: Mon, 16 Aug 2004 10:58:30 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Including prefix information in BU in explicit mode References: <411D220D.9040507@iprg.nokia.com> <3F577998-EDBD-11D8-988A-000D936735C4@sfc.wide.ad.jp> In-Reply-To: <3F577998-EDBD-11D8-988A-000D936735C4@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Content-Transfer-Encoding: 7bit Ryuji Ryuji Wakikawa wrote: > The problem of option-2 is when MR sends BU w/out prefix option, > but HA already discards binding for the MR. did the HA discard the binding cache entry because it expired or for some other reason? if it discarded the binding cache entry because it expired, then there isnt an issue. the MR also knows when the binding expires and includes the prefix information accordingly. Vijay > In such case, HA does not have any prefix information for the MR and > it returns BA with 143 status code. > After MR receiving the BA, it'll try to register another HA. > > We can also say that R-bit cannot be set in BU when there is no mobile > network prefix in explicit mode. > As alex pointed out, HA always knows explicit or implicit by checking R > bit and prefix options. > > regards, > ryuji > > On 2004/08/14, at 5:18, Vijay Devarapalli wrote: > >> hi all, >> >> Pascal brought this issue up. >> >> In the explicit mode, can the MR avoid including prefix information >> in binding updates that just refresh an existing binding cache entry? >> >> a brief summary of the discussion is at >> http://people.nokia.net/vijayd/nemo/issue42.txt >> >> we have 2 options. >> >> 1. mandate that the MR include prefix information in every BU in >> explicit mode. the prefix information should only contain those >> prefixes for which the MR wants forwarding setup. >> >> 2. the MR can avoid including prefix information in the BU, if >> it is not updating the list of prefixes for which it needs >> forwarding setup at the HA. if it is updating (removing a prefix >> or adding a prefix), then it needs to include the prefix >> information in the BU. >> >> option 1) is simpler for the Home Agent, but option 2) saves bits >> over the air. >> >> comments are welcome. >> >> Vijay > > From nemo-bounces@ietf.org Mon Aug 16 14:21:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20099 for ; Mon, 16 Aug 2004 14:21:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwluf-0002JB-4U; Mon, 16 Aug 2004 14:08:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlrJ-0001hs-Bv for nemo@megatron.ietf.org; Mon, 16 Aug 2004 14:05:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18882 for ; Mon, 16 Aug 2004 14:05:24 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwlx8-0005pz-7q for nemo@ietf.org; Mon, 16 Aug 2004 14:11:28 -0400 Received: from [203.178.128.195] (n128-195.sfc.wide.ad.jp [203.178.128.195]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7GI1V4v005693; Tue, 17 Aug 2004 03:01:31 +0900 In-Reply-To: <4120F5C6.3010204@iprg.nokia.com> References: <411D220D.9040507@iprg.nokia.com> <3F577998-EDBD-11D8-988A-000D936735C4@sfc.wide.ad.jp> <4120F5C6.3010204@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Including prefix information in BU in explicit mode Date: Tue, 17 Aug 2004 03:05:19 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Content-Transfer-Encoding: 7bit Hi Vijay On 2004/08/17, at 2:58, Vijay Devarapalli wrote: > Ryuji > > Ryuji Wakikawa wrote: > >> The problem of option-2 is when MR sends BU w/out prefix option, >> but HA already discards binding for the MR. > > did the HA discard the binding cache entry because it expired > or for some other reason? if it discarded the binding cache > entry because it expired, then there isnt an issue. the MR also > knows when the binding expires and includes the prefix > information accordingly. While operating MIP6/NEMO, I found the situation where HA discards BC before MR successfully updating BC. For example, when a BU sent by MR is dropped due to network trouble, MR retries to send another BU. However, it's possibly happened that the lifetime of BC is expired before the second BU. It is totally up to timing between HA's BC lifetime and BU arrival time. In MIP and NEMO, it's fine, because HA re-creates BC right after receiving the second BU. If we go with option-2, HA can not create BC due to lack of prefix information. Although HA may keep prefix information for a while after removing BC, I don't think we should bring these new status for option-2. ryuji From nemo-bounces@ietf.org Mon Aug 16 14:27:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20382 for ; Mon, 16 Aug 2004 14:27:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwm75-0004hZ-Js; Mon, 16 Aug 2004 14:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwlyn-0003BH-V7 for nemo@megatron.ietf.org; Mon, 16 Aug 2004 14:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19536 for ; Mon, 16 Aug 2004 14:13:08 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwm4e-00061l-CT for nemo@ietf.org; Mon, 16 Aug 2004 14:19:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7GICBk11564; Mon, 16 Aug 2004 11:12:11 -0700 X-mProtect: <200408161812> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1f4T5c; Mon, 16 Aug 2004 11:12:09 PDT Message-ID: <4120FB13.5020606@iprg.nokia.com> Date: Mon, 16 Aug 2004 11:21:07 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Including prefix information in BU in explicit mode References: <411D220D.9040507@iprg.nokia.com> <3F577998-EDBD-11D8-988A-000D936735C4@sfc.wide.ad.jp> <4120F5C6.3010204@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Content-Transfer-Encoding: 7bit you are right. this could lead to the MR trying another HA. Vijay Ryuji Wakikawa wrote: > Hi Vijay > > On 2004/08/17, at 2:58, Vijay Devarapalli wrote: > >> Ryuji >> >> Ryuji Wakikawa wrote: >> >>> The problem of option-2 is when MR sends BU w/out prefix option, >>> but HA already discards binding for the MR. >> >> >> did the HA discard the binding cache entry because it expired >> or for some other reason? if it discarded the binding cache >> entry because it expired, then there isnt an issue. the MR also >> knows when the binding expires and includes the prefix >> information accordingly. > > > While operating MIP6/NEMO, I found the situation where HA > discards BC before MR successfully updating BC. > For example, when a BU sent by MR is dropped due to network trouble, > MR retries to send another BU. However, it's possibly happened that > the lifetime of BC is expired before the second BU. > It is totally up to timing between HA's BC lifetime and BU arrival time. > > In MIP and NEMO, it's fine, because HA re-creates BC right after > receiving the second BU. > > If we go with option-2, HA can not create BC due to lack of prefix > information. > Although HA may keep prefix information for a while after removing BC, > I don't think we should bring these new status for option-2. > > ryuji > > From nemo-bounces@ietf.org Mon Aug 16 14:43:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21386 for ; Mon, 16 Aug 2004 14:43:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmJw-0006de-8G; Mon, 16 Aug 2004 14:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmEQ-0005pb-8B for nemo@megatron.ietf.org; Mon, 16 Aug 2004 14:29:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20480 for ; Mon, 16 Aug 2004 14:29:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwmKF-0006LI-RZ for nemo@ietf.org; Mon, 16 Aug 2004 14:35:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7GISKS00639; Mon, 16 Aug 2004 11:28:20 -0700 X-mProtect: <200408161828> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIU6tRa; Mon, 16 Aug 2004 11:28:17 PDT Message-ID: <4120FEC7.4060805@iprg.nokia.com> Date: Mon, 16 Aug 2004 11:36:55 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Issue 42 (was Re: [nemo] Including prefix information in BU in explicit mode) References: <411D220D.9040507@iprg.nokia.com> In-Reply-To: <411D220D.9040507@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Content-Transfer-Encoding: 7bit hi all, looks like there is concensus for option 1). I think we should add some text to clarify this. here is a suggestion. add the following to the end of section 5.2 In explicit mode, the Mobile Router MUST include prefix information in all binding updates, including those sent to refresh existing binding cache entres, if it wants forwarding enabled for the corresponding Mobile Network Prefixes. comments are welcome. Vijay Vijay Devarapalli wrote: > hi all, > > Pascal brought this issue up. > > In the explicit mode, can the MR avoid including prefix information > in binding updates that just refresh an existing binding cache entry? > > a brief summary of the discussion is at > http://people.nokia.net/vijayd/nemo/issue42.txt > > we have 2 options. > > 1. mandate that the MR include prefix information in every BU in > explicit mode. the prefix information should only contain those > prefixes for which the MR wants forwarding setup. > > 2. the MR can avoid including prefix information in the BU, if > it is not updating the list of prefixes for which it needs > forwarding setup at the HA. if it is updating (removing a prefix > or adding a prefix), then it needs to include the prefix > information in the BU. > > option 1) is simpler for the Home Agent, but option 2) saves bits > over the air. > > comments are welcome. > > Vijay > From nemo-bounces@ietf.org Mon Aug 16 15:04:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22824 for ; Mon, 16 Aug 2004 15:04:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwmfy-00023w-Sh; Mon, 16 Aug 2004 14:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmYW-0000NB-9L for nemo@megatron.ietf.org; Mon, 16 Aug 2004 14:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21747 for ; Mon, 16 Aug 2004 14:50:02 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwmeM-0006kv-IK for nemo@ietf.org; Mon, 16 Aug 2004 14:56:07 -0400 Received: from [203.178.128.195] (n128-195.sfc.wide.ad.jp [203.178.128.195]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7GIkB4v006331; Tue, 17 Aug 2004 03:46:11 +0900 In-Reply-To: <4120FEC7.4060805@iprg.nokia.com> References: <411D220D.9040507@iprg.nokia.com> <4120FEC7.4060805@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13B9DA1B-EFB5-11D8-93AD-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU in explicit mode) Date: Tue, 17 Aug 2004 03:50:00 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Content-Transfer-Encoding: 7bit Vijay We can also add MUST in section 5.2. Explicit: In this mode, the Mobile Router "MUST" include one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the mobile network. ryuji On 2004/08/17, at 3:36, Vijay Devarapalli wrote: > hi all, > > looks like there is concensus for option 1). > > I think we should add some text to clarify this. here is a suggestion. > add the following to the end of section 5.2 > > In explicit mode, the Mobile Router MUST include > prefix information in all binding updates, including those sent to > refresh existing binding cache entres, if it wants forwarding > enabled > for the corresponding Mobile Network Prefixes. > > comments are welcome. > > Vijay > > Vijay Devarapalli wrote: >> hi all, >> Pascal brought this issue up. >> In the explicit mode, can the MR avoid including prefix information >> in binding updates that just refresh an existing binding cache entry? >> a brief summary of the discussion is at >> http://people.nokia.net/vijayd/nemo/issue42.txt >> we have 2 options. >> 1. mandate that the MR include prefix information in every BU in >> explicit mode. the prefix information should only contain those >> prefixes for which the MR wants forwarding setup. >> 2. the MR can avoid including prefix information in the BU, if >> it is not updating the list of prefixes for which it needs >> forwarding setup at the HA. if it is updating (removing a prefix >> or adding a prefix), then it needs to include the prefix >> information in the BU. >> option 1) is simpler for the Home Agent, but option 2) saves bits >> over the air. >> comments are welcome. >> Vijay > From nemo-bounces@ietf.org Mon Aug 16 15:14:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23983 for ; Mon, 16 Aug 2004 15:14:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmpZ-0001Wx-0R; Mon, 16 Aug 2004 15:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmmD-0007Tn-EP for nemo@megatron.ietf.org; Mon, 16 Aug 2004 15:04:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22845 for ; Mon, 16 Aug 2004 15:04:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwms3-00071o-1r for nemo@ietf.org; Mon, 16 Aug 2004 15:10:16 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7GJ3Dm19706; Mon, 16 Aug 2004 12:03:13 -0700 X-mProtect: <200408161903> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrNDIXz; Mon, 16 Aug 2004 12:03:10 PDT Message-ID: <41210708.2080801@iprg.nokia.com> Date: Mon, 16 Aug 2004 12:12:08 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU in explicit mode) References: <411D220D.9040507@iprg.nokia.com> <4120FEC7.4060805@iprg.nokia.com> <13B9DA1B-EFB5-11D8-93AD-000D936735C4@sfc.wide.ad.jp> In-Reply-To: <13B9DA1B-EFB5-11D8-93AD-000D936735C4@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Content-Transfer-Encoding: 7bit Ryuji, I think we can avoid the additional "MUST". this MUST does not increase interoperability. > We can also add MUST in section 5.2. > > Explicit: > > In this mode, the Mobile Router "MUST" include one or more Mobile > Network Prefix Options in the Binding Update. These options > contain information about the Mobile Network Prefix(es) > configured on the mobile network. Vijay From nemo-bounces@ietf.org Tue Aug 17 03:22:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27043 for ; Tue, 17 Aug 2004 03:22:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwyG5-0000i7-R9; Tue, 17 Aug 2004 03:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwyF9-0000ae-61 for nemo@megatron.ietf.org; Tue, 17 Aug 2004 03:18:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26918 for ; Tue, 17 Aug 2004 03:18:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwyL5-00063S-OG for nemo@ietf.org; Tue, 17 Aug 2004 03:25:01 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2004 09:27:21 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7H7I9uY008061; Tue, 17 Aug 2004 09:18:14 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Aug 2004 09:11:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Date: Tue, 17 Aug 2004 09:16:57 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0A2B4C@xmb-ams-337.emea.cisco.com> Thread-Topic: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Thread-Index: AcSDxYlN0RUHGteASi2yYny9ExElqwAZDkSQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Ryuji Wakikawa" X-OriginalArrivalTime: 17 Aug 2004 07:11:37.0343 (UTC) FILETIME=[6F8FB0F0:01C48429] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Content-Transfer-Encoding: quoted-printable If the MR has no prefix it can not add them. It needs to learn them. I'm = not sure we ever said that explicit excluded implicit; If the HA has = some prefixes for the MR, it can install them (e.g. static routes). If = the MR claims others, then the HA can install them too. When the MR = stops claiming prefixes it claimed before in explicit mode (HA knows = because of prefix list) then the HA removes the forwarding states for = those prefixes only.=20 What do you think? > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Vijay Devarapalli > Sent: lundi 16 ao=FBt 2004 21:12 > To: Ryuji Wakikawa > Cc: nemo@ietf.org > Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in = BU inexplicit mode) >=20 > Ryuji, >=20 > I think we can avoid the additional "MUST". this MUST does not > increase interoperability. >=20 > > We can also add MUST in section 5.2. > > > > Explicit: > > > > In this mode, the Mobile Router "MUST" include one or more = Mobile > > Network Prefix Options in the Binding Update. These = options > > contain information about the Mobile Network Prefix(es) > > configured on the mobile network. >=20 > Vijay From nemo-bounces@ietf.org Tue Aug 17 05:02:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02147 for ; Tue, 17 Aug 2004 05:02:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwzo6-0007v7-Eb; Tue, 17 Aug 2004 04:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwzl1-0007PB-I6 for nemo@megatron.ietf.org; Tue, 17 Aug 2004 04:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01773 for ; Tue, 17 Aug 2004 04:55:49 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwzqo-0007sL-Pk for nemo@ietf.org; Tue, 17 Aug 2004 05:02:02 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7H8tclU009978 for ; Tue, 17 Aug 2004 10:55:38 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 10:55:38 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZMC2NK3; Tue, 17 Aug 2004 10:55:38 +0200 Message-ID: <4121C809.4060107@ericsson.com> Date: Tue, 17 Aug 2004 10:55:37 +0200 X-Sybari-Trust: 47e7ff92 74470f8f e35fb442 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) References: <7892795E1A87F04CADFCCF41FADD00FC0A2B4C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0A2B4C@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2004 08:55:38.0045 (UTC) FILETIME=[F74F3ED0:01C48437] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit It is important that the HA and the MR has exactly the same perception on what prefixes are in use and what their respective registration lifetimes are. IMHO I think it may be dangerous to mix explicit and implicit like you describe below. Do you think it will add functionality? /Mattias Pascal Thubert (pthubert) wrote: > If the MR has no prefix it can not add them. It needs to learn them. I'm not sure we ever said that explicit excluded implicit; If the HA has some prefixes for the MR, it can install them (e.g. static routes). If the MR claims others, then the HA can install them too. When the MR stops claiming prefixes it claimed before in explicit mode (HA knows because of prefix list) then the HA removes the forwarding states for those prefixes only. > > What do you think? > > From nemo-bounces@ietf.org Tue Aug 17 05:46:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04287 for ; Tue, 17 Aug 2004 05:46:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx0UH-0006Lz-MW; Tue, 17 Aug 2004 05:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx0O2-0005nK-Rz for nemo@megatron.ietf.org; Tue, 17 Aug 2004 05:36:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03773 for ; Tue, 17 Aug 2004 05:36:08 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx0U0-00006J-PD for nemo@ietf.org; Tue, 17 Aug 2004 05:42:22 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i7H9a85x008105; Tue, 17 Aug 2004 02:36:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7H9SLQ1014725; Tue, 17 Aug 2004 04:28:21 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 728848A3A71; Tue, 17 Aug 2004 11:36:05 +0200 (CEST) Message-ID: <4121D17F.3070308@motorola.com> Date: Tue, 17 Aug 2004 11:35:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU in explicit mode) References: <411D220D.9040507@iprg.nokia.com> <4120FEC7.4060805@iprg.nokia.com> In-Reply-To: <4120FEC7.4060805@iprg.nokia.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D3670E5C7497C2AFDDC68BA" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D3670E5C7497C2AFDDC68BA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi all, > > looks like there is concensus for option 1). > > I think we should add some text to clarify this. here is a > suggestion. add the following to the end of section 5.2 > > In explicit mode, the Mobile Router MUST include prefix information > in all binding updates, including those sent to refresh existing > binding cache entres, if it wants forwarding enabled for the > corresponding Mobile Network Prefixes. Yes, I agree with option 1 and with this text at the end of section 5.2. note "entres" to "entries", capitalized BU's, etc... Alex --------------enig5D3670E5C7497C2AFDDC68BA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBIdGFMmC0w56zj54RAhS1AKCSVFONXbits5bg+REDjuBvKzVmkwCeOrXf CHicQ2w6wo8hLMz+iA3p+dw= =uJgc -----END PGP SIGNATURE----- --------------enig5D3670E5C7497C2AFDDC68BA-- From nemo-bounces@ietf.org Tue Aug 17 06:26:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05768 for ; Tue, 17 Aug 2004 06:26:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx18l-00062d-Jg; Tue, 17 Aug 2004 06:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx17q-0005nI-Qt for nemo@megatron.ietf.org; Tue, 17 Aug 2004 06:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05672 for ; Tue, 17 Aug 2004 06:23:28 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx1Dp-0000oe-PP for nemo@ietf.org; Tue, 17 Aug 2004 06:29:42 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7HANSAh014278 for ; Tue, 17 Aug 2004 12:23:28 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 12:23:28 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZMCJKAJ; Tue, 17 Aug 2004 12:23:28 +0200 Message-ID: <4121DC9F.9020402@ericsson.com> Date: Tue, 17 Aug 2004 12:23:27 +0200 X-Sybari-Trust: a0a7fde5 74470f8f e35fb442 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mattias Pettersson L (KI/EAB)" Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) References: 47e7ff92 74470f8f e35fb442 00000138 <4121C809.4060107@ericsson.com> In-Reply-To: <4121C809.4060107@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2004 10:23:28.0549 (UTC) FILETIME=[3CC65550:01C48444] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit An addition: I had a closer look at the basic support spec. I'm a bit curious how an MR can register and deregister multiple MNPs independently of each other. Is there ever a possibility that the MR can be registered with MNP1 and MNP2 and at some point chose to deregister MNP1, while keeping MNP2? Does MR send a BU with lifetime=0 and a prefix option with MNP1? Or does it have to first deregister all (set lifetime=0) and then make a fresh registration with MNP2 only? Section 6.2. (see below) is a bit ambiguous about this. It says the deregistration _only affects_ the specified MNPs (but it says that the binding for the HoA should be removed). Last sentence of Section 6.7. (see below) on the other hand says that HA will ignore _all_ MNP options (in explicit mode - but that's the only time they are used, isn't it?). In addition to what I said in my quoted mail below about MR and HA being in complete agreement of what MNPs are bound, I think it is very useful to have a mechanism for registering and deregistering MNPs for MR independently. Option 1: In each BU, only the specified MNPs will be kept in the binding cache in the HA after a successful registration. All other MNPs not specified will be removed. In my example, MR would go from registering {MNP1, MNP2} to registering {MNP2} only. The binding for MNP1 will be removed immediately. Option 2: In a BU, the HA only updates the specified MNPs. This implicitly means that each MNP will have a lifetime. In my example, MR would go from registering {MNP1, MNP2} to registering {MNP2} only. To handle a quick transition, MR would also have to deregister MNP1 explicitly, by sending a BU with lifetime=0 and MNP1 as the only prefix option. Does anyone else see the need for this? From Vijay's initial discussion, it seems so. From Section 6.2: > If the Lifetime specified in the Binding Update is zero or the > specified Care-of address matches the Home Address in the Binding > Update, then this is a request to delete the cached binding for > the home address and specified Mobile Network Prefixes. The > Binding Update is processed according to the procedure described in > Section 6.7. > 6.7. Mobile Network Prefix De-Registration > > The Mobile Router de-registers with the Home Agent by sending a > Binding Update with the lifetime set to zero. When the Home Agent > successfully processes the de-registration BU, it deletes the Binding > Cache Entry for the Mobile Router's Home Address and stops proxying > the Home Address. This is described in detail in the Mobile IPv6 > specification [1]. > > In addition, the Home Agent also removes the bi-directional tunnel > and stops forwarding packets to the mobile network. The Home Agent > should keep all necessary information to clean up whichever routes it > installed, whether they come from implicit or explicit source. > In Explicit mode, the Home Agent MUST ignore any Mobile Network > Prefix Options present in the de-registration Binding Update. In addition, Section 6.2. allows the MR to indicate deregistration by either setting lifetime=0 or set CoA=HoA. Section 6.7. only accepts lifetime=0. /Mattias Mattias Pettersson L (KI/EAB) wrote: > It is important that the HA and the MR has exactly the same perception > on what prefixes are in use and what their respective registration > lifetimes are. > > IMHO I think it may be dangerous to mix explicit and implicit like you > describe below. Do you think it will add functionality? > > /Mattias > > Pascal Thubert (pthubert) wrote: > >>If the MR has no prefix it can not add them. It needs to learn them. > > I'm not sure we ever said that explicit excluded implicit; If the HA has > some prefixes for the MR, it can install them (e.g. static routes). If > the MR claims others, then the HA can install them too. When the MR > stops claiming prefixes it claimed before in explicit mode (HA knows > because of prefix list) then the HA removes the forwarding states for > those prefixes only. > >>What do you think? >> >> > > From nemo-bounces@ietf.org Tue Aug 17 06:51:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06772 for ; Tue, 17 Aug 2004 06:51:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx1UD-00015i-Dy; Tue, 17 Aug 2004 06:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx1Sb-0000tl-81 for nemo@megatron.ietf.org; Tue, 17 Aug 2004 06:44:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06528 for ; Tue, 17 Aug 2004 06:44:54 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx1Ya-00015s-Bn for nemo@ietf.org; Tue, 17 Aug 2004 06:51:08 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 92B543A120; Tue, 17 Aug 2004 12:44:24 +0200 (CEST) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id 6FF913A11F; Tue, 17 Aug 2004 12:44:24 +0200 (CEST) Received: from violin.it.uc3m.es (violin.it.uc3m.es [163.117.139.250]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id MAA08896; Tue, 17 Aug 2004 12:44:24 +0200 Received: (from cjbc@localhost) by violin.it.uc3m.es (8.9.3p2/8.9.3/Debian 8.9.3-21) id MAA02017; Tue, 17 Aug 2004 12:44:24 +0200 Date: Tue, 17 Aug 2004 12:44:23 +0200 From: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= To: Mattias Pettersson Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) Message-ID: <20040817124423.B29411@violin.it.uc3m.es> References: <4121C809.4060107@ericsson.com> <4121DC9F.9020402@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4121DC9F.9020402@ericsson.com>; from mattias.l.pettersson@ericsson.com on Tue, Aug 17, 2004 at 12:23:27PM +0200 X-Editor: Vim 5.6 X-Operating-System: Linux violin.it.uc3m.es 2.6.7 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi all, Mattias Pettersson escribi=F3, el 2004-08-17 12:23:27: > An addition: >=20 > I had a closer look at the basic support spec. I'm a bit curious how an= =20 > MR can register and deregister multiple MNPs independently of each othe= r. >=20 > Is there ever a possibility that the MR can be registered with MNP1 and= =20 > MNP2 and at some point chose to deregister MNP1, while keeping MNP2?=20 > Does MR send a BU with lifetime=3D0 and a prefix option with MNP1? Or d= oes=20 > it have to first deregister all (set lifetime=3D0) and then make a fres= h=20 > registration with MNP2 only? >=20 > Section 6.2. (see below) is a bit ambiguous about this. It says the=20 > deregistration _only affects_ the specified MNPs (but it says that the=20 > binding for the HoA should be removed). >=20 > Last sentence of Section 6.7. (see below) on the other hand says that H= A=20 > will ignore _all_ MNP options (in explicit mode - but that's the only=20 > time they are used, isn't it?). >=20 > In addition to what I said in my quoted mail below about MR and HA bein= g=20 > in complete agreement of what MNPs are bound, I think it is very useful= =20 > to have a mechanism for registering and deregistering MNPs for MR=20 > independently. >=20 > Option 1: > In each BU, only the specified MNPs will be kept in the binding cache i= n=20 > the HA after a successful registration. All other MNPs not specified=20 > will be removed. In my example, MR would go from registering {MNP1,=20 > MNP2} to registering {MNP2} only. The binding for MNP1 will be removed=20 > immediately. >=20 > Option 2: > In a BU, the HA only updates the specified MNPs. This implicitly means=20 > that each MNP will have a lifetime. In my example, MR would go from=20 > registering {MNP1, MNP2} to registering {MNP2} only. To handle a quick=20 > transition, MR would also have to deregister MNP1 explicitly, by sendin= g=20 > a BU with lifetime=3D0 and MNP1 as the only prefix option. >=20 > Does anyone else see the need for this? From Vijay's initial discussion= ,=20 > it seems so. Yes, I also see the need for this, and I prefer Option 1 (more bits over the air, but less state is needed in the HA). C. J. >=20 > From Section 6.2: > > If the Lifetime specified in the Binding Update is zero or the > > specified Care-of address matches the Home Address in the Binding > > Update, then this is a request to delete the cached binding for > > the home address and specified Mobile Network Prefixes. The > > Binding Update is processed according to the procedure described i= n > > Section 6.7. >=20 >=20 > > 6.7. Mobile Network Prefix De-Registration > >=20 > > The Mobile Router de-registers with the Home Agent by sending a > > Binding Update with the lifetime set to zero. When the Home Agent > > successfully processes the de-registration BU, it deletes the Bind= ing > > Cache Entry for the Mobile Router's Home Address and stops proxyin= g > > the Home Address. This is described in detail in the Mobile IPv6 > > specification [1]. > >=20 > > In addition, the Home Agent also removes the bi-directional tunnel > > and stops forwarding packets to the mobile network. The Home Agen= t > > should keep all necessary information to clean up whichever routes= it > > installed, whether they come from implicit or explicit source. > > In Explicit mode, the Home Agent MUST ignore any Mobile Network > > Prefix Options present in the de-registration Binding Update. >=20 > In addition, Section 6.2. allows the MR to indicate deregistration by=20 > either setting lifetime=3D0 or set CoA=3DHoA. Section 6.7. only accepts= =20 > lifetime=3D0. >=20 > /Mattias >=20 >=20 > Mattias Pettersson L (KI/EAB) wrote: > > It is important that the HA and the MR has exactly the same perceptio= n=20 > > on what prefixes are in use and what their respective registration=20 > > lifetimes are. > >=20 > > IMHO I think it may be dangerous to mix explicit and implicit like yo= u=20 > > describe below. Do you think it will add functionality? > >=20 > > /Mattias > >=20 > > Pascal Thubert (pthubert) wrote: > >=20 > >>If the MR has no prefix it can not add them. It needs to learn them. > >=20 > > I'm not sure we ever said that explicit excluded implicit; If the HA = has > > some prefixes for the MR, it can install them (e.g. static routes). I= f > > the MR claims others, then the HA can install them too. When the MR > > stops claiming prefixes it claimed before in explicit mode (HA knows > > because of prefix list) then the HA removes the forwarding states for > > those prefixes only.=20 > >=20 > >>What do you think? > >> > >> > >=20 > >=20 >=20 From nemo-bounces@ietf.org Tue Aug 17 10:18:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18213 for ; Tue, 17 Aug 2004 10:18:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4jJ-0002Rz-4J; Tue, 17 Aug 2004 10:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4fM-0000sF-Jj for nemo@megatron.ietf.org; Tue, 17 Aug 2004 10:10:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17234 for ; Tue, 17 Aug 2004 10:10:18 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4lA-0004jV-Kr for nemo@ietf.org; Tue, 17 Aug 2004 10:16:34 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7HEA5WR001997 for ; Tue, 17 Aug 2004 16:10:05 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 16:10:05 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6GYZ2F6; Tue, 17 Aug 2004 16:10:05 +0200 Message-ID: <412211BD.1080206@ericsson.com> Date: Tue, 17 Aug 2004 16:10:05 +0200 X-Sybari-Trust: 9487f2b6 477d8de1 d065362c 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nemo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2004 14:10:05.0582 (UTC) FILETIME=[E53CEAE0:01C48463] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [nemo] draft-ietf-nemo-multihoming-issues-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Authors of draft-ietf-nemo-multihoming-issues-00, Just a remark, I think it is important to point out that Appendix B is only applicable to (*,*,n) (or even n,n,n?) cases. It is said in Section 4.3 which refers to Appendix B, but I figure it should be explicitly stated in B itself. Thanks. /Mattias From nemo-bounces@ietf.org Wed Aug 18 01:13:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11217 for ; Wed, 18 Aug 2004 01:13:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxIjG-0004xz-2R; Wed, 18 Aug 2004 01:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxIhr-0004E6-7V for nemo@megatron.ietf.org; Wed, 18 Aug 2004 01:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11040 for ; Wed, 18 Aug 2004 01:09:50 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxInz-0004d6-8w for nemo@ietf.org; Wed, 18 Aug 2004 01:16:13 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i7I56qam010863; Wed, 18 Aug 2004 13:06:53 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 99E96B237D6; Wed, 18 Aug 2004 13:15:10 +0800 (SGT) Subject: Re: [nemo] draft-ietf-nemo-multihoming-issues-00 From: Chan-Wah Ng To: Mattias Pettersson In-Reply-To: <412211BD.1080206@ericsson.com> References: <412211BD.1080206@ericsson.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1092806109.32760.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 18 Aug 2004 13:15:09 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Content-Transfer-Encoding: 7bit Hello, Mattias On Tue, 2004-08-17 at 22:10, Mattias Pettersson wrote: > Authors of draft-ietf-nemo-multihoming-issues-00, > > Just a remark, I think it is important to point out that Appendix B is > only applicable to (*,*,n) (or even n,n,n?) cases. It is said in Section > 4.3 which refers to Appendix B, but I figure it should be explicitly > stated in B itself. Noted. Thank you. /rgds /cwng From nemo-bounces@ietf.org Wed Aug 18 08:21:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00994 for ; Wed, 18 Aug 2004 08:21:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxPMS-00041W-4Q; Wed, 18 Aug 2004 08:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxPHA-0003CV-Oy for nemo@megatron.ietf.org; Wed, 18 Aug 2004 08:10:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00604 for ; Wed, 18 Aug 2004 08:10:43 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxPNN-0003ca-N5 for nemo@ietf.org; Wed, 18 Aug 2004 08:17:10 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i7ICAeGN003708; Wed, 18 Aug 2004 05:10:40 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7ICAMqw023421; Wed, 18 Aug 2004 07:10:23 -0500 Message-ID: <41234736.3070303@motorola.com> Date: Wed, 18 Aug 2004 14:10:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) References: 47e7ff92 74470f8f e35fb442 00000138 <4121C809.4060107@ericsson.com> <4121DC9F.9020402@ericsson.com> In-Reply-To: <4121DC9F.9020402@ericsson.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8DF2E4DA0316264B4EA2827A" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8DF2E4DA0316264B4EA2827A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > An addition: > > I had a closer look at the basic support spec. I'm a bit curious how > an MR can register and deregister multiple MNPs independently of each > other. I think it's not specified and there are many ways in which one could implement the synchronization between MR's MNP's in its BU list and HA's MNP's of this HoA in its BC. > Is there ever a possibility that the MR can be registered with MNP1 > and MNP2 and at some point chose to deregister MNP1, while keeping > MNP2? Does MR send a BU with lifetime=0 and a prefix option with > MNP1? Or does it have to first deregister all (set lifetime=0) and > then make a fresh registration with MNP2 only? > > Section 6.2. (see below) is a bit ambiguous about this. It says the > deregistration _only affects_ the specified MNPs (but it says that > the binding for the HoA should be removed). > > Last sentence of Section 6.7. (see below) on the other hand says that > HA will ignore _all_ MNP options (in explicit mode - but that's the > only time they are used, isn't it?). > > In addition to what I said in my quoted mail below about MR and HA > being in complete agreement of what MNPs are bound, I think it is > very useful to have a mechanism for registering and deregistering > MNPs for MR independently. > > Option 1: In each BU, only the specified MNPs will be kept in the > binding cache in the HA after a successful registration. All other > MNPs not specified will be removed. In my example, MR would go from > registering {MNP1, MNP2} to registering {MNP2} only. The binding for > MNP1 will be removed immediately. > > Option 2: In a BU, the HA only updates the specified MNPs. This > implicitly means that each MNP will have a lifetime. In my example, > MR would go from registering {MNP1, MNP2} to registering {MNP2} only. > To handle a quick transition, MR would also have to deregister MNP1 > explicitly, by sending a BU with lifetime=0 and MNP1 as the only > prefix option. > > Does anyone else see the need for this? From Vijay's initial > discussion, it seems so. Indeed, there may be many ways in which MR may update its MNP's to the HA. Option 2 would require a new lifetime field for each MNP, thus leaving me to prefer option 1. Additionally, I think there may be other ways in which this can be done, an Option 3 would require only one MNP per BU, easier to implement and manage consistently. Finally, a simpler and cleaner way is to use NEMO implicit mode and let OSPF manage these prefixes. Alex --------------enig8DF2E4DA0316264B4EA2827A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBI0c7MmC0w56zj54RAt3UAKC1TDybgea2dv/K+rC7rPmzLVfq8ACdH/yO I4cPbZEOaSUdJ132kuRYsbY= =FQj1 -----END PGP SIGNATURE----- --------------enig8DF2E4DA0316264B4EA2827A-- From nemo-bounces@ietf.org Wed Aug 18 22:10:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07893 for ; Wed, 18 Aug 2004 22:10:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxcJl-0001xQ-7r; Wed, 18 Aug 2004 22:06:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxcGL-0001FI-GM for nemo@megatron.ietf.org; Wed, 18 Aug 2004 22:02:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07501 for ; Wed, 18 Aug 2004 22:02:43 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxcMg-00086f-4n for nemo@ietf.org; Wed, 18 Aug 2004 22:09:18 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7J21Vk25879; Wed, 18 Aug 2004 19:01:31 -0700 X-mProtect: <200408190201> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6KOwv2; Wed, 18 Aug 2004 19:01:29 PDT Message-ID: <41240C1A.5040904@iprg.nokia.com> Date: Wed, 18 Aug 2004 19:10:34 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) References: 47e7ff92 74470f8f e35fb442 00000138 <4121C809.4060107@ericsson.com> <4121DC9F.9020402@ericsson.com> In-Reply-To: <4121DC9F.9020402@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > An addition: > Option 1: > In each BU, only the specified MNPs will be kept in the binding cache in > the HA after a successful registration. All other MNPs not specified > will be removed. In my example, MR would go from registering {MNP1, > MNP2} to registering {MNP2} only. The binding for MNP1 will be removed > immediately. > > Option 2: > In a BU, the HA only updates the specified MNPs. This implicitly means > that each MNP will have a lifetime. In my example, MR would go from > registering {MNP1, MNP2} to registering {MNP2} only. To handle a quick > transition, MR would also have to deregister MNP1 explicitly, by sending > a BU with lifetime=0 and MNP1 as the only prefix option. > > Does anyone else see the need for this? From Vijay's initial discussion, > it seems so. I agree there is a need for clarification. I prefer option 1. here is some text If the Home Agent has a valid binding cache entry for the Mobile Router, it should compare the list of prefixes in the Binding Update against the prefixes stored in the binding cache entry. If the binding cache entry contains prefixes that do not appear in the Binding Update, the Home Agent MUST disable forwarding for these Mobile Network Prefixes. I was thinking of adding this to section 6.2. please see http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre04.txt it can also be added to section 6.7, instead. let me know. however, I am not sure this change is minor enough to be done during AUTH48 stage. otherwise we may have to drop this. WG chairs? > In addition, Section 6.2. allows the MR to indicate deregistration by > either setting lifetime=0 or set CoA=HoA. Section 6.7. only accepts > lifetime=0. I just deleted the first sentence in section 6.7. Vijay > > /Mattias > > > Mattias Pettersson L (KI/EAB) wrote: > >> It is important that the HA and the MR has exactly the same perception >> on what prefixes are in use and what their respective registration >> lifetimes are. >> >> IMHO I think it may be dangerous to mix explicit and implicit like you >> describe below. Do you think it will add functionality? >> >> /Mattias >> >> Pascal Thubert (pthubert) wrote: >> >>> If the MR has no prefix it can not add them. It needs to learn them. >> >> >> I'm not sure we ever said that explicit excluded implicit; If the HA has >> some prefixes for the MR, it can install them (e.g. static routes). If >> the MR claims others, then the HA can install them too. When the MR >> stops claiming prefixes it claimed before in explicit mode (HA knows >> because of prefix list) then the HA removes the forwarding states for >> those prefixes only. >> >>> What do you think? >>> >>> >> >> > From nemo-bounces@ietf.org Thu Aug 19 06:56:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19852 for ; Thu, 19 Aug 2004 06:56:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxkXX-0003zM-Rl; Thu, 19 Aug 2004 06:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxkUB-0003T1-Nz for nemo@megatron.ietf.org; Thu, 19 Aug 2004 06:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19571 for ; Thu, 19 Aug 2004 06:49:33 -0400 (EDT) Received: from web25008.mail.ukl.yahoo.com ([217.12.10.44]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bxkaa-0000Zj-PU for nemo@ietf.org; Thu, 19 Aug 2004 06:56:13 -0400 Message-ID: <20040819104903.65677.qmail@web25008.mail.ukl.yahoo.com> Received: from [137.194.192.231] by web25008.mail.ukl.yahoo.com via HTTP; Thu, 19 Aug 2004 12:49:03 CEST Date: Thu, 19 Aug 2004 12:49:03 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= To: IETF NEMO WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1686726632-1092912543=:65067" X-Spam-Score: 0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [nemo] new draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --0-1686726632-1092912543=:65067 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA19571 Content-Transfer-Encoding: quoted-printable Hi all, =20 We have submitted a new draft on the multihoming, handover and resource m= anagement issues, a proposed architecture is presented. Your comments are= appreciated. http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-man= agement-00.txt Abstract: This draft introduces a protocol that achieves handoff and resource management in a NEMO network in the case of multi-homed MR. We called this protocol an HRMMN protocol (Handoff and Resource Management for Multi-homed Networks). We introduce into the NEMO=20 architecture an intelligent control entity called Access Router=20 Controller (ARC). Based on traffic information transmitted through=20 several ARs under the control of specific ARC, this latter is=20 responsible of taking decisions about handoff, resource management=20 and maintain of multiple bidirectional tunnels. =20 =20 Regards Mazen TLAIS =09 --------------------------------- Cr=E9ez gratuitement votre Yahoo! Mail avec 100 Mo de stockage ! Cr=E9ez votre Yahoo! Mail Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau= t=E9s pour dialoguer instantan=E9ment avec vos amis.T=E9l=E9chargez GRATU= ITEMENT ici ! --0-1686726632-1092912543=:65067 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA19571 Content-Transfer-Encoding: quoted-printable
Hi all,
 
We have submitted a new draft on the multihoming, handover and resou= rce management issues, a proposed architecture is presented. Your co= mments are appreciated.
   This draft introduces a protocol that achieves han= doff and resource
   management in a NEMO network in the cas= e of multi-homed MR.
   We called this protocol an HRMMN protocol (Ha= ndoff and Resource
   Management for Multi-homed Networks). We introduce into= the NEMO
   architecture an intelligent control entity called Acces= s Router
   Controller (ARC). Based on traffic information tra= nsmitted through
   several ARs under the control of specific ARC, this lat= ter is
   responsible of taking decisions about handoff, resource= management
   and maintain of multiple bidirectional tunnels.
 
 
Regards
Mazen TLAIS

Cr=E9ez gratuitement votre Yahoo! Mail avec 100 Mo= de stockage !
Cr=E9ez votre Yahoo! Mail

Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveaut=E9s pour dialoguer instantan=E9ment a= vec vos amis. T=E9l=E9chargez GRATUITEMENT ici ! --0-1686726632-1092912543=:65067-- From nemo-bounces@ietf.org Thu Aug 19 08:57:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28827 for ; Thu, 19 Aug 2004 08:57:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxmRc-0006Of-IW; Thu, 19 Aug 2004 08:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxmIC-0004eA-A8 for nemo@megatron.ietf.org; Thu, 19 Aug 2004 08:45:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27966 for ; Thu, 19 Aug 2004 08:45:19 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxmON-0003Jk-AI for nemo@ietf.org; Thu, 19 Aug 2004 08:51:59 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7JCj2lU021227 for ; Thu, 19 Aug 2004 14:45:03 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 14:45:02 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PRJANG15; Thu, 19 Aug 2004 14:45:02 +0200 Message-ID: <4124A0CD.7020208@ericsson.com> Date: Thu, 19 Aug 2004 14:45:01 +0200 X-Sybari-Trust: 43b9170c 74470f8f d874ac8e 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) References: 47e7ff92 74470f8f e35fb442 00000138 <4121C809.4060107@ericsson.com> <4121DC9F.9020402@ericsson.com> <41240C1A.5040904@iprg.nokia.com> In-Reply-To: <41240C1A.5040904@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2004 12:45:02.0105 (UTC) FILETIME=[5827A090:01C485EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Mattias Pettersson wrote: > >> An addition: >> Option 1: >> In each BU, only the specified MNPs will be kept in the binding cache >> in the HA after a successful registration. All other MNPs not >> specified will be removed. In my example, MR would go from registering >> {MNP1, MNP2} to registering {MNP2} only. The binding for MNP1 will be >> removed immediately. >> >> Option 2: >> In a BU, the HA only updates the specified MNPs. This implicitly means >> that each MNP will have a lifetime. In my example, MR would go from >> registering {MNP1, MNP2} to registering {MNP2} only. To handle a quick >> transition, MR would also have to deregister MNP1 explicitly, by >> sending a BU with lifetime=0 and MNP1 as the only prefix option. >> >> Does anyone else see the need for this? From Vijay's initial >> discussion, it seems so. > > > I agree there is a need for clarification. I prefer option 1. here is > some text > > If the Home Agent has a valid binding cache entry for the Mobile > Router, it should compare the list of prefixes in the Binding Update > against the prefixes stored in the binding cache entry. If the > binding cache entry contains prefixes that do not appear in the > Binding Update, the Home Agent MUST disable forwarding for these > Mobile Network Prefixes. > > I was thinking of adding this to section 6.2. please see > http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre04.txt > > it can also be added to section 6.7, instead. let me know. It should be where it is now, Section 6.2. Thanks. > > however, I am not sure this change is minor enough to be done during > AUTH48 stage. otherwise we may have to drop this. WG chairs? > >> In addition, Section 6.2. allows the MR to indicate deregistration by >> either setting lifetime=0 or set CoA=HoA. Section 6.7. only accepts >> lifetime=0. > > > I just deleted the first sentence in section 6.7. Fine. /Mattias > > Vijay > >> >> /Mattias >> >> >> Mattias Pettersson L (KI/EAB) wrote: >> >>> It is important that the HA and the MR has exactly the same >>> perception on what prefixes are in use and what their respective >>> registration lifetimes are. >>> >>> IMHO I think it may be dangerous to mix explicit and implicit like >>> you describe below. Do you think it will add functionality? >>> >>> /Mattias >>> >>> Pascal Thubert (pthubert) wrote: >>> >>>> If the MR has no prefix it can not add them. It needs to learn them. >>> >>> >>> >>> I'm not sure we ever said that explicit excluded implicit; If the HA has >>> some prefixes for the MR, it can install them (e.g. static routes). If >>> the MR claims others, then the HA can install them too. When the MR >>> stops claiming prefixes it claimed before in explicit mode (HA knows >>> because of prefix list) then the HA removes the forwarding states for >>> those prefixes only. >>> >>>> What do you think? >>>> >>>> >>> >>> >> > From nemo-bounces@ietf.org Thu Aug 19 09:00:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29005 for ; Thu, 19 Aug 2004 09:00:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxmSu-0006hh-3Z; Thu, 19 Aug 2004 08:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxmMb-0005RW-Q9 for nemo@megatron.ietf.org; Thu, 19 Aug 2004 08:49:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28260 for ; Thu, 19 Aug 2004 08:49:52 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxmSq-0003PS-UQ for nemo@ietf.org; Thu, 19 Aug 2004 08:56:32 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7JCneWR018115 for ; Thu, 19 Aug 2004 14:49:40 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 14:49:40 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZMDA1LR; Thu, 19 Aug 2004 14:49:40 +0200 Message-ID: <4124A1E4.90107@ericsson.com> Date: Thu, 19 Aug 2004 14:49:40 +0200 X-Sybari-Trust: 190962a4 74470f8f d874ac8e 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nemo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2004 12:49:40.0625 (UTC) FILETIME=[FE2A6810:01C485EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [nemo] OSPF ref X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Basic support has an incorrect reference (typo): > [13] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, > IETF. December 1999. It should be 2740. /Mattias From nemo-bounces@ietf.org Thu Aug 19 14:20:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21696 for ; Thu, 19 Aug 2004 14:20:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxrU7-0001Xk-4c; Thu, 19 Aug 2004 14:17:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxrNw-0000q4-15 for nemo@megatron.ietf.org; Thu, 19 Aug 2004 14:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20843 for ; Thu, 19 Aug 2004 14:11:35 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxrUP-0001XQ-0y for nemo@ietf.org; Thu, 19 Aug 2004 14:18:17 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7JIBXWR010507 for ; Thu, 19 Aug 2004 20:11:33 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 20:11:33 +0200 Received: from ericsson.com (sealwa02m086.sw.ericsson.se [130.100.249.86]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6GZ3TN8; Thu, 19 Aug 2004 20:11:46 +0200 Message-ID: <4124ED53.6090308@ericsson.com> Date: Thu, 19 Aug 2004 20:11:31 +0200 X-Sybari-Trust: c05fa93a 477d8de1 f9fb810e 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mazen TLAIS Subject: Re: [nemo] new draft References: <20040819104903.65677.qmail@web25008.mail.ukl.yahoo.com> In-Reply-To: <20040819104903.65677.qmail@web25008.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 19 Aug 2004 18:11:33.0603 (UTC) FILETIME=[F598FB30:01C48617] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i7JIBXWR010507 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Mazen, Thanks for the I-D. I'm rather curious on scenarios when such an architecture as you propose=20 would be likely. You seem to assume that there is a suitable point in a typical access=20 network where an ARC can be placed. From your draft I can't be sure what=20 security relationships that are required, but if the ARC needs security=20 relationships with many ARs this in general creates scalability=20 problems. My general assumption is that in order to benefit from=20 multihoming, an MR would connect to various access networks of different=20 technologies. That would mean that ARs belong to different domains. The=20 nature of multihoming is to connect to the network in topological=20 locations far from each other, often even completely unrelated=20 locations. That is what makes the placement of an ARC difficult, as it=20 is meant to be near the different ARs. But I may have misinterpreted=20 your architecture. What is the actual function of the ARC? I don't think the draft explains=20 clearly enough if it actually acts as a local home agent and creates=20 bi-directional tunnels towards the MRs. What makes it different from a MAP in HMIPv6 (apart from the very=20 loosely defined resource reservations you include)? BR Mattias Mazen TLAIS wrote: > Hi all, > =20 > We have submitted a new draft on the multihoming, handover and resource= =20 > management issues, a proposed architecture is presented. Your comments=20 > are appreciated. >=20 > /http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-= management-00.txt/ >=20 > Abstract: > This draft introduces a protocol that achieves handoff and resource > management in a NEMO network in the case of multi-homed MR. > We called this protocol an HRMMN protocol (Handoff and Resource > Management for Multi-homed Networks). We introduce into the NEMO > architecture an intelligent control entity called Access Router > Controller (ARC). Based on traffic information transmitted through > several ARs under the control of specific ARC, this latter is > responsible of taking decisions about handoff, resource management > and maintain of multiple bidirectional tunnels. > =20 > =20 > Regards > Mazen TLAIS >=20 > -----------------------------------------------------------------------= - > Cr=E9ez gratuitement votre Yahoo! Mail avec *100 Mo de stockage !* > Cr=E9ez votre Yahoo! Mail=20 > >=20 > *Le nouveau Yahoo! Messenger est arriv=E9 !* D=E9couvrez toutes les=20 > nouveaut=E9s pour dialoguer instantan=E9ment avec vos amis. T=E9l=E9cha= rgez=20 > GRATUITEMENT ici !=20 > =20 >=20 From nemo-bounces@ietf.org Fri Aug 20 06:40:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03243 for ; Fri, 20 Aug 2004 06:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By6WX-0002hS-Iz; Fri, 20 Aug 2004 06:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By6Kp-0008Dj-Bd for nemo@megatron.ietf.org; Fri, 20 Aug 2004 06:09:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01824 for ; Fri, 20 Aug 2004 06:09:15 -0400 (EDT) Received: from web25002.mail.ukl.yahoo.com ([217.12.10.38]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1By6RI-0003n4-2W for nemo@ietf.org; Fri, 20 Aug 2004 06:16:08 -0400 Message-ID: <20040820100842.32429.qmail@web25002.mail.ukl.yahoo.com> Received: from [137.194.192.231] by web25002.mail.ukl.yahoo.com via HTTP; Fri, 20 Aug 2004 12:08:42 CEST Date: Fri, 20 Aug 2004 12:08:42 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] new draft To: Mattias Pettersson In-Reply-To: <4124ED53.6090308@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA01824 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 Content-Transfer-Encoding: quoted-printable Hi Mattias, Here are some responses for your comments > You seem to assume that there is a suitable point in > a typical access=20 > network where an ARC can be placed. From your draft > I can't be sure what=20 > security relationships that are required, but if the > ARC needs security=20 > relationships with many ARs this in general creates > scalability=20 > problems. Updating messages sent by MR to ARC need=20 security relationships. I'm not sure about ARs. >My general assumption is that in order to > benefit from=20 > multihoming, an MR would connect to various access > networks of different=20 > technologies. That would mean that ARs belong to > different domains. The=20 > nature of multihoming is to connect to the network > in topological=20 > locations far from each other, often even completely > unrelated=20 > locations. That is what makes the placement of an > ARC difficult, as it=20 > is meant to be near the different ARs. But I may > have misinterpreted=20 > your architecture. If the AR is registered within an ARC, then=20 this later can manage the AR. It's not a location question. > What is the actual function of the ARC? I don't > think the draft explains=20 > clearly enough if it actually acts as a local home > agent and creates=20 > bi-directional tunnels towards the MRs. through AR preferences option, ARC is responsible to help MR to prefer an AR in face of another AR . But we assume that ARC MAY play the role of a local home agent according to administrator's configuration.=20 >=20 > What makes it different from a MAP in HMIPv6 May be i misunderstand HMIPv6, but i think that MAP is useful for handoff operation, it does not manage resources, and the MR does not have any additional=20 information to choose between different ARs. > (apart > from the very=20 > loosely defined resource reservations you include)? In our draft, we present a possible scenario=20 of the ARC contribution to reserve resources. We are working now on a complete idea for end to end reservation protocol adapted for NEMO networks. But we need few weeks to finalize it. =20 Thanks, we really appreciate your comments Regards Mazen =20 > Mazen TLAIS wrote: > > Hi all, > > =20 > > We have submitted a new draft on the multihoming, > handover and resource=20 > > management issues, a proposed architecture is > presented. Your comments=20 > > are appreciated. > >=20 > > > /http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-ma= nagement-00.txt/ > >=20 > > Abstract: > > This draft introduces a protocol that achieves > handoff and resource > > management in a NEMO network in the case of > multi-homed MR. > > We called this protocol an HRMMN protocol > (Handoff and Resource > > Management for Multi-homed Networks). We > introduce into the NEMO > > architecture an intelligent control entity > called Access Router > > Controller (ARC). Based on traffic information > transmitted through > > several ARs under the control of specific ARC, > this latter is > > responsible of taking decisions about handoff, > resource management > > and maintain of multiple bidirectional tunnels. > > =20 > > =20 > > Regards > > Mazen TLAIS > >=20 > > > ------------------------------------------------------------------------ > > Cr=E9ez gratuitement votre Yahoo! Mail avec *100 Mo > de stockage !* > > Cr=E9ez votre Yahoo! Mail=20 > > > > >=20 > > *Le nouveau Yahoo! Messenger est arriv=E9 !* > D=E9couvrez toutes les=20 > > nouveaut=E9s pour dialoguer instantan=E9ment avec vos > amis. T=E9l=E9chargez=20 > > GRATUITEMENT ici !=20 > > > >=20 > >=20 >=20 >=20 > =20 =09 =09 =09 Vous manquez d=92espace pour stocker vos mails ?=20 Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau= t=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger gr= atuitement sur http://fr.messenger.yahoo.com From nemo-bounces@ietf.org Fri Aug 20 06:51:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03837 for ; Fri, 20 Aug 2004 06:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By6hv-0006kp-UK; Fri, 20 Aug 2004 06:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By6TP-0001C1-IZ for nemo@megatron.ietf.org; Fri, 20 Aug 2004 06:18:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02209 for ; Fri, 20 Aug 2004 06:18:07 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By6Zv-0003v9-6Y for nemo@ietf.org; Fri, 20 Aug 2004 06:25:00 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 24DF62839F; Fri, 20 Aug 2004 12:17:35 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id D1F132839E; Fri, 20 Aug 2004 12:17:34 +0200 (CEST) Subject: Re: [nemo] new draft From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Mazen TLAIS In-Reply-To: <20040819104903.65677.qmail@web25008.mail.ukl.yahoo.com> References: <20040819104903.65677.qmail@web25008.mail.ukl.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q8XrY/iUTEHbFUzJBMNI" Organization: Universidad Carlos III de Madrid Message-Id: <1092997058.2429.27.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 20 Aug 2004 12:17:38 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 --=-Q8XrY/iUTEHbFUzJBMNI Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Thanks for submitting the i-d. I agree with Mattias. Besides, there some scenarios of multihoming in NEMO that have not been covered by your solution and that are also important IMHO. For example, a NEMO can be multihomed by having more than one MR connecting to different ARs. Another point I don't see clearly is what happens when the NEMOs are nested, how does your mechanism work in this case? With nesting is involved, the overhead problem is more severe. Kind regards, C.J. El jue, 19-08-2004 a las 12:49, Mazen TLAIS escribi=F3: > Hi all, > =20 > We have submitted a new draft on the multihoming, handover and > resource management issues, a proposed architecture is presented. Your > comments are appreciated. > http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-man= agement-00.txt >=20 > Abstract: > This draft introduces a protocol that achieves handoff and resource > management in a NEMO network in the case of multi-homed MR. > We called this protocol an HRMMN protocol (Handoff and Resource > Management for Multi-homed Networks). We introduce into the NEMO=20 > architecture an intelligent control entity called Access Router=20 > Controller (ARC). Based on traffic information transmitted through=20 > several ARs under the control of specific ARC, this latter is=20 > responsible of taking decisions about handoff, resource management=20 > and maintain of multiple bidirectional tunnels. > =20 > =20 > Regards > Mazen TLAIS >=20 >=20 >=20 >=20 > ______________________________________________________________________ > Cr=E9ez gratuitement votre Yahoo! Mail avec 100 Mo de stockage ! > Cr=E9ez votre Yahoo! Mail >=20 > Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les > nouveaut=E9s pour dialoguer instantan=E9ment avec vos amis. T=E9l=E9charg= ez > GRATUITEMENT ici ! --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-Q8XrY/iUTEHbFUzJBMNI Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBJc/B5vKyPtrWqkARAuEQAJ9Fm6BstaQCO+rJOb7TajkSnrt0sACfemGX WBLz0H10VLoKa8f9Nl5V4r8= =b3kg -----END PGP SIGNATURE----- --=-Q8XrY/iUTEHbFUzJBMNI-- From nemo-bounces@ietf.org Fri Aug 20 07:25:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05376 for ; Fri, 20 Aug 2004 07:25:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By75b-0002TY-Hm; Fri, 20 Aug 2004 06:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By6qZ-0008P7-RP for nemo@megatron.ietf.org; Fri, 20 Aug 2004 06:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03352 for ; Fri, 20 Aug 2004 06:42:03 -0400 (EDT) Received: from web25010.mail.ukl.yahoo.com ([217.12.10.46]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1By6x6-0004K4-Tx for nemo@ietf.org; Fri, 20 Aug 2004 06:48:57 -0400 Message-ID: <20040820104134.31813.qmail@web25010.mail.ukl.yahoo.com> Received: from [137.194.192.231] by web25010.mail.ukl.yahoo.com via HTTP; Fri, 20 Aug 2004 12:41:34 CEST Date: Fri, 20 Aug 2004 12:41:34 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] new draft To: Carlos "Jesús" Bernardos Cano In-Reply-To: <1092997058.2429.27.camel@acorde> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA03352 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 Content-Transfer-Encoding: quoted-printable Hi Carlos, thanks for your comments, here are some responses =20 >there some scenarios > of multihoming in > NEMO that have not been covered by your solution and > that are also > important IMHO. For example, a NEMO can be > multihomed by having more > than one MR connecting to different ARs. Yes, our solution does not cover all multihoming scenarios. > Another > point I don't see > clearly is what happens when the NEMOs are nested, > how does your > mechanism work in this case? With nesting is > involved, the overhead > problem is more severe. In fact, we assume that only the root mobile router is charged to communicate with the ARC. Regards Mazen >=20 > Kind regards, >=20 > C.J. >=20 > El jue, 19-08-2004 a las 12:49, Mazen TLAIS > escribi=F3: > > Hi all, > > =20 > > We have submitted a new draft on the multihoming, > handover and > > resource management issues, a proposed > architecture is presented. Your > > comments are appreciated. > > > http://www.ietf.org/internet-drafts/draft-tlais-nemo-handoff-resource-man= agement-00.txt > >=20 > > Abstract: > > This draft introduces a protocol that achieves > handoff and resource > > management in a NEMO network in the case of > multi-homed MR. > > We called this protocol an HRMMN protocol > (Handoff and Resource > > Management for Multi-homed Networks). We > introduce into the NEMO=20 > > architecture an intelligent control entity > called Access Router=20 > > Controller (ARC). Based on traffic information > transmitted through=20 > > several ARs under the control of specific ARC, > this latter is=20 > > responsible of taking decisions about handoff, > resource management=20 > > and maintain of multiple bidirectional tunnels. > > =20 > > =20 > > Regards > > Mazen TLAIS > >=20 > >=20 > >=20 > >=20 > > > ______________________________________________________________________ > > Cr=E9ez gratuitement votre Yahoo! Mail avec 100 Mo > de stockage ! > > Cr=E9ez votre Yahoo! Mail > >=20 > > Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez > toutes les > > nouveaut=E9s pour dialoguer instantan=E9ment avec vos > amis. T=E9l=E9chargez > > GRATUITEMENT ici ! > --=20 > Carlos Jes=FAs Bernardos Cano - > http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E > DAD6 AA40 >=20 > ATTACHMENT part 2 application/pgp-signature name=3Dsignature.asc =20 =09 =09 =09 Vous manquez d=92espace pour stocker vos mails ?=20 Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau= t=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger gr= atuitement sur http://fr.messenger.yahoo.com From nemo-bounces@ietf.org Fri Aug 20 10:03:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13960 for ; Fri, 20 Aug 2004 10:03:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9e6-0007rc-U4; Fri, 20 Aug 2004 09:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9PS-0005AL-04 for nemo@megatron.ietf.org; Fri, 20 Aug 2004 09:26:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12067 for ; Fri, 20 Aug 2004 09:26:15 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By9Vz-0007L0-QP for nemo@ietf.org; Fri, 20 Aug 2004 09:33:09 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Aug 2004 15:35:47 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7KDPUua019110; Fri, 20 Aug 2004 15:25:40 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 15:25:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Date: Fri, 20 Aug 2004 15:25:24 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0A2EFC@xmb-ams-337.emea.cisco.com> Thread-Topic: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Thread-Index: AcSEOBlv2R7/8JyvTOepEPAF1+auXwCgI4LA From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" X-OriginalArrivalTime: 20 Aug 2004 13:25:38.0769 (UTC) FILETIME=[2EEECC10:01C486B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ryuji Wakikawa , "Sri Gundavelli \(sgundave\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Mattias: It's just pretty hard to prevent configuring static routes and using = explicit prefix at the same time. And this does not necessarily lead to = wrongdoing. But it could, and this would lead to packets bouncing over = MRHA till TTL. To avoid this, the key is that when the MR receives a = packet from the HA, it should NEVER send it back to the HA. This is = usual router behaviour, but it very critical to enforce it here. Pascal > -----Original Message----- > From: Mattias Pettersson [mailto:mattias.l.pettersson@ericsson.com] > Sent: mardi 17 ao=FBt 2004 10:56 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; Ryuji Wakikawa; nemo@ietf.org > Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in = BU inexplicit mode) >=20 > It is important that the HA and the MR has exactly the same perception > on what prefixes are in use and what their respective registration > lifetimes are. >=20 > IMHO I think it may be dangerous to mix explicit and implicit like you > describe below. Do you think it will add functionality? >=20 > /Mattias >=20 > Pascal Thubert (pthubert) wrote: > > If the MR has no prefix it can not add them. It needs to learn them. = I'm not sure we ever > said that explicit excluded implicit; If the HA has some prefixes for = the MR, it can install > them (e.g. static routes). If the MR claims others, then the HA can = install them too. When > the MR stops claiming prefixes it claimed before in explicit mode (HA = knows because of prefix > list) then the HA removes the forwarding states for those prefixes = only. > > > > What do you think? > > > > From nemo-bounces@ietf.org Fri Aug 20 10:09:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14662 for ; Fri, 20 Aug 2004 10:09:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9eB-0007t1-Pn; Fri, 20 Aug 2004 09:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9Qi-0005I4-02 for nemo@megatron.ietf.org; Fri, 20 Aug 2004 09:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12116 for ; Fri, 20 Aug 2004 09:27:33 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By9XG-0007MV-QH for nemo@ietf.org; Fri, 20 Aug 2004 09:34:27 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Aug 2004 15:37:07 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7KDR0uS019355; Fri, 20 Aug 2004 15:27:00 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Aug 2004 15:26:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Date: Fri, 20 Aug 2004 15:26:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0A2EFE@xmb-ams-337.emea.cisco.com> Thread-Topic: Issue 42 (was Re: [nemo] Including prefix information in BU inexplicit mode) Thread-Index: AcSFkfk2gnwY3wCSTGC0VndNaLnu+ABJ15hw From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Mattias Pettersson" , "Sri Gundavelli \(sgundave\)" X-OriginalArrivalTime: 20 Aug 2004 13:26:59.0841 (UTC) FILETIME=[5F416710:01C486B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Content-Transfer-Encoding: quoted-printable Great :) 6.2 is fine with me. > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Vijay Devarapalli > Sent: jeudi 19 ao=FBt 2004 04:11 > To: Mattias Pettersson > Cc: nemo@ietf.org > Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in = BU inexplicit mode) >=20 > Mattias Pettersson wrote: > > An addition: > > Option 1: > > In each BU, only the specified MNPs will be kept in the binding = cache in > > the HA after a successful registration. All other MNPs not specified > > will be removed. In my example, MR would go from registering {MNP1, > > MNP2} to registering {MNP2} only. The binding for MNP1 will be = removed > > immediately. > > > > Option 2: > > In a BU, the HA only updates the specified MNPs. This implicitly = means > > that each MNP will have a lifetime. In my example, MR would go from > > registering {MNP1, MNP2} to registering {MNP2} only. To handle a = quick > > transition, MR would also have to deregister MNP1 explicitly, by = sending > > a BU with lifetime=3D0 and MNP1 as the only prefix option. > > > > Does anyone else see the need for this? From Vijay's initial = discussion, > > it seems so. >=20 > I agree there is a need for clarification. I prefer option 1. here is > some text >=20 > If the Home Agent has a valid binding cache entry for the Mobile > Router, it should compare the list of prefixes in the Binding = Update > against the prefixes stored in the binding cache entry. If the > binding cache entry contains prefixes that do not appear in the > Binding Update, the Home Agent MUST disable forwarding for these > Mobile Network Prefixes. >=20 > I was thinking of adding this to section 6.2. please see > = http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre04.t= xt >=20 > it can also be added to section 6.7, instead. let me know. >=20 > however, I am not sure this change is minor enough to be done during > AUTH48 stage. otherwise we may have to drop this. WG chairs? >=20 > > In addition, Section 6.2. allows the MR to indicate deregistration = by > > either setting lifetime=3D0 or set CoA=3DHoA. Section 6.7. only = accepts > > lifetime=3D0. >=20 > I just deleted the first sentence in section 6.7. >=20 > Vijay >=20 > > > > /Mattias > > > > > > Mattias Pettersson L (KI/EAB) wrote: > > > >> It is important that the HA and the MR has exactly the same = perception > >> on what prefixes are in use and what their respective registration > >> lifetimes are. > >> > >> IMHO I think it may be dangerous to mix explicit and implicit like = you > >> describe below. Do you think it will add functionality? > >> > >> /Mattias > >> > >> Pascal Thubert (pthubert) wrote: > >> > >>> If the MR has no prefix it can not add them. It needs to learn = them. > >> > >> > >> I'm not sure we ever said that explicit excluded implicit; If the = HA has > >> some prefixes for the MR, it can install them (e.g. static routes). = If > >> the MR claims others, then the HA can install them too. When the MR > >> stops claiming prefixes it claimed before in explicit mode (HA = knows > >> because of prefix list) then the HA removes the forwarding states = for > >> those prefixes only. > >> > >>> What do you think? > >>> > >>> > >> > >> > > >=20 From nemo-bounces@ietf.org Fri Aug 20 11:06:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19231 for ; Fri, 20 Aug 2004 11:06:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAgr-0001v8-VY; Fri, 20 Aug 2004 10:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAAR-0001mh-Kl for nemo@megatron.ietf.org; Fri, 20 Aug 2004 10:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15351 for ; Fri, 20 Aug 2004 10:14:48 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAGl-0008EF-Kh for nemo@ietf.org; Fri, 20 Aug 2004 10:21:43 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7KEEXlU019915 for ; Fri, 20 Aug 2004 16:14:33 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 16:14:33 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT526HF; Fri, 20 Aug 2004 16:14:33 +0200 Message-ID: <41260748.5090704@ericsson.com> Date: Fri, 20 Aug 2004 16:14:32 +0200 X-Sybari-Trust: e1e1ceba 74470f8f 61255b5f 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) References: <7892795E1A87F04CADFCCF41FADD00FC0A2EFC@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0A2EFC@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 20 Aug 2004 14:14:33.0006 (UTC) FILETIME=[03DFD4E0:01C486C0] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.ericsson.se id i7KEEXlU019915 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > Hi Mattias: >=20 > It's just pretty hard to prevent configuring static routes and using > explicit prefix at the same time. And this does not necessarily lead to > wrongdoing. But it could, and this would lead to packets bouncing over > MRHA till TTL. To avoid this, the key is that when the MR receives a > packet from the HA, it should NEVER send it back to the HA. This is > usual router behaviour, but it very critical to enforce it here. You may be correct that it is in fact up to the HA and MR to deal with=20 synchronization of the static routes and that the BU signalling doesn't=20 deal with them at all. Which in turn means that we can mix static and=20 explicit. To answer your last sentence, I didn't know this was usual router=20 behaviour. To my knowledge the MR would forward the packet back over the=20 MRHA tunnel and also send an ICMP redirect as the outgoing interface =3D=3D= =20 receiving interface. /Mattias >=20 > Pascal >=20 >=20 >>-----Original Message----- >>From: Mattias Pettersson [mailto:mattias.l.pettersson@ericsson.com] >>Sent: mardi 17 ao=FBt 2004 10:56 >>To: Pascal Thubert (pthubert) >>Cc: Vijay Devarapalli; Ryuji Wakikawa; nemo@ietf.org >>Subject: Re: Issue 42 (was Re: [nemo] Including prefix information in >=20 > BU inexplicit mode) >=20 >>It is important that the HA and the MR has exactly the same perception >>on what prefixes are in use and what their respective registration >>lifetimes are. >> >>IMHO I think it may be dangerous to mix explicit and implicit like you >>describe below. Do you think it will add functionality? >> >>/Mattias >> >>Pascal Thubert (pthubert) wrote: >> >>>If the MR has no prefix it can not add them. It needs to learn them. >=20 > I'm not sure we ever >=20 >>said that explicit excluded implicit; If the HA has some prefixes for >=20 > the MR, it can install >=20 >>them (e.g. static routes). If the MR claims others, then the HA can >=20 > install them too. When >=20 >>the MR stops claiming prefixes it claimed before in explicit mode (HA >=20 > knows because of prefix >=20 >>list) then the HA removes the forwarding states for those prefixes >=20 > only. >=20 >>>What do you think? >>> >>> >=20 >=20 From nemo-bounces@ietf.org Mon Aug 23 10:50:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13596 for ; Mon, 23 Aug 2004 10:50:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFmm-0004y0-Ul; Mon, 23 Aug 2004 10:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFZY-0001EY-Cp for nemo@megatron.ietf.org; Mon, 23 Aug 2004 10:13:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10289 for ; Mon, 23 Aug 2004 10:13:13 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFZn-0005pH-9z for nemo@ietf.org; Mon, 23 Aug 2004 10:13:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Aug 2004 16:23:42 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7NECcuU010636; Mon, 23 Aug 2004 16:12:40 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Aug 2004 16:12:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) Date: Mon, 23 Aug 2004 16:12:33 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0A3113@xmb-ams-337.emea.cisco.com> Thread-Topic: Issue 42 (was Re: [nemo] Including prefix information in BU i nexplicit mode) Thread-Index: AcSGwDh1YWP6e1LMSD250bSv1xlnAwCUsAGg From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" X-OriginalArrivalTime: 23 Aug 2004 14:12:38.0476 (UTC) FILETIME=[3ED930C0:01C4891B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Content-Transfer-Encoding: quoted-printable >=20 > Pascal Thubert (pthubert) wrote: > > Hi Mattias: > > > > It's just pretty hard to prevent configuring static routes and using > > explicit prefix at the same time. And this does not necessarily lead to > > wrongdoing. But it could, and this would lead to packets bouncing over > > MRHA till TTL. To avoid this, the key is that when the MR receives a > > packet from the HA, it should NEVER send it back to the HA. This is > > usual router behaviour, but it very critical to enforce it here. >=20 > You may be correct that it is in fact up to the HA and MR to deal with > synchronization of the static routes and that the BU signalling doesn't > deal with them at all. Which in turn means that we can mix static and > explicit. >=20 > To answer your last sentence, I didn't know this was usual router > behaviour. To my knowledge the MR would forward the packet back over the > MRHA tunnel and also send an ICMP redirect as the outgoing interface =3D=3D > receiving interface. >=20 Actually I was referring to the MRHA tunnel, which is a router to router communication, as opposed to a host to router. In the general case of host to router, the router will act as you mention - unless it acts as an ND proxy for the source address. In the specific case of P2P links, your flow should not happen, since the router will not have a route over the host. In the case of router to router, sending a packet back over the same P2P link is an obvious anomaly that IOS routers check for (they will send ICMP unreachable and drop the packet). So there can be specific code that depends on the interface type and that would check for an obvious loop. This is analogous to the routing protocols such has IGRP or RIP doing split horizon, which avoid that problem at the routing level. Basically any time the HA has a route via the MR but the MR does not know that prefix, packets may ping pong till TTL. I think we already discussed adding a check for such loops in the MRHA tunnel. I do not remember of any outcome. But it's my suggestion to implementers to actually do it. Pascal From nemo-bounces@ietf.org Mon Aug 23 21:33:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05642 for ; Mon, 23 Aug 2004 21:33:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzPbv-0008D9-Cq; Mon, 23 Aug 2004 20:56:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzPKr-0004Zf-FX for nemo@megatron.ietf.org; Mon, 23 Aug 2004 20:38:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01360 for ; Mon, 23 Aug 2004 20:38:42 -0400 (EDT) Message-Id: <200408240038.UAA01360@ietf.org> Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzPLB-0003YJ-6k for nemo@ietf.org; Mon, 23 Aug 2004 20:39:10 -0400 Received: from skylane1 (6ants6.etri.re.kr [129.254.112.240]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RM62PBPT; Tue, 24 Aug 2004 09:37:33 +0900 From: "Byung-Yeob Kim" To: Date: Tue, 24 Aug 2004 09:38:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSJcqGVNeu451wyQxiqmgrtxZWtkw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 1.5 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: autonet Subject: [nemo] Handling MIPL options in 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 Content-Transfer-Encoding: 7bit Hi, all, I am implementing draft-ietf-nemo-basic-support-v03 by modifying MIPL 1.0. I see two MIPL configuration options, autoconf and forwarding. I think autoconf is for nodes while forwarding is for routers; problem is nemo MR needs both of them. Does anyone have any idea about handling these options? I tried to change the code to accept both options at the same time. However, I found that MR does not forward pings from its subsidiary nodes anymore. (I am not yet sure this is because of taking both options though.) Regards, Bob PEC/ETRI From nemo-bounces@ietf.org Tue Aug 24 00:12:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14394 for ; Tue, 24 Aug 2004 00:12:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzS4j-00068f-Tk; Mon, 23 Aug 2004 23:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzRab-0001iK-MO for nemo@megatron.ietf.org; Mon, 23 Aug 2004 23:03:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10738 for ; Mon, 23 Aug 2004 23:03:06 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzRaw-00065M-Ij for nemo@ietf.org; Mon, 23 Aug 2004 23:03:36 -0400 Received: from [203.178.128.157] (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7O2wm4v012096; Tue, 24 Aug 2004 11:58:49 +0900 In-Reply-To: <200408240038.UAA01360@ietf.org> References: <200408240038.UAA01360@ietf.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1BD2FD20-F57A-11D8-8AA6-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Handling MIPL options in nemo Date: Tue, 24 Aug 2004 12:03:00 +0900 To: "Byung-Yeob Kim" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, autonet X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Bob In our BSD implementation, we set autoconf and forwarding option on MR. We made some kernel modification to handle both options in the kernel. MR must relax the IPv6 spec for enabling both options. ryuji On 2004/08/24, at 9:38, Byung-Yeob Kim wrote: > > Hi, all, > I am implementing draft-ietf-nemo-basic-support-v03 by modifying MIPL > 1.0. > > I see two MIPL configuration options, autoconf and forwarding. I think > autoconf is for nodes while forwarding is for routers; problem is nemo > MR > needs both of them. Does anyone have any idea about handling these > options? > > I tried to change the code to accept both options at the same time. > However, I found that MR does not forward pings from its subsidiary > nodes > anymore. (I am not yet sure this is because of taking both options > though.) > > Regards, > Bob > PEC/ETRI > From nemo-bounces@ietf.org Tue Aug 24 00:50:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16506 for ; Tue, 24 Aug 2004 00:50:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzSi9-0004Z9-H0; Tue, 24 Aug 2004 00:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzSJY-0008VM-SZ for nemo@megatron.ietf.org; Mon, 23 Aug 2004 23:49:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13244 for ; Mon, 23 Aug 2004 23:49:32 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzSJs-0006mB-Ar for nemo@ietf.org; Mon, 23 Aug 2004 23:50:03 -0400 Received: from bender (jules.nautilus6.org [203.178.138.2]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A2FA45D0AA for ; Tue, 24 Aug 2004 12:48:59 +0900 (JST) Date: Tue, 24 Aug 2004 12:49:59 +0900 From: Romain KUNTZ To: nemo@ietf.org Subject: Re: [nemo] Handling MIPL options in nemo Message-Id: <20040824124959.650f329d.kuntz@sfc.wide.ad.jp> In-Reply-To: <200408240038.UAA01360@ietf.org> References: <200408240038.UAA01360@ietf.org> Organization: Keio University X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.3; i686-pc-linux-gnu) Mime-Version: 1.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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, > I see two MIPL configuration options, autoconf and forwarding. I > think autoconf is for nodes while forwarding is for routers; problem > is nemo MR needs both of them. Does anyone have any idea about > handling these options? > > I tried to change the code to accept both options at the same time. > However, I found that MR does not forward pings from its subsidiary > nodes anymore. (I am not yet sure this is because of taking both > options though.) you may need to change neighbor discovery behaviour, because it cannot handle both autoconf and forwarding at the same time (if forwarding is set, RA are dropped even if accept_ra is set for the interface). see net/ipv6/ndisc.c, function ndisc_router_discovery(). Hope it will help! Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Tue Aug 24 04:22:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13811 for ; Tue, 24 Aug 2004 04:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWIa-000517-6Q; Tue, 24 Aug 2004 04:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzVwh-0001IF-9w for nemo@megatron.ietf.org; Tue, 24 Aug 2004 03:42:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10166 for ; Tue, 24 Aug 2004 03:42:12 -0400 (EDT) Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzVx4-0002By-Ok for nemo@ietf.org; Tue, 24 Aug 2004 03:42:44 -0400 Received: from speedy (speedy.comnets.uni-bremen.de [134.102.155.154]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id i7O7g4x12609; Tue, 24 Aug 2004 09:42:05 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host speedy.comnets.uni-bremen.de [134.102.155.154] claimed to be speedy From: "Stefan Aust" To: "'Byung-Yeob Kim'" , Subject: AW: [nemo] Handling MIPL options in nemo Date: Tue, 24 Aug 2004 09:40:27 +0200 Message-ID: <002c01c489ad$a08f7440$9a9b6686@speedy> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-reply-to: <200408240038.UAA01360@ietf.org> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: "'autonet'" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Bob, hi all, we are also working with MIPL and fixed the problem in the same way as = it is mentioned above. Do you have any information about the implemented = Movement Detection in MIPL?. There are ECS and LCS but it seems that only one of = them is working well (I guess LCS). What is your experience concerning MD? You can set a flag but it seems that the implementation does not use it. Regards,=20 Stefan > -----Urspr=FCngliche Nachricht----- > Von: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] Im=20 > Auftrag von Byung-Yeob Kim > Gesendet: Dienstag, 24. August 2004 02:38 > An: nemo@ietf.org > Cc: autonet > Betreff: [nemo] Handling MIPL options in nemo >=20 >=20 >=20 > Hi, all, > I am implementing draft-ietf-nemo-basic-support-v03 by=20 > modifying MIPL 1.0.=20 >=20 > I see two MIPL configuration options, autoconf and=20 > forwarding. I think autoconf is for nodes while forwarding=20 > is for routers; problem is nemo MR needs both of them. Does=20 > anyone have any idea about handling these options? >=20 > I tried to change the code to accept both options at the same=20 > time. However, I found that MR does not forward pings from=20 > its subsidiary nodes anymore. (I am not yet sure this is=20 > because of taking both options though.) >=20 > Regards, > Bob > PEC/ETRI >=20 >=20 From nemo-bounces@ietf.org Wed Aug 25 06:52:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02982 for ; Wed, 25 Aug 2004 06:52:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzv8N-0005dB-1O; Wed, 25 Aug 2004 06:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzuu7-0003Dm-4K for nemo@megatron.ietf.org; Wed, 25 Aug 2004 06:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01126 for ; Wed, 25 Aug 2004 06:21:11 -0400 (EDT) Received: from tripoli.ucdavis.edu ([169.237.104.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzuui-0006oo-25 for nemo@ietf.org; Wed, 25 Aug 2004 06:21:58 -0400 Received: from adalia.ucdavis.edu (adalia.ucdavis.edu [169.237.104.182]) by tripoli.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i7PAKvMd029352; Wed, 25 Aug 2004 03:20:57 -0700 (PDT) Received: from adalia.ucdavis.edu (localhost [127.0.0.1]) by adalia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i7PAKu7d023432; Wed, 25 Aug 2004 03:20:56 -0700 (PDT) Received: (from www@localhost) by adalia.ucdavis.edu (8.12.10/8.12.9/Submit) id i7PAKut0023431; Wed, 25 Aug 2004 03:20:56 -0700 (PDT) Date: Wed, 25 Aug 2004 03:20:56 -0700 (PDT) Message-Id: <200408251020.i7PAKut0023431@adalia.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [nemo] comments on "Tree Discovery" draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Pascal, I have read the "Nested NEMO Tree Discovery" draft and have some comments as follows. 1. In section 1, "if loops are avoided, the nested NEMO assumes the shape of a tree." It is not clear to me which one is described here, the real topology of nested nemo or the abstract model of that topology? What relationship between MRs is represented by the edge in the "tree"? In the multihoming nested nemo, the topology of NEMO is not a tree. I think a Directed Acyclic Graph where N is a set of nodes and E is a set of directed links is a more general model. MR and/or LFN/VMN belongs to E and there is a directed link from i to j, i->j as long as j achieves the care of address from i. 2.In the first papragraph in section 3.1, it seems to me that there is no direct connection with the following text. Maybe delete it? 3. The draft descibes the state transitions in section 5.3. A state machine diagram will be helpful. 4. This draft proposes to use the RA message to carry TIO. I wonder how to pretect and verify those messages? A black hole attack is easily launched. Thanks for all the replies. Sincerely, fan From nemo-bounces@ietf.org Wed Aug 25 12:41:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29607 for ; Wed, 25 Aug 2004 12:41:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C00UF-0001iJ-KK; Wed, 25 Aug 2004 12:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C008I-0006Z6-62 for nemo@megatron.ietf.org; Wed, 25 Aug 2004 11:56:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26021 for ; Wed, 25 Aug 2004 11:56:14 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0090-0004f3-PE for nemo@ietf.org; Wed, 25 Aug 2004 11:57:04 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2004 18:07:20 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7PFtVua012799; Wed, 25 Aug 2004 17:55:40 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 17:55:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Wed, 25 Aug 2004 17:55:31 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103B60@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSKlBT6qwAJBwdMQoOUm9XTgKaTzgAIsYzg From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , X-OriginalArrivalTime: 25 Aug 2004 15:55:38.0261 (UTC) FILETIME=[F71D0C50:01C48ABB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Content-Transfer-Encoding: quoted-printable Hi Fan :) Thanks for your interest. 2 high level points here: 1) I provide some (sometimes the obvious) response your questions inline but my understanding is that what you really want is more clarity in the doc. So thanks for your points and I'll go revisit the text for version 01.=20 2) TD is a proposed solution for issue 24. One question is whether people feel that this is a real important issue for NEMO, whether its RO only, whether we need to do anything here at all. I'd appreciate your point of view on this. >=20 > I have read the "Nested NEMO Tree Discovery" draft and have some > comments as follows. >=20 > 1. In section 1, "if loops are avoided, the nested NEMO assumes the > shape of a tree." It is not clear to me which one is described here, > the real topology of nested nemo or the abstract model of that topology? You're right. It's the NEMO abstraction that's a tree.=20 > What relationship between MRs is represented by the edge in the "tree"? TD as described is for nemo basic; as such, MRs form a single primary careof that they use for registration. So a node is attached to another one if it formed its primary careof from it and installed it as its default gateway. > In the multihoming nested nemo, the topology of NEMO is not a tree. I think > a Directed Acyclic Graph where N is a set of nodes > and E is a set of directed links is a more general model. MR and/or > LFN/VMN > belongs to E and there is a directed link from i to j, i->j as long as j > achieves the care of address from i. Multihoming makes the picture more complex. We could limit to a set of overlapping trees rooted at the various exits. We could also form DAGs as you suggest. If -as I expect- you direct them towards the exits, that would be overlapping DAGS, one per root-MR. The TIO can help build that as well. You could also imagine one DAG per nested MR and reverse DAG forwarding to get out, but that will be much harder to set up, maybe using a link state manet.=20 Anyway this is way too much for nemo basic :) >=20 > 2.In the first papragraph in section 3.1, it seems to me that there is no > direct connection with the following text. Maybe delete it? It justifies the need for multihoming and the next paragraph explains that in the nested case, he router selection draft is not enough.... =20 > 3. The draft descibes the state transitions in section 5.3. A state machine > diagram will be helpful. OK > 4. This draft proposes to use the RA message to carry TIO. > I wonder how to pretect and verify those messages? > A black hole attack is easily launched. Right. Do you think that the usual suspects (L2 access control, SeND...) are either insufficient or inappropriate?=20 Pascal From nemo-bounces@ietf.org Wed Aug 25 14:14:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06309 for ; Wed, 25 Aug 2004 14:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01sE-0007Wy-Iv; Wed, 25 Aug 2004 13:47:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01dx-00058E-5r for nemo@megatron.ietf.org; Wed, 25 Aug 2004 13:33:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03485 for ; Wed, 25 Aug 2004 13:32:59 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01eb-0006TG-WD for nemo@ietf.org; Wed, 25 Aug 2004 13:33:48 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7PHOLGU005463; Wed, 25 Aug 2004 10:24:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i7PHNIhL011553; Wed, 25 Aug 2004 12:23:19 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 466FF88043E; Wed, 25 Aug 2004 19:23:18 +0200 (CEST) Message-ID: <412CCAFF.80107@motorola.com> Date: Wed, 25 Aug 2004 19:23:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103B60@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103B60@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5424B82D32DA84D0EF146FA" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5424B82D32DA84D0EF146FA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 2) TD is a proposed solution for issue 24. One question is whether > people feel that this is a real important issue for NEMO, whether its > RO only, whether we need to do anything here at all. I'd appreciate > your point of view on this. I doubt the name Tree Discovery fits. I'd call it Tree Building (like in team building) or something. In a graph topology there's no tree to be discovered but rather a sort of virtual tree to be overlayed over the existing graph. And, speaking of which, I'm sure OSPF builds spanning trees, which may even be minimal. Which leads me to offer my humble point of view replying to your request: investigate instead the use of OSPF within an aggregation of moving networks. Which raises the question: why not. > 4. The Nemo ClusterHead of a tree exposes the tree in the RA/TIO and > MRs propagate the TIO down the tree with the RAs that they forward > over their ingress links. Does this mean somehow that the "deeper" the tree the larger size the "leaf" RA's will be (because including many many TIO's)? IMHO... Alex --------------enigE5424B82D32DA84D0EF146FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLMsGMmC0w56zj54RAuO0AJ9JCECWR7oyCBNUf3SFcUtEHaJ7GgCfeFId l/HlQSiG5kJoiHgF4rwfglM= =F5PH -----END PGP SIGNATURE----- --------------enigE5424B82D32DA84D0EF146FA-- From nemo-bounces@ietf.org Wed Aug 25 14:16:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06477 for ; Wed, 25 Aug 2004 14:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01uR-0007na-BW; Wed, 25 Aug 2004 13:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01iQ-0005SF-Nz for nemo@megatron.ietf.org; Wed, 25 Aug 2004 13:37:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03681 for ; Wed, 25 Aug 2004 13:37:36 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01j6-0006XU-Km for nemo@ietf.org; Wed, 25 Aug 2004 13:38:25 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i7PHTcTw002457; Wed, 25 Aug 2004 10:29:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7PHZkqw008339; Wed, 25 Aug 2004 12:35:46 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A25F988043E; Wed, 25 Aug 2004 19:36:00 +0200 (CEST) Message-ID: <412CCDFA.8060602@motorola.com> Date: Wed, 25 Aug 2004 19:35:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103B60@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103B60@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF6A4639BC4CC4936B45068B" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF6A4639BC4CC4936B45068B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > You could also imagine one DAG per nested MR and reverse DAG > forwarding to get out, but that will be much harder to set up, maybe > using a link state manet. YEs, wouldn't a link-state manet help with all this tree discovery stuff? Especially with the A in DAG, i.e. avoiding loops? > Anyway this is way too much for nemo basic :) I agree, Alex --------------enigAF6A4639BC4CC4936B45068B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLM4AMmC0w56zj54RAgyaAJ9BE0y56JBxNwvwfpbHJDI2mOWbggCg7wp5 aNTcKgWCMFGhEdrIFlxr2iA= =yeqR -----END PGP SIGNATURE----- --------------enigAF6A4639BC4CC4936B45068B-- From nemo-bounces@ietf.org Thu Aug 26 10:35:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05154 for ; Thu, 26 Aug 2004 10:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L6C-0001SL-41; Thu, 26 Aug 2004 10:19:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0KmQ-00014h-EG for nemo@megatron.ietf.org; Thu, 26 Aug 2004 09:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01070 for ; Thu, 26 Aug 2004 09:59:04 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0KnL-0004VU-UB for nemo@ietf.org; Thu, 26 Aug 2004 10:00:05 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 16:10:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7QDvvOQ003550; Thu, 26 Aug 2004 15:58:30 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:58:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Thu, 26 Aug 2004 15:55:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103CEF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSLbwr+sE4gtJ03SS2WFzQW0eWGhgABRl2A From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Aug 2004 13:58:26.0616 (UTC) FILETIME=[C256EB80:01C48B74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Content-Transfer-Encoding: quoted-printable > I don't see flows in the draft and I can't find "flow" either... TD does not add messages to ND. It is expected that RAs are well understood by now. But yes, I could add a picture showing how an RA is propagated down the tree. Pascal=20 From nemo-bounces@ietf.org Thu Aug 26 10:36:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05476 for ; Thu, 26 Aug 2004 10:36:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L6C-0001Sn-J0; Thu, 26 Aug 2004 10:19:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0KmR-00015J-Tt for nemo@megatron.ietf.org; Thu, 26 Aug 2004 09:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01073 for ; Thu, 26 Aug 2004 09:59:06 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0KnN-0004VU-LP for nemo@ietf.org; Thu, 26 Aug 2004 10:00:07 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 16:10:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7QDw4OU003562; Thu, 26 Aug 2004 15:58:30 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:58:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Thu, 26 Aug 2004 15:58:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103CF0@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSLbwr+sE4gtJ03SS2WFzQW0eWGhgABU/wQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Aug 2004 13:58:26.0803 (UTC) FILETIME=[C2737430:01C48B74] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Content-Transfer-Encoding: quoted-printable > > Sure. Is issue 24 a problem that we want to handle for NEMO? Or do > > we leave it all to MANET/OSPF? >=20 > As I said in my reply on Issue 24 itself, I do not see that to be a > problem. The looping described in issue 24 assumes simultaneous L2 > connectivity of one interface to two wireless access systems, something > impossible. That problem has not been refined since. That is not a > problem, and so it can not be solved in NEMO and in no other WG present > or future. >=20 > The RA confliction problem can never appear in practice once the various > wireless access systems covering a common area are (1) different in > nature, frequency, encoding or (2) protected by different sec keys. If > two such systems fail both conditions, L2 connectivity is unclear, a > much bigger problem that the little NEMO Mobile IPv6 support. The so called RA confliction is just a very narrow instance of the loop problem. Jari's case had 3 routers forming careofs from each other in a loop. No way out. The discussion was that since they can not bind, one would eventually try a careof from an available AR and make it. Then another would eventually use that successful MR and bind via it, etc... Obviously, this takes the longest time and does not produce an optimal path to the outside. Pascal From nemo-bounces@ietf.org Thu Aug 26 10:40:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05936 for ; Thu, 26 Aug 2004 10:40:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L6Q-0001eg-9K; Thu, 26 Aug 2004 10:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L02-00070F-SW for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:13:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28714 for ; Thu, 26 Aug 2004 09:17:22 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0K90-0003pg-0r for nemo@ietf.org; Thu, 26 Aug 2004 09:18:22 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7QDGmOS012800; Thu, 26 Aug 2004 06:16:48 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7QD8nQ1029137; Thu, 26 Aug 2004 08:08:51 -0500 Message-ID: <412DE2B4.8080502@motorola.com> Date: Thu, 26 Aug 2004 15:16:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103C74@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103C74@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF94DB96DD4C47901E66E1F5B" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF94DB96DD4C47901E66E1F5B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > A typical example is cars in a city. You have a number of antennas > distributed in buildings, but down there, there are a lot of shadow > area. So cars will hop over other cars. Yes, but related to quickness, to you think an individual car will have to change its CoA very often per second, from connecting to the car in front to connecting to the now-visible AP on a building? It is true that our human perception of many little cars moving in a crowded city streets makes think of Brownian movement, and one-to-one packet-switched communication (instead of broadcast) looks like an interesting challenge. But throw over this some blanket wireless coverage areas (or "canopies", adv.) and the picture is different, to me. > But it is clear that my connectivity is impacted by its movements, > and I wan to know what I get from him vs other potential attachment > routers. With TD I can swap at anytime. With OSPF, changing the > neighbors impact the whole AS dramatically? And what is my AS, > anyway? "dramattically" depends to the size of that AS, so let's make your AS be a small set of routers. Let's say that a NEMO OSPF AS can have maximum 10 MR's, thus impact is manageable with current hardware, a speculation. Couple to this the necessity to have a single OSPF area for each MR and its HA pair. > There's a lot we have to figure out about metrics. E.g; Even if you > have little relative movement with the car in front of you that you > hop over, it's hard to define if itself will see the antenna for a > long time or in a short window. The thing is building this logical > tree simplifies the problem set and makes it manageable. Right, trying to predict where the device moves is very difficult. > Did you look at the draft? Yes, quickly. > You may compare the flows with what it take to establish neighbouring > and distribute the databases. I don't see flows in the draft and I can't find "flow" either... >>> If you are interested in the applicability of OSPF in a MANET >>> environment, please have a look at the activities that now take >>> place in the OSPF and MANET WGs on that respect. You'll find that >>> it's a great idea and that there's a lot of work to get there. >>> One good thing for MANET is that OSPFv3 uses linklocal whereas v2 >>> requires that peers have an address on the same network. >>> >>> Then again, it would be slower than TD for many applications. TD >>> is not a routing protocol, it's much simpler and quicker. It does >>> just what nested nemo needs to get out. If it doesn't grow up into a routing protocol then it'll never avoid loops and offer short paths. BTW, do you think loops are impossible with TD? > Sure. Is issue 24 a problem that we want to handle for NEMO? Or do > we leave it all to MANET/OSPF? As I said in my reply on Issue 24 itself, I do not see that to be a problem. The looping described in issue 24 assumes simultaneous L2 connectivity of one interface to two wireless access systems, something impossible. That problem has not been refined since. That is not a problem, and so it can not be solved in NEMO and in no other WG present or future. The RA confliction problem can never appear in practice once the various wireless access systems covering a common area are (1) different in nature, frequency, encoding or (2) protected by different sec keys. If two such systems fail both conditions, L2 connectivity is unclear, a much bigger problem that the little NEMO Mobile IPv6 support. The "cross-over" tunnels problem still holds as a NEMO problem. The "disconnected operation" problem still holds as a NEMO problem. Unoptimal long multi-angular paths looks like a NEMO problem. > The assumption in TD is that building that tree and only that tree is > enough for nested nemo operation with the infrastructure, and can be > done quicker than if you use an abstraction that handles more > meshing. The implementation delivers an actual proof of that, but if > you just look at the flow What flow? Do you mean the numbered list 1-9 of rules and definitions that MUST be followed by all Mobile Routers in section 5 Tree Discovery? Alex --------------enigF94DB96DD4C47901E66E1F5B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLeK6MmC0w56zj54RAlSVAKCH241I+7fZoSSLUHv4j6+xckjZuQCgjqrC Lx53o8byh+M9XIpxJxXGzeA= =G6N1 -----END PGP SIGNATURE----- --------------enigF94DB96DD4C47901E66E1F5B-- From nemo-bounces@ietf.org Thu Aug 26 10:58:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08044 for ; Thu, 26 Aug 2004 10:58:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LaZ-0001IY-QD; Thu, 26 Aug 2004 10:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LH0-0004GR-0F for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24241 for ; Thu, 26 Aug 2004 07:56:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0IsL-0002Jt-Ms for nemo@ietf.org; Thu, 26 Aug 2004 07:57:07 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 14:06:27 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7QBs1O6008979; Thu, 26 Aug 2004 13:54:04 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 13:53:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Thu, 26 Aug 2004 13:53:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103C74@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSLS1DNB7sMLnKtT6ujoYrIp9RrCQAFg/pw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Aug 2004 11:53:57.0744 (UTC) FILETIME=[5E8B7F00:01C48B63] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Content-Transfer-Encoding: quoted-printable Hi Alex: all good questions :) see inline > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: jeudi 26 ao=FBt 2004 11:00 > To: Pascal Thubert (pthubert) > Cc: Fan Zhao; nemo@ietf.org > Subject: Re: [nemo] comments on "Tree Discovery" draft >=20 > Pascal Thubert (pthubert) wrote: > >> existing graph. And, speaking of which, I'm sure OSPF builds > >> spanning trees, which may even be minimal. > >> > >> Which leads me to offer my humble point of view replying to your > >> request: investigate instead the use of OSPF within an aggregation > >> of moving networks. Which raises the question: why not. > >> > > Well the key is how quickly things come up, and how the solution > > being deployed survives quick movements. TD is optimized to obtain > > one tree, and it does it in one pass. >=20 > Look, I'm eager to find a more expressive definition of this "quick" > word. What is a "quick movement" by the way. In Mobile IP terms, it = is > something related to how often the CoA is changed per time unit (e.g. = 3 > CoA changes per second is quick, 1 CoA per second is normal and 10 CoA > per second is very quick). Note how different is this from the = physics > terms where speed is physical distance over time; this physical > "quickness" is in no way related to the Mobile IP quickness because > there may be very large rectilinear areas where you go 220km/h and = still > don't change the CoA (Mobile IP "quickness" is really below normal). >=20 > So, having this in mind, do you have an idea of a practical setup = where > the NEMO MR's nest and form aggregations and at the same time they are > very "quick" in terms of Mobile IP to each other. I do agree with that definition of CoA change rate. A typical example is = cars in a city. You have a number of antennas distributed in buildings, = but down there, there are a lot of shadow area. So cars will hop over = other cars. But it is clear that my connectivity is impacted by its = movements, and I wan to know what I get from him vs other potential = attachment routers. With TD I can swap at anytime. With OSPF, changing = the neighbors impact the whole AS dramatically? And what is my AS, = anyway? There's a lot we have to figure out about metrics. E.g; Even if you have = little relative movement with the car in front of you that you hop over, = it's hard to define if itself will see the antenna for a long time or in = a short window. The thing is building this logical tree simplifies the = problem set and makes it manageable. Did you look at the draft? You may = compare the flows with what it take to establish neighbouring and = distribute the databases. > > If you are interested in the applicability of OSPF in a MANET > > environment, please have a look at the activities that now take = place > > in the OSPF and MANET WGs on that respect. You'll find that it's a > > great idea and that there's a lot of work to get there. One good > > thing for MANET is that OSPFv3 uses linklocal whereas v2 requires > > that peers have an address on the same network. > > > > Then again, it would be slower than TD for many applications. TD is > > not a routing protocol, it's much simpler and quicker. It does just > > what nested nemo needs to get out. >=20 > TD is quicker than what? TD is "quicker" like accomodating quicker MR > movements? How many CoA changes per second per MR would TD support > compared to OSPF? Sure.=20 Is issue 24 a problem that we want to handle for NEMO? Or do we leave = it all to MANET/OSPF?=20 The assumption in TD is that building that tree and only that tree is = enough for nested nemo operation with the infrastructure, and can be = done quicker than if you use an abstraction that handles more meshing. = The implementation delivers an actual proof of that, but if you just = look at the flow, TD is part of ND, which happens before the hello = protocol even starts. Pascal From nemo-bounces@ietf.org Thu Aug 26 11:01:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08242 for ; Thu, 26 Aug 2004 11:01:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Lad-0001L0-Hs; Thu, 26 Aug 2004 10:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LHU-0004Pe-Tg for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16371 for ; Thu, 26 Aug 2004 05:01:39 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0G9T-0007vA-Tx for nemo@ietf.org; Thu, 26 Aug 2004 05:02:37 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7Q90dOS016941; Thu, 26 Aug 2004 02:00:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7Q8qiQ1009184; Thu, 26 Aug 2004 03:52:45 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 149A488CF79; Thu, 26 Aug 2004 11:00:37 +0200 (CEST) Message-ID: <412DA6A9.4070408@motorola.com> Date: Thu, 26 Aug 2004 11:00:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103BDC@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103BDC@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBAE9C529848B238746FAF8DC" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBAE9C529848B238746FAF8DC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> existing graph. And, speaking of which, I'm sure OSPF builds >> spanning trees, which may even be minimal. >> >> Which leads me to offer my humble point of view replying to your >> request: investigate instead the use of OSPF within an aggregation >> of moving networks. Which raises the question: why not. >> > Well the key is how quickly things come up, and how the solution > being deployed survives quick movements. TD is optimized to obtain > one tree, and it does it in one pass. Look, I'm eager to find a more expressive definition of this "quick" word. What is a "quick movement" by the way. In Mobile IP terms, it is something related to how often the CoA is changed per time unit (e.g. 3 CoA changes per second is quick, 1 CoA per second is normal and 10 CoA per second is very quick). Note how different is this from the physics terms where speed is physical distance over time; this physical "quickness" is in no way related to the Mobile IP quickness because there may be very large rectilinear areas where you go 220km/h and still don't change the CoA (Mobile IP "quickness" is really below normal). So, having this in mind, do you have an idea of a practical setup where the NEMO MR's nest and form aggregations and at the same time they are very "quick" in terms of Mobile IP to each other. > If you are interested in the applicability of OSPF in a MANET > environment, please have a look at the activities that now take place > in the OSPF and MANET WGs on that respect. You'll find that it's a > great idea and that there's a lot of work to get there. One good > thing for MANET is that OSPFv3 uses linklocal whereas v2 requires > that peers have an address on the same network. > > Then again, it would be slower than TD for many applications. TD is > not a routing protocol, it's much simpler and quicker. It does just > what nested nemo needs to get out. TD is quicker than what? TD is "quicker" like accomodating quicker MR movements? How many CoA changes per second per MR would TD support compared to OSPF? Alex --------------enigBAE9C529848B238746FAF8DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLaa0MmC0w56zj54RAiqrAKDAVf0woypyvSTILC6NG4tNn7RD6wCfRENb qRQX7eB5XMtEDI9gHPt5wWA= =3kwN -----END PGP SIGNATURE----- --------------enigBAE9C529848B238746FAF8DC-- From nemo-bounces@ietf.org Thu Aug 26 11:10:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09149 for ; Thu, 26 Aug 2004 11:10:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Lam-0001W4-Pk; Thu, 26 Aug 2004 10:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LIu-0004om-AZ for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04478 for ; Thu, 26 Aug 2004 10:32:38 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0LJq-0005Gg-An for nemo@ietf.org; Thu, 26 Aug 2004 10:33:39 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7QEUpOS016076; Thu, 26 Aug 2004 07:30:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7QEUnrV030815; Thu, 26 Aug 2004 09:30:49 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A6FFF88CF7B; Thu, 26 Aug 2004 16:30:48 +0200 (CEST) Message-ID: <412DF412.8060608@motorola.com> Date: Thu, 26 Aug 2004 16:30:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103CF0@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103CF0@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4DF83FC593BB7DB5FE005675" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4DF83FC593BB7DB5FE005675 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The so called RA confliction is just a very narrow instance of the > loop problem. I'd say the reverse. The RA confliction problem is more generic and the Jari problem is very narrow; RA confliction description involves only one router and with it says all, no need to depict three routers to express the same problem. RA confliction problem has a MR with two wireless interfaces. The egress interface receives RA from the ingress, configures CoA and sends BU over wireless towards its own ingress interface, receives it, and will not encapsulate it again towards its egress interface because it has not yet received a BAck. Actually this BAck will never come so no loop nor infinite encapsulation. The RA confliction problem assumes that the egress and ingress interface of MR can talk to each other wirelessly. In 802.11b this is the case _only_ if they both use ESSID, or same keys, or same ad-hoc mode, or any other same something. This is bad configuration, not bad protocol. Please disagree with a more exact setup using any wireless techno. > Jari's case had 3 routers forming careofs from each other in a loop. > No way out. The discussion was that since they can not bind, one > would eventually try a careof from an available AR and make it. YEs, and at this exact point, when this successful MR connects to AR it cuts its egress connection to any other MR (keeping its ingress). Thus, no loop. > Then another would eventually use that successful MR and bind via it, > etc... Fact which does not lead to a loop. Alex --------------enig4DF83FC593BB7DB5FE005675 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLfQYMmC0w56zj54RAhXLAJ9cLkz1Xiq9Y7min0sAVQN7p0lyHQCguTwo oVTBybLEmJyKN2LqwcLIRQ4= =IiJT -----END PGP SIGNATURE----- --------------enig4DF83FC593BB7DB5FE005675-- From nemo-bounces@ietf.org Thu Aug 26 11:23:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10699 for ; Thu, 26 Aug 2004 11:23:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LeC-00033K-Bc; Thu, 26 Aug 2004 10:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LTd-0007kT-UX for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:43:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13551 for ; Thu, 26 Aug 2004 03:49:05 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0F1E-0006Zo-P3 for nemo@ietf.org; Thu, 26 Aug 2004 03:50:02 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 09:59:46 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7Q7lcOC002079; Thu, 26 Aug 2004 09:47:49 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 09:47:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Thu, 26 Aug 2004 09:47:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103BDC@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSKyb2dZbmyLKv9TSKLGeA4lpNOJgAdgxYQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Aug 2004 07:47:37.0918 (UTC) FILETIME=[F51505E0:01C48B40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Content-Transfer-Encoding: quoted-printable > > 2) TD is a proposed solution for issue 24. One question is whether > > people feel that this is a real important issue for NEMO, whether its > > RO only, whether we need to do anything here at all. I'd appreciate > > your point of view on this. >=20 > I doubt the name Tree Discovery fits. I'd call it Tree Building (like > in team building) or something. In a graph topology there's no tree to > be discovered but rather a sort of virtual tree to be overlayed over the > existing graph. And, speaking of which, I'm sure OSPF builds spanning > trees, which may even be minimal. >=20 > Which leads me to offer my humble point of view replying to your > request: investigate instead the use of OSPF within an aggregation of > moving networks. Which raises the question: why not. >=20 Well the key is how quickly things come up, and how the solution being deployed survives quick movements. TD is optimized to obtain one tree, and it does it in one pass.=20 If you are interested in the applicability of OSPF in a MANET environment, please have a look at the activities that now take place in the OSPF and MANET WGs on that respect. You'll find that it's a great idea and that there's a lot of work to get there. One good thing for MANET is that OSPFv3 uses linklocal whereas v2 requires that peers have an address on the same network.=20 Then again, it would be slower than TD for many applications. TD is not a routing protocol, it's much simpler and quicker. It does just what nested nemo needs to get out. Pascal From nemo-bounces@ietf.org Thu Aug 26 11:35:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11952 for ; Thu, 26 Aug 2004 11:35:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0MAw-0003Pe-W5; Thu, 26 Aug 2004 11:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LjC-0004NV-U7 for nemo@megatron.ietf.org; Thu, 26 Aug 2004 10:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08092 for ; Thu, 26 Aug 2004 10:59:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0LkA-0006FY-4i for nemo@ietf.org; Thu, 26 Aug 2004 11:00:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 17:11:14 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7QEwbOc014398; Thu, 26 Aug 2004 16:59:15 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:59:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on "Tree Discovery" draft Date: Thu, 26 Aug 2004 16:59:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSLeZByVfxoBqNnT22yXGON7+vSyAAApGaQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Aug 2004 14:59:10.0108 (UTC) FILETIME=[3E07ADC0:01C48B7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: jeudi 26 ao=FBt 2004 16:31 > To: Pascal Thubert (pthubert) > Cc: Fan Zhao; nemo@ietf.org > Subject: Re: [nemo] comments on "Tree Discovery" draft >=20 > Pascal Thubert (pthubert) wrote: > > The so called RA confliction is just a very narrow instance of the > > loop problem. >=20 > I'd say the reverse. The RA confliction problem is more generic and = the > Jari problem is very narrow; RA confliction description involves only > one router and with it says all, no need to depict three routers to > express the same problem. >=20 > RA confliction problem has a MR with two wireless interfaces. The > egress interface receives RA from the ingress, configures CoA and = sends > BU over wireless towards its own ingress interface, receives it, and > will not encapsulate it again towards its egress interface because it > has not yet received a BAck. Actually this BAck will never come so no > loop nor infinite encapsulation. >=20 > The RA confliction problem assumes that the egress and ingress = interface > of MR can talk to each other wirelessly. In 802.11b this is the case > _only_ if they both use ESSID, or same keys, or same ad-hoc mode, or = any > other same something. This is bad configuration, not bad protocol. >=20 > Please disagree with a more exact setup using any wireless techno. It's very easy for a MR to detect a loop with itself. The RA has its own = prefix and in MIP, it's own address. Since the prefix is already present = on the ingress interface, the router will not create an address and a = connected route on the egress. This, no effect. What is impossible for a = MR is that 3 hops away in a chain of careof, there's itself again. >=20 > > Jari's case had 3 routers forming careofs from each other in a loop. > > No way out. The discussion was that since they can not bind, one > > would eventually try a careof from an available AR and make it. >=20 > YEs, and at this exact point, when this successful MR connects to AR = it > cuts its egress connection to any other MR (keeping its ingress). = Thus, > no loop. >=20 > > Then another would eventually use that successful MR and bind via = it, > > etc... >=20 > Fact which does not lead to a loop. Yes, this is the reason why we could neglect the issue. Please see the = slides on the nemo site:=20 http://www.mobilenetworks.org/nemo/ietf60/nemo-ietf60-RO-TreeDiscovery.pd= f =20 You'll fond my words:" Without a coordination - the startup of a nested nemo is very slow - the shape of the resulting tree is not optimized " This is what TD is improving. Quite dramatically. Pascal From nemo-bounces@ietf.org Thu Aug 26 12:20:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15362 for ; Thu, 26 Aug 2004 12:20:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Mmv-0004Jx-3z; Thu, 26 Aug 2004 12:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0MeK-00028y-DQ for nemo@megatron.ietf.org; Thu, 26 Aug 2004 11:58:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13801 for ; Thu, 26 Aug 2004 11:58:49 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0MfF-0007uB-GP for nemo@ietf.org; Thu, 26 Aug 2004 11:59:52 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7QFldGU029526; Thu, 26 Aug 2004 08:47:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i7QFjMlx025305; Thu, 26 Aug 2004 10:45:22 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id EE77D88CF7B; Thu, 26 Aug 2004 17:46:35 +0200 (CEST) Message-ID: <412E05D5.2090600@motorola.com> Date: Thu, 26 Aug 2004 17:46:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C0963834E5F05F43150A20F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C0963834E5F05F43150A20F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > It's very easy for a MR to detect a loop with itself. The RA has its > own prefix and in MIP, it's own address. Since the prefix is already > present on the ingress interface, the router will not create an > address and a connected route on the egress. This, no effect. Ok. > What is impossible for a MR is that 3 hops away in a chain of careof, > there's itself again. Ah, I see. Can we talk about only two MR's instead of 3? So assume two MR's like this: +---> MR1 -> MR2 ->+ | | +------------------+ MR1's egress is to MR2's ingress and MR2 egress is to MR1's ingress. MR1's BU goes to MR2. And MR2's BU goes to MR1. Neither MR1 nor MR2 will send those BU's any further because none has received the corresponding BAck's expected from their respective HA's. So this is not a "loop" but a sort of a deadlock. What else would one expect from a topology set in a loop. A protocol - whatever that is - can not prevent people from arranging computers in a certain way such that nothing works. >> Fact which does not lead to a loop. > > Yes, this is the reason why we could neglect the issue. Please see > the slides on the nemo site: > http://www.mobilenetworks.org/nemo/ietf60/nemo-ietf60-RO-TreeDiscovery.pdf I've studied them once posted. Nice graphs. They seem to be optimizing something but not raising any actual unsolved problem. In a nested aggregation of moving networks, any number of MR's, any number of interfaces per MR, forming any arbitrary topology, all MR's will be able to send their BU's as long as each one uses a unique default route. This can be guaranteed by designating a unique interface on each MR to be _the_ outgoing (or egress) interface. There will be no loops. If, on the other hand, I think about the dangers of each MR changing its default route at the reception of a new RA on a different interface, then there can be instabilities, loops, etc. This may be seen as a problem at the first glance. But then if I think about this as fixed routers, not MR's, that form a graph, they'd still have the same problems. Fixed routers manage this with routing protocols, or statically assigned routes. And even so, they'd always have a unique default route. "Preventing loops in nested NEMO topology" I don't think there are loops in a nested NEMO topology as long as each router uses a unique default route. "Optimize Default Route selection into shallow trees" Why shallow and not deep. Anyways, seems to be about optimizing, as I said. "Attachment selection fixed vs Mobile Router" What? "Which metrics" This is indeed a good question. Hop count is a good metric. "Fast reconfiguration upon movements" Brings back our other issue about movements. Your optimization seems to imply that there are fast movements that are inducing some drawbacks and that TD may keep up with those fast movements (while other solutions may not). That's maybe a problem, but let's define it, see it in practice and only then optimize it. Or does it mean that only a unique minor movement of one MR may induce large changes in the routing tables of the nested NEMO aggregation and OSPF does not cope with, while TD does? > You'll fond my words:" Without a coordination - the startup of a > nested nemo is very slow - the shape of the resulting tree is not > optimized " This is what TD is improving. Quite dramatically. Ok, I think TD is a solution but we're not quite sure about the problem. Alex --------------enig3C0963834E5F05F43150A20F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLgXbMmC0w56zj54RAtsPAJ49SrFkLAfKMb52wfGoJ7NIXEepgwCg9bMR Vn+wjgvvDMDa9auyXzzPpQQ= =krO4 -----END PGP SIGNATURE----- --------------enig3C0963834E5F05F43150A20F-- From nemo-bounces@ietf.org Thu Aug 26 12:29:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16078 for ; Thu, 26 Aug 2004 12:29:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0N0G-0000ue-UG; Thu, 26 Aug 2004 12:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Mre-0005yE-Id for nemo@megatron.ietf.org; Thu, 26 Aug 2004 12:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14916 for ; Thu, 26 Aug 2004 12:12:36 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0Msb-0008Es-CX for nemo@ietf.org; Thu, 26 Aug 2004 12:13:38 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i7QG9eck003784; Thu, 26 Aug 2004 09:09:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7QG9Oqw004575; Thu, 26 Aug 2004 11:09:24 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8BFF088CF7B; Thu, 26 Aug 2004 18:09:38 +0200 (CEST) Message-ID: <412E0B3D.1020007@motorola.com> Date: Thu, 26 Aug 2004 18:09:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD037843110832F49EC21C30" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD037843110832F49EC21C30 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > You'll fond my words:" > Without a coordination > - the startup of a nested nemo is very slow > - the shape of the resulting tree is not optimized > " > This is what TD is improving. Quite dramatically. Come on, in what is a shallow tree better than a "resulting tree" and better than a deep tree in terms of NEMO? This risks seeing a DT (reverse TD) proposal that builds a deep tree instead, and claiming also that it's better. Is there a NEMO problem in having arbitrary-tree topologies of nested moving networks? Besides, if there are loops in any nested aggregation of moving networks, they obviously don't depend on the tree being shallow or deep... Alex --------------enigCD037843110832F49EC21C30 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLgtCMmC0w56zj54RArpoAJ0fnAeE6EbM7z2F5ehIJtuzpBKWhACg2y49 qC1RiaoOhaSZyYAqDIRJ1Uw= =4A0f -----END PGP SIGNATURE----- --------------enigCD037843110832F49EC21C30-- From nemo-bounces@ietf.org Thu Aug 26 12:39:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17026 for ; Thu, 26 Aug 2004 12:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0N0M-0000xV-EV; Thu, 26 Aug 2004 12:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Mua-00074u-DN for nemo@megatron.ietf.org; Thu, 26 Aug 2004 12:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15111 for ; Thu, 26 Aug 2004 12:15:38 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0MvV-0008Iv-Fb for nemo@ietf.org; Thu, 26 Aug 2004 12:16:40 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7QFwvGU009156; Thu, 26 Aug 2004 08:58:58 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i7QFvshL014686; Thu, 26 Aug 2004 10:57:55 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5842688CF7C; Thu, 26 Aug 2004 17:57:54 +0200 (CEST) Message-ID: <412E0877.5030105@motorola.com> Date: Thu, 26 Aug 2004 17:57:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103D1F@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD70509C7DCA65C6A5B25228F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD70509C7DCA65C6A5B25228F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > You'll fond my words:" Without a coordination - the startup of a > nested nemo is very slow - the shape of the resulting tree is not > optimized " This is what TD is improving. Quite dramatically. TD draft: > In order to build trees of Mobile Routers, we propose an extension to > the ICMP Router Advertisement (RA) message, the Tree Information > Option (TIO). The RA/TIO allows MRs to advertise the tree they belong > to, and to select and move to the best location within the available > trees. MRs propagate the TIO down the tree, updating some metrics > such as the tree depth, leaving alone root information such as the > tree identifier, and sending the result in RAs over the ingress > interfaces. Propagating information from a received RA down in another RA is getting TD out of the scope of ND (of which it is a "minimum extension") in a quite substantial way. ND is scoped to a link only. (RFC2461: "IPv6 nodes on the same link use Neighbor Discovery"). A large number of proposals for many NEMO aspects rely on some form of propagating RA information. Outside NEMO too, the HMIPv6 MAP option. (I think that whenever there's a need to propagate RA information, one can better do with routing protocols. But in the TD case, I'm not sure about the problem itself.) So let's define a problem first, before enforcing a solution, no? Alex --------------enigD70509C7DCA65C6A5B25228F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLgiCMmC0w56zj54RAgc0AKCRhtNsxLVqClCXeszC/RsYuh8uSgCdFF1X oKBOIv6+CI9gtDqW5rUpfPo= =tHK+ -----END PGP SIGNATURE----- --------------enigD70509C7DCA65C6A5B25228F-- From nemo-bounces@ietf.org Thu Aug 26 12:46:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17577 for ; Thu, 26 Aug 2004 12:46:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0NJ5-00065a-Gs; Thu, 26 Aug 2004 12:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0N5s-0001yQ-4v for nemo@megatron.ietf.org; Thu, 26 Aug 2004 12:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15863 for ; Thu, 26 Aug 2004 12:27:17 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0N6p-0008Vz-5f for nemo@ietf.org; Thu, 26 Aug 2004 12:28:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7QGSIGU005365 for ; Thu, 26 Aug 2004 09:28:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i7QGQ1lx010545 for ; Thu, 26 Aug 2004 11:26:02 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1DB6E88CF7B for ; Thu, 26 Aug 2004 18:27:15 +0200 (CEST) Message-ID: <412E0F5D.6020306@motorola.com> Date: Thu, 26 Aug 2004 18:27:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig28DC23990A2E8C80269F2533" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [nemo] mor comments on TD X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig28DC23990A2E8C80269F2533 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Pascal, here are more comments on TD. I hope I'm not missing something obvious... > When several MRs attach to each other to form a nested Nemo, loops > can be created if they are not explicitely avoided. In the simplest > case, when egress and ingress interfaces of an MR are all wireless, a > mobile router may be listening to Router Advertisement from its own > ingress interface, creating a confliction problem. This is bad configuration. This is something that an administrator should avoid. When a machine has several wireless interfaces each intended to belong to different IP subnets (the case of a typical router) then administrator should enforce this. With 802.11b, it is at least necessary to set up different ESSID's. This is not a NEMO problem. > In the general case, arbitrary attachment of MRs will form graphs > that are not exempt of loops. For instance: Assume a nested Nemo > where MR1 is connected to the infrastructure, and MR3 is attached to > MR2. Say that MR2 can hear both MR3 and MR1 over its wireless egress > interface. If MR2 select MR1, the connectivity to the infrastruture > is provided for all. But if MR2 selects MR3, MR2 and MR3 end up > forming a loop and are disconnected from their Home Agents. See same remark as above. Administrator of MR2 should decide to attach to either MR1 or MR3 based on out-of-band data, that is having some outside knowledge about which of the two MR's actually provides access to the Internet and not to some local loophole. You have this problem with a single laptop (not several) if you walk around your favorite downtown and see a bunch of available AP's and don't know which is actually leading to the Internet. You have the same problem when you're using a PDA getting in a train stopped at the railway station and you don't know which ESSID to use, the train's or the railway station's. Both these cases have been experienced in practice (ask for details). None is NEMO related. If one ever needs options in RA's that say "I'm a better lead to the Internet" then maybe one would use Router Lifetimes such as to use the Default Router stuff. For example, in your above case, when MR3 knows it does not yet have Internet access (because no BAck received) then it should not put Router Lifetime 0 in its RA's. In this way, MR2 will be constrained to automatically choose MR1 as a default route. This may help and no need of TIO. I'll make a separate message with this. > Each MR should be able to make its own attachment router selection > based on its own condition (eg battery level), its own set of > constraints that may not apply to other MRs in the tree, and in > general its own algorithm. As a result, the standardization effort > should concentrate on a common minimum set of rules that must be > common to all MRs in order to prevent routing loops in the nested > NEMO while leaving MRs independent in their AR selection algorithms. On the contrary, I think a standardization effort should look first at the problem to be solved instead of standardizing a proposal whose need is not yet clear. Alex --------------enig28DC23990A2E8C80269F2533 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLg9iMmC0w56zj54RAqh1AKCIuEwphaVXyUBHj92xzkpLKoJlPwCg9fNa 5CkblDiYHwouQrk6oDYQMpE= =QisS -----END PGP SIGNATURE----- --------------enig28DC23990A2E8C80269F2533-- From nemo-bounces@ietf.org Thu Aug 26 12:52:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17848 for ; Thu, 26 Aug 2004 12:52:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0NJg-0006KJ-J4; Thu, 26 Aug 2004 12:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0NDA-000472-8z for nemo@megatron.ietf.org; Thu, 26 Aug 2004 12:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16519 for ; Thu, 26 Aug 2004 12:34:49 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0NE7-0000FE-F4 for nemo@ietf.org; Thu, 26 Aug 2004 12:35:52 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7QGZpGU011572 for ; Thu, 26 Aug 2004 09:35:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i7QGXYlx018835 for ; Thu, 26 Aug 2004 11:33:34 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 11C1B88CF7B for ; Thu, 26 Aug 2004 18:34:48 +0200 (CEST) Message-ID: <412E1121.7000500@motorola.com> Date: Thu, 26 Aug 2004 18:34:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig38ABC0A92401B04261751319" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [nemo] Alternative to TD: forbid MR become AR until BAck received X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38ABC0A92401B04261751319 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I propose that instead of using TD, require MR's to not set Router Lifetime in their RA's on their ingress interfaces to zero, until they haven't received positive BAcks (don't become AR until BAck). Thus, if other MR's attach to it, they know that this MR can not be quite used as a default router. A MR connected to the Internet is a MR that has a tunnel up to its HA and it too has a tunnel to the MR. This may help with the not-so-clear looping problem. This is a matter of configuration, not any protocol matter. Aleex --------------enig38ABC0A92401B04261751319 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLhEnMmC0w56zj54RAvFiAKChXvxQhcCcJw/vf5IoSzZattPQkgCg2Kv2 7FyqiAhOIm+FNWahIXpdLfk= =jFRc -----END PGP SIGNATURE----- --------------enig38ABC0A92401B04261751319-- From nemo-bounces@ietf.org Thu Aug 26 21:20:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00077 for ; Thu, 26 Aug 2004 21:20:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0VO1-0006cc-SP; Thu, 26 Aug 2004 21:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0VKA-0005fu-2J for nemo@megatron.ietf.org; Thu, 26 Aug 2004 21:14:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29771 for ; Thu, 26 Aug 2004 21:14:36 -0400 (EDT) Received: from rome.ucdavis.edu ([169.237.104.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0VLB-0004Ld-OS for nemo@ietf.org; Thu, 26 Aug 2004 21:15:43 -0400 Received: from syrphus.ucdavis.edu (syrphus.ucdavis.edu [169.237.104.152]) by rome.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i7R1ERIr023473; Thu, 26 Aug 2004 18:14:28 -0700 (PDT) Received: from syrphus.ucdavis.edu (localhost [127.0.0.1]) by syrphus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i7R1ERu5028095; Thu, 26 Aug 2004 18:14:27 -0700 (PDT) Received: (from www@localhost) by syrphus.ucdavis.edu (8.12.10/8.12.9/Submit) id i7R1ER4q028094; Thu, 26 Aug 2004 18:14:27 -0700 (PDT) Date: Thu, 26 Aug 2004 18:14:27 -0700 (PDT) Message-Id: <200408270114.i7R1ER4q028094@syrphus.ucdavis.edu> To: nemo@ietf.org Subject: Summary Re: [nemo] comments on "Tree Discovery" draft From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.45] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, Alex and all, I have followed this long discussion and want to sort of make a summary. Hope it helps. Problem statement: When one MR moves to a (nested) NEMO network and wants to connect to the Internet, we need to have an efficient and scalable mechanism for MR to choose which AR to attach to as fast as possible. Note that this problem may share some similarity with others in different scenarios. We need to know whether there is something specific to NEMO here or a more efficient solution works well with this problem in NEMO only but not in other scenarios. There are several possible solutions to this problem. 1. Routing protocol: Routing protocol is running on each MR in order to propagate the connectivity information. However it is heavy in terms of the routing table and slow to propagate and converge when the topology changes. 2. Detection solution: MR may use BU to discover the usable AR to the Internet. Firstly, without any helpful metrics, MR has to randomly select one AR from (maybe) multiple ARs. MR has no idea about AR and may end up with a “bad” (according to its preference) AR even though a better AR is available. Secondly, MR has to start the BU procedure and wait until either BAck arrives or an error is detected. 3. TD is efficient because MR just needs to make a decision based on the received RA and its preference. No state or routing table is needed. However, this doesn’t guarantee the connectivity to the Internet (No one does). MR at least needs to wait until the BU procedure succeeds before sending the data packet. A “shadow” tree may reduce the length of the routing path inside the nested NEMO, but the resulting tree can be any shape because it is totally up to the decision of MR. Do I miss something here? Fan From nemo-bounces@ietf.org Fri Aug 27 04:53:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11002 for ; Fri, 27 Aug 2004 04:53:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cSm-0006XH-BQ; Fri, 27 Aug 2004 04:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cJr-0004RH-Rn for nemo@megatron.ietf.org; Fri, 27 Aug 2004 04:42:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10061 for ; Fri, 27 Aug 2004 04:42:45 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0cKn-00041C-J3 for nemo@ietf.org; Fri, 27 Aug 2004 04:43:57 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7R8gYlU016628 for ; Fri, 27 Aug 2004 10:42:34 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 10:42:34 +0200 Received: from ericsson.com (pcp043189pcs.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT7G7RH; Fri, 27 Aug 2004 10:42:34 +0200 Message-ID: <412EF3FA.1010001@ericsson.com> Date: Fri, 27 Aug 2004 10:42:34 +0200 X-Sybari-Trust: 7a7c1a1e 74470f8f 01232f82 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] mor comments on TD References: <412E0F5D.6020306@motorola.com> In-Reply-To: <412E0F5D.6020306@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 08:42:34.0485 (UTC) FILETIME=[CC66FA50:01C48C11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Hi Pascal, here are more comments on TD. I hope I'm not missing > something obvious... > > >>When several MRs attach to each other to form a nested Nemo, loops >>can be created if they are not explicitely avoided. In the simplest >>case, when egress and ingress interfaces of an MR are all wireless, a >> mobile router may be listening to Router Advertisement from its own >> ingress interface, creating a confliction problem. > > > This is bad configuration. This is something that an administrator > should avoid. When a machine has several wireless interfaces each > intended to belong to different IP subnets (the case of a typical > router) then administrator should enforce this. With 802.11b, it is at > least necessary to set up different ESSID's. This is not a NEMO > problem. I completely agree. This is what I pointed out in San Diego. An administrator wouldn't randomly connect an Ethernet cable to any socket he finds. He needs to have a clear picture of the wiring. Wireless isn't any different. You don't just connect to APs without knowing where they fit in the topology. /Mattias From nemo-bounces@ietf.org Fri Aug 27 06:37:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17454 for ; Fri, 27 Aug 2004 06:37:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0e0w-0008Oj-Dr; Fri, 27 Aug 2004 06:31:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0dxS-0007ow-E1 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 06:27:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16994 for ; Fri, 27 Aug 2004 06:27:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0dyZ-00068I-8F for nemo@ietf.org; Fri, 27 Aug 2004 06:28:56 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 12:39:24 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RAR7O6003862; Fri, 27 Aug 2004 12:27:10 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 12:27:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Alternative to TD: forbid MR become AR until BAck received Date: Fri, 27 Aug 2004 12:27:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Alternative to TD: forbid MR become AR until BAck received Thread-Index: AcSLjb8LauNv/HRcTICjjVtXAW13cgAkMl6g From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "IETF NEMO WG" X-OriginalArrivalTime: 27 Aug 2004 10:27:08.0155 (UTC) FILETIME=[67CD0CB0:01C48C20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Content-Transfer-Encoding: quoted-printable Hi Alex; I agree there's value in looking at that. It could improve both the = speed at which things come up and the shape of the result; so it goes = the right direction. There are limitations though: 1) nodes in the MNP can not form global addresses till the MR is = registered. This prevents a bunch of things including MANET in the = nested structure and limits node to node communication to link local.=20 2) there's not much control/optimization on the resulting shape. 3) What happens when the TLMR moves and looses access?=20 4) The binding lifetime is orders of magnitude longer then RAs that TD = uses. So the reaction to changes may take quite some time. You need to = write up something more complete to detail your proposal=20 5) you know that RRH allows a configuration where a mobile Home Agent is = nested behind its own MRs, and that was presented twice at the WG. Your = proposal kills this kind if stuff. Pascal=20 > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Alexandru Petrescu > Sent: jeudi 26 ao=FBt 2004 18:35 > To: IETF NEMO WG > Subject: [nemo] Alternative to TD: forbid MR become AR until BAck = received >=20 > Hi all, >=20 > I propose that instead of using TD, require MR's to not set Router > Lifetime in their RA's on their ingress interfaces to zero, until > they haven't received positive BAcks (don't become AR until BAck). > Thus, if other MR's attach to it, they know that this MR can not be > quite used as a default router. >=20 > A MR connected to the Internet is a MR that has a tunnel up to its HA > and it too has a tunnel to the MR. >=20 > This may help with the not-so-clear looping problem. >=20 > This is a matter of configuration, not any protocol matter. >=20 > Aleex From nemo-bounces@ietf.org Fri Aug 27 07:08:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19663 for ; Fri, 27 Aug 2004 07:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eWZ-0005jf-0n; Fri, 27 Aug 2004 07:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eMj-0003iX-Gu for nemo@megatron.ietf.org; Fri, 27 Aug 2004 06:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18676 for ; Fri, 27 Aug 2004 06:53:49 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0eNq-0006dE-57 for nemo@ietf.org; Fri, 27 Aug 2004 06:55:02 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i7RAmPVZ021677; Fri, 27 Aug 2004 03:48:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7R8mB4C018025; Fri, 27 Aug 2004 03:48:12 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8783888CF7B; Fri, 27 Aug 2004 12:48:22 +0200 (CEST) Message-ID: <412F116E.3080009@motorola.com> Date: Fri, 27 Aug 2004 12:48:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Alternative to TD: forbid MR become AR until BAck received References: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2E5924CCE9C54C549632E527" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E5924CCE9C54C549632E527 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 1) nodes in the MNP can not form global addresses till the MR is > registered. First, nodes in the moving network immediately under MR _may_ form global addresses, they just won't have a default route if the Router Lifetime is not zero. All other nodes in the moving network (not immediately under MR) may form and addresses and default routes towards their respective FR's. > This prevents a bunch of things including MANET in the nested > structure Which MANET? > and limits node to node communication to link local. This is not a limitation. If the MR is not connected to its HA then nodes under MR don't have to whom to communicate outside the local link. > 2) there's not much control/optimization on the resulting shape. There's no control and no optimization, it just works. > 3) What happens when the TLMR moves and looses access? When TLMR moves and looses access then nodes within the moving network can only talk to each other, this is as natural as it gets. No node in the moving network needs to use TLMR as a default router if that default router is not connected to the Internet. > 4) The binding lifetime is orders of magnitude longer then RAs that > TD uses. So the reaction to changes may take quite some time. Every 4 seconds the MR can know whether it's connected to its HA or not. I find 4 seconds to be enough to avoid loop forming. You find it's too long? Maybe propose something to the MIP6 WG. > You need to write up something more complete to detail your proposal Maybe... before starting writing anything I want to be sure there's a need for that thing, that there's a problem to be solved, that there's value to customers, that it's priority, that there's interoperability needed, etc. > 5) you know that RRH allows a configuration where a mobile Home Agent > is nested behind its own MRs, and that was presented twice at the > WG. Your proposal kills this kind if stuff. Huh??? What is my proposal killing more exactly, I don't get it, frankly speaking. Why mentioning a mobile HA behind its own MR, is this solving "cross-over tunnel" or something? I wouldn't propose anything against that... Alex --------------enig2E5924CCE9C54C549632E527 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLxF2MmC0w56zj54RAr++AKCA5m+WCXy1aLrQd5/L3oBQ0QuCbwCgy8eh 6eSgm4QMw6RBERt3w1lBlGk= =WKIE -----END PGP SIGNATURE----- --------------enig2E5924CCE9C54C549632E527-- From nemo-bounces@ietf.org Fri Aug 27 07:25:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20677 for ; Fri, 27 Aug 2004 07:25:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eph-0000n6-EZ; Fri, 27 Aug 2004 07:23:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0egJ-0007cG-3L for nemo@megatron.ietf.org; Fri, 27 Aug 2004 07:14:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19999 for ; Fri, 27 Aug 2004 07:14:05 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ehR-00072e-CL for nemo@ietf.org; Fri, 27 Aug 2004 07:15:17 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 13:25:44 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RBCfOg009280; Fri, 27 Aug 2004 13:13:29 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 13:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Fri, 27 Aug 2004 13:13:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103EA2@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSL1G/c7LtQ4JdLT/qrceN8QKZhrAAUjUQQ From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , X-OriginalArrivalTime: 27 Aug 2004 11:13:29.0180 (UTC) FILETIME=[E16BC9C0:01C48C26] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Content-Transfer-Encoding: quoted-printable Hi Fan: This is a very good summary. Thanks for it. Pascal >=20 >=20 > Hi, Pascal, Alex and all, >=20 > I have followed this long discussion and want to sort of make a summary. > Hope it helps. >=20 > Problem statement: > When one MR moves to a (nested) NEMO network and wants to connect to the > Internet, we need to have an efficient and scalable mechanism for MR to > choose which AR to attach to as fast as possible. Note that this problem > may share some similarity with others in different scenarios. We need to > know whether there is something specific to NEMO here or a more efficient > solution works well with this problem in NEMO only but not in other > scenarios. >=20 > There are several possible solutions to this problem. > 1. Routing protocol: Routing protocol is running on each MR in order to > propagate the connectivity information. However it is heavy in terms of > the routing table and slow to propagate and converge when the topology > changes. >=20 > 2. Detection solution: MR may use BU to discover the usable AR to the > Internet. Firstly, without any helpful metrics, MR has to randomly select > one AR from (maybe) multiple ARs. MR has no idea about AR and may end up > with a "bad" (according to its preference) AR even though a better AR is > available. Secondly, MR has to start the BU procedure and wait until > either BAck arrives or an error is detected. >=20 > 3. TD is efficient because MR just needs to make a decision based on the > received RA and its preference. No state or routing table is needed. > However, this doesn't guarantee the connectivity to the Internet (No one > does). MR at least needs to wait until the BU procedure succeeds before > sending the data packet. A "shadow" tree may reduce the length of the > routing path inside the nested NEMO, but the resulting tree can be any > shape because it is totally up to the decision of MR. >=20 > Do I miss something here? >=20 > Fan From nemo-bounces@ietf.org Fri Aug 27 07:31:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20978 for ; Fri, 27 Aug 2004 07:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0euM-0001pO-CA; Fri, 27 Aug 2004 07:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0erx-0001Hn-SE for nemo@megatron.ietf.org; Fri, 27 Aug 2004 07:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20738 for ; Fri, 27 Aug 2004 07:26:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0et6-0007ER-8z for nemo@ietf.org; Fri, 27 Aug 2004 07:27:20 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 13:37:50 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RBOpOa011652; Fri, 27 Aug 2004 13:25:30 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 13:25:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] mor comments on TD Date: Fri, 27 Aug 2004 13:25:24 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103EAB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] mor comments on TD Thread-Index: AcSME4nXOfyBoT8JRm6X44xwXm4z5gAFOYjQ From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" , "Alexandru Petrescu" X-OriginalArrivalTime: 27 Aug 2004 11:25:27.0010 (UTC) FILETIME=[8D47F420:01C48C28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 >=20 > Alexandru Petrescu wrote: > > Hi Pascal, here are more comments on TD. I hope I'm not missing > > something obvious... > > > > > >>When several MRs attach to each other to form a nested Nemo, loops > >>can be created if they are not explicitely avoided. In the simplest > >>case, when egress and ingress interfaces of an MR are all wireless, a > >> mobile router may be listening to Router Advertisement from its own > >> ingress interface, creating a confliction problem. > > > > > > This is bad configuration. This is something that an administrator > > should avoid. When a machine has several wireless interfaces each > > intended to belong to different IP subnets (the case of a typical > > router) then administrator should enforce this. With 802.11b, it is at > > least necessary to set up different ESSID's. This is not a NEMO > > problem. >=20 > I completely agree. This is what I pointed out in San Diego. An > administrator wouldn't randomly connect an Ethernet cable to any socket > he finds. He needs to have a clear picture of the wiring. Wireless isn't > any different. You don't just connect to APs without knowing where they > fit in the topology. >=20 Mattias, the topology here is not necessarily engineered, it's ad hoc. Like car2car. Pascal =20 From nemo-bounces@ietf.org Fri Aug 27 07:58:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22557 for ; Fri, 27 Aug 2004 07:58:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fLH-000717-Ig; Fri, 27 Aug 2004 07:56:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fIj-0006RO-SF for nemo@megatron.ietf.org; Fri, 27 Aug 2004 07:53:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22336 for ; Fri, 27 Aug 2004 07:53:48 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0fJr-0007j1-7N for nemo@ietf.org; Fri, 27 Aug 2004 07:55:00 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i7RBlKjf009026; Fri, 27 Aug 2004 04:47:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7RBrjZH028540; Fri, 27 Aug 2004 06:53:45 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D3E6E88CF7B; Fri, 27 Aug 2004 13:53:44 +0200 (CEST) Message-ID: <412F20C3.1090209@motorola.com> Date: Fri, 27 Aug 2004 13:53:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <200408270114.i7R1ER4q028094@syrphus.ucdavis.edu> In-Reply-To: <200408270114.i7R1ER4q028094@syrphus.ucdavis.edu> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3CF6F94E5F6E2F1030F3F502" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3CF6F94E5F6E2F1030F3F502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks for summarizing, some aspects have been overlooked. Fan Zhao wrote: > Problem statement: When one MR moves to a (nested) NEMO network and > wants to connect to the Internet, we need to have an efficient and > scalable mechanism for MR to choose which AR to attach to as fast as > possible. Note that this problem may share some similarity with > others in different scenarios. We need to know whether there is > something specific to NEMO here or a more efficient solution works > well with this problem in NEMO only but not in other scenarios. Also one would check DNA BoF about Dynamic Network Attachment. > There are several possible solutions to this problem. 1. Routing > protocol: Routing protocol is running on each MR in order to > propagate the connectivity information. However it is heavy in terms > of the routing table and slow to propagate and converge when the > topology changes. Here heaviness depends on how many routing tables are there to be modified. A small aggregation of MR's like 10 MR's where only one extreme MR moves will _not_ induce any large modifications to routing tables. > 2. Detection solution: MR may use BU to discover the usable AR to the > Internet. Firstly, without any helpful metrics, MR has to randomly > select one AR from (maybe) multiple ARs. DNA stuff? > Secondly, MR has to start the BU procedure and wait until either BAck > arrives or an error is detected. MR should advertise itself as a default router only if it actually is connected to the Internet, that is, to its HA (not only to AR). > 3. TD is efficient because MR just needs to make a decision based on > the received RA and its preference. No state or routing table is > needed. "Efficiency" can be defined only if we know requirements and see what tradeoffs can be made. TD is not efficient because the deeper the network, the larger RA's will be. With a tree of height (or depth) 100, there'll presumably 100 TIO's in the leaf RA's. If this is so, TD is nor scaleable nor efficient. > A “shadow” tree may reduce the length of the routing path inside the > nested NEMO, but the resulting tree can be any shape because it is > totally up to the decision of MR. You mean the "shallow" TD term (having little depth)? Because we also have a "shadow" routing table where a dynamic routing protocol puts its routes when MR is not at home. Thanks, Alex --------------enig3CF6F94E5F6E2F1030F3F502 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBLyDIMmC0w56zj54RAhVvAJ9T1vVWi0Tk5Z/A+qX1mdiMXjNcvwCfQm6W 4uKIJHpNZiuKCmk8fw0yBZs= =JjsL -----END PGP SIGNATURE----- --------------enig3CF6F94E5F6E2F1030F3F502-- From nemo-bounces@ietf.org Fri Aug 27 08:50:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26276 for ; Fri, 27 Aug 2004 08:50:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0g4g-0007S1-J1; Fri, 27 Aug 2004 08:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fye-0006AE-Vk for nemo@megatron.ietf.org; Fri, 27 Aug 2004 08:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25489 for ; Fri, 27 Aug 2004 08:37:07 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0fzl-0000I0-1t for nemo@ietf.org; Fri, 27 Aug 2004 08:38:20 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 14:48:47 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RCaTO4020830; Fri, 27 Aug 2004 14:36:30 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 14:26:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Fri, 27 Aug 2004 14:26:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103EF1@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMLXoCbLA9y1VYThO8ofCXNpzQpQAA1PZg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Fan Zhao" X-OriginalArrivalTime: 27 Aug 2004 12:26:27.0017 (UTC) FILETIME=[12D0B390:01C48C31] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Content-Transfer-Encoding: quoted-printable > > 3. TD is efficient because MR just needs to make a decision based on > > the received RA and its preference. No state or routing table is > > needed. >=20 > "Efficiency" can be defined only if we know requirements and see what > tradeoffs can be made. TD is not efficient because the deeper the > network, the larger RA's will be. With a tree of height (or depth) 100, > there'll presumably 100 TIO's in the leaf RA's. If this is so, TD is > nor scaleable nor efficient. Alex: you misread the draft. There's only 1 TIO per tree the MR belongs to. With nemo basic, it's 1 TIO per RA. TD makes the Default Router List an ordered list. Pascal From nemo-bounces@ietf.org Fri Aug 27 09:14:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27436 for ; Fri, 27 Aug 2004 09:14:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gRK-0003WL-Ne; Fri, 27 Aug 2004 09:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gFV-0001Aq-Rl for nemo@megatron.ietf.org; Fri, 27 Aug 2004 08:54:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26505 for ; Fri, 27 Aug 2004 08:54:32 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gGe-0000bz-1L for nemo@ietf.org; Fri, 27 Aug 2004 08:55:45 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i7RCoA94022669 for ; Fri, 27 Aug 2004 05:50:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7RCsSZH022110 for ; Fri, 27 Aug 2004 07:54:28 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 906E088CF7B for ; Fri, 27 Aug 2004 14:54:27 +0200 (CEST) Message-ID: <412F2F03.4040508@motorola.com> Date: Fri, 27 Aug 2004 14:54:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [nemo] Question on TD X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit "When the NEMO where the MN is connected to is multihomed, the MN may have the choice between several AR to be its default router" What does this mean? If MNis connected to a NEMO then it is connected, so it has no choice between several AR's. MN has a default router already. It's that NEMO's TLMR that has choice, no? Or maybe it is meant that MN may use one of the two MR's (TLMR's) as its default route? Alex From nemo-bounces@ietf.org Fri Aug 27 09:17:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27781 for ; Fri, 27 Aug 2004 09:17:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gWo-0004qq-Cg; Fri, 27 Aug 2004 09:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gNk-0002fl-JV for nemo@megatron.ietf.org; Fri, 27 Aug 2004 09:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26787 for ; Fri, 27 Aug 2004 09:03:02 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gOi-0000jr-JI for nemo@ietf.org; Fri, 27 Aug 2004 09:04:16 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7RD2mWR021006 for ; Fri, 27 Aug 2004 15:02:51 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:02:48 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMT7JDYN; Fri, 27 Aug 2004 15:02:48 +0200 Message-ID: <412F30F7.5020302@ericsson.com> Date: Fri, 27 Aug 2004 15:02:47 +0200 X-Sybari-Trust: 2aebebf5 74470f8f 01232f82 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] mor comments on TD References: <7892795E1A87F04CADFCCF41FADD00FC103EAB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103EAB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 13:02:48.0201 (UTC) FILETIME=[26E6F790:01C48C36] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > >>any different. You don't just connect to APs without knowing where > > they > >>fit in the topology. >> > > Mattias, the topology here is not necessarily engineered, it's ad hoc. > Like car2car. Personally, I see no motivation for such scenarios. How would you formulate the requirements that motivate this? I'm not discouraging your work, but I think the WG needs to see the need for this more futuristic case. I would say we more likely need RO before TD. Also, with such scenarios you would bring in a lot of new issues that we probably don't see now and this will make solutions _much_ more complex. /Mattias From nemo-bounces@ietf.org Fri Aug 27 09:25:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28185 for ; Fri, 27 Aug 2004 09:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ghi-00073r-Ut; Fri, 27 Aug 2004 09:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gYM-00058V-QW for nemo@megatron.ietf.org; Fri, 27 Aug 2004 09:14:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27426 for ; Fri, 27 Aug 2004 09:14:00 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gZU-0000xe-Vb for nemo@ietf.org; Fri, 27 Aug 2004 09:15:14 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i7RDD4n0018825; Fri, 27 Aug 2004 06:13:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7RD57bK018784; Fri, 27 Aug 2004 08:05:07 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9CC2488CF7B; Fri, 27 Aug 2004 15:13:01 +0200 (CEST) Message-ID: <412F335D.6080309@motorola.com> Date: Fri, 27 Aug 2004 15:13:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103EF1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103EF1@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> 3. TD is efficient because MR just needs to make a decision based >>> on the received RA and its preference. No state or routing table >>> is needed. >> >> "Efficiency" can be defined only if we know requirements and see >> what tradeoffs can be made. TD is not efficient because the deeper >> the network, the larger RA's will be. With a tree of height (or >> depth) 100, there'll presumably 100 TIO's in the leaf RA's. If >> this is so, TD is nor scaleable nor efficient. > > > Alex: you misread the draft. There's only 1 TIO per tree the MR > belongs to. With nemo basic, it's 1 TIO per RA. TD makes the Default > Router List an ordered list. That's right, I've misread. Still, TreeDepth value on 8bit only? Does this mean that only 255levels of aggregation can be made? This is not scalable. TreeID: why this field. Why not simply using the Home Address of the ingress interface advertising this stuff? Besides, it can be derived from the src field of the base header and the prefix in the RA, no need to add a new field in the TIO... This is not efficient. What prevents two MR's to set up their TreePreference to the highest possible values (255)? If they do so, they'll present potential MR's wishing to attach to it the same difficulty of choice as if they did not use any TIO: to AR's can pretend to be default routers and the wishing MR can not know which one to choose. So, MR's using 255 TreePreference are no better than AR's using Router Lifetime 0, from a wishing MR pov. No? Why adding a CRC? Why not a checksum with a virtual header, the classic stuff? Why is CRC needed? Remark RA already has a checksum covering all RA options... This is not efficient. Alex From nemo-bounces@ietf.org Fri Aug 27 09:44:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29291 for ; Fri, 27 Aug 2004 09:44:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gtd-0000bB-31; Fri, 27 Aug 2004 09:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gjS-0007UL-H1 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 09:25:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28218 for ; Fri, 27 Aug 2004 09:25:28 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gkb-0001DI-0p for nemo@ietf.org; Fri, 27 Aug 2004 09:26:42 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 15:37:10 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RDOfOE029409; Fri, 27 Aug 2004 15:24:54 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:24:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] mor comments on TD Date: Fri, 27 Aug 2004 15:24:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103F25@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] mor comments on TD Thread-Index: AcSMNovwqoAK84MPRO20nBzbRGbg2gAAZsvw From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" X-OriginalArrivalTime: 27 Aug 2004 13:24:52.0388 (UTC) FILETIME=[3C2DDE40:01C48C39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > How would you formulate the requirements that motivate this? I'm not > discouraging your work, but I think the WG needs to see the need for > this more futuristic case. I would say we more likely need RO before TD. >=20 There may be a misunderstanding here. TSD is quite simple. And TD comes before RO. Say you have 10 MRs: With no organisation, you may end up with a line of 10 routers, leading to 10 levels of tunnelling and pinball routing.=20 TD allows you to build your tree as shallow as can be, so that, say, MRs are between 0 and 2 hops from the outside. It's a 'physical' RO. Optimizes the number of hops to the infrastructure. This is transparent to nemo basic so you still have up to 3 levels of tunnelling. =20 Once you've done that, then you want to do a nemo RO and avoid going through the HAs etc... Pascal From nemo-bounces@ietf.org Fri Aug 27 09:48:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29515 for ; Fri, 27 Aug 2004 09:48:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gyD-0001P9-EZ; Fri, 27 Aug 2004 09:40:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0grl-0000GB-R3 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 09:34:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28649 for ; Fri, 27 Aug 2004 09:34:03 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gst-0001LC-0a for nemo@ietf.org; Fri, 27 Aug 2004 09:35:17 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 15:45:45 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RDWiOg000723; Fri, 27 Aug 2004 15:33:28 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:33:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Fri, 27 Aug 2004 15:33:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103F30@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMN7qiKtZqplACQ1eLR+JCbDquXQAAY71g From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Aug 2004 13:33:15.0075 (UTC) FILETIME=[67CDD130:01C48C3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Content-Transfer-Encoding: quoted-printable Alex: the draft is not too thick, please read it better: > >>> 3. TD is efficient because MR just needs to make a decision based > >>> on the received RA and its preference. No state or routing table > >>> is needed. > >> > >> "Efficiency" can be defined only if we know requirements and see > >> what tradeoffs can be made. TD is not efficient because the deeper > >> the network, the larger RA's will be. With a tree of height (or > >> depth) 100, there'll presumably 100 TIO's in the leaf RA's. If > >> this is so, TD is nor scaleable nor efficient. > > > > > > Alex: you misread the draft. There's only 1 TIO per tree the MR > > belongs to. With nemo basic, it's 1 TIO per RA. TD makes the Default > > Router List an ordered list. >=20 > That's right, I've misread. >=20 > Still, TreeDepth value on 8bit only? Does this mean that only 255levels > of aggregation can be made? This is not scalable. It means that you can not be deeper than 255 hops from the AR. Enough considering TTL. > TreeID: why this field. Why not simply using the Home Address of the > ingress interface advertising this stuff? Besides, it can be derived > from the src field of the base header and the prefix in the RA, no need > to add a new field in the TIO... This is not efficient. >=20 This gives a unique ID for the tree. It's needed to prevent loops. It comes from the root-MR and can not be deduced from any field in the TIO. > What prevents two MR's to set up their TreePreference to the highest > possible values (255)? If they do so, they'll present potential MR's > wishing to attach to it the same difficulty of choice as if they did not > use any TIO: to AR's can pretend to be default routers and the wishing > MR can not know which one to choose. So, MR's using 255 TreePreference > are no better than AR's using Router Lifetime 0, from a wishing MR pov. No? If a MR uses that preference in its algorithm (case of a managed network), then it will be configured appropriately. Case of fire brigade for instance. The simplest algorithm just uses the least depth to a grounded tree. =20 >=20 > Why adding a CRC? Why not a checksum with a virtual header, the classic > stuff? Why is CRC needed? Remark RA already has a checksum covering > all RA options... This is not efficient. >=20 That CRC is not there to validate the packet. It is the checksum of the careofs to the outside. It is used to detect if the path to the outside has changed.=20 Pascal From nemo-bounces@ietf.org Fri Aug 27 10:46:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04535 for ; Fri, 27 Aug 2004 10:46:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ht9-0005xU-5O; Fri, 27 Aug 2004 10:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0hmR-0004tN-Um for nemo@megatron.ietf.org; Fri, 27 Aug 2004 10:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03470 for ; Fri, 27 Aug 2004 10:32:37 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0hnQ-0002Qm-OK for nemo@ietf.org; Fri, 27 Aug 2004 10:33:52 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7REWRAh000657 for ; Fri, 27 Aug 2004 16:32:27 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 16:32:27 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RPJ2THBW; Fri, 27 Aug 2004 16:32:27 +0200 Message-ID: <412F45FA.7030605@ericsson.com> Date: Fri, 27 Aug 2004 16:32:26 +0200 X-Sybari-Trust: 8da55205 74470f8f 01232f82 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] mor comments on TD References: <7892795E1A87F04CADFCCF41FADD00FC103F25@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F25@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 14:32:27.0050 (UTC) FILETIME=[ACF230A0:01C48C42] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>How would you formulate the requirements that motivate this? I'm not >>discouraging your work, but I think the WG needs to see the need for >>this more futuristic case. I would say we more likely need RO before > > TD. > > > There may be a misunderstanding here. TSD is quite simple. And TD comes > before RO. > Say you have 10 MRs: > With no organisation, you may end up with a line of 10 routers, leading > to 10 levels of tunnelling and pinball routing. > TD allows you to build your tree as shallow as can be, so that, say, MRs > are between 0 and 2 hops from the outside. It's a 'physical' RO. > Optimizes the number of hops to the infrastructure. > This is transparent to nemo basic so you still have up to 3 levels of > tunnelling. > Once you've done that, then you want to do a nemo RO and avoid going > through the HAs etc... That's a nice thought and you have good intentions. I just don't agree with the assumptions you make; - no organisation, complete automation, no human decisions - lots of MRs - many levels of nesting Of course we should not design a protocol (basic support) that only supports a limited number of MRs or a limited number of nesting levels, for instance. But a good estimation of likely figures helps when making design trade-offs. Unfortunately, in my experience, adding more autoconfiguration in one place in the system or on one layer in the stack doesn't eradicate the problem in question, it just pushes it to another place or to another layer. I want this WG to work on the problem and requirements stated in the WG docs. We want basic support to provide connectivity. Optimisations of various kinds will come in a later stage. Why not make this a part of the problem statement for the continuation of the WG where we talk about RO? /Mattias From nemo-bounces@ietf.org Fri Aug 27 11:17:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08565 for ; Fri, 27 Aug 2004 11:17:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0iPp-0007rM-KX; Fri, 27 Aug 2004 11:13:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0i5Y-0000Xh-Hr for nemo@megatron.ietf.org; Fri, 27 Aug 2004 10:52:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05129 for ; Fri, 27 Aug 2004 10:52:21 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0i6h-0002pJ-Nb for nemo@ietf.org; Fri, 27 Aug 2004 10:53:37 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i7REkRvH022057; Fri, 27 Aug 2004 07:46:28 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7REkQZH025381; Fri, 27 Aug 2004 09:46:26 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B5AA888CF7B; Fri, 27 Aug 2004 16:46:25 +0200 (CEST) Message-ID: <412F4941.8000709@motorola.com> Date: Fri, 27 Aug 2004 16:46:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103F30@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F30@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Alex: the draft is not too thick, please read it better. Ok, I read it better; it's indeed not thick (16 pages) but there are still unclear things... >>>>> 3. TD is efficient because MR just needs to make a decision >>>>> based on the received RA and its preference. No state or >>>>> routing table is needed. >>>> >>>> "Efficiency" can be defined only if we know requirements and >>>> see what tradeoffs can be made. TD is not efficient because >>>> the deeper the network, the larger RA's will be. With a tree >>>> of height (or depth) 100, there'll presumably 100 TIO's in the >>>> leaf RA's. If this is so, TD is nor scaleable nor efficient. >>> >>> >>> Alex: you misread the draft. There's only 1 TIO per tree the MR >>> belongs to. With nemo basic, it's 1 TIO per RA. TD makes the >>> Default Router List an ordered list. >> >> That's right, I've misread. >> >> Still, TreeDepth value on 8bit only? Does this mean that only > 255levels of aggregation can be made? This is not scalable. > > It means that you can not be deeper than 255 hops from the AR. Enough > considering TTL. I see no relation between TTL and TreeDepth. A moving network may offer an AR that is not its MR, the moving network may introduce more hops within itself. Do you have a form of AR-to-MR communication (AR and MR of same moving network) such as to propagate consistently that TIO modifications. >> Why adding a CRC? Why not a checksum with a virtual header, the > classic stuff? Why is CRC needed? Remark RA already has a checksum >> covering all RA options... This is not efficient. >> > That CRC is not there to validate the packet. It is the checksum of > the careofs to the outside. It is used to detect if the path to the > outside has changed. Where does the draft say so? First, where does the MR CoA come from? It's not in the TIO. It's not in the src field of the RA. The TreeID is the Home Address initially, not the CoA. Second, does CRC-32c algorithm guarantee a unique output for a unique set of Care-of Addresses? Not even MD5 does. This is not efficient. Third, if one wants to say that something has changed why not simply sending a bit in the TIO that says "something has changed". This is less expensive than computing CRC's... Alex From nemo-bounces@ietf.org Fri Aug 27 11:29:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09671 for ; Fri, 27 Aug 2004 11:29:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0iTB-0001gg-KC; Fri, 27 Aug 2004 11:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0iPH-0007UL-QP for nemo@megatron.ietf.org; Fri, 27 Aug 2004 11:12:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08127 for ; Fri, 27 Aug 2004 11:12:45 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0iQQ-0003n1-0O for nemo@ietf.org; Fri, 27 Aug 2004 11:14:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 17:24:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RFBfOY016285; Fri, 27 Aug 2004 17:12:10 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 17:12:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] mor comments on TD Date: Fri, 27 Aug 2004 17:12:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103F82@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] mor comments on TD Thread-Index: AcSMQvauyAVFdK6BQ/28Gw36CzuguAAAv1Nw From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" X-OriginalArrivalTime: 27 Aug 2004 15:12:06.0117 (UTC) FILETIME=[36FB0150:01C48C48] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > That's a nice thought and you have good intentions. >=20 > I just don't agree with the assumptions you make; > - no organisation, complete automation, no human decisions > - lots of MRs > - many levels of nesting I gave an example of 10 MRs. That's not a lot. But in a daisy chain, that's 10 levels of nesting - a lot. This is not a network design problem, though - this may be totally ad hoc. It's a lack of capability of the system. We want to avoid that. That's why we need TD. =20 > Of course we should not design a protocol (basic support) that only > supports a limited number of MRs or a limited number of nesting levels, > for instance. But a good estimation of likely figures helps when making > design trade-offs.=20 Right, that was discussed at the beginning of the WG: We have scenarios with 3 or more level of nesting. But nothing says how we get there. One such example is:=20 ferry boat <- car <- pan.=20 NEMO does not provide for the PAN to attach to a car (mine in particular), for the car to attach to a ferry etc... We could end up having a car joining the ferry and then the hundred other in a daisy chain till the overhead of tunnels is so huge that it does not work at all. We have been asked to look at realistic scenarios such as traffic jams. That's 2000 cars. I did not make up the numbers.=20 > Unfortunately, in my experience, adding more > autoconfiguration in one place in the system or on one layer in the > stack doesn't eradicate the problem in question, it just pushes it to > another place or to another layer. That can be true but I fail to understand what exactly you want to express here. Sorry. > I want this WG to work on the problem and requirements stated in the WG > docs. We want basic support to provide connectivity. Optimisations of > various kinds will come in a later stage. Why not make this a part of > the problem statement for the continuation of the WG where we talk about RO? True... TD is somewhere in a twilight zone between nemo basic and RO. I asked that same question to the WG, but did not get a clear response. I'd say that it may be covered by the charter (just to be able to do the ferry stuff) but then it would not be a priority compared to, say prefix delegation.=20 Also, it's not 100% sure we ever recharter for RO. I hope we do. Pascal From nemo-bounces@ietf.org Fri Aug 27 11:55:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11442 for ; Fri, 27 Aug 2004 11:55:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ium-0000Nl-2l; Fri, 27 Aug 2004 11:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0imq-0006v0-8I for nemo@megatron.ietf.org; Fri, 27 Aug 2004 11:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10176 for ; Fri, 27 Aug 2004 11:37:05 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0inz-0004P6-Ov for nemo@ietf.org; Fri, 27 Aug 2004 11:38:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 17:48:51 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RFaQOA019517; Fri, 27 Aug 2004 17:36:32 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 17:36:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Fri, 27 Aug 2004 17:36:23 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMRXqX9XuMciH6SSiikjJzSTqLiAAAyiTw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Aug 2004 15:36:25.0885 (UTC) FILETIME=[9D11ECD0:01C48C4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Content-Transfer-Encoding: quoted-printable > >> Still, TreeDepth value on 8bit only? Does this mean that only > > 255levels of aggregation can be made? This is not scalable. > > > > It means that you can not be deeper than 255 hops from the AR. Enough > > considering TTL. >=20 > I see no relation between TTL and TreeDepth. A moving network may offer > an AR that is not its MR, the moving network may introduce more hops > within itself. Do you have a form of AR-to-MR communication (AR and MR > of same moving network) such as to propagate consistently that TIO > modifications. A tree depth of 200 means 200 MRs to go through to get to the AR. A default TTL of 64 will be dropped in the middle of such a tree. By current standards, a depth of 200 is insane. We currently have a MAX of 10. That's already 10 radio hops. Quite a radius.=20 The AR question is a good one. We discussed that with Marcello on the thread. There are option and I'd appreciate recommendations from the ML. One option is for Mobile AR to propagate TIO and not to use legacy MAR which could not do it. =20 > >> Why adding a CRC? Why not a checksum with a virtual header, the > > classic stuff? Why is CRC needed? Remark RA already has a checksum > >> covering all RA options... This is not efficient. > >> > > That CRC is not there to validate the packet. It is the checksum of > > the careofs to the outside. It is used to detect if the path to the > > outside has changed. >=20 > Where does the draft say so? PathDigest 32-bit unsigned integer CRC, updated by each MR. This is the result of a CRC-32c computation on a bit string obtained by appending the received value and the MR Care of Address. Clusterheads use a 'previous value' of zeroes to initially set the PathDigest >=20 > First, where does the MR CoA come from? It's not in the TIO. It's not > in the src field of the RA. The TreeID is the Home Address initially, > not the CoA. A MR is expected to know it's CoA. The tree ID is an ID of the root-MR file the CareOf is that of the MR that propagates the TIO. >=20 > Second, does CRC-32c algorithm guarantee a unique output for a unique > set of Care-of Addresses? Not even MD5 does. This is not efficient. Its' a hint, but the chances of being wrong are veeeeeeeeeeeerrrrrrrrrrryyyyy low. It may be used for various purposes such as tree movement detection, multihop RH type2 validation etc.=20 > Third, if one wants to say that something has changed why not simply > sending a bit in the TIO that says "something has changed". This is > less expensive than computing CRC's... Could work in a P2P environment. But... for a MR for force the bit you propose in its RA-TIO, it must know what was in the last RA that a VMR received. That may depend on the MR, so either VMRs may miss changes or they may see it twice or something. So it can not be done that way. Each MR has to maintain its own state for what it saw last time. Also, the CRC computation is not that complex. It's done on 2*Ipv6 addresses so it compares with the validation on an IPv4 header.=20 Pascal From nemo-bounces@ietf.org Fri Aug 27 12:27:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13794 for ; Fri, 27 Aug 2004 12:27:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jTm-0002Aa-4p; Fri, 27 Aug 2004 12:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jAi-00048v-L4 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 12:01:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11880 for ; Fri, 27 Aug 2004 12:01:45 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0jBt-0004yb-7T for nemo@ietf.org; Fri, 27 Aug 2004 12:03:01 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i7RG0Qck003406; Fri, 27 Aug 2004 09:00:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7RE0C4C017934; Fri, 27 Aug 2004 09:00:12 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8370E88CF7C; Fri, 27 Aug 2004 18:00:23 +0200 (CEST) Message-ID: <412F5A97.6060208@motorola.com> Date: Fri, 27 Aug 2004 18:00:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > By current standards, a depth of 200 is insane. I was thinking you were looking at traffic jams, those may have more than just 10 vehicles... > The AR question is a good one. We discussed that with Marcello on the > thread. There are option and I'd appreciate recommendations from the > ML. One option is for Mobile AR to propagate TIO and not to use > legacy MAR which could not do it. When was the last time we discussed NEMO-related communication between entities in a moving network and its MR, such to delegate security powers and stuff... >>> That CRC is not there to validate the packet. It is the checksum >>> of the careofs to the outside. It is used to detect if the path >>> to the outside has changed. >> >> Where does the draft say so? > > PathDigest 32-bit unsigned integer CRC, updated by each MR. This is > the result of a CRC-32c computation on a bit string obtained by > appending the received value and the MR Care of Address. Clusterheads > use a 'previous value' of zeroes to initially set the PathDigest > >> First, where does the MR CoA come from? It's not in the TIO. It's >> not in the src field of the RA. The TreeID is the Home Address >> initially, not the CoA. > > A MR is expected to know it's CoA. Yeah, once it's formed based on information from the same RA (prefix). I really don't get it. Whenever an MR receives a TIO that has a PathDigest different than the TIO it received previously it looks at the previously received PathDigest from the same router ll address and finds different. No need to compute its own PathDigest based on the newly-received PathDigest to realize that. Thus, it is sufficient that every MR that establishes for itself a new dfeault route will set the "has changed" bit in its TIO's and MR's below to retransmit this bit and everybody notices something has changed, no need for digests and checksums. As simple as that. Why wouldn't it work. > The tree ID is an ID of the root-MR file the CareOf is that of the MR > that propagates the TIO. > >> Second, does CRC-32c algorithm guarantee a unique output for a >> unique set of Care-of Addresses? Not even MD5 does. This is not >> efficient. > > Its' a hint, but the chances of being wrong are > veeeeeeeeeeeerrrrrrrrrrryyyyy low. Depends what you call ve12r11y5 low. An intermediate MR may wish to fool the MR's below and tell them that nothing has changed. Hence TD has security issues. > It may be used for various purposes such as tree movement detection, > multihop RH type2 validation etc. Wasn't RH type 2 reserved for BU's and such? What's multihop RH type 2? >> Third, if one wants to say that something has changed why not >> simply sending a bit in the TIO that says "something has changed". >> This is less expensive than computing CRC's... > > Could work in a P2P environment. But... for a MR for force the bit > you propose in its RA-TIO, it must know what was in the last RA that > a VMR received. Yep, it must know the prefix in the received RA and the ll address of the router who sent it. Both are present. > That may depend on the MR, so either VMRs may miss changes or they > may see it twice or something. A TD MR is not an MR, it's just a TD MR. > So it can not be done that way. Each MR has to maintain its own state > for what it saw last time. Also, the CRC computation is not that > complex. It's done on 2*Ipv6 addresses so it compares with the > validation on an IPv4 header. The TD MR's CRC computation is something that should be done _in addition_ to the ICMP checksum; the CRC is more expensive than just a comparison to the previous values (by all accounts). Thus the more efficient solution is the bit solution. Could you modify the draft accordingly please? Alex From nemo-bounces@ietf.org Fri Aug 27 12:29:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14069 for ; Fri, 27 Aug 2004 12:29:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jUT-0002N5-3F; Fri, 27 Aug 2004 12:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jQA-0000PN-KO for nemo@megatron.ietf.org; Fri, 27 Aug 2004 12:17:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12983 for ; Fri, 27 Aug 2004 12:17:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0jRI-0005GT-EU for nemo@ietf.org; Fri, 27 Aug 2004 12:18:59 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2004 18:29:27 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7RGGXOa024714; Fri, 27 Aug 2004 18:17:08 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 18:16:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Fri, 27 Aug 2004 18:16:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC103F97@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMTy1vjT+LTo/oSu6O/WEPpx+RZAAAIKOA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Aug 2004 16:16:58.0276 (UTC) FILETIME=[46E35640:01C48C51] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Content-Transfer-Encoding: quoted-printable > >> First, where does the MR CoA come from? It's not in the TIO. It's > >> not in the src field of the RA. The TreeID is the Home Address > >> initially, not the CoA. > > > > A MR is expected to know it's CoA. >=20 > Yeah, once it's formed based on information from the same RA (prefix). >=20 > I really don't get it. Seems not. I'll have to be more verbose for version 01.=20 >=20 > Whenever an MR receives a TIO that has a PathDigest different than the > TIO it received previously it looks at the previously received > PathDigest from the same router ll address and finds different. No need > to compute its own PathDigest based on the newly-received PathDigest to > realize that. MR receives digest in RA-TIO from AR over egress and saves it. MR computes newdigest =3D CRC32(digest, CoA) and puts that in the RA-TIO = it sends over ingress.=20 Next time MR gets RA-TIO, it compares the consecutive digest and if they are different, something changed in the chain of MRs to the outside. The computation of CRC is not done for itself but for the guys below so that the digest has all the CoAs within it. I hope you understand that, or someone else has to try using different words. >=20 > Thus, it is sufficient that every MR that establishes for itself a new > dfeault route will set the "has changed" bit in its TIO's and MR's below > to retransmit this bit and everybody notices something has changed, no > need for digests and checksums. As simple as that. Why wouldn't it work. >=20 > > The tree ID is an ID of the root-MR file the CareOf is that of the MR > > that propagates the TIO. > > > >> Second, does CRC-32c algorithm guarantee a unique output for a > >> unique set of Care-of Addresses? Not even MD5 does. This is not > >> efficient. > > > > Its' a hint, but the chances of being wrong are > > veeeeeeeeeeeerrrrrrrrrrryyyyy low. >=20 > Depends what you call ve12r11y5 low. An intermediate MR may wish to > fool the MR's below and tell them that nothing has changed. Hence TD > has security issues. >=20 > > It may be used for various purposes such as tree movement detection, > > multihop RH type2 validation etc. >=20 > Wasn't RH type 2 reserved for BU's and such? What's multihop RH type 2? >=20 > >> Third, if one wants to say that something has changed why not > >> simply sending a bit in the TIO that says "something has changed". > >> This is less expensive than computing CRC's... > > > > Could work in a P2P environment. But... for a MR for force the bit > > you propose in its RA-TIO, it must know what was in the last RA that > > a VMR received. >=20 > Yep, it must know the prefix in the received RA and the ll address of > the router who sent it. Both are present. >=20 > > That may depend on the MR, so either VMRs may miss changes or they > > may see it twice or something. >=20 > A TD MR is not an MR, it's just a TD MR. >=20 > > So it can not be done that way. Each MR has to maintain its own state > > for what it saw last time. Also, the CRC computation is not that > > complex. It's done on 2*Ipv6 addresses so it compares with the > > validation on an IPv4 header. >=20 > The TD MR's CRC computation is something that should be done _in > addition_ to the ICMP checksum; the CRC is more expensive than just a > comparison to the previous values (by all accounts). Thus the more > efficient solution is the bit solution. Could you modify the draft > accordingly please? I explained it does not work. Try again: the fact that something changed is not from the view of the emitter but from the different viewpoints of all the receivers. If a MR sets a bit in TIO saying there's a change, and one of 10 visitors misses the RA. Should the sending MR repeat the bit next time?=20 Pascal From nemo-bounces@ietf.org Fri Aug 27 13:07:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16551 for ; Fri, 27 Aug 2004 13:07:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0k6f-0003AO-PC; Fri, 27 Aug 2004 13:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0k21-00026p-PJ for nemo@megatron.ietf.org; Fri, 27 Aug 2004 12:56:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16001 for ; Fri, 27 Aug 2004 12:56:50 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0k3C-00062S-2S for nemo@ietf.org; Fri, 27 Aug 2004 12:58:07 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7RGpNGU000699; Fri, 27 Aug 2004 09:51:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7RGgObK014897; Fri, 27 Aug 2004 11:42:25 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1B6CC88CF7B; Fri, 27 Aug 2004 18:50:19 +0200 (CEST) Message-ID: <412F664A.3060204@motorola.com> Date: Fri, 27 Aug 2004 18:50:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103F97@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F97@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> Yeah, once it's formed based on information from the same RA >> (prefix). >> >> I really don't get it. > > Seems not. I'll have to be more verbose for version 01. I don't think being more verbose helps. I think that helping to define a problem before offering a solution may help. >> The TD MR's CRC computation is something that should be done _in >> addition_ to the ICMP checksum; the CRC is more expensive than just >> a comparison to the previous values (by all accounts). Thus the >> more efficient solution is the bit solution. Could you modify the >> draft accordingly please? > > I explained it does not work. Try again: the fact that something > changed is not from the view of the emitter but from the different > viewpoints of all the receivers. If a MR sets a bit in TIO saying > there's a change, and one of 10 visitors misses the RA. Should the > sending MR repeat the bit next time? See it the other way around. If a receiving MR misses any one RA TIO in any order of RA TIOs, it has no way of being sure of a path being changed or not at any point in time. If the logic of "path has changed" works with CRC's it also works with 1-bit only, that's a fact. By the current draft, the receiving MR hasn't all the information to compute a correct CRC, it just looks at whether it changed or not. This is against the fundamentals of using a CRC. A CRC is computed on some received data to see it fits the CRC-field it actually receives (the intelligent stuff actually compares to 0). This gives a hint, as you say, to whether the received data is corrupted or not. In fact, what do you assume "CRC-32c" to be more exactly, if I'm not too ignorant. I'd suppose it to be "Cyclic Redundancy Check (CRC) codes [Peterson] are shortened cyclic codes used for error detection." But what is the "32c" part? Two's complement or something on 32bit? Which CRC code more exactly? Note CRC's are for checking message integrity for error correction not for checking a path has changed. Note "Digest" in "PathDigest" invites to think of message digest (like in "MD5"); digests are also used to check for integrity, but not for "path has changed". I doubt that combining "Digest" with "CRC" makes a good tool for "path has changed". For "path has changed" I'd use 1 bit. I doubt there's any need for transmitting information of paths being changed. This is usually done different. Receive new path, internally compute new better destinations, and so on. Alex From nemo-bounces@ietf.org Fri Aug 27 13:14:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16893 for ; Fri, 27 Aug 2004 13:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0k7E-0003HY-H6; Fri, 27 Aug 2004 13:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0k5r-0002qA-R3 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 13:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16162 for ; Fri, 27 Aug 2004 13:00:48 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0k72-000670-2B for nemo@ietf.org; Fri, 27 Aug 2004 13:02:05 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i7RGv4ck013920; Fri, 27 Aug 2004 09:57:04 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7RGulft019110; Fri, 27 Aug 2004 11:56:48 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E61F288CF7B; Fri, 27 Aug 2004 18:57:01 +0200 (CEST) Message-ID: <412F67DD.2000205@motorola.com> Date: Fri, 27 Aug 2004 18:57:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC103F97@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F97@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed 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 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > MR receives digest in RA-TIO from AR over egress and saves it. MR > computes newdigest = CRC32(digest, CoA) and puts that in the RA-TIO > it sends over ingress. > > Next time MR gets RA-TIO, it compares the consecutive digest and if > they are different, something changed in the chain of MRs to the > outside. > > The computation of CRC is not done for itself but for the guys below > so that the digest has all the CoAs within it. I hope you understand > that, or someone else has to try using different words. Ok, how about this substitution of "bit" for "CRC": MR receives bit in RA-TIO from AR over egress and saves it. MR computes new bit = not-bit and puts that in the RA-TIO it sends over ingress. Next time MR gets RA-TIO it compares the consecutive bits and if they are different, something has changed in the chain of MR's to the outside. The computation of the bit is not done for itself but for the guys below so that the bit has all the previous MR's bits within it. I think it can work with one-bit only, no? Alex From nemo-bounces@ietf.org Fri Aug 27 13:27:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17732 for ; Fri, 27 Aug 2004 13:27:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0kSy-0008OI-58; Fri, 27 Aug 2004 13:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0kQ6-0007Vu-6F for nemo@megatron.ietf.org; Fri, 27 Aug 2004 13:21:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17269 for ; Fri, 27 Aug 2004 13:21:42 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0kRG-0006RC-0A for nemo@ietf.org; Fri, 27 Aug 2004 13:22:59 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF6A13A21C; Fri, 27 Aug 2004 19:21:10 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 5F92C3A22C; Fri, 27 Aug 2004 19:21:10 +0200 (CEST) Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BH/tROaibnu8hjSge31W" Organization: Universidad Carlos III de Madrid Message-Id: <1093627278.8873.126.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 27 Aug 2004 19:21:19 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-BH/tROaibnu8hjSge31W Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Pascal, El vie, 27-08-2004 a las 17:36, Pascal Thubert (pthubert) escribi=F3: > > >> Still, TreeDepth value on 8bit only? Does this mean that only > > > 255levels of aggregation can be made? This is not scalable. > > > > > > It means that you can not be deeper than 255 hops from the AR. > Enough > > > considering TTL. > >=20 > > I see no relation between TTL and TreeDepth. A moving network may > offer > > an AR that is not its MR, the moving network may introduce more hops > > within itself. Do you have a form of AR-to-MR communication (AR and > MR > > of same moving network) such as to propagate consistently that TIO > > modifications. >=20 > A tree depth of 200 means 200 MRs to go through to get to the AR. A > default TTL of 64 will be dropped in the middle of such a tree. >=20 > By current standards, a depth of 200 is insane. We currently have a MAX > of 10. That's already 10 radio hops. Quite a radius.=20 >=20 > The AR question is a good one. We discussed that with Marcello on the > thread. There are option and I'd appreciate recommendations from the ML. > One option is for Mobile AR to propagate TIO and not to use legacy MAR > which could not do it. I agree with Marcelo and Alex, that the AR issue is important an that we, IMHO, should look for options in order to not impose restrictions to TD to work. I agree that there are several options. Actually, we thought about some ones. If you are interested, we can discuss it. Kind regards, Carlos J. (suppressed text) > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-BH/tROaibnu8hjSge31W Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBL22O5vKyPtrWqkARAlpgAKDJi0vUpOM6+Gl5geduknVE+f2KEwCggkcT pv/2Redu2bz0qsh6NE0wsFs= =84sY -----END PGP SIGNATURE----- --=-BH/tROaibnu8hjSge31W-- From nemo-bounces@ietf.org Fri Aug 27 14:15:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20834 for ; Fri, 27 Aug 2004 14:15:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0lBh-0001rs-Aa; Fri, 27 Aug 2004 14:10:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0l5V-0000oX-SP for nemo@megatron.ietf.org; Fri, 27 Aug 2004 14:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20014 for ; Fri, 27 Aug 2004 14:04:32 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0l6h-0007HE-PQ for nemo@ietf.org; Fri, 27 Aug 2004 14:05:48 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7RHxAGU017201; Fri, 27 Aug 2004 10:59:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i7RHuvSA017456; Fri, 27 Aug 2004 12:56:57 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 66D4888CF7B; Fri, 27 Aug 2004 19:58:07 +0200 (CEST) Message-ID: <412F762F.3000503@motorola.com> Date: Fri, 27 Aug 2004 19:58:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F8E@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] Re: more on "something has changed" (was: comments on "Tree Discovery" draft) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Could work in a P2P environment. But... for a MR for force the bit > you propose in its RA-TIO, it must know what was in the last RA that > a VMR received. That may depend on the MR, so either VMRs may miss > changes or they may see it twice or something. So it can not be done > that way. Each MR has to maintain its own state for what it saw last > time. Also, the CRC computation is not that complex. It's done on > 2*Ipv6 addresses so it compares with the validation on an IPv4 > header. >>>>> Why adding a CRC? Why not a checksum with a virtual header, >>>>> the classic stuff? Why is CRC needed? Remark RA already has >>>>> a checksum covering all RA options... This is not efficient. >>>>> >>>> >>>>> That CRC is not there to validate the packet. It is the >>>>> checksum of the careofs to the outside. It is used to detect >>>>> if the path to the outside has changed. >>> >>> Where does the draft say so? > > PathDigest 32-bit unsigned integer CRC, updated by each MR. This is > the result of a CRC-32c computation on a bit string obtained by > appending the received value and the MR Care of Address. Clusterheads > use a 'previous value' of zeroes to initially set the PathDigest Pascal, let me bring more on the "something has changed" indicator. You're basically proposing hashing some addresses and propagating the result in TIO's down. I've proposed using a single bit inverted by each entity. Imagine a sequence of routers: TLMR-MR1-M2-MR3. The latter proposal has the inconvenient that if MR1 and MR2 disappear at the same time, then MR3 will not notice (twice inverting is no inverting). But the former proposal has the inconvenient that if MR2 disappears and a new MR4 takes its place immediately after, the PathDigest will change inevitably (due to MAC addresses being unique) and so MR3 will see a change in path when there is actually none (in terms of number of hops: one MR replaced another). So here we're with two proposals, none actually being able to reliably signal to MR3 that something has changed. To me this is a typical example of a solution that may work in a context that one may imagine (I imagined that only unit changes need to be indicated) but immediately after someone can build a physical movement scenario that can not work. (Maybe a total proposal is to actually distribute all lists of neighbours to everybody at every change, ressembling to multicast distribution of LS protocols. And this has been looked into by many routing protocols...) IMHO one can not ask the WG "are you interested in TD"; or maybe it's only me, but I'm not interested in TD. Maybe "are you interested in a problem whose TD may be a solution". So let's see the problem. Looping is not. Alex From nemo-bounces@ietf.org Fri Aug 27 15:17:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26896 for ; Fri, 27 Aug 2004 15:17:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0m96-0006eR-1A; Fri, 27 Aug 2004 15:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0m2i-0002Jk-24 for nemo@megatron.ietf.org; Fri, 27 Aug 2004 15:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25452 for ; Fri, 27 Aug 2004 15:05:41 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0m3t-0000Ar-Cv for nemo@ietf.org; Fri, 27 Aug 2004 15:06:58 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7RJ5fOS028904; Fri, 27 Aug 2004 12:05:41 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7RH5Ogk017528; Fri, 27 Aug 2004 12:05:25 -0500 Message-ID: <412F85F8.3020907@motorola.com> Date: Fri, 27 Aug 2004 21:05:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <200408270114.i7R1ER4q028094@syrphus.ucdavis.edu> <412F20C3.1090209@motorola.com> In-Reply-To: <412F20C3.1090209@motorola.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070609080202010504020804" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms070609080202010504020804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Thanks for summarizing, some aspects have been overlooked. > > Fan Zhao wrote: > >> Problem statement: When one MR moves to a (nested) NEMO network and >> wants to connect to the Internet, we need to have an efficient and >> scalable mechanism for MR to choose which AR to attach to as fast >> as possible. Note that this problem may share some similarity with >> others in different scenarios. We need to know whether there is >> something specific to NEMO here or a more efficient solution works >> well with this problem in NEMO only but not in other scenarios. > > > Also one would check DNA BoF about Dynamic Network Attachment. Sorry its Detecting Network Attachment and it's a WG... Alex --------------ms070609080202010504020804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MjcxOTA1MjhaMCMGCSqGSIb3DQEJBDEWBBQLEOBE4IoaMmuxxcbIVw+MUu5OhzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCzSKnIyhwnLaSwT/Hdz0/zRhpB6IXJZP/WHFm+ N+mggvALAngdOoQx4d8dh86470qKb9zB95CnkHFoKNPZRWH/BaozKOxbm1Lh2NMnd72QUdCF bMOVvggq7MFbWcUW2f6j64wFrZd1k/7DsNv3SUkRTb8Yb3RcffdRk+FD4No2aQAAAAAAAA== --------------ms070609080202010504020804-- From nemo-bounces@ietf.org Sun Aug 29 14:10:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24210 for ; Sun, 29 Aug 2004 14:10:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Tz9-00050o-HE; Sun, 29 Aug 2004 14:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Tvr-0004RI-AG for nemo@megatron.ietf.org; Sun, 29 Aug 2004 13:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23533 for ; Sun, 29 Aug 2004 13:57:33 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1TxH-0005bZ-Rc for nemo@ietf.org; Sun, 29 Aug 2004 13:59:15 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7THvMAh024589 for ; Sun, 29 Aug 2004 19:57:22 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Aug 2004 19:57:22 +0200 Received: from ericsson.com (sealwa01m093.sw.ericsson.se [130.100.251.222]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QZMFSQYT; Sun, 29 Aug 2004 19:57:21 +0200 Message-ID: <413218FE.90705@ericsson.com> Date: Sun, 29 Aug 2004 19:57:18 +0200 X-Sybari-Trust: 53d25acf 74470f8f c74c2605 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] mor comments on TD References: <7892795E1A87F04CADFCCF41FADD00FC103F82@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC103F82@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2004 17:57:22.0408 (UTC) FILETIME=[A2606E80:01C48DF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>That's a nice thought and you have good intentions. >> >>I just don't agree with the assumptions you make; >> - no organisation, complete automation, no human decisions >> - lots of MRs >> - many levels of nesting > > > I gave an example of 10 MRs. That's not a lot. But in a daisy chain, > that's 10 levels of nesting - a lot. This is not a network design > problem, though - this may be totally ad hoc. It's a lack of capability > of the system. We want to avoid that. That's why we need TD. > > >>Of course we should not design a protocol (basic support) that only >>supports a limited number of MRs or a limited number of nesting > > levels, > >>for instance. But a good estimation of likely figures helps when > > making > >>design trade-offs. > > > Right, that was discussed at the beginning of the WG: > > We have scenarios with 3 or more level of nesting. But nothing says how > we get there. One such example is: > ferry boat <- car <- pan. > NEMO does not provide for the PAN to attach to a car (mine in > particular), for the car to attach to a ferry etc... We could end up > having a car joining the ferry and then the hundred other in a daisy > chain till the overhead of tunnels is so huge that it does not work at > all. > > We have been asked to look at realistic scenarios such as traffic jams. > That's 2000 cars. I did not make up the numbers. Now I think you are making a dangerous assumption here. You seem to say that an MR can hear any number of access points (ARs, other MRs' ingress interfaces etc.) _and that it connects to them all on the IP layer_, so that it can hear each and everybody's RA. This seem to indicate that there are no distinct logical links on top of 802.11 or whatever we run, but rather that there is basically only one single logical link where everybody can hear everybody else. This is really bad. This is what ad hoc assumes, but I would like to see NEMO assuming a bit more _structured_ and _managed_ networks. If an MR can hear all APs, I guess all MNNs can do the same. They all listen to the same channel. An MNN would find itself hearing 2000 prefixes then and maybe configure addresses from of them all, as long as is it within range. I say that an MR must first look for APs, then attach to one of them on L2, and finally listen to the RAs on L3. And while this is interesting to study, it is not related to NEMO. NEMO comes in after the third step. Vaguely defined L2 links are dangerous. They introduce so many problems. TD is just a small part of a solution. Think of whether this is a problem with wire NEMOs. I think we need to see wireless as a cable replacement rather than magic. /Mattias From nemo-bounces@ietf.org Sun Aug 29 14:11:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24362 for ; Sun, 29 Aug 2004 14:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Tz9-00050w-TL; Sun, 29 Aug 2004 14:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1Tvx-0004SX-Aw for nemo@megatron.ietf.org; Sun, 29 Aug 2004 13:57:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23538 for ; Sun, 29 Aug 2004 13:57:39 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1TxO-0005bi-SL for nemo@ietf.org; Sun, 29 Aug 2004 13:59:21 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7THvTWR018934 for ; Sun, 29 Aug 2004 19:57:29 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Aug 2004 19:57:29 +0200 Received: from ericsson.com (sealwa01m093.sw.ericsson.se [130.100.251.222]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Q6G6VAD3; Sun, 29 Aug 2004 19:57:28 +0200 Message-ID: <41321906.5040604@ericsson.com> Date: Sun, 29 Aug 2004 19:57:26 +0200 X-Sybari-Trust: b53bb7b5 477d8de1 f476a46b 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mazen TLAIS Subject: Re: [nemo] new draft References: <20040820100842.32429.qmail@web25002.mail.ukl.yahoo.com> In-Reply-To: <20040820100842.32429.qmail@web25002.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2004 17:57:29.0395 (UTC) FILETIME=[A68A9030:01C48DF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Content-Transfer-Encoding: 7bit Mazen TLAIS wrote: > Hi Mattias, > > Here are some responses for your comments > > >>You seem to assume that there is a suitable point in >>a typical access >>network where an ARC can be placed. From your draft >>I can't be sure what >>security relationships that are required, but if the >>ARC needs security >>relationships with many ARs this in general creates >>scalability >>problems. > > Updating messages sent by MR to ARC need > security relationships. I'm not sure about ARs. > > > >>My general assumption is that in order to >>benefit from >>multihoming, an MR would connect to various access >>networks of different >>technologies. That would mean that ARs belong to >>different domains. The >>nature of multihoming is to connect to the network >>in topological >>locations far from each other, often even completely >>unrelated >>locations. That is what makes the placement of an >>ARC difficult, as it >>is meant to be near the different ARs. But I may >>have misinterpreted >>your architecture. > > If the AR is registered within an ARC, then > this later can manage the AR. It's not a location > question. Continuing my assumption that there is a need for security associations between AR and ARC, if an AR is located in a different administrative domain than where the ARC is located, this generally creates scalability problems. Maybe you can line out what messages each entity sends to other entities, and what state change each message will cause at the receiver? Any state change must be authorized. > > > >>What is the actual function of the ARC? I don't >>think the draft explains >>clearly enough if it actually acts as a local home >>agent and creates >>bi-directional tunnels towards the MRs. > > through AR preferences option, ARC is responsible to > help MR to prefer an AR in face of another AR . > > But we assume that ARC MAY play the role of a > local home agent according to administrator's > configuration. > > > >>What makes it different from a MAP in HMIPv6 > > May be i misunderstand HMIPv6, but i think that MAP is > useful for handoff operation, it does not manage > resources, and the MR does not have any additional > information to choose between different ARs. That is very true. > > >>(apart >>from the very >>loosely defined resource reservations you include)? > > In our draft, we present a possible scenario > of the ARC contribution to reserve resources. > We are working now on a complete idea for end to end > reservation protocol adapted for NEMO networks. But we > need few weeks to finalize it. OK, we'll see. /Mattias From nemo-bounces@ietf.org Mon Aug 30 06:00:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06932 for ; Mon, 30 Aug 2004 06:00:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1ivy-0001fk-Lo; Mon, 30 Aug 2004 05:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1iuq-0001VS-97 for nemo@megatron.ietf.org; Mon, 30 Aug 2004 05:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06773 for ; Mon, 30 Aug 2004 05:57:29 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1iwV-0007ao-WE for nemo@ietf.org; Mon, 30 Aug 2004 05:59:20 -0400 Received: from n128-157.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7U9uM4v024089; Mon, 30 Aug 2004 18:56:23 +0900 Date: Mon, 30 Aug 2004 18:56:22 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] Alternative to TD: forbid MR become AR until BAck received In-Reply-To: <412F116E.3080009@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> <412F116E.3080009@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Alex and Pascal. Your proposal works. MR can send RA with router lifetime set to zero and prefix lifetime set to non-zero. I found following possible issues. When MR stop serving a default route to MNNs even for short time, MNN sessions will be cut off because of "no route". Some of applications cannot recover connectivity. You can add some modification to MNN to handle the in-out default route, but it is not easily accepted. It also has same problem of routing approach of the basic NEMO. NDP must be aware of the NEMO state. When does MR set router lifetime to zero? as soon as (re-)sending BU? Actually the looping problem is occurred while MR1 lost connectivity and is retrying BU. Another MR2 can connect to MR1 before giving up BAck. I think you just came up with this idea, it will be nice to write complete spec. as a draft. regards, ryuji At Fri, 27 Aug 2004 12:48:14 +0200, Alexandru Petrescu wrote: > > [1 ] > Pascal Thubert (pthubert) wrote: > > 1) nodes in the MNP can not form global addresses till the MR is > > registered. > > First, nodes in the moving network immediately under MR _may_ form > global addresses, they just won't have a default route if the Router > Lifetime is not zero. > > All other nodes in the moving network (not immediately under MR) may > form and addresses and default routes towards their respective FR's. > > > This prevents a bunch of things including MANET in the nested > > structure > > Which MANET? > > > and limits node to node communication to link local. > > This is not a limitation. If the MR is not connected to its HA then > nodes under MR don't have to whom to communicate outside the local link. > > > 2) there's not much control/optimization on the resulting shape. > > There's no control and no optimization, it just works. > > > 3) What happens when the TLMR moves and looses access? > > When TLMR moves and looses access then nodes within the moving network > can only talk to each other, this is as natural as it gets. No node in > the moving network needs to use TLMR as a default router if that default > router is not connected to the Internet. > > > 4) The binding lifetime is orders of magnitude longer then RAs that > > TD uses. So the reaction to changes may take quite some time. > > Every 4 seconds the MR can know whether it's connected to its HA or not. > I find 4 seconds to be enough to avoid loop forming. You find it's too > long? Maybe propose something to the MIP6 WG. > > > You need to write up something more complete to detail your proposal > > Maybe... before starting writing anything I want to be sure there's a > need for that thing, that there's a problem to be solved, that there's > value to customers, that it's priority, that there's interoperability > needed, etc. > > > 5) you know that RRH allows a configuration where a mobile Home Agent > > is nested behind its own MRs, and that was presented twice at the > > WG. Your proposal kills this kind if stuff. > > Huh??? > > What is my proposal killing more exactly, I don't get it, frankly speaking. > > Why mentioning a mobile HA behind its own MR, is this solving > "cross-over tunnel" or something? I wouldn't propose anything against > that... > > Alex > [2 OpenPGP digital signature ] > From nemo-bounces@ietf.org Mon Aug 30 06:56:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11568 for ; Mon, 30 Aug 2004 06:56:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1jny-0000MQ-S7; Mon, 30 Aug 2004 06:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1jiM-0008Hg-St for nemo@megatron.ietf.org; Mon, 30 Aug 2004 06:48:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11139 for ; Mon, 30 Aug 2004 06:48:40 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1jk7-0000TR-MI for nemo@ietf.org; Mon, 30 Aug 2004 06:50:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 13:01:18 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UAllTc011178; Mon, 30 Aug 2004 12:48:08 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 12:47:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] mor comments on TD Date: Mon, 30 Aug 2004 12:47:47 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] mor comments on TD Thread-Index: AcSN8avz2FLCFiVWRxKWPBeiD90T1gAisbOA From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson" X-OriginalArrivalTime: 30 Aug 2004 10:47:53.0007 (UTC) FILETIME=[CD07A3F0:01C48E7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Mattias: I'm happy that you point this out because it's at the core of the problem. Note that we started a discussion like this about with John from 802.21 when came present his work at IETF 59. > > > > We have scenarios with 3 or more level of nesting. But nothing says how > > we get there. One such example is: > > ferry boat <- car <- pan. > > NEMO does not provide for the PAN to attach to a car (mine in > > particular), for the car to attach to a ferry etc... We could end up > > having a car joining the ferry and then the hundred other in a daisy > > chain till the overhead of tunnels is so huge that it does not work at > > all. > > > > We have been asked to look at realistic scenarios such as traffic jams. > > That's 2000 cars. I did not make up the numbers. >=20 > Now I think you are making a dangerous assumption here. You seem to say > that an MR can hear any number of access points (ARs, other MRs' ingress > interfaces etc.) _and that it connects to them all on the IP layer_, so > that it can hear each and everybody's RA. All of them is a big word. A number of them is closer to the truth.=20 The radio world is far from limited to 802.11, and there are radios around that allow you to get signals from more then one neighbour. Quite a good thing in my view, if we want all this MANET thing to work at all. >=20 > This seem to indicate that there are no distinct logical links on top of > 802.11 or whatever we run, but rather that there is basically only one > single logical link where everybody can hear everybody else. This is > really bad. This is what ad hoc assumes, but I would like to see NEMO > assuming a bit more _structured_ and _managed_ networks. >=20 Use cases... There's no such a restriction that I know of for NEMO applicability. I copy Thierry, in case he wishes to provide his view on this debate. > If an MR can hear all APs, I guess all MNNs can do the same. They all > listen to the same channel. An MNN would find itself hearing 2000 > prefixes then and maybe configure addresses from of them all, as long as > is it within range. Now I think you are making a dangerous assumption here :) LFNs could be wired or connected to the MR using short range techno such as Bluetooth. Allowing LFNs to listen to other MRs simply kills the whole thing.=20 > I say that an MR must first look for APs, then attach to one of them on > L2, and finally listen to the RAs on L3. This is what we do today with 802.11. Basically a blind L2 selects the AR on behalf of L3. This is very near sighted :( This is why we asked for a better interface from 802.21. Hopefully, we'll be able to get all the RAs from all the APs from monitor mode, and then let L3 (and above) sort out which router it needs to connect to; and then associate, under L3 control. This is not only good for NEMO/TD. It applies to draft-ietf-ipv6-router-selection-05.txt for instance. Pascal From nemo-bounces@ietf.org Mon Aug 30 08:15:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17888 for ; Mon, 30 Aug 2004 08:15:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1l0J-0001BF-Js; Mon, 30 Aug 2004 08:11:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1ku5-0000f4-Tr for nemo@megatron.ietf.org; Mon, 30 Aug 2004 08:04:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15591 for ; Mon, 30 Aug 2004 08:04:52 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1kvq-0002EG-54 for nemo@ietf.org; Mon, 30 Aug 2004 08:06:43 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7UC3vOS008987; Mon, 30 Aug 2004 05:03:58 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7UC3uBV010400; Mon, 30 Aug 2004 07:03:56 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8DE6588043E; Mon, 30 Aug 2004 14:03:55 +0200 (CEST) Message-ID: <413317A5.3000604@motorola.com> Date: Mon, 30 Aug 2004 14:03:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Alternative to TD: forbid MR become AR until BAck received References: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> <412F116E.3080009@motorola.com> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig363A4700A206EE30ECE27688" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig363A4700A206EE30ECE27688 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ryuji, Ryuji Wakikawa wrote: > Your proposal works. MR can send RA with router lifetime set to zero > and prefix lifetime set to non-zero. True. And thanks to this it is possible for LFN's to autoconfigure addresses and talk to each other even if they can't talk to CN's on the Internet. And this is normal as long as MR is disconnected from its HA. MR connected to its HA means: MR has a tunnel up with its HA. MR connected to AR means: MR is connected to AR. MR can be connected to AR but not its HA. LFN's are connected to the Internet when MR is connected its HA; it is not sufficient for MR to be connected to AR in order for LFN's to be connected to the Internet. > I found following possible issues. > > When MR stop serving a default route to MNNs even for short time, MNN > sessions will be cut off because of "no route". It is an issue if you look at it in isolation. But, if MR does advertise itself as a default router (although it's not connected to its HA) then MNN sessions will be cut off because of "no TCP ACK". For one reason or another, the MNN-CN sessions will be cut off if MR is not connected to its HA. It is not the "Router Lifetime 0" in the RA that makes the MNN sessions to be cut off. It's because MR has not received BAck, so having Router Lifetime 0 or non-zero makes no difference to MNN sessions being cut off. Not to be forgotten the fact that all sessions between all LFN's within the moving network will not be cut off if the MR is disconnected from its HA and MR does not advertise as a default router. > Some of applications cannot recover connectivity. Applications that need to recover connectivity when MR re-connects to its HA are not helped by some packets that LFN had sent and have arrived at MR (MR simply drops them if no tunnel). So applications that need to recover do not care whether the Router Lifetime was 0 or not. > You can add some modification to MNN to handle the in-out default > route, but it is not easily accepted. I wouldn't write such an application looking at flapping routes either. > It also has same problem of routing approach of the basic NEMO. NDP > must be aware of the NEMO state. When does MR set router lifetime to > zero? as soon as (re-)sending BU? I don't get it... HA runs NDP when it has sent BAck to MN... no? MR sets ingress router lifetime to 0 always. Only when it has a confirmed entry in its BC list (received positive BAck) can it set the router lifetime different than 0. > Actually the looping problem is occurred while MR1 lost connectivity > and is retrying BU. Another MR2 can connect to MR1 before giving up > BAck. Could you please explain in more detail? First, do you agree this is not a true complete "looping problem"? The packets will not loop between two MR's, do you agree with this? Even if TD is not used, even if the ingress router lifetime=0 is not zero, the packets do not loop within the MR1-MR2 pair, even if the two MR's are connected in a looping fashion... > I think you just came up with this idea, it will be nice to write > complete spec. as a draft. Yes, I've had just thought of it, only to improve somehow the picture that Pascal was seeing about loops everywhere, and such as to say that it is sufficient to have some configuration helpers. About writing a draft... I'm not sure... not until a problem is clearer. Alex --------------enig363A4700A206EE30ECE27688 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMxerMmC0w56zj54RAvfmAJ9QkfRjq3ALIQhweiS7NI63Aw611ACgxAg0 EnVT5LA5XoJnofm7XeVZ0Aw= =RmD7 -----END PGP SIGNATURE----- --------------enig363A4700A206EE30ECE27688-- From nemo-bounces@ietf.org Mon Aug 30 08:37:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19250 for ; Mon, 30 Aug 2004 08:37:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lKw-0003aR-HN; Mon, 30 Aug 2004 08:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lJ2-0003Sd-PG for nemo@megatron.ietf.org; Mon, 30 Aug 2004 08:30:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18602 for ; Mon, 30 Aug 2004 08:30:39 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1lKo-0002ro-Fu for nemo@ietf.org; Mon, 30 Aug 2004 08:32:30 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7UCTGGU007492; Mon, 30 Aug 2004 05:29:16 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i7UCSAYD009294; Mon, 30 Aug 2004 07:28:11 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5F8CE88043E; Mon, 30 Aug 2004 14:28:10 +0200 (CEST) Message-ID: <41331D55.9070600@motorola.com> Date: Mon, 30 Aug 2004 14:28:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] mor comments on TD References: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig866570880AD476C0C2CA7755" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: IETF NEMO WG , Mattias Pettersson X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig866570880AD476C0C2CA7755 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The radio world is far from limited to 802.11, and there are radios > around that allow you to get signals from more then one neighbour. > Quite a good thing in my view, if we want all this MANET thing to > work at all. Pascal, partially true. You're saying "there are radios around that allow you to get signals from more than one neighbour". As if this was not the case with 802.11b. Well, it is. You're saying "if we want all this MANET thing to work at all". Well, I do not want this MANET thing to work at all until I know what exactly is this "MANET thing". I strongly doubt there is a commonly accepted view of what this "MANET thing" is other than a very fruitful research topic and a set of experimental proposals, some more mature than the other. >> If an MR can hear all APs, I guess all MNNs can do the same. Yes, this is logic. But note that with 802.11b an MR can only listen to RA's from a link on which it is configured with an ESSID and/or a key. Before listening to RA's, the Client listens to Beacons; the User selects an ESSID manually and only then does it listen for RA's. In an area where Client listens to Beacons of two AP's and that send no ESSID, no key and different RA's, the Client and the AP's have many problems to talk to each other, see impossible. >> They all listen to the same channel. An MNN would find itself >> hearing 2000 prefixes then and maybe configure addresses from of >> them all, as long as is it within range. Again, this is not an IP problem at all. You can not have a meaningful IP configuration in an area where two AP's emit their Beacons without ESSID, without key and that are connected to different IP wired Ethernet subnets. This is like physically connecting together two Ethernet cables of two totally different IP subnets. > Now I think you are making a dangerous assumption here :) LFNs could > be wired or connected to the MR using short range techno such as > Bluetooth. Allowing LFNs to listen to other MRs simply kills the > whole thing. > >> I say that an MR must first look for APs, then attach to one of >> them on L2, and finally listen to the RAs on L3. > > This is what we do today with 802.11. Basically a blind L2 selects > the AR on behalf of L3. This is very near sighted :( If it were true, it were near sighted. Pascal, with Linux and Windows and Mac Clients, it is the _human user_ that selects an ESSID to connect to (in Windows and MAC there are some preferences that allow for automation but it's still a human who set those preferences). The only apparent problem is when preferences are wrongly set, or when two AP's send Beacons without ESSID's. It is not true that a blind L2 selects the AR on behalf of L3. > This is why we asked for a better interface from 802.21. Sorry, where did you ask for this? Did they give you anything better than a MAC-family? I wouldn't ask for anything different than MAC because most stacks work on MAC today. What are you talking about more explicitly here? What's 802.21 and what's the relation to NEMO? > Hopefully, we'll be able to get all the RAs from all the APs from > monitor mode, No no no... I don't want that. I want the RA to be sent on well established and meaningful "virtual" L2 cables already established. I don't want IP to be adapted to this model. > and then let L3 (and above) sort out which router it needs to connect > to; and then associate, under L3 control. This is not only good for > NEMO/TD. But the current ND has already a good model of local broadcast and local multicast. Would this work with this new L2? Alex --------------enig866570880AD476C0C2CA7755 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMx1aMmC0w56zj54RAhCJAKCILgMNjiIC/XP7P+OfxpINkunQXgCg9haH RWv3iF//fBfhhdAr59htZiA= =hSrt -----END PGP SIGNATURE----- --------------enig866570880AD476C0C2CA7755-- From nemo-bounces@ietf.org Mon Aug 30 09:09:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21443 for ; Mon, 30 Aug 2004 09:09:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lp5-0007QP-G2; Mon, 30 Aug 2004 09:03:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lk8-0006gJ-85 for nemo@megatron.ietf.org; Mon, 30 Aug 2004 08:58:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20879 for ; Mon, 30 Aug 2004 08:58:38 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1llt-0003Vi-7Z for nemo@ietf.org; Mon, 30 Aug 2004 09:00:30 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 15:11:15 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UCw1TQ028814; Mon, 30 Aug 2004 14:58:04 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 14:57:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 14:57:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104129@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMVyDIkp0n8trgQB+CqiCvK6j3YACOK8ww From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 12:57:58.0776 (UTC) FILETIME=[F9A17780:01C48E90] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Content-Transfer-Encoding: quoted-printable > In fact, what do you assume "CRC-32c" to be more exactly, if I'm not too > ignorant. I'd suppose it to be "Cyclic Redundancy Check (CRC) codes > [Peterson] are shortened cyclic codes used for error detection." But > what is the "32c" part? Two's complement or something on 32bit? Which > CRC code more exactly? CRC32C has been proven quite strong and is used for modern protocols such as SCTP and iSCSI. If you *really* want more, I suggest you read rfc 3385. Enjoy :) BTW, here's the patch file that added CRC32C to linux 2.6: http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1648.html So you see: it's not like if the code was not available. >=20 > Note CRC's are for checking message integrity for error correction not > for checking a path has changed. >=20 > Note "Digest" in "PathDigest" invites to think of message digest (like > in "MD5"); digests are also used to check for integrity, but not for > "path has changed". >=20 > I doubt that combining "Digest" with "CRC" makes a good tool for "path > has changed". >=20 Imagine a message that would be the concatenation of all the careofs. And compute a digest of that message. If anything changes in the path (one or more careofs, the number of careofs, whatever), and if the digest algorithm is properly distributed, there are little chances (at best one out of 2^bits_in_digest) that the digest stays the same. We use a 32 bits digest... Since we do not want to pass all the list in the RA, we actually compute: Crc32c(CoA, Crc32c(CoA, Crc32c(CoA, Crc_32( ... Crc32c(CoA, 0) ...) ) ) ) <---------------------------------------------------------> Received in TIO from Attachment Router over egress =20 <----------------------------------------------------------------------- -> Sent in TIO over ingress interfaces to all nodes including visitors =20 This also lets little chance for any change in the chain to go undetected. So that is quite a good tool to check whether the path has changed and I'm surprised you doubt that. Whether it's too expensive is another issue, but this thing does the job quite well.=20 Pascal From nemo-bounces@ietf.org Mon Aug 30 09:12:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21592 for ; Mon, 30 Aug 2004 09:12:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lv3-0008Ba-61; Mon, 30 Aug 2004 09:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1lpy-0007WJ-Tn for nemo@megatron.ietf.org; Mon, 30 Aug 2004 09:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21171 for ; Mon, 30 Aug 2004 09:04:41 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1lrk-0003e2-FF for nemo@ietf.org; Mon, 30 Aug 2004 09:06:33 -0400 Received: from n128-157.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i7UD3c4v026433; Mon, 30 Aug 2004 22:03:38 +0900 Date: Mon, 30 Aug 2004 22:03:38 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] Alternative to TD: forbid MR become AR until BAck received In-Reply-To: <413317A5.3000604@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> <412F116E.3080009@motorola.com> <413317A5.3000604@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: nemo@ietf.org, pthubert@cisco.com, ryuji@sfc.wide.ad.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 Alex At Mon, 30 Aug 2004 14:03:49 +0200, Alexandru Petrescu wrote: > > [1 ] > Hi Ryuji, > > Ryuji Wakikawa wrote: > > Your proposal works. MR can send RA with router lifetime set to zero > > and prefix lifetime set to non-zero. > > True. And thanks to this it is possible for LFN's to autoconfigure > addresses and talk to each other even if they can't talk to CN's on the > Internet. And this is normal as long as MR is disconnected from its HA. > > MR connected to its HA means: MR has a tunnel up with its HA. > MR connected to AR means: MR is connected to AR. > > MR can be connected to AR but not its HA. > > LFN's are connected to the Internet when MR is connected its HA; it is > not sufficient for MR to be connected to AR in order for LFN's to be > connected to the Internet. right. > > I found following possible issues. > > > > When MR stop serving a default route to MNNs even for short time, MNN > > sessions will be cut off because of "no route". > > It is an issue if you look at it in isolation. > > But, if MR does advertise itself as a default router (although it's not > connected to its HA) then MNN sessions will be cut off because of "no > TCP ACK". Yes, if this is the case when MR lost the Internet connectivity. Can you clarify the timing when MR stop advertising its default router!? During normal movement detection, the tunnel will be re-established due to CoA change. It takes certain time of "sending BU and receiving BA" from the movement detection to the tunnel re-establishment. Does MR stop advertising default route at the movement detection? The point is that MR is no idea whether it can re-establish tunnel right after movement detection. > For one reason or another, the MNN-CN sessions will be cut off if MR is > not connected to its HA. It is not the "Router Lifetime 0" in the RA > that makes the MNN sessions to be cut off. It's because MR has not > received BAck, so having Router Lifetime 0 or non-zero makes no > difference to MNN sessions being cut off. right. I was talking about normal movement detection (change AR and renew tunnel). see above. > Not to be forgotten the fact that all sessions between all LFN's within > the moving network will not be cut off if the MR is disconnected from > its HA and MR does not advertise as a default router. > > > Some of applications cannot recover connectivity. > > Applications that need to recover connectivity when MR re-connects to > its HA are not helped by some packets that LFN had sent and have arrived > at MR (MR simply drops them if no tunnel). So applications that need to > recover do not care whether the Router Lifetime was 0 or not. Slightly different. If MNN keeps a default router, it sends packets to MR (default router) regardless of MR's tunnel availability. Then, MR can buffer certain packets till the tunnel is recovered. Or it can just drops these packets without issuing any ICMP error messages to MNN. In such case, session is still active although TCP window size will be closed. On the other hand, if MNN lost its default route, applications get unreachable error and may stop. > > You can add some modification to MNN to handle the in-out default > > route, but it is not easily accepted. > > I wouldn't write such an application looking at flapping routes either. > > > It also has same problem of routing approach of the basic NEMO. NDP > > must be aware of the NEMO state. When does MR set router lifetime to > > zero? as soon as (re-)sending BU? > > I don't get it... HA runs NDP when it has sent BAck to MN... no? > > MR sets ingress router lifetime to 0 always. Only when it has a > confirmed entry in its BC list (received positive BAck) can it set the > router lifetime different than 0. > > > Actually the looping problem is occurred while MR1 lost connectivity > > and is retrying BU. Another MR2 can connect to MR1 before giving up > > BAck. > > Could you please explain in more detail? MR detects movement and sends BU at the time "t1". It gives up tunnel establishment and stop sending default route at the time "t2". During "t2-t1", other MR (MR2) can connect to MR1 and will try to send BU via MR1. I am not clear whether MR stop advertising default router after failure of single BU or numbers of BU. In latter case, (t2-t1) will not be negligible. According to MIP6 spec, MAX_BINDACK_TIMEOUT is 32 seconds. So my question is when does MR decide to stop default route advertisement? > First, do you agree this is not a true complete "looping problem"? The > packets will not loop between two MR's, do you agree with this? Even if > TD is not used, even if the ingress router lifetime=0 is not zero, the > packets do not loop within the MR1-MR2 pair, even if the two MR's are > connected in a looping fashion... I saw looong discussions on ML and can agree both you and Pascal. It is true that the topological loop is occurred. But packets are never looped as you noted. > > I think you just came up with this idea, it will be nice to write > > complete spec. as a draft. > > Yes, I've had just thought of it, only to improve somehow the picture > that Pascal was seeing about loops everywhere, and such as to say that > it is sufficient to have some configuration helpers. > > About writing a draft... I'm not sure... not until a problem is clearer. :-) ryuji From nemo-bounces@ietf.org Mon Aug 30 09:37:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23362 for ; Mon, 30 Aug 2004 09:37:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mEV-0001sr-Tz; Mon, 30 Aug 2004 09:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1m9c-0001Nf-Qj for nemo@megatron.ietf.org; Mon, 30 Aug 2004 09:25:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22565 for ; Mon, 30 Aug 2004 09:24:59 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mBO-00044H-2Q for nemo@ietf.org; Mon, 30 Aug 2004 09:26:51 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 15:37:37 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UDOKTS003122; Mon, 30 Aug 2004 15:24:25 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 15:24:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 15:24:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104139@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSMV2ysx3n9uZQZTO6w0rtTuXOCswCPRhsg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 13:24:06.0876 (UTC) FILETIME=[A04A89C0:01C48E94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: vendredi 27 ao=FBt 2004 18:57 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft >=20 > Pascal Thubert (pthubert) wrote: > > MR receives digest in RA-TIO from AR over egress and saves it. MR > > computes newdigest =3D CRC32(digest, CoA) and puts that in the = RA-TIO > > it sends over ingress. > > > > Next time MR gets RA-TIO, it compares the consecutive digest and if > > they are different, something changed in the chain of MRs to the > > outside. > > > > The computation of CRC is not done for itself but for the guys below > > so that the digest has all the CoAs within it. I hope you = understand > > that, or someone else has to try using different words. >=20 > Ok, how about this substitution of "bit" for "CRC": >=20 > MR receives bit in RA-TIO from AR over egress and saves it. MR > computes new bit =3D not-bit and puts that in the RA-TIO it sends = over > ingress. >=20 > Next time MR gets RA-TIO it compares the consecutive bits and if = they > are different, something has changed in the chain of MR's to the > outside. >=20 > The computation of the bit is not done for itself but for the guys > below so that the bit has all the previous MR's bits within it. >=20 > I think it can work with one-bit only, no? Two consecutive changes end up restoring the bit, right? Pascal From nemo-bounces@ietf.org Mon Aug 30 09:39:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23480 for ; Mon, 30 Aug 2004 09:39:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mK4-0002W1-8N; Mon, 30 Aug 2004 09:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mE2-0001lL-5Q for nemo@megatron.ietf.org; Mon, 30 Aug 2004 09:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22829 for ; Mon, 30 Aug 2004 09:29:32 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mFo-00049x-D6 for nemo@ietf.org; Mon, 30 Aug 2004 09:31:24 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7UDUMGU018432; Mon, 30 Aug 2004 06:30:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7UDLLFT003191; Mon, 30 Aug 2004 08:21:22 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5305C88043E; Mon, 30 Aug 2004 15:29:16 +0200 (CEST) Message-ID: <41332BA7.2000808@motorola.com> Date: Mon, 30 Aug 2004 15:29:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104129@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104129@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig22BF8E9DADBA09275EF2BA47" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig22BF8E9DADBA09275EF2BA47 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> In fact, what do you assume "CRC-32c" to be more exactly, if I'm >> not too ignorant. I'd suppose it to be "Cyclic Redundancy Check >> (CRC) codes [Peterson] are shortened cyclic codes used for error >> detection." But what is the "32c" part? Two's complement or >> something on 32bit? > > Which CRC code more exactly? > > CRC32C has been proven quite strong and is used for modern protocols > such as SCTP and iSCSI. If you *really* want more, I suggest you > read rfc 3385. Enjoy :) I was not saying CRC32C was not strong (although I doubt the qualification of "strong" for an error detection code, "strong" is better adapted for encryption codes). I was asking what exactly is it other than some redundancy check for communicating to SCSI devices (not even IP over SCSI). And why not using the classic ICMP Checksum as documented in rfc2460/1/2/3/4. Do you have any reason to prefer CRC32c instead of this IPv6 checksum? Is one having a better error detection capability than the other? > BTW, here's the patch file that added CRC32C to linux 2.6: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1648.html > > So you see: it's not like if the code was not available. Ok, I was not saying that CRC32C were not publicly available. But, since you talk about this, and since you've mentioned there may be IPR on TD, would the TD IPR cover the use of CRC32c? >> Note CRC's are for checking message integrity for error correction >> not for checking a path has changed. >> >> Note "Digest" in "PathDigest" invites to think of message digest >> (like in "MD5"); digests are also used to check for integrity, but >> not for "path has changed". >> >> I doubt that combining "Digest" with "CRC" makes a good tool for >> "path has changed". >> > Imagine a message that would be the concatenation of all the careofs. > And compute a digest of that message. If anything changes in the > path (one or more careofs, the number of careofs, whatever), and if > the digest algorithm is properly distributed, there are little > chances (at best one out of 2^bits_in_digest) that the digest stays > the same. We use a 32 bits digest... I understand that... but I don't know whether sending the digest separated from the actual message makes much sense. Do you know about another example mechanism where they'd send the digest separated from the actual message? I know in S/MIME email it's not the case, in ICMP checksums it's not the case either... if you know of such a case (where the digest is sent separated from the original), I want to learn. > Since we do not want to pass all the list in the RA, we actually > compute: > > Crc32c(CoA, Crc32c(CoA, Crc32c(CoA, Crc_32( ... Crc32c(CoA, 0) ...) ) > ) ) > > <---------------------------------------------------------> Received > in TIO from Attachment Router over egress > > <----------------------------------------------------------------------- > -> Sent in TIO over ingress interfaces to all nodes including > visitors I understand the mechanism. I understand how it works. I doubt it's a good use of CRC32c and I doubt it's an efficient and secure mechanism to detect something has changed in the upper path. Call me pessimistic but I also doubt there's a need to detect something has changed in the upper path as long as the whole "looping problem" is not actually a problem with NEMO MR's. > This also lets little chance for any change in the chain to go > undetected. It actually lets a big change for to falsely indicate that something has changed when actually nothing has. If an intermediary MR is suddenly replace by another, the CRC stuff will be different because different EUID's. > So that is quite a good tool to check whether the path has changed > and I'm surprised you doubt that. Do you agree that there are situations where the leaf MR will believe something has changed when nothing has, actually? > Whether it's too expensive is another issue, but this thing does the > job quite well. Yes, expensive is another issue, but it is a certitude that it does not do the job quite well, based on my above example with "replacing MR", no? Alex --------------enig22BF8E9DADBA09275EF2BA47 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMyusMmC0w56zj54RAom9AKDUfiFAb8Ljzm7iwkpvk5ljCO1OAACdHS+a yz4/jvGbCp8If5wrmsREXig= =rKtS -----END PGP SIGNATURE----- --------------enig22BF8E9DADBA09275EF2BA47-- From nemo-bounces@ietf.org Mon Aug 30 09:50:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24079 for ; Mon, 30 Aug 2004 09:50:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mVl-0004Od-0B; Mon, 30 Aug 2004 09:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mPo-0003bI-LW for nemo@megatron.ietf.org; Mon, 30 Aug 2004 09:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23666 for ; Mon, 30 Aug 2004 09:41:42 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mRa-0004QT-SC for nemo@ietf.org; Mon, 30 Aug 2004 09:43:35 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i7UDXhjf015836; Mon, 30 Aug 2004 06:33:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i7UDeCBV028623; Mon, 30 Aug 2004 08:40:13 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3740188043E; Mon, 30 Aug 2004 15:40:12 +0200 (CEST) Message-ID: <41332E36.8080500@motorola.com> Date: Mon, 30 Aug 2004 15:40:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104139@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104139@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000404070407030103090508" X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms000404070407030103090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Pascal Thubert (pthubert) wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:Alexandru.Petrescu@motorola.com] Sent: vendredi 27 août >> 2004 18:57 To: Pascal Thubert (pthubert) Cc: nemo@ietf.org Subject: >> Re: Summary Re: [nemo] comments on "Tree Discovery" draft >> >> Pascal Thubert (pthubert) wrote: >> >>> MR receives digest in RA-TIO from AR over egress and saves it. MR >>> computes newdigest = CRC32(digest, CoA) and puts that in the >>> RA-TIO it sends over ingress. >>> >>> Next time MR gets RA-TIO, it compares the consecutive digest and >>> if they are different, something changed in the chain of MRs to >>> the outside. >>> >>> The computation of CRC is not done for itself but for the guys >>> below so that the digest has all the CoAs within it. I hope you >>> understand that, or someone else has to try using different >>> words. >> >> Ok, how about this substitution of "bit" for "CRC": >> >> MR receives bit in RA-TIO from AR over egress and saves it. MR >> computes new bit = not-bit and puts that in the RA-TIO it sends >> over ingress. >> >> Next time MR gets RA-TIO it compares the consecutive bits and if >> they are different, something has changed in the chain of MR's to >> the outside. >> >> The computation of the bit is not done for itself but for the guys >> below so that the bit has all the previous MR's bits within it. >> >> I think it can work with one-bit only, no? > > > Two consecutive changes end up restoring the bit, right? Yes, and this means that if a multiple of two intermediate MR's disappear simultaneously then leaf MR won't notice. At the same time, the digesting method has the inconvenient that if one intermediate MR is instantaneously replaced by another then the leaf MR will notice a change (in fact there's no change, it's the same number of intermediary IP hops). My method can be still used if a very fine time sampling is used, such that there can not be too actual simultaneous MR's disparritions. Your method can be improved if the digest is applied on something else than the CoA, maybe on the depth level number defined somewhere in the TD draft. It's these kinds of things that are needed in order for a draft to become WG item, IMHO... Alex --------------ms000404070407030103090508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MzAxMzQwMDZaMCMGCSqGSIb3DQEJBDEWBBSktxa4M+8i2Mmk2qHqXO0QUr01sDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCH7kvgeOTH3LZLsuY97ZE8Jkodq+KINjmtq9aj ZnkGyKj86dCdWgXSS6xJQ3gp0qeG54nYzpQknQjGOzJdA7B8h0oAnoOrbyqpZV/yFmcbz8qd iCGj7sXf/tgUhlLwvHgh0gCu3BvY6PoEjU9+ahbb3dsxhJa0AUINbqIlGWpHGgAAAAAAAA== --------------ms000404070407030103090508-- From nemo-bounces@ietf.org Mon Aug 30 10:09:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25790 for ; Mon, 30 Aug 2004 10:09:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mo8-0001B4-IQ; Mon, 30 Aug 2004 10:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mkD-0007Oj-6l for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:02:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24857 for ; Mon, 30 Aug 2004 10:02:46 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1mly-0004s9-6B for nemo@ietf.org; Mon, 30 Aug 2004 10:04:39 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i7UDkD94015858; Mon, 30 Aug 2004 06:46:13 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7UBoHgk005386; Mon, 30 Aug 2004 06:50:18 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 55E8A88043E; Mon, 30 Aug 2004 15:50:29 +0200 (CEST) Message-ID: <4133309F.7080603@motorola.com> Date: Mon, 30 Aug 2004 15:50:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Alternative to TD: forbid MR become AR until BAck received References: <7892795E1A87F04CADFCCF41FADD00FC103E77@xmb-ams-337.emea.cisco.com> <412F116E.3080009@motorola.com> <413317A5.3000604@motorola.com> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060305080507090004080506" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: nemo@ietf.org, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms060305080507090004080506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > Can you clarify the timing when MR stop advertising its default > router!? Suppose MR is currently default router. Next time it sends a second BU because the first has not been answered is a good time to stop advertising itself as a default router. Just an idea. > During normal movement detection, the tunnel will be re-established > due to CoA change. It takes certain time of "sending BU and receiving > BA" from the movement detection to the tunnel re-establishment. Does > MR stop advertising default route at the movement detection? Stop advertising as DR when a second BU has been sent because the previous was not answered. > Slightly different. If MNN keeps a default router, it sends packets > to MR (default router) regardless of MR's tunnel availability. Then, > MR can buffer certain packets till the tunnel is recovered. Or it can > just drops these packets without issuing any ICMP error messages to > MNN. In such case, session is still active although TCP window size > will be closed. I see what you mean, I think the issue is important. I think in practice, the application behaviour depends on a large number of parameters of MR re-connecting to new AR. I am sure we don't want default route flapping on the LFN's to induce bad application performance. For this matter, I'd say that we need good handovers. It may also be that we don't want default route flapping all the time, or we just want some intelligent default route set up and tear down. > MR detects movement and sends BU at the time "t1". It gives up tunnel > establishment and stop sending default route at the time "t2". > > During "t2-t1", other MR (MR2) can connect to MR1 and will try to > send BU via MR1. > > I am not clear whether MR stop advertising default router after > failure of single BU or numbers of BU. In latter case, (t2-t1) will > not be negligible. After failure of first BU for same pair HoA-CoA. #Defined as 1 true and set in stone. >> First, do you agree this is not a true complete "looping problem"? >> The packets will not loop between two MR's, do you agree with this? >> Even if TD is not used, even if the ingress router lifetime=0 is >> not zero, the packets do not loop within the MR1-MR2 pair, even if >> the two MR's are connected in a looping fashion... > > I saw looong discussions on ML and can agree both you and Pascal. It > is true that the topological loop is occurred. But packets are never > looped as you noted. Yes, me too I think the same. Alex --------------ms060305080507090004080506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4 MzAxMzUwMjNaMCMGCSqGSIb3DQEJBDEWBBRfZb3CNjraejEzXMpppXqYtNkCFjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCupnN1f+pBViwX/LsCMt1fT4PmHmNUOVgqkB/j RoeCLvujF8bk1/6Td0qh7Am8mQqX9vWSpK8IgJ4e89NQV+RrmQbbR3tiVJsZzojhx/VjtHMQ yrKRCO7DHNaU8ZRt9Run4YNdCtEMZU1wSLlHdP9YrGUYWModQOsF9aNkPF2uhwAAAAAAAA== --------------ms060305080507090004080506-- From nemo-bounces@ietf.org Mon Aug 30 10:33:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28186 for ; Mon, 30 Aug 2004 10:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nAL-0007Xz-2J; Mon, 30 Aug 2004 10:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1n1P-0005Zg-Bj for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:20:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26927 for ; Mon, 30 Aug 2004 10:20:33 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1n3A-0005Fb-VM for nemo@ietf.org; Mon, 30 Aug 2004 10:22:26 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 16:33:12 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UEJ3TY011673; Mon, 30 Aug 2004 16:19:59 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 16:19:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 16:19:50 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOlxt5UXaOxwRfTDqVf9OyMSqzyQAAN4XA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 14:19:54.0713 (UTC) FILETIME=[6BC1EC90:01C48E9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Content-Transfer-Encoding: quoted-printable > > Two consecutive changes end up restoring the bit, right? >=20 > Yes, and this means that if a multiple of two intermediate MR's > disappear simultaneously then leaf MR won't notice. >=20 > At the same time, the digesting method has the inconvenient that if one > intermediate MR is instantaneously replaced by another then the leaf MR > will notice a change (in fact there's no change, it's the same number of > intermediary IP hops). >=20 Sorry but this is actually the change we do want to detect. That may actually trigger a Binding Update in RO case - see for instance the RRH operation. If you just want to detect a change of depth, the depth is readily available in its own TIO field.=20 > My method can be still used if a very fine time sampling is used, such > that there can not be too actual simultaneous MR's disparritions. >=20 What do you mean simultaneous?=20 A visitor may miss an RA. Say that RA reversed the bit. And say the next one does too. Now the bit is reversed again and then the visitor sees the bit unchanged. The CRC method allows each visitor to keep and independent state for its view of the path out of the nested tree. For that purpose, the crc32c is arguably as good as the string of careofs. Since that view might be echoed in the RO states at the HA, it is important not to miss changes. > Your method can be improved if the digest is applied on something else > than the CoA, maybe on the depth level number defined somewhere in the > TD draft. >=20 > It's these kinds of things that are needed in order for a draft to > become WG item, IMHO... >=20 Actually the MR looks at both the depth and the digest. And yes we could make the digest more complex to include other fields like the depth in the string, so that any change worth looking at would cause a change in the digest that could be detected in one test. On the other hand, if we do so, we have to make sure that the action on the change does not depend on which field has actually changed... TD version 00 allows distinguishing a change in the depth vs change of tree vs change in MR path etc... Pascal From nemo-bounces@ietf.org Mon Aug 30 10:40:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28670 for ; Mon, 30 Aug 2004 10:40:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nId-0001ab-O2; Mon, 30 Aug 2004 10:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nCu-0008Kt-Lh for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28104 for ; Mon, 30 Aug 2004 10:32:26 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nEh-0005XW-40 for nemo@ietf.org; Mon, 30 Aug 2004 10:34:19 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i7UEQ594022210; Mon, 30 Aug 2004 07:26:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i7UEMQFT000364; Mon, 30 Aug 2004 09:22:27 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9B5F488043E; Mon, 30 Aug 2004 16:30:21 +0200 (CEST) Message-ID: <413339F7.3000800@motorola.com> Date: Mon, 30 Aug 2004 16:30:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB45EBC92FAD117FD98B276F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB45EBC92FAD117FD98B276F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Sorry but this is actually the change we do want to detect. That may > actually trigger a Binding Update in RO case - see for instance the > RRH operation. If you just want to detect a change of depth, the > depth is readily available in its own TIO field. Oh, now I see... So if the leaf MR just wants to detect that some intermediate router has changed then again just use a bit that is constantly 0 and propagated by MR's in RA's. Then if an MR detects that its default route points to some other MR (than the previous) set this bit to 1 in the RA it advertises on the ingress. Monitor the BU it receives from the leaf MR. If thi BU changed (the leaf MR has not missed the "change" RA then switch back that bit to 0). BTW, when you say that this change will trigger the BU in RO case, it's who who sends the BU? The MR that is near the MR that changed? Or the leaf MR that was told via propagated RA's that something has changed? Alex > > > >> My method can be still used if a very fine time sampling is used, >> such that there can not be too actual simultaneous MR's >> disparritions. >> > > What do you mean simultaneous? > > A visitor may miss an RA. Say that RA reversed the bit. And say the > next one does too. Now the bit is reversed again and then the visitor > sees the bit unchanged. > > The CRC method allows each visitor to keep and independent state for > its view of the path out of the nested tree. For that purpose, the > crc32c is arguably as good as the string of careofs. Since that view > might be echoed in the RO states at the HA, it is important not to > miss changes. > > > >> Your method can be improved if the digest is applied on something >> else than the CoA, maybe on the depth level number defined >> somewhere in the TD draft. >> >> It's these kinds of things that are needed in order for a draft to >> become WG item, IMHO... >> > > Actually the MR looks at both the depth and the digest. And yes we > could make the digest more complex to include other fields like the > depth in the string, so that any change worth looking at would cause > a change in the digest that could be detected in one test. > > On the other hand, if we do so, we have to make sure that the action > on the change does not depend on which field has actually changed... > TD version 00 allows distinguishing a change in the depth vs change > of tree vs change in MR path etc... > > > Pascal > > --------------enigAB45EBC92FAD117FD98B276F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMzn9MmC0w56zj54RAuB5AJ4stikBB1dhPTWq7UcqsDhcia6HJwCgp7E8 htm5fmt/0jwSVKor7fCTRxU= =PmW1 -----END PGP SIGNATURE----- --------------enigAB45EBC92FAD117FD98B276F-- From nemo-bounces@ietf.org Mon Aug 30 10:43:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28976 for ; Mon, 30 Aug 2004 10:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nJ9-0001t3-Do; Mon, 30 Aug 2004 10:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nHg-00011o-Ed for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:37:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28473 for ; Mon, 30 Aug 2004 10:37:22 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nJS-0005cO-07 for nemo@ietf.org; Mon, 30 Aug 2004 10:39:15 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i7UEZTVZ029750; Mon, 30 Aug 2004 07:35:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7UEZCnq022452; Mon, 30 Aug 2004 09:35:13 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E962388043E; Mon, 30 Aug 2004 16:35:26 +0200 (CEST) Message-ID: <41333B29.1060307@motorola.com> Date: Mon, 30 Aug 2004 16:35:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62949AE3696B97A82A364B93" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62949AE3696B97A82A364B93 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> My method can be still used if a very fine time sampling is used, >> such that there can not be too actual simultaneous MR's >> disparritions. >> > What do you mean simultaneous? > > A visitor may miss an RA. Say that RA reversed the bit. And say the > next one does too. Now the bit is reversed again and then the visitor > sees the bit unchanged. YEs... But still, missing messages can discomfort your own digesting method too. Missing messages will discomfort any protocol design for that matter. I may be sounding too pessimistic... > The CRC method allows each visitor to keep and independent state for > its view of the path out of the nested tree. For that purpose, the > crc32c is arguably as good as the string of careofs. Yes, and it is also as good as the rfc2460 checksum and as the simple XOR'ing of the EUID's. Why CRC32c? > Since that view might be echoed in the RO states at the HA, it is > important not to miss changes. You seem to have a relatively clear picture of a certain RO mechanism, by assumption. Is this RRH by any chance? Alex --------------enig62949AE3696B97A82A364B93 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMzsuMmC0w56zj54RAlMjAJ4h/60JmGqKXFMIskYsrPjvFFyfCACfb3Lu RfBkKTYfiyBbktJDT1vEP+E= =rlqP -----END PGP SIGNATURE----- --------------enig62949AE3696B97A82A364B93-- From nemo-bounces@ietf.org Mon Aug 30 10:50:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29419 for ; Mon, 30 Aug 2004 10:50:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nOS-0002oC-5X; Mon, 30 Aug 2004 10:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nKY-0002Bg-2b for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:40:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28715 for ; Mon, 30 Aug 2004 10:40:19 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nMJ-0005gJ-TH for nemo@ietf.org; Mon, 30 Aug 2004 10:42:13 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7UEdkGU011035; Mon, 30 Aug 2004 07:39:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i7UEbUSA025277; Mon, 30 Aug 2004 09:37:31 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C8F5488CF7E; Mon, 30 Aug 2004 16:38:40 +0200 (CEST) Message-ID: <41333BEB.6090700@motorola.com> Date: Mon, 30 Aug 2004 16:38:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104171@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7048E9B6AC655D3FACDCD192" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7048E9B6AC655D3FACDCD192 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Sorry but this is actually the change we do want to detect. That may > actually trigger a Binding Update in RO case - see for instance the > RRH operation. Please clarify... if a leaf MR receives a digest and deduces some router has changed in its upper path, it is this leaf MR that will send RO messages? Or is it the MR immediately below the MR that has changed that sends the RO messaging? Or is it the new MR that appeared that actually sends the RO messaging? I'd prefer this latter case, so no need to signal to leaf MR's that some intermediary path has changed. Alex --------------enig7048E9B6AC655D3FACDCD192 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMzvwMmC0w56zj54RAph1AKDscD/xZWRYcS4KMZDUCVN/PYcFXACgt5G8 PGrH1QJ+NyoVXre8oScgUJM= =s/+6 -----END PGP SIGNATURE----- --------------enig7048E9B6AC655D3FACDCD192-- From nemo-bounces@ietf.org Mon Aug 30 10:53:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29605 for ; Mon, 30 Aug 2004 10:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nOl-0002tB-R7; Mon, 30 Aug 2004 10:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nN5-0002Xe-2k for nemo@megatron.ietf.org; Mon, 30 Aug 2004 10:42:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28969 for ; Mon, 30 Aug 2004 10:42:56 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nOo-0005jC-Q9 for nemo@ietf.org; Mon, 30 Aug 2004 10:44:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 16:55:35 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UEg8TY015190; Mon, 30 Aug 2004 16:42:21 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 16:42:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 16:42:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104180@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOnjGoI6WCEopHSc+G6Fr0noQpywAANC4A From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 14:42:09.0585 (UTC) FILETIME=[87673A10:01C48E9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Content-Transfer-Encoding: quoted-printable =20 > BTW, when you say that this change will trigger the BU in RO case, it's > who who sends the BU? The MR that is near the MR that changed? Or the > leaf MR that was told via propagated RA's that something has changed? For a RO scheme where the HA knows about the path down the nested tree to its MR (like RRH) the MR needs to update its own HA if that path changes. So if a subtree moves, each MR down that subtree rebinds with the new path. There is an obvious value in using our DHCP PD draft so that this all happens locally... Pascal From nemo-bounces@ietf.org Mon Aug 30 11:06:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00535 for ; Mon, 30 Aug 2004 11:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nfZ-0005ex-2J; Mon, 30 Aug 2004 11:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1ndn-0005Kk-3s for nemo@megatron.ietf.org; Mon, 30 Aug 2004 11:00:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00006 for ; Mon, 30 Aug 2004 11:00:12 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nfZ-00065z-6x for nemo@ietf.org; Mon, 30 Aug 2004 11:02:06 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7UExnGU026494; Mon, 30 Aug 2004 07:59:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i7UEvTtf018536; Mon, 30 Aug 2004 09:57:30 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 649BF88CF7E; Mon, 30 Aug 2004 16:58:43 +0200 (CEST) Message-ID: <4133409B.1080607@motorola.com> Date: Mon, 30 Aug 2004 16:58:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104180@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104180@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2887FB1AB89AAE777FF2E557" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2887FB1AB89AAE777FF2E557 Pascal Thubert (pthubert) wrote: > For a RO scheme where the HA knows about the path down the nested > tree to its MR (like RRH) the MR needs to update its own HA if that > path changes. So, in the beginning there were bindings HoA-CoA, then there were bindings HoA-MNP and now there are bindings HoA-Ad1-Ad2...Adn? Do you know which current RO proposals assume that HA uses such "path" bindings? Such bindings sound like DSR... > So if a subtree moves, each MR down that subtree rebinds with the new > path. There is an obvious value in using our DHCP PD draft so that > this all happens locally... PD together with RRH and TD would actually constitute an entire and complete solution for the whole RO space? We don't even have a problem description for the RO space (while Chartered to do so) but the solution is there :-( We do have, however, personal drafts gen-ro-model and nemo-ro-taxonomy. Would RRH+TD+PD fit both models? Alex --------------enig2887FB1AB89AAE777FF2E557 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBM0CjMmC0w56zj54RArFeAJ4rUDTg3Lwyn2V28sIoodR9TB+nIACcC/iq WRixtrcWQSpVPNbWQx0Roh0= =Dl3Y -----END PGP SIGNATURE----- --------------enig2887FB1AB89AAE777FF2E557-- From nemo-bounces@ietf.org Mon Aug 30 11:11:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00799 for ; Mon, 30 Aug 2004 11:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nmJ-0000lN-RK; Mon, 30 Aug 2004 11:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nk1-0000MA-Kq for nemo@megatron.ietf.org; Mon, 30 Aug 2004 11:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00533 for ; Mon, 30 Aug 2004 11:06:38 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nln-0006E6-8m for nemo@ietf.org; Mon, 30 Aug 2004 11:08:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 17:19:18 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UF5vTW018021; Mon, 30 Aug 2004 17:06:06 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:05:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 17:05:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC10418D@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOnx/moY3uHmZiTcyRfq2g8L52QQAAIhbg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 15:05:56.0798 (UTC) FILETIME=[DA16A5E0:01C48EA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Content-Transfer-Encoding: quoted-printable > > The CRC method allows each visitor to keep and independent state for > > its view of the path out of the nested tree. For that purpose, the > > crc32c is arguably as good as the string of careofs. >=20 > Yes, and it is also as good as the rfc2460 checksum and as the simple > XOR'ing of the EUID's. Why CRC32c? RFC 2460 does not define the checksum, but the pseudo header. If there's still legacy ICMP, TCP and UDP above, then it will be a 16bit checksum, which is not exactly 'as good' as 32 bits CRC. We now have a standard, readily available, for a robust 32 bits function. For our purpose, it is needed only on RA-TIO which is not like on every packet. And we can afford the 32bits in the TIO. So, why not CRC32C?=20 >=20 > > Since that view might be echoed in the RO states at the HA, it is > > important not to miss changes. >=20 > You seem to have a relatively clear picture of a certain RO mechanism, > by assumption. Is this RRH by any chance? >=20 RRH was there before NEMO was a working group. Since then, RRH has given us some good practise of Route Optimization. And yes, we found that this was a very relevant information. Other drafts were published for which the path was known by the HA, like draft-na-nemo-nested-path-info-00. TD does not imply RRH. TD provides a set of valuable information that RO can build on. The TD draft is still 00. We can discuss about adding new fields, for instance as optional suboptions - I hope we do it, actually. Pascal From nemo-bounces@ietf.org Mon Aug 30 11:26:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01807 for ; Mon, 30 Aug 2004 11:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1o0A-0002Z1-V8; Mon, 30 Aug 2004 11:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nvT-0001xC-HM for nemo@megatron.ietf.org; Mon, 30 Aug 2004 11:18:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01210 for ; Mon, 30 Aug 2004 11:18:29 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nxF-0006R4-Ml for nemo@ietf.org; Mon, 30 Aug 2004 11:20:23 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 17:31:09 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UFHRTm020524; Mon, 30 Aug 2004 17:17:55 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:17:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 17:17:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104192@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOohLreNKoxGcOSaiSu6k99h5CYQAAP4vA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 15:17:54.0623 (UTC) FILETIME=[85F20CF0:01C48EA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Content-Transfer-Encoding: quoted-printable > > For a RO scheme where the HA knows about the path down the nested > > tree to its MR (like RRH) the MR needs to update its own HA if that > > path changes. >=20 > So, in the beginning there were bindings HoA-CoA, then there were > bindings HoA-MNP and now there are bindings HoA-Ad1-Ad2...Adn? >=20 > Do you know which current RO proposals assume that HA uses such "path" > bindings? >=20 > Such bindings sound like DSR... Does :) RRH is source routing. This accommodates with quick movements within the nested tree; it is optimized for maintaining the path to the outside, as opposed to providing any-to-any; if things stabilize, RRH can be 'compressed' using local states, allowing to navigate dynamically between a source route and a transparent (stateful) model, on a per hop basis. >=20 > > So if a subtree moves, each MR down that subtree rebinds with the new > > path. There is an obvious value in using our DHCP PD draft so that > > this all happens locally... >=20 > PD together with RRH and TD would actually constitute an entire and > complete solution for the whole RO space? >=20 > We don't even have a problem description for the RO space (while > Chartered to do so) but the solution is there :-( Yes... > We do have, however, personal drafts gen-ro-model and nemo-ro-taxonomy. > Would RRH+TD+PD fit both models? >=20 Taxonomy does not provide a model but attempts to list what was (or could be?) proposed around, grouped into families. We need to update the draft but yes, it's all in there. Gen-ro-model abstracts the solutions to enable a discussion at a higher level, between those families. It looked good when I read it, but then I did not make the exercise to map everything in there. I'd need to do the exercise to be able to give my answer. Pascal From nemo-bounces@ietf.org Mon Aug 30 11:36:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02380 for ; Mon, 30 Aug 2004 11:36:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1o77-0003qv-Mx; Mon, 30 Aug 2004 11:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1o5x-0003fd-8M for nemo@megatron.ietf.org; Mon, 30 Aug 2004 11:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01983 for ; Mon, 30 Aug 2004 11:29:18 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1o7k-0006ge-Kk for nemo@ietf.org; Mon, 30 Aug 2004 11:31:13 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 17:42:00 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7UFSLTm022232; Mon, 30 Aug 2004 17:28:46 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:28:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Mon, 30 Aug 2004 17:28:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104194@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOn58gNzR9n/H7TtuaHTPICuFinAABSW/w From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Aug 2004 15:28:19.0029 (UTC) FILETIME=[FA1ED850:01C48EA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Content-Transfer-Encoding: quoted-printable > Please clarify... if a leaf MR receives a digest and deduces some router > has changed in its upper path, it is this leaf MR that will send RO > messages? >=20 > Or is it the MR immediately below the MR that has changed that sends the > RO messaging? >=20 > Or is it the new MR that appeared that actually sends the RO messaging? >=20 Sorry Alex, it will depend on the RO solution, and by now we have seen it all. In the case of RRH, each MR updates its own HA about the changes on its egress path.=20 There have been proposals where the parent MRs above would all bind to the HA of the MR below. The associated complexity is detailed in the taxonomy draft. =20 Pascal From nemo-bounces@ietf.org Mon Aug 30 12:44:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07450 for ; Mon, 30 Aug 2004 12:44:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p7e-0003fd-5E; Mon, 30 Aug 2004 12:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p3a-0002iz-5K for nemo@megatron.ietf.org; Mon, 30 Aug 2004 12:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06122 for ; Mon, 30 Aug 2004 12:30:54 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1p5N-0007yI-Jw for nemo@ietf.org; Mon, 30 Aug 2004 12:32:49 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7UGPnOS028311; Mon, 30 Aug 2004 09:25:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7UGPW53023002; Mon, 30 Aug 2004 11:25:32 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8A38088043E; Mon, 30 Aug 2004 18:25:46 +0200 (CEST) Message-ID: <41335505.6080309@motorola.com> Date: Mon, 30 Aug 2004 18:25:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC10418D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC10418D@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02AF5F56CD066B3E34B010A6" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02AF5F56CD066B3E34B010A6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> The CRC method allows each visitor to keep and independent state >>> for its view of the path out of the nested tree. For that >>> purpose, the crc32c is arguably as good as the string of careofs. >>> >>> >>> >> Yes, and it is also as good as the rfc2460 checksum and as the >> simple XOR'ing of the EUID's. Why CRC32c? > > RFC 2460 does not define the checksum, but the pseudo header. If > there's still legacy ICMP, TCP and UDP above, then it will be a 16bit > checksum, which is not exactly 'as good' as 32 bits CRC. Yes, it's the ICMPv6 checksum rfc2463, four lines of text, sufficient to implement. When was the last time you saw a packet dropped because of wrong checksum; when was the last time you thought to yourself "hmmm, maybe a better checksum is needed". In what is CRC better than the ICMPv6 checksum, other than just saying that one is 32 bit and the other 16. How many messages have you seen that were corrupted and not recognized as such by the ICMPv6 checksum but were recognized as corrupted by CRC32c. How many messages have you seen that were correct and identified as corrupted by ICMPv6 checksum but identified as correct by CRC32c? > We now have a standard, readily available, for a robust 32 bits > function. Why using an IEEE-802 CRC when an IETF Checksum is available? > For our purpose, it is needed only on RA-TIO which is not like on > every packet. And we can afford the 32bits in the TIO. So, why not > CRC32C? Because cheaper and easier to implement and execute functions are available. >>> Since that view might be echoed in the RO states at the HA, it is >>> important not to miss changes. >> >> You seem to have a relatively clear picture of a certain RO >> mechanism, by assumption. Is this RRH by any chance? >> > > RRH was there before NEMO was a working group. Since then, RRH has > given us some good practise of Route Optimization. And yes, we found > that this was a very relevant information. Other drafts were > published for which the path was known by the HA, like > draft-na-nemo-nested-path-info-00. TD does not imply RRH. TD provides > a set of valuable information that RO can build on. The TD draft is > still 00. We can discuss about adding new fields, for instance as > optional suboptions - I hope we do it, actually. What I'd like to discuss is about the problems that TD solves. Are you reluctant about discussing the actual problem? Do you acknowledge that the "looping problem" as raised in Issue 24 is not in fact a problem that needs solution? Alex --------------enig02AF5F56CD066B3E34B010A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBM1UKMmC0w56zj54RAj4bAKC1kVgHHXHP4sZjFWcCn0LxCrKM5wCg3pNa uZj03Z6BMqlg17IRlPPdupE= =FKa5 -----END PGP SIGNATURE----- --------------enig02AF5F56CD066B3E34B010A6-- From nemo-bounces@ietf.org Mon Aug 30 23:59:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29234 for ; Mon, 30 Aug 2004 23:59:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1ziT-0006rI-6n; Mon, 30 Aug 2004 23:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1zeN-000686-0w for nemo@megatron.ietf.org; Mon, 30 Aug 2004 23:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28658 for ; Mon, 30 Aug 2004 23:49:35 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1zgF-0008RU-8q for nemo@ietf.org; Mon, 30 Aug 2004 23:51:37 -0400 Received: from galibier.nautilus6.org (unknown [2001:200:0:8400:206:5bff:fe73:439f]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 66F9F5D0BB; Tue, 31 Aug 2004 12:49:04 +0900 (JST) Date: Tue, 31 Aug 2004 12:48:48 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] mor comments on TD Message-Id: <20040831124848.76077e33.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mattias.l.pettersson@ericsson.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 Content-Transfer-Encoding: 7bit Dear all, Since I've been asked by Pascal to give my point of view .... > > > We have scenarios with 3 or more level of nesting. But nothing says > how > > > we get there. One such example is: > > > ferry boat <- car <- pan. This one is a valid scenario. > > > NEMO does not provide for the PAN to attach to a car (mine in > > > particular), for the car to attach to a ferry etc... We could end up > > > having a car joining the ferry and then the hundred other in a daisy > > > chain till the overhead of tunnels is so huge that it does not work Would you explain what you mean by "NEMO does not provide for the PAN to attach to a car" ? I'm not sure I get it. From my first understanding, I would disagree. > > Now I think you are making a dangerous assumption here. You seem to > say > > that an MR can hear any number of access points (ARs, other MRs' > ingress > > interfaces etc.) _and that it connects to them all on the IP layer_, > so > > that it can hear each and everybody's RA. > > All of them is a big word. A number of them is closer to the truth. > > The radio world is far from limited to 802.11, and there are radios > around that allow you to get signals from more then one neighbour. Quite > a good thing in my view, if we want all this MANET thing to work at all. > > > > > This seem to indicate that there are no distinct logical links on top > of > > 802.11 or whatever we run, but rather that there is basically only one > > single logical link where everybody can hear everybody else. This is > > really bad. This is what ad hoc assumes, but I would like to see NEMO > > assuming a bit more _structured_ and _managed_ networks. > > > > Use cases... There's no such a restriction that I know of for NEMO > applicability. I copy Thierry, in case he wishes to provide his view on > this debate. 1st, while setting up this WG, we have said that we would assumed that MNNs within the NEMO are relatively fixed compared to the MR. In addition to that, a NEMO could be offering access to sub-NEMOs, therefore forming nested NEMO. There is no limitations in the number of levels in the nested NEMO, but we have written in the requirement documents that the solution should accommodate at least 2-3 levels. Having more would clearly not be efficient, but in such case, I would assume that people would not form too many levels of nested NEMO only because it's not efficient (the proportion of payload would be low compared to the tunnelled headers, and packets could be lost because of the PMTU limit). 2nd, speaking about RO, according to me, it means all kind of ROs, including ROs within the mobile network (how to allow to MNNs in the same nested mobile networks to communicate directly, how to minimize the overhead of tunneling within the nest). However, the charter says the following: The WG will not: - consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. So, we need stay on the right side of the boundary, but RO within the nested NEMO still need to be studied in the analysis. > > If an MR can hear all APs, I guess all MNNs can do the same. They all > > listen to the same channel. An MNN would find itself hearing 2000 > > prefixes then and maybe configure addresses from of them all, as long > > as is it within range. > Now I think you are making a dangerous assumption here :) LFNs could be > wired or connected to the MR using short range techno such as Bluetooth. > Allowing LFNs to listen to other MRs simply kills the whole thing. Agree here. I don't see how Matias had assumed the MNNs would hear APs. Well, wireless VMNs might, but in such case they would have to decide if they prefer to join the APs directly, or through the MR. But, taking the example of a bus, connected to the Internet via 802.11 APs deployed in the street, and also offering a 802.11 access to its customers within the bus, I would guess that only MR would have the credentials to join the street-AP (key, etc), while the bus-AP icould only be accessed to the passengers who have the credentials for the bus-AP. From nemo-bounces@ietf.org Tue Aug 31 00:07:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29771 for ; Tue, 31 Aug 2004 00:07:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1zsA-0000mj-Bh; Tue, 31 Aug 2004 00:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1zmP-00082a-5V for nemo@megatron.ietf.org; Mon, 30 Aug 2004 23:57:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29051 for ; Mon, 30 Aug 2004 23:57:54 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1zoI-00008x-0s for nemo@ietf.org; Mon, 30 Aug 2004 23:59:55 -0400 Received: from galibier.nautilus6.org (unknown [2001:200:0:8400:206:5bff:fe73:439f]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 603555D0BB for ; Tue, 31 Aug 2004 12:57:24 +0900 (JST) Date: Tue, 31 Aug 2004 12:57:08 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Question on TD Message-Id: <20040831125708.6a92c1ce.ernst@sfc.wide.ad.jp> In-Reply-To: <412F2F03.4040508@motorola.com> References: <412F2F03.4040508@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Content-Transfer-Encoding: 7bit Hi, > "When the NEMO where the MN is connected to is multihomed, the MN may > have the choice between several AR to be its default router" > > What does this mean? I concur, 'what does it mean' ? If a MN attaches to the NEMO (and thus becomes a VMN from our terminology), its default router is the MR (or one of the MR if the NEMO is multihomed (cases [n,*,1] from http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt). The AR is the default router of the MR. > If MNis connected to a NEMO then it is connected, so it has no choice > between several AR's. MN has a default router already. It's that > NEMO's TLMR that has choice, no? > > Or maybe it is meant that MN may use one of the two MR's (TLMR's) as its > default route? in which case the default router of the VMN would still be one of the root-MRs (what some people call TLMR - note that the decision at IETF60 is to remove this term and solely use root-MR). Thierry From nemo-bounces@ietf.org Tue Aug 31 05:22:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01126 for ; Tue, 31 Aug 2004 05:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C24oo-0000DI-2p; Tue, 31 Aug 2004 05:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C24iW-00089J-Fm for nemo@megatron.ietf.org; Tue, 31 Aug 2004 05:14:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00760 for ; Tue, 31 Aug 2004 05:14:14 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C24kT-0006Na-9D for nemo@ietf.org; Tue, 31 Aug 2004 05:16:17 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 11:27:06 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7V9D7Ti025587; Tue, 31 Aug 2004 11:13:39 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:13:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2004 11:11:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> Thread-Topic: Tree Discovery Thread-Index: AcSPDY/TmvC7zaJPQAyKefzPuDzifAAHhpkQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "Greg Daley" X-OriginalArrivalTime: 31 Aug 2004 09:13:10.0945 (UTC) FILETIME=[BCAB8910:01C48F3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, dna@eng.monash.edu.au, mattias.l.pettersson@ericsson.com Subject: [nemo] Tree Discovery X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: This thread is about=20 http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt . > > > > ferry boat <- car <- pan. >=20 > This one is a valid scenario. >=20 > > > > NEMO does not provide for the PAN to attach to a car (mine in > > > > particular), for the car to attach to a ferry etc... We could end up > > > > having a car joining the ferry and then the hundred other in a daisy > > > > chain till the overhead of tunnels is so huge that it does not work >=20 > Would you explain what you mean by "NEMO does not provide for the PAN to > attach to a car" ? I'm not sure I get it. From my first understanding, > I would disagree. NEMO basic support does not provide tooling for default router selection. I may be wrong, but I'm afraid that a detecting/building a multi-hop network attachment is out of scope for DNA as well - copying Greg and DNA here. As far as NEMO basic support is concerned, the MR serving my PAN could attach to my wife's PAN which could attach to the neighbour's car which could attach to my car, maybe all cars forming a daisy chain... and maybe a loop, for quite a long time. This is issue 24. You need additional control to establish/maintain the ferry boat <- car <- pan chain quickly and efficiently. I think it was Steve Deering at IETF 54, who asked how we (NEMMO WG) make sure that we do not get the whole ferry boat going out via my PAN... The preference in TD provides for that case. That same result can be achieved by manual config (e.g. SSID for 802.11) and AAA, as I understand Mattias is proposing. I do not see firemen playing with SSIDs in front of a fire, though. Nor me changing my SSID when I hop in a bus for a few minutes, just to maintain my VOIP call. TD is an extension of ND that improves the default router selection. It is pretty generic and can be adapted for the use cases we want to support. But first, we need to reckon that there is a problem and make sure somebody is looking at it. > But, taking the example of a bus, connected to the Internet via 802.11 > APs deployed in the street, and also offering a 802.11 access to its > customers within the bus, I would guess that only MR would have the > credentials to join the street-AP (key, etc), while the bus-AP icould > only be accessed to the passengers who have the credentials for the > bus-AP. I wish to discuss that case further. Same question as above. Is this all AAA based, or do we need to enhance the default Router selection? I understand there's a need for AAA anyway, but I'm not sure that we can leave it at that: Say I'm a pedestrian in the street. My PAN MR attaches to an AR along the curb. I'm not nested. Now I hop into the bus. Should I keep roaming using curb MRs or should I attach to the bus MR and let the bus do the roaming in a nested fashion? Do I need to change my MR config to do one or the other?=20 One good thing could be to do AAA with the ARs regardless on whether I hop via the bus or not (PANA?) One other good thing would be to get a CareOf from the bus while I'm in the bus and only while I'm in the bus (not if buses pass by me). One other good thing would be that buses do not use my PAN to get to the curb AR. One other good thing would be that another PAN might relay my own if I do not have direct visibility to the AR (anonymous relaying). ... Pascal From nemo-bounces@ietf.org Tue Aug 31 05:40:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01781 for ; Tue, 31 Aug 2004 05:40:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C253R-0002lT-BP; Tue, 31 Aug 2004 05:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C251C-0002FV-PH for nemo@megatron.ietf.org; Tue, 31 Aug 2004 05:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01523 for ; Tue, 31 Aug 2004 05:33:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2539-0006gW-P4 for nemo@ietf.org; Tue, 31 Aug 2004 05:35:36 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 11:46:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7V9WdTi000383; Tue, 31 Aug 2004 11:33:00 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:32:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft Date: Tue, 31 Aug 2004 11:32:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104255@xmb-ams-337.emea.cisco.com> Thread-Topic: Summary Re: [nemo] comments on "Tree Discovery" draft Thread-Index: AcSOrr2yuWwy2ZBDTbqeqoZpd5DToAAjXi1g From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 31 Aug 2004 09:32:59.0289 (UTC) FILETIME=[80FA7090:01C48F3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Content-Transfer-Encoding: quoted-printable >=20 > Pascal Thubert (pthubert) wrote: > >>> The CRC method allows each visitor to keep and independent state > >>> for its view of the path out of the nested tree. For that > >>> purpose, the crc32c is arguably as good as the string of careofs. > >>> > >>> > >>> > >> Yes, and it is also as good as the rfc2460 checksum and as the > >> simple XOR'ing of the EUID's. Why CRC32c? > > > > RFC 2460 does not define the checksum, but the pseudo header. If > > there's still legacy ICMP, TCP and UDP above, then it will be a 16bit > > checksum, which is not exactly 'as good' as 32 bits CRC. >=20 > Yes, it's the ICMPv6 checksum rfc2463, four lines of text, sufficient to > implement. >=20 > When was the last time you saw a packet dropped because of wrong > checksum; when was the last time you thought to yourself "hmmm, > maybe a better checksum is needed". >=20 > In what is CRC better than the ICMPv6 checksum, other than just saying > that one is 32 bit and the other 16. How many messages have you seen > that were corrupted and not recognized as such by the ICMPv6 checksum > but were recognized as corrupted by CRC32c. How many messages have you > seen that were correct and identified as corrupted by ICMPv6 checksum > but identified as correct by CRC32c? We are in a loop. I already passed you the RFC that details all this. But yes, roughly specking, 32 bits is better than 16. > > We now have a standard, readily available, for a robust 32 bits > > function. >=20 > Why using an IEEE-802 CRC when an IETF Checksum is available? >=20 > > For our purpose, it is needed only on RA-TIO which is not like on > > every packet. And we can afford the 32bits in the TIO. So, why not > > CRC32C? >=20 > Because cheaper and easier to implement and execute functions are available. Functions are available for both, as I already pointed out, even in open source environment. This is a minor issue and I'll take the vote from the WG when we make one. Please come up with the question. >=20 > >>> Since that view might be echoed in the RO states at the HA, it is > >>> important not to miss changes. > >> > >> You seem to have a relatively clear picture of a certain RO > >> mechanism, by assumption. Is this RRH by any chance? > >> > > > > RRH was there before NEMO was a working group. Since then, RRH has > > given us some good practise of Route Optimization. And yes, we found > > that this was a very relevant information. Other drafts were > > published for which the path was known by the HA, like > > draft-na-nemo-nested-path-info-00. TD does not imply RRH. TD provides > > a set of valuable information that RO can build on. The TD draft is > > still 00. We can discuss about adding new fields, for instance as > > optional suboptions - I hope we do it, actually. >=20 > What I'd like to discuss is about the problems that TD solves. Are you > reluctant about discussing the actual problem? Do you acknowledge that > the "looping problem" as raised in Issue 24 is not in fact a problem > that needs solution? >=20 I started a thread for that. The current one has done its job, we started looping and I'll not sure anyone is reading it anymore. Like NEMO with issue 24 :) I do believe we need to do something for that issue, while I also agree that the answer in the issue is valid and sufficient for some configurations - thus moving forward with the draft as is. Pascal From nemo-bounces@ietf.org Tue Aug 31 06:04:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02839 for ; Tue, 31 Aug 2004 06:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25PZ-0006Dl-4c; Tue, 31 Aug 2004 05:58:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25P8-00065J-25 for nemo@megatron.ietf.org; Tue, 31 Aug 2004 05:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02600 for ; Tue, 31 Aug 2004 05:58:16 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C25R5-00078n-32 for nemo@ietf.org; Tue, 31 Aug 2004 06:00:19 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i7V9vSmk028872; Tue, 31 Aug 2004 02:57:28 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7V7vBaT028836; Tue, 31 Aug 2004 02:57:12 -0500 Message-ID: <41344B7C.902@motorola.com> Date: Tue, 31 Aug 2004 11:57:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Tree Discovery References: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E3BF25393DC51B43CC051F3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: nemo@ietf.org, dna@eng.monash.edu.au, Thierry Ernst , mattias.l.pettersson@ericsson.com, Greg Daley X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E3BF25393DC51B43CC051F3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > As far as NEMO basic support is concerned, the MR serving my PAN > could attach to my wife's PAN which could attach to the neighbour's > car which could attach to my car, maybe all cars forming a daisy > chain... and maybe a loop, for quite a long time. This is issue 24. Tell your wife your neighbour's car is not adequate for attaching, or get control of her laptop. The apparent ubiquity of wifi cafes and browsing yahoo for everbody does not mean that _setting up_ networks is a mundane task that mere mortals could get trapped into. > You need additional control to establish/maintain the ferry boat <- > car <- pan chain quickly and efficiently. I think it was Steve > Deering at IETF 54, who asked how we (NEMMO WG) make sure that we do > not get the whole ferry boat going out via my PAN... The preference > in TD provides for that case. Make sure that the admin who sets up the TD preferences does it right. Make sure that the TD preferences do not lead to TD loops. > That same result can be achieved by manual config (e.g. SSID for > 802.11) and AAA, as I understand Mattias is proposing. I do not see > firemen playing with SSIDs in front of a fire, though. I do not see firemen playing with TD preferences in front of a fire. > Nor me changing my SSID when I hop in a bus for a few minutes, just > to maintain my VOIP call. Well, you don't have to. If you use the same bus company every day, just make sure you add it to your Windows preferences and then order those preferences with the street AP's, and you're all set. If you take similar trajectories daily, you won't have to manually change the ESSID, Windows (and associated driver) will do it by your preferences. > TD is an extension of ND that improves the default router selection. > It is pretty generic and can be adapted for the use cases we want to > support. But first, we need to reckon that there is a problem and > make sure somebody is looking at it. I think a better default router selection can be used when several AR-AP pairs are outgoing routers for the same unique IP link. Let's first identify where such cases occur in wireless? A hotspot deployment in Paris/France (where Cisco is a partner) has fixed hotspot areas that may overlap each other. Both AP's have the same ESSID. In the small overlapping area a Client may see two AP's, same ESSID. However, it can not communicate with both at the same time, the Client "flips" between the two AP's; in this particular case, the IP stack can not choose between two default routes, it is only one AP accessible at a time. In the same area, the overlapping common physical area, although covered by two AP's with same ESSID and key, are not actually the same unique IP subnet. The IP(v4!) address obtained from one AP/AR and the associated masks are different than the ones obtained from the other AP/AR. So this particular deployment does not qualify for an intelligent default router selection, IMHO. In order to have a need for a better default router selection, we need to have a wireless deployment with two AP-AR pairs, same ESSID and same subnet mask (or IPv6 prefix). That can be 802.11b or another wireless with a MAC layer. Cellular GPRS and UMTS do not apply because GPRS/UMTS use ppp and the default route is practically tied to an innterface. >> But, taking the example of a bus, connected to the Internet via >> 802.11 APs deployed in the street, and also offering a 802.11 >> access to its customers within the bus, I would guess that only MR >> would have the credentials to join the street-AP (key, etc), while >> the bus-AP icould only be accessed to the passengers who have the >> credentials for the bus-AP. Passengers may have both credentials (for bus and for street). An existing train deployment, passenger buys credentials for both the train and the station. The train is not connected to the station AP's but to GPRS (and I doubt any bus will roam between hotspot areas, it's just too fast). When the passenger is in the train inside the station, passenger has the choice of AP of this train, or neighbour trains, or the station's AP. Passenger has all these choices, but I don't think the IP stack has any choice once the passengers has chosen one. > Say I'm a pedestrian in the street. My PAN MR attaches to an AR along > the curb. I'm not nested. Now I hop into the bus. Should I keep > roaming using curb MRs or should I attach to the bus MR and let the > bus do the roaming in a nested fashion? Do I need to change my MR > config to do one or the other? > > One good thing could be to do AAA with the ARs regardless on whether > I hop via the bus or not (PANA?) > > One other good thing would be to get a CareOf from the bus while I'm > in the bus and only while I'm in the bus (not if buses pass by me). > > One other good thing would be that buses do not use my PAN to get to > the curb AR. > > One other good thing would be that another PAN might relay my own if > I do not have direct visibility to the AR (anonymous relaying). I think there are many ways in which one would design a wireless hotspot deployment. The best way to do better is to pick an existing hostpot deployment and see where are the problems. The 2-3 hotspot deployments I've seen, my favourite problems are the following: -none uses IPv6. -none uses Mobile IPv4. -IPv4 address is changed from hotspot area to the next. -all are behind NAT. -none offers continuous applications when changing AP, thus not allowing for any physical movement (don't even dream of "fast" movements). Alex --------------enig1E3BF25393DC51B43CC051F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNEuCMmC0w56zj54RAoKrAKCVh1TRAKHikIRIf8hb/XNy18QUVwCgqQMq 9YCOnC2beTtSi/ug+iCQ0rU= =Ndx9 -----END PGP SIGNATURE----- --------------enig1E3BF25393DC51B43CC051F3-- From nemo-bounces@ietf.org Tue Aug 31 06:18:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03548 for ; Tue, 31 Aug 2004 06:18:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25gG-0001U8-8i; Tue, 31 Aug 2004 06:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25dq-0000cX-3t for nemo@megatron.ietf.org; Tue, 31 Aug 2004 06:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03383 for ; Tue, 31 Aug 2004 06:13:27 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C25fm-0007Po-G9 for nemo@ietf.org; Tue, 31 Aug 2004 06:15:31 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i7VACHoe015763; Tue, 31 Aug 2004 03:12:17 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i7VAALM0031549; Tue, 31 Aug 2004 05:10:22 -0500 Message-ID: <41344EF9.7000300@motorola.com> Date: Tue, 31 Aug 2004 12:12:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: Summary Re: [nemo] comments on "Tree Discovery" draft References: <7892795E1A87F04CADFCCF41FADD00FC104255@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104255@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig90516CB309BCF11454CA3440" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig90516CB309BCF11454CA3440 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> What I'd like to discuss is about the problems that TD solves. Are >> you reluctant about discussing the actual problem? Do you >> acknowledge that the "looping problem" as raised in Issue 24 is not >> in fact a problem that needs solution? >> > I started a thread for that. The current one has done its job, we > started looping and I'll not sure anyone is reading it anymore. Like > NEMO with issue 24 :) I do believe we need to do something for that > issue, while I also agree that the answer in the issue is valid and > sufficient for some configurations I partially agree with you; yes we were a bit verbose, sorry to audience :-) I agree TD is a protocol. I don't agree to send CRC's without the associated data. I agree the answer in issue 24 "looping" is valid and sufficient for some if not all configurations. I don't believe currently TD solves any stated problem, has no associated NEMO Charter item. > - thus moving forward with the draft as is. You mean the NEMO basic support draft, right? Alex --------------enig90516CB309BCF11454CA3440 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNE7/MmC0w56zj54RAjsvAKD3JSx6AkyDfKLQPcl/6RlFD0OfVACguVJb IIziKn1k5MV6sSG6MO9OHIc= =ABp8 -----END PGP SIGNATURE----- --------------enig90516CB309BCF11454CA3440-- From nemo-bounces@ietf.org Tue Aug 31 07:45:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09502 for ; Tue, 31 Aug 2004 07:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C270E-0006HY-E7; Tue, 31 Aug 2004 07:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26yO-00063X-Ky for nemo@megatron.ietf.org; Tue, 31 Aug 2004 07:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09179 for ; Tue, 31 Aug 2004 07:38:48 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C270L-0000nT-St for nemo@ietf.org; Tue, 31 Aug 2004 07:40:51 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 13:51:43 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7VBbjTo021389; Tue, 31 Aug 2004 13:38:12 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 13:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Tree Discovery Date: Tue, 31 Aug 2004 13:37:38 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC1042EF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Tree Discovery Thread-Index: AcSPQQpK3EGdX25AT7GLPfQpDnme/QADafLg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 31 Aug 2004 11:37:44.0738 (UTC) FILETIME=[EEA75020:01C48F4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, dna@eng.monash.edu.au, Thierry Ernst , mattias.l.pettersson@ericsson.com, Greg Daley X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > The 2-3 hotspot deployments I've seen, my favourite problems are the > following: > -none uses IPv6. > -none uses Mobile IPv4. > -IPv4 address is changed from hotspot area to the next. > -all are behind NAT. > -none offers continuous applications when changing AP, thus not allowing > for any physical movement (don't even dream of "fast" movements). >=20 Try Doors :) http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver sal-01.txt Pascal From nemo-bounces@ietf.org Tue Aug 31 08:31:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12563 for ; Tue, 31 Aug 2004 08:31:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27ju-000504-KW; Tue, 31 Aug 2004 08:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27hd-0004QD-0g for nemo@megatron.ietf.org; Tue, 31 Aug 2004 08:25:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12199 for ; Tue, 31 Aug 2004 08:25:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27jb-0001uo-JC for nemo@ietf.org; Tue, 31 Aug 2004 08:27:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 14:38:28 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7VCOaTg000792; Tue, 31 Aug 2004 14:24:58 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 14:24:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Question on TD Date: Tue, 31 Aug 2004 14:24:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Question on TD Thread-Index: AcSPEEQ6JKPJr2I4TtWFBxXvjRp5sQALzrow From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 31 Aug 2004 12:24:53.0682 (UTC) FILETIME=[84D5E920:01C48F55] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: Nicolas Montavont X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I agree that the multihoming case in the draft may not be the most = appropriate and we might remove it for simplicity (Nicolas, what do you = think?). There's still something that surprises me. In the discussions, it seems = that the nested tree is taken for granted and then NEMO can start. Here, = the MN is connected to the MR, etc... Well actually that's not granted at all. This tree has to be established = and maintained. A VMR permanently does its 'DNA' and might change its AR = at any time...and that AR can be a MR as well -> a MAR. The question at = DNA level might be 'am I connected to the same link'. But for nested = NEMO, you want to know what's behind a MAR before you even try it. For = instance the level of nesting, or whether you can get to the = infrastructure, etc... Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Thierry Ernst > Sent: mardi 31 ao=FBt 2004 05:57 > To: nemo@ietf.org > Subject: Re: [nemo] Question on TD >=20 >=20 > Hi, >=20 > > "When the NEMO where the MN is connected to is multihomed, the MN = may > > have the choice between several AR to be its default router" > > > > What does this mean? >=20 > I concur, 'what does it mean' ? If a MN attaches to the NEMO (and thus > becomes a VMN from our terminology), its default router is the MR (or > one of the MR if the NEMO is multihomed (cases [n,*,1] from > = http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00= .txt). > The AR is the default router of the MR. >=20 > > If MNis connected to a NEMO then it is connected, so it has no = choice > > between several AR's. MN has a default router already. It's that > > NEMO's TLMR that has choice, no? > > > > Or maybe it is meant that MN may use one of the two MR's (TLMR's) as = its > > default route? >=20 > in which case the default router of the VMN would still be one of the > root-MRs (what some people call TLMR - note that the decision at = IETF60 > is to remove this term and solely use root-MR). >=20 > Thierry From nemo-bounces@ietf.org Tue Aug 31 11:49:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26633 for ; Tue, 31 Aug 2004 11:49:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AjY-0005ai-Fu; Tue, 31 Aug 2004 11:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AiJ-0005Pn-G3 for nemo@megatron.ietf.org; Tue, 31 Aug 2004 11:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25951 for ; Tue, 31 Aug 2004 11:38:24 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AkJ-00065V-54 for nemo@ietf.org; Tue, 31 Aug 2004 11:40:31 -0400 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F3EFB5D1B9; Wed, 1 Sep 2004 00:37:53 +0900 (JST) Date: Wed, 01 Sep 2004 00:37:35 +0900 (JST) Message-Id: <20040901.003735.74751084.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Subject: Re: [nemo] Question on TD From: Masafumi Watari In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Mew version 4.0.68 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, ernst@sfc.wide.ad.jp, montavont@clarinet.u-strasbg.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi all, On Tue, 31 Aug 2004 14:24:20 +0200, "Pascal Thubert (pthubert)" wrote: > I agree that the multihoming case in the draft may not be the most ap= propriate and we might remove it for simplicity (Nicolas, what do you t= hink?). > = > There's still something that surprises me. In the discussions, it see= ms that the nested tree is taken for granted and then NEMO can start. H= ere, the MN is connected to the MR, etc... > = > Well actually that's not granted at all. This tree has to be establis= hed and maintained. A VMR permanently does its 'DNA' and might change i= ts AR at any time...and that AR can be a MR as well -> a MAR. The quest= ion at DNA level might be 'am I connected to the same link'. But for ne= sted NEMO, you want to know what's behind a MAR before you even try it.= For instance the level of nesting, or whether you can get to the infra= structure, etc... You mean, a MR would want to know where the MAR is connected behind, and not what's behind a MAR, correct? I don't know how to assure that AR or MAR actually provides a path to the infrastructure, but knowing the level of nesting before trying to connect to is important to avoid forming the nest itself. We all know that the more deeper the nest gets, the more delay it causes to packets and the less MTU we have. If there is more MRs than the MTU allows in a tree without any loops, thats what I think is the real problem of nested NEMO. In that sense, TD is one of the solution to solve the forming of such state. BTW, if we allow a fixed router to be attached behind a MR, those routers must also provide the TIO with TD. Masafumi Watari > Pascal > = > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behal= f Of Thierry Ernst > > Sent: mardi 31 ao=FBt 2004 05:57 > > To: nemo@ietf.org > > Subject: Re: [nemo] Question on TD > > = > > = > > Hi, > > = > > > "When the NEMO where the MN is connected to is multihomed, the MN= may > > > have the choice between several AR to be its default router" > > > > > > What does this mean? > > = > > I concur, 'what does it mean' ? If a MN attaches to the NEMO (and t= hus > > becomes a VMN from our terminology), its default router is the MR (= or > > one of the MR if the NEMO is multihomed (cases [n,*,1] from > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-iss= ues-00.txt). > > The AR is the default router of the MR. > > = > > > If MNis connected to a NEMO then it is connected, so it has no ch= oice > > > between several AR's. MN has a default router already. It's tha= t > > > NEMO's TLMR that has choice, no? > > > > > > Or maybe it is meant that MN may use one of the two MR's (TLMR's)= as its > > > default route? > > = > > in which case the default router of the VMN would still be one of t= he > > root-MRs (what some people call TLMR - note that the decision at IE= TF60 > > is to remove this term and solely use root-MR). > > = > > Thierry From nemo-bounces@ietf.org Tue Aug 31 12:37:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02136 for ; Tue, 31 Aug 2004 12:37:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BOF-0006G2-7K; Tue, 31 Aug 2004 12:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Av7-0007qO-9S for nemo@megatron.ietf.org; Tue, 31 Aug 2004 11:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26769 for ; Tue, 31 Aug 2004 11:51:39 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Ax7-0006NG-M3 for nemo@ietf.org; Tue, 31 Aug 2004 11:53:46 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 18:04:38 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.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 i7VFoqTa010753; Tue, 31 Aug 2004 17:51:06 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 17:51:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Question on TD Date: Tue, 31 Aug 2004 17:50:54 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC1043D9@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Question on TD Thread-Index: AcSPcMLasOyeYBBKSryOD1seB4w5pgAANpsg From: "Pascal Thubert \(pthubert\)" To: "Masafumi Watari" X-OriginalArrivalTime: 31 Aug 2004 15:51:00.0551 (UTC) FILETIME=[50105D70:01C48F72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, ernst@sfc.wide.ad.jp, montavont@clarinet.u-strasbg.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Masafumi Watari [mailto:watari@sfc.wide.ad.jp] > Sent: mardi 31 ao=FBt 2004 17:38 > To: Pascal Thubert (pthubert) > Cc: ernst@sfc.wide.ad.jp; nemo@ietf.org; = montavont@clarinet.u-strasbg.fr > Subject: Re: [nemo] Question on TD >=20 > Hi all, >=20 > On Tue, 31 Aug 2004 14:24:20 +0200, > "Pascal Thubert (pthubert)" wrote: >=20 > > I agree that the multihoming case in the draft may not be the most = appropriate and we might > remove it for simplicity (Nicolas, what do you think?). > > > > There's still something that surprises me. In the discussions, it = seems that the nested > tree is taken for granted and then NEMO can start. Here, the MN is = connected to the MR, etc... > > > > Well actually that's not granted at all. This tree has to be = established and maintained. A > VMR permanently does its 'DNA' and might change its AR at any = time...and that AR can be a MR > as well -> a MAR. The question at DNA level might be 'am I connected = to the same link'. But > for nested NEMO, you want to know what's behind a MAR before you even = try it. For instance > the level of nesting, or whether you can get to the infrastructure, = etc... >=20 > You mean, a MR would want to know where the MAR is connected behind, > and not what's behind a MAR, correct? >=20 Sure :) the eye of the beholder. By attaching to MAP, MR would like to = see what it really attaches to in terms of nested NEMO. > I don't know how to assure that AR or MAR actually provides a path to > the infrastructure, but knowing the level of nesting before trying to > connect to is important to avoid forming the nest itself. We all know > that the more deeper the nest gets, the more delay it causes to > packets and the less MTU we have. If there is more MRs than the MTU > allows in a tree without any loops, thats what I think is the real > problem of nested NEMO. In that sense, TD is one of the solution to > solve the forming of such state. Yes. As you point out, TD is even more critical for NEMO when you do not = have RO, since each additional MR means an additional tunnelling. So we = really want to optimize for shallowness. > BTW, if we allow a fixed router to be attached behind a MR, those > routers must also provide the TIO with TD. >=20 If such a fixed router accepts visitors, yes. If you have a 'legacy' = local fixed router that cannot propagate TIOs, then it should have a = lifetime of 0, or be hidden from visitors. Pascal From nemo-bounces@ietf.org Tue Aug 31 13:11:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05915 for ; Tue, 31 Aug 2004 13:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C0L-0002Rr-3i; Tue, 31 Aug 2004 13:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BkL-00068S-Dh for nemo@megatron.ietf.org; Tue, 31 Aug 2004 12:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03519 for ; Tue, 31 Aug 2004 12:44:34 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2BmL-0008Uo-64 for nemo@ietf.org; Tue, 31 Aug 2004 12:46:42 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i7VGgBn0002640; Tue, 31 Aug 2004 09:42:13 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7VEfuaT018472; Tue, 31 Aug 2004 09:41:57 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4368D88043E; Tue, 31 Aug 2004 18:42:08 +0200 (CEST) Message-ID: <4134AA5A.1050304@motorola.com> Date: Tue, 31 Aug 2004 18:42:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Question on TD References: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> <20040901.003735.74751084.watari@sfc.wide.ad.jp> In-Reply-To: <20040901.003735.74751084.watari@sfc.wide.ad.jp> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig772CA271A0AD687CA379C468" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nemo@ietf.org, pthubert@cisco.com, ernst@sfc.wide.ad.jp, montavont@clarinet.u-strasbg.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig772CA271A0AD687CA379C468 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Masafumi Watari wrote: > Hi all, > > On Tue, 31 Aug 2004 14:24:20 +0200, "Pascal Thubert (pthubert)" > wrote: > > >> I agree that the multihoming case in the draft may not be the most >> appropriate and we might remove it for simplicity (Nicolas, what do >> you think?). >> >> There's still something that surprises me. In the discussions, it >> seems that the nested tree is taken for granted and then NEMO can >> start. Here, the MN is connected to the MR, etc... >> >> Well actually that's not granted at all. This tree has to be >> established and maintained. A VMR permanently does its 'DNA' and >> might change its AR at any time...and that AR can be a MR as well >> -> a MAR. The question at DNA level might be 'am I connected to the >> same link'. But for nested NEMO, you want to know what's behind a >> MAR before you even try it. For instance the level of nesting, or >> whether you can get to the infrastructure, etc... > > > You mean, a MR would want to know where the MAR is connected behind, > and not what's behind a MAR, correct? > > I don't know how to assure that AR or MAR actually provides a path to > the infrastructure, but knowing the level of nesting before trying > to connect to is important to avoid forming the nest itself. We all > know that the more deeper the nest gets, the more delay it causes to > packets and the less MTU we have. If there is more MRs than the MTU > allows in a tree without any loops, thats what I think is the real > problem of nested NEMO. In that sense, TD is one of the solution to > solve the forming of such state. RA's have an MTU option and lifetime options. Maybe routers may advertise an MTU lower than the physical ingress MTU's capacity, but based on the MTU received on the egress interface and substracting the size of a base header (the encapsulating header). In this way, MR's in a nested aggregation would reduce the advertised MTU down the path. In this way, a vistiing MR may decide to connect to the AR's whose RA has the largest MTU, which leads to shallow trees. But this woudl require again MR to use the MTU of RA different than the definition of the link-scoped definition of ND. Instead of using MTU, maybe play with the lifetimes. Decrease the advertised lifetime as you go down the path. Again, the prefix lifetimes are tight to a local link, not currently related to any other link of router. Alex --------------enig772CA271A0AD687CA379C468 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNKpgMmC0w56zj54RAmAYAKDjnjn3TJLXLTih7D+i2JsO95yM1wCfW91s mMnDnenBWQ8IsVDiroJHjsU= =dgmz -----END PGP SIGNATURE----- --------------enig772CA271A0AD687CA379C468-- From nemo-bounces@ietf.org Tue Aug 31 13:23:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07152 for ; Tue, 31 Aug 2004 13:23:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C5O-0003gR-QU; Tue, 31 Aug 2004 13:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BoD-0007No-TC for nemo@megatron.ietf.org; Tue, 31 Aug 2004 12:48:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04111 for ; Tue, 31 Aug 2004 12:48:35 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2BqD-0000Fa-TU for nemo@ietf.org; Tue, 31 Aug 2004 12:50:43 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i7VGlpGU020081; Tue, 31 Aug 2004 09:47:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i7VGjW5u006951; Tue, 31 Aug 2004 11:45:32 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DA84388043E; Tue, 31 Aug 2004 18:46:45 +0200 (CEST) Message-ID: <4134AB70.1020001@motorola.com> Date: Tue, 31 Aug 2004 18:46:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Question on TD References: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> <20040901.003735.74751084.watari@sfc.wide.ad.jp> In-Reply-To: <20040901.003735.74751084.watari@sfc.wide.ad.jp> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B38A7E2C9BC9ACEFE76A05E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, pthubert@cisco.com, ernst@sfc.wide.ad.jp, montavont@clarinet.u-strasbg.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B38A7E2C9BC9ACEFE76A05E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Masafumi Watari wrote: > I don't know how to assure that AR or MAR actually provides a path to > the infrastructure, but knowing the level of nesting before trying > to connect to is important to avoid forming the nest itself. We all > know that the more deeper the nest gets, the more delay it causes to > packets and the less MTU we have. If there is more MRs than the MTU > allows in a tree without any loops, thats what I think is the real > problem of nested NEMO. But when the MTU is exceeded then fragmentation occurs, it's not that the nested NEMO does not work. And, if MTU is exceeded it does not mean that there are loops. Agreed, a nested NEMO is less performant if too much fragmentation occurs. Avoiding fragmentation may be an optimization problem. Avoiding fragmentation can be performed in a local manner (ROHC) or in a distributed manner (distributed ROHC). Alex --------------enig8B38A7E2C9BC9ACEFE76A05E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNKt1MmC0w56zj54RAp64AJ4ufrYpRBgEVlUHeWCcZ0j4ZFdUawCgnq9b OHzP7UWNy0WA8jJPP6uMhJg= =o1nx -----END PGP SIGNATURE----- --------------enig8B38A7E2C9BC9ACEFE76A05E--