From nemo-bounces@ietf.org Thu Jul 1 04:59: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 EAA06288 for ; Thu, 1 Jul 2004 04:59: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 1BfxJn-0008Mo-05; Thu, 01 Jul 2004 04:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfxIZ-00086d-MX for nemo@megatron.ietf.org; Thu, 01 Jul 2004 04:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05981 for ; Thu, 1 Jul 2004 04:52:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfxIX-0001sg-A3 for nemo@ietf.org; Thu, 01 Jul 2004 04:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfxHP-00017B-00 for nemo@ietf.org; Thu, 01 Jul 2004 04:50:52 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BfxGD-0000XN-00 for nemo@ietf.org; Thu, 01 Jul 2004 04:49:37 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2AEF85D139; Thu, 1 Jul 2004 17:49:07 +0900 (JST) Date: Thu, 1 Jul 2004 17:48:47 +0900 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: [nemo] Announcing RRH version 5 Message-Id: <20040701174847.4391cefd.ernst@sfc.wide.ad.jp> In-Reply-To: <40E18145.8080108@motorola.com> References: <40E18145.8080108@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Dear all, > [about RRH...] > > In fact, since it's an RO feature, we had to hold it for some time in > > order to focus on the basic support; on the bright side, this left > > RRH a fair chance to mature, which it did. Overtime, a number of > > competing techniques have been proposed, but RRH still stands as one > > good way of performing RO. > > > > In fact, now that Tree Discovery is available as a separate draft, > > the needs and values of RRH are much clearer. Tree Discovery traces > > an optimized spanning tree of MRs, rooted at the infrastructure; and > > on top of route optimization and tunnel compression, RRH alleviates > > security and privacy issues and allows forwarding by a MR that would > > not be bound home, which in particular breaks a classical mobile Home > > deadlock in basic NEMO. > > > > I believe it's time to discuss whether tree discovery and RRH are > > part of the things we want to work on as a WG. I'm not sure it all > > fits in the current charter. My perception is that whether the WG decides to work on this or not is a matter of the conclusions of the WG problem statement document that we haven't issued yet. So, to early to discuss if the WG wants to work on it, but early enough to discuss such ideas on the ML and in drafts. > Informally speaking, there may be IPR on solutions for Route > Optimization for Moving Networks. Thierry. From mailman-bounces@ietf.org Thu Jul 1 07:18:28 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 HAA15226 for ; Thu, 1 Jul 2004 07:18: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 1BfxiF-0003es-CW for nemo-archive@lists.ietf.org; Thu, 01 Jul 2004 05:18:35 -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: Thu, 01 Jul 2004 05:04:31 -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 Thu Jul 1 11:38: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 LAA11658 for ; Thu, 1 Jul 2004 11:38: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 1Bg2dW-0005fe-Nw; Thu, 01 Jul 2004 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg1GW-0006DP-Pb for nemo@megatron.ietf.org; Thu, 01 Jul 2004 09:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21849 for ; Thu, 1 Jul 2004 09:06:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg1GW-0000lQ-4K for nemo@ietf.org; Thu, 01 Jul 2004 09:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg1FX-0000NL-00 for nemo@ietf.org; Thu, 01 Jul 2004 09:05:11 -0400 Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1Bg1EQ-0007Ql-00 for nemo@ietf.org; Thu, 01 Jul 2004 09:04:03 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 71E2361FF; Thu, 1 Jul 2004 06:02:35 -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 30050-02; Thu, 1 Jul 2004 06:02:34 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 70F3061F6; Thu, 1 Jul 2004 06:02:34 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id A40486189; Thu, 1 Jul 2004 06:02:33 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-858168198; protocol="application/pkcs7-signature" Message-Id: <1AF3EA4B-CB5F-11D8-B04A-000A95DA08F2@kniveton.com> From: "T.J.Kniveton" Subject: Re: [nemo] RIPng with NEMO again.. Date: Thu, 1 Jul 2004 06:03:54 -0700 To: "jhon saint" X-Mailer: Apple Mail (2.618) X-Spam-Score: -0.1 X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 --Apple-Mail-2-858168198 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 9:05 PM, jhon saint wrote: > Thank you for your answers!~~ ^^/ > > >> From: Vijay Devarapalli >> To: jhon saint >> Subject: Re: [nemo] RIPng with NEMO again.. >> Date: Tue, 29 Jun 2004 11:53:14 -0700 >> >> hi, >> >> are you happy with TJ's response? >> >> Vijay >> >> T.J.Kniveton wrote: > >>> Options: >>> I'll present a few possible ways to handle this. >>> >>> 1. MR-raised metric >>> Under this scenario, the MR could advertise an artificially high >>> metric, so that when it leaves the link, the HA's normal metric will >>> capture the entry. For instance, the MR could advertise metric 2, or >>> metric 5, for the MNP. When it leaves, the HA will receive a BU from >>> the MR and send a triggered update with its own address as next hop, >>> and metric 1 (received as 2). > > What about returning home?? > If MR returns home, MR will advertise high metric RIPng message.. > then, I think no routers can update their routing table.. becase the > metric is > higher than HA's advertisement... Good point; the description I gave wasn't fully detailed. When the HA gets the deregistration, it would have to change its metric back to using the MR, which means it would use the MR's metric, plus one. Once it advertises this, the other routers will update to that value; then, they will see the MR's value which is 1 lower, and use that. TJ --Apple-Mail-2-858168198 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcwMTEzMDM1 NFowIwYJKoZIhvcNAQkEMRYEFJdilkJ6rcULeE3fE5Jv4A48jrYBMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBXYEzIGdyrU4Zwqv9fMciLc32aoOAvINlBJpi1QK+EU GxfXIqBcAqiUQba/ifhA/ETp7mil0fg0AD+Aq5jPxLBnRTzf62q98Litb82MlThZSWa9c0uejFWq 7bl2guqvDrMsl4xvE3axouP/w0rgmKio2OKoLU5KvZSh2WD0Bsc3AAAAAAAA --Apple-Mail-2-858168198-- From nemo-bounces@ietf.org Tue Jul 6 15:20: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 PAA15362 for ; Tue, 6 Jul 2004 15:20: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 1BhuuK-0004HF-OR; Tue, 06 Jul 2004 14:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhuS1-0006BN-KH for nemo@megatron.ietf.org; Tue, 06 Jul 2004 14:13:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08799 for ; Tue, 6 Jul 2004 14:13:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhuS0-0003y4-JC for nemo@ietf.org; Tue, 06 Jul 2004 14:13:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhuQO-0003G3-00 for nemo@ietf.org; Tue, 06 Jul 2004 14:12:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BhuOV-0002Q6-00; Tue, 06 Jul 2004 14:10:15 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BhuOW-00019M-Cd; Tue, 06 Jul 2004 14:10:16 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BhtlI-00025t-Ew; Tue, 06 Jul 2004 13:29:44 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 06 Jul 2004 13:29:44 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo mailing list , nemo chair , Internet Architecture Board , nemo chair , RFC Editor Subject: [nemo] Protocol Action: 'Network Mobility (NEMO) Basic Support Protocol' to Proposed Standard X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org The IESG has approved the following document: - 'Network Mobility (NEMO) Basic Support Protocol ' as a Proposed Standard This document is the product of the Network Mobility Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document describes the NEMO Basic Support protocol that enables mobile networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. Working Group Summary This document is the output of the NEMO WG. This document was reviewed by many members of the WG, and there is consensus to advance the draft. There are IPR claims regarding this technology from Cisco and Nokia. The WG is aware of those claims and made a consensus decision to continue work in spite of those claims. Protocol Quality This draft was reviewed for the IESG by Margaret Wasserman. From nemo-bounces@ietf.org Mon Jul 12 05:57: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 FAA26358 for ; Mon, 12 Jul 2004 05:57: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 1BjxVi-0005fs-HT; Mon, 12 Jul 2004 05:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjxS2-0005I5-HE for nemo@megatron.ietf.org; Mon, 12 Jul 2004 05:50:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25854 for ; Mon, 12 Jul 2004 05:50:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjxRz-00068l-Ni for nemo@ietf.org; Mon, 12 Jul 2004 05:50:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjxQz-0005wj-00 for nemo@ietf.org; Mon, 12 Jul 2004 05:49:18 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BjxQ9-0005aT-00 for nemo@ietf.org; Mon, 12 Jul 2004 05:48:25 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 39B925D0C6; Mon, 12 Jul 2004 18:47:55 +0900 (JST) Date: Mon, 12 Jul 2004 18:47:38 +0900 From: Thierry Ernst To: nemo Message-Id: <20040712184738.62b08869.ernst@sfc.wide.ad.jp> In-Reply-To: <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: "T.J.Kniveton" Subject: [nemo] 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: 7bit 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 - 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 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 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 responsability of the author to send a note to the NEMO ML. Regards, NEMO Chairs. From nemo-bounces@ietf.org Mon Jul 12 07:21: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 HAA00058 for ; Mon, 12 Jul 2004 07:21: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 1BjykT-0000hs-Rt; Mon, 12 Jul 2004 07:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bjyad-0007bC-P2 for nemo@megatron.ietf.org; Mon, 12 Jul 2004 07:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29394 for ; Mon, 12 Jul 2004 07:03:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bjyaa-00057O-7e for nemo@ietf.org; Mon, 12 Jul 2004 07:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjyZh-0004vX-00 for nemo@ietf.org; Mon, 12 Jul 2004 07:02:24 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BjyYy-0004k7-00 for nemo@ietf.org; Mon, 12 Jul 2004 07:01:36 -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 i6CAvM1u001633 for ; Mon, 12 Jul 2004 19:57:22 +0900 Message-Id: <200407121057.i6CAvM1u001633@popeye.snu.ac.kr> From: "Jongkeun Na" To: Date: Mon, 12 Jul 2004 19:59:24 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03A9_01C4684A.BE1E1E50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40925CA9.6000101@motorola.com> Thread-Index: AcQuvKRkBmVpnOEhTY2rVutJ0rnCFgCHEpgw X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [nemo] new draft submitted about 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 a multi-part message in MIME format. ------=_NextPart_000_03A9_01C4684A.BE1E1E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Just to inform you that I've submitted a new draft on the analysis of RO solution space. Any feedback from you all is welcomed. Please comment on that does it make sense? Or does it valuable to further develop this generic model in order to more well describe our RO problem & solution?, and so on. Abstract: In this memo, we introduce the generic Route Optimization (RO) model that can be used as a framework to evaluate the existing RO models. Then, we analyze typical RO problems by virtue of that. And, we discuss on the feasibility of achieving a unified RO in NEMO, and enumerate the issues that should be cleared for the purpose of that. Thanks /Jongkeun ------=_NextPart_000_03A9_01C4684A.BE1E1E50 Content-Type: text/plain; name="draft-na-nemo-gen-ro-model-00.txt" Content-Disposition: attachment; filename="draft-na-nemo-gen-ro-model-00.txt" Content-Transfer-Encoding: quoted-printable NEMO Working Group = Jongkeun Na=20 Internet Draft = Seongho Cho=20 Expires: January 2005 = Chongkwon Kim=20 Seoul = National University=20 = Changhoi Koo=20 = Samsung Electronics=20 = July 2004=20 =20 =20 =20 =20 Generic Route Optimization Model for NEMO = Extended Support=20 draft-na-nemo-gen-ro-model-00=20 =20 =20 =20 =20 Status of this Memo =20 =20 This document is an Internet-Draft and is in full = conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the = Internet Engineering=20 Task Force (IETF), its areas, and its working = groups. Note that=20 other groups may also distribute working documents = as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a = maximum of six=20 months and may be updated, replaced, or obsoleted by = other=20 documents at any time. It is inappropriate to use = Internet-Drafts=20 as reference material or to cite them other than as = "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed = at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be = accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 =20 Abstract=20 =20 In this memo, we introduce the generic Route = Optimization (RO)=20 model that can be used as a framework to evaluate = the existing RO=20 models. Then, we analyze typical RO problems by = virtue of that. And,=20 we discuss on the feasibility of achieving a unified = RO in NEMO,=20 and enumerate the issues that should be cleared for = the purpose of=20 that.=20 =20 =20 =20 Na, et al. Expires - November 2004 = [Page 1]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and = "OPTIONAL" in=20 this document are to be interpreted as described in = RFC-2119.=20 =20 =20 =20 =20 Table of Contents=20 =20 =20 1. = Introduction.................................................3=20 2. Generic Route Optimization = Model.............................3=20 3. The Analysis of RO Problems in = NEMO..........................5=20 3.1 RO in the = infrastructure................................6=20 3.2 Nested Tunnels Optimization = (NTO).......................7=20 4. Toward to a unified route optimization in = NEMO...............8=20 5. Open = Issues..................................................9=20 6. Security = Considerations......................................9=20 = References......................................................10=20 = Acknowledgments.................................................11=20 Authors' = Addresses..............................................11=20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 2]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 =20 1. Introduction=20 =20 NEMO Basic Support Protocol [15] would suppose to = support the=20 transparent mobility to mobile network nodes (MNNs) = in mobile=20 networks by using MR-HA bi-directional tunnel. = However, inherently=20 due to the use of the bi-directional tunnel, there = are some types=20 of route optimization problem [14] that need our = attention. =20 =20 RO problems have a common property that there is an = optimized path,=20 but it cannot be used due to support the transparent = mobility to=20 the IP terminals. While preserving the goals of = Mobile IP [1] and=20 NEMO Basic [15], it is impossible to realize RO = without introducing=20 the tunnel-based virtual path over IP routing = through some=20 extensions or new functionalities of routing = facilities. This is=20 the reason why the existing proposed solutions for = RO at least use=20 tunnel-based packet redirection or re-routing = mechanism in the=20 extended routing facilities such as Correspondent = Router (CR).=20 =20 As a requirement about RO, we argue that RO in NEMO = should be=20 provided by a unified solution which can solve most = of RO problems=20 by applying the same principle to the routing = facilities such as HA,=20 MR, CR. If each different RO solution is used to = solve each RO=20 problem, it will produce the protocol redundancy and = complexity in=20 the routing facilities.=20 =20 In this memo, we introduce the generic RO model that = can be used as=20 a framework to evaluate the existing RO models. = Then, we analyze=20 typical RO problems by virtue of the generic RO = model. And, we=20 discuss on the feasibility of achieving a unified RO = in NEMO, and=20 enumerate the issues that should be cleared for the = purpose of that.=20 =20 =20 2. Generic Route Optimization Model=20 =20 Route Optimization in NEMO means that one routing = entity uses an IP=20 tunnel to redirect the original packets to the other = routing entity=20 that is most closely located from the destination. = To enable such a=20 route optimization, two routing entities must = recognize each other,=20 in other words, anyone among them should feel the = need of RO tunnel=20 and initiate the signaling procedure to make an IP = tunnel between=20 them. We can define such an IP tunnel as `RO Tunnel = (ROT)` in NEMO=20 context because it is established for the purpose of = route=20 optimization in NEMO. This is like the basic = principle of Mobile IP.=20 In Mobile IP, MN detects its movement and initiates = BU to HA. Such=20 an analogy can be extended to RO problem in NEMO. In = this point of=20 view, we can extract some of statements = characterizing how to=20 achieve RO tunnel. For example, which routing = facilities can=20 initiate RO tunnel? What information does trigger = such a RO tunnel?=20 =20 =20 Na, et al. Expires - January 2005 = [Page 3]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 How can the trigger information be delivered to the = initiator of RO=20 tunnel? And so on. The answer to those of questions = depends on the=20 problem spaces [14] and the proposed solutions = [4][5][19][20] in=20 each problem space.=20 =20 The attributes of RO tunnel can concretely well = express the RO=20 context including the purpose of RO, the operation = of RO, and the=20 effectiveness of RO. =20 =20 =20 TE[1] TS[0..n] TR[0..n] TE[1]=20 +--+---------+--+--------+--+--------+--+=20 = =3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D|=3D= =3D|=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=20 +--+---------+--+--------+--+--------+--+=20 =20 XX: Tunnel Processing (Encap./Decap.)=20 TE: Tunnel Endpoint=20 TS: Tunnel Switcher=20 TR: Tunnel Relay=20 =20 Fig.1 Generic RO Tunnel (ROT) Model=20 =20 Fig.1 shows the generalized ROT model. ROT can be = made of at least=20 two TEs. In here, TE is a router or host which is = allowed to=20 initiate or terminate the RO tunnel in the view of = route=20 optimization. According to the type of ROT, ROT can = include zero or=20 more TS for switching an incoming tunnel to an = outgoing tunnel at=20 that point, zero or more TR for relaying the = tunneled packets to=20 next intermediate point. As of TR, The difference is = that it=20 operates a routing mechanism, such as Source Routing = using RH0=20 header [10], based on the packet header information = without the=20 knowledge of the end-to-end tunneling, while TS = processes the=20 tunnel switching based on a given tunnel mapping = information that=20 consistently maintained in that point by interacting = with other=20 tunnel endpoints.=20 =20 From the general ROT model, we can drive the = following attributes=20 which can be exploited to characterize a specific RO = model.=20 =20 RO Initiator (ROI)=20 =20 We need to identify which TE among two TEs can be = the initiator=20 in making a RO tunnel. This parameter depends on = the applied RO=20 scheme. In one RO scheme, MR is only the = initiator, on the other=20 hand, HA and CR can be the initiator in the other = RO scheme.=20 =20 RO Responder (ROR)=20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 4]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 We need to identify which routing facilities can = be the=20 responder in making a RO tunnel. This parameter = also depends on=20 the applied RO scheme.=20 =20 RO Trigger Source (ROTS)=20 =20 The RO initiator (ROI) is recognized for the need = of RO from=20 this information. For example, an explicit RO bit = in the packet=20 header can be used to force the receiver to start = the RO.=20 =20 RO Responder Information (RORI)=20 =20 This information is used for the RO initiator = (ROI) to identify=20 the RO responder (ROR). It would include the = address information=20 of the moving entity such as MR, or the address = information of=20 the correspondent nodes.=20 =20 RO Discovery Mechanism (RODM)=20 =20 This mechanism describes that how RORI can be = delivered to the=20 RO initiator (ROI). In other words, ROI can get = RORI by using=20 this discovery mechanism. For example, if ROI = itself try to find=20 its ROR using IPv6 anycast address, RORI becomes = an address of=20 ROR and we can say that RODM is IPv6 anycasting = mechanism.=20 =20 RO Tunnel Type (ROTT)=20 =20 ROTT can be classified as the followings: Simple = ROT (SiROT),=20 Switched ROT (SwROT), Releyed ROT (ReROT). SiROT = consists of=20 only two TEs. SwROT consists of one or more TS = between two TEs.=20 ReROT consists of one or more TR between two TEs. = For example,=20 we can say that RRH [4] uses ReROT as RO Tunnel = Type, HMIPv6=20 uses SwROT.=20 =20 =20 More attributes to be defined.=20 =20 =20 3. The Analysis of RO Problems in NEMO=20 =20 In this section, we analyze typical RO problems in = NEMO using the=20 generic ROT model.=20 =20 =20 =20 =20 =20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 5]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 3.1 RO in the infrastructure=20 =20 =20 =20 TE[1] TE[1]=20 +--+---------------------------------+--+=20 = =3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=20 +--+---------------------------------+--+=20 =20 Fig.2 SiROT based RO in the infrastructure=20 =20 =20 Fig.2 shows the simple RO in the infrastructure. = This RO model was=20 used in ORC [19]. According to the generic ROT = model, the following=20 formulation is possible.=20 =20 TE: Mobile Router (MR), Optimized Route Cache (ORC) = Router=20 ROI: MR=20 ROR: ORC Router=20 ROTS: the packet sent from any CN via MR-HA default = tunnel=20 RORI: the global IPv6 address of ORC Router=20 RODM: IPv6 anycast addressing=20 ROTT: SiROT=20 =20 Above attributes compactly describes that this RO = implements ROT=20 between MR and ORC Router, and MR initiates the = signaling procedure=20 for ROT to ORC Router after getting the global IPv6 = address of ORC=20 Router through IPv6 anycast addressing. This RO = model also includes=20 some RO approaches, such as C-Side Router or = Correspondent Router=20 (CR), mentioned in RO-Taxonomy [14]. To include = those of RO=20 approaches, we can loosely redefine above attributes = as follows:=20 =20 TE: Mobile Router (MR), Optimized Route Cache (ORC) = Router, C-Side=20 Router, Correspondent Router (CR)=20 ROI: MR=20 ROR: ORC Router, C-Side Router, CR=20 ROTS: the packet sent from any CN via MR-HA default = tunnel=20 RORI: the global IPv6 address of ROR=20 RODM: IPv6 anycast addressing=20 ROTT: SiROT=20 =20 =20 TE[1] TS[1] TE[1]=20 +--+---------------------+--+--------+--+=20 = =3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=20 +--+---------------------+--+--------+--+=20 =20 Fig.3 SwROT based RO in the infrastructure=20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 6]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 =20 =20 Fig.3 shows extended RO in the infrastructure. This = RO model=20 includes one TS entity and two TEs. Distributed = Anchor Routers=20 described in RO-Taxonomy [14] can be expressed as = this model like=20 below.=20 =20 TE: Mobile Router (MR), C-Side Anchor Router=20 TS: M-Side Anchor Router (a.k.a Mobility Anchor = Point in HMIPv6)=20 ROI: Not mentioned=20 ROR: Not mentioned=20 ROTS: Not mentioned=20 RORI: Not mentioned=20 RODM: Not mentioned=20 ROTT: SwROT=20 =20 In this case, most of attributes in the ROT model = are not=20 determined, so it is required to deeply understand = this RO problem=20 and derive its viable solution.=20 =20 =20 3.2 Nested Tunnels Optimization (NTO)=20 =20 NTO can be modeled like Fig.4 by using the ROT = model. For example,=20 the attributes of RRH [4] model are as follows:=20 =20 =20 TE[1] TR[1..n] TE[1]=20 +--+---------------------+--+--------+--+=20 = =3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D|=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=20 +--+---------------------+--+--------+--+=20 =20 Fig.4 ReROT based NTO=20 =20 =20 TE: Mobile Router (MR), Home Agent (HA)=20 TR: MR (via Source Routing)=20 ROI: MR=20 ROR: HA=20 ROTS: TIO option in RA [14]=20 RORI: Nested Path Information like = MR3->MR2->MR1->HA3=20 RODM: Using Reverse Routing Header (RRH)=20 ROTT: ReROT=20 =20 Similarly, ARO [5] can be expressed as follows:=20 =20 TE: Mobile Router (MR), Home Agent (HA)=20 TR: MR (via Source Routing)=20 ROI: MR=20 =20 =20 Na, et al. Expires - January 2005 = [Page 7]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 ROR: HA=20 ROTS: BU with ARO option, Recursive Binding Update = by ancestor MRs=20 RORI: Nested Path Information like = MR3->MR2->MR1->HA3=20 RODM: Using Access Router Option (ARO) & Recursive = BU=20 ROTT: ReROT=20 =20 =20 4. Toward to a unified route optimization in NEMO=20 =20 There are some efforts for Route Optimization (RO). = For RO in the=20 routing infrastructure, some approaches such as VIP = [17], ORC [19]=20 require a special router or the extension of the = existing router=20 which can handle the packet redirection to gain RO = effect. The RO=20 schemes belong to this category can be applied to = both Mobile IP=20 and NEMO in IP routing infrastructure. On the other = hand, There are=20 other kinds of the NEMO-specific RO problem. [14] = well defines RO=20 problem spaces of NEMO and briefly analyzes the = proposed interim=20 solutions. Typically, one of NEMO-specific RO = problem is a nested=20 tunneling problem that can be formed due to the = network mobility.=20 Most of proposed solutions are for solving that = problem. As of now,=20 it's not easy to say how RO problems in NEMO can be = best solved in=20 the reasonable manner. However, the sure thing is = that current=20 proposed solutions can be applied only to one = problem space of RO.=20 That is an uncomfortable and unnatural facet in = supporting coherent=20 network mobility. We need a simple and effective, = unified route=20 optimization scheme for network mobility.=20 =20 With the help of the ROT model, we can evaluate = whether or not=20 there is the feasibility of achieving a unified = route optimization=20 in NEMO, and enumerate the issues that should be = cleared for the=20 purpose of that. As a unified RO model, let us = illustrate one=20 example as Fig.5. In here, TR can be zero. That is = only difference=20 in comparing with Fig.4. However, this trivial = difference in the=20 model implies that this model can support SiROT = based RO in the=20 infrastructure as well as ReROT based NTO. PCH [20] = approach=20 belongs to this model.=20 =20 =20 =20 TE[1] TR[0..n] TE[1]=20 +--+---------------------+--+--------+--+=20 = =3D=3D=3D=3D|XX|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D|=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D|XX|=3D=3D=3D=3D=20 +--+---------------------+--+--------+--+=20 =20 Fig.5 A unified RO supporting ReROT as well as = SiROT=20 =20 =20 As an instance of a unified RO, The attributes of = PCH [20] model=20 can be summarized as follows:=20 =20 =20 Na, et al. Expires - January 2005 = [Page 8]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 =20 TE: Mobile Router (MR), Home Agent (HA), = Correspondent Router (CR)=20 TR: MR (via Source Routing)=20 ROI: CR, HA=20 ROR: MR=20 ROTS: Receiving the packet with Path Control Header = (PCH)=20 RORI: Nested Path Information like MR1-MR2-MR3, = contained in PCH=20 RODM: PCH Piggybacking by HA=20 ROTT: SiROT+ReROT=20 =20 =20 5. Open Issues=20 =20 =20 ? Functional entities involving in RO=20 =20 ? Source routing in the inside of nested mobile = network=20 =20 ? Considerations on RO in multi-homed mobile = networks=20 =20 ? Performance / Evaluation Metric for RO=20 =20 TBD=20 =20 =20 =20 6. Security Considerations=20 =20 TBD=20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 9]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 =20 References=20 =20 [1] Perkins, C., Johnson, D. and J. Arkko, = "Mobility Support in=20 IPv6", draft-ietf-mobileip-ipv6-18 (work in = progress), July=20 2002.=20 =20 [2] Ernst, T. and H. Lach, "Network Mobility = Support Terminology",=20 draft-ietf-nemo-terminology-00 (work in = progress), May 2003.=20 =20 [3] Ernst, T., Castelluccia, C., Bellier, L., = Lach, H. and A.=20 Olivereau, "Mobile Networks Support in Mobile = IPv6 (Prefix=20 Scope Binding Updates)", = draft-ernst-mobileip-v6-network-03=20 (work in progress), March 2002.=20 =20 [4] Thubert, P., and Molteni, M., "IPv6 Reverse = Routing Header=20 and Its Application to Mobile Networks", = Internet Draft:=20 draft-thubert-nemo-reverse-routing-header-01=20 (work in progress), Oct 2002. =20 =20 [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing = Nested Tunnels=20 Optimization with Access Router Option", = Internet Draft:draft=20 -ng-nemo-access-router-option-00(work in = progress), Oct 2002.=20 =20 [7] Kent, S. and R. Atkinson, "Security = Architecture for the=20 Internet Protocol", RFC 2401, November 1998.=20 =20 [8] Kent, S. and R. Atkinson, "IP Authentication = Header", =20 RFC 2402, November 1998.=20 =20 [9] Kent, S. and R. Atkinson, "IP Encapsulating = Security Payload=20 (ESP)", RFC 2406, November 1998.=20 =20 [10] Deering, S. and R. Hinden, "Internet Protocol, = =20 Version 6 (IPv6) Specification", RFC 2460, = December 1998.=20 =20 [11] Narten, T., Nordmark, E. and W. Simpson, = "Neighbor Discovery=20 for IP Version 6 (IPv6)", RFC 2461, December = 1998.=20 =20 [12] Conta, A. and S. Deering, "Internet Control = Message Protocol=20 (ICMPv6) for the Internet Protocol Version 6 = (IPv6)=20 Specification", RFC 2463, December 1998.=20 =20 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is = Replaced by =20 an On-line Database", RFC 3232, January 2002.=20 =20 [14] Thubert, P., and Molteni, M., "Taxonomy of = Route Optimization =20 Models in the NEMO Context", Internet Draft: = draft-thubert-=20 nemo-ro-taxonomy-00(work in progress), Oct = 2002. =20 =20 =20 Na, et al. Expires - January 2005 = [Page 10]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 =20 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, = T., "NEMO Basic=20 Support Protocol", = draft-ietf-nemo-basic-support-00(work in=20 process), June 2003.=20 =20 [16] A. Conta, S. Deering, "Generic Packet = Tunneling in IPv6 =20 Specificiation", RFC2473, December 1998.=20 =20 [17] Fumio Teraoka, Keisuke Uehara, Hideki = Sunahara, and Jun Murai,=20 ``VIP : A Protocol Providing Host Mobility,`` = Aug. 1994=20 =20 [18] Weidong Chen, Eric Lin, ``Route Optimization = and Location=20 Updates for Mobile Hosts,`` International = Conference on =20 Distributed Computing Systems,1996=20 =20 [19] Ryuji Wakikawa, Susumu Koshiba, Keisuke = Uehara, Jun Murai,=20 ``ORC: Optimized Route Cache Management = Protocol for Network=20 Mobility,`` Proc. of ICT2003, Nov 2003.=20 =20 [20] Jongkeun Na, et.al. ``Route Optimization = Scheme based on Path=20 Control Header,`` = draft-na-nemo-path-control-header-00(work=20 in process), April 2004.=20 =20 =20 Acknowledgments=20 =20 =20 =20 Authors' Addresses=20 =20 Jongkeun Na=20 Information Networking & Computing Lab.=20 School of Computer Science and Engineering, =20 Seoul National University, Seoul Korea=20 EMail: jkna@popeye.snu.ac.kr=20 =20 Sungho Cho=20 Information Networking & Computing Lab.=20 School of Computer Science and Engineering, =20 Seoul National University, Seoul Korea=20 EMail: shcho@popeye.snu.ac.kr=20 =20 Chongkwon Kim=20 Information Networking & Computing Lab.=20 School of Computer Science and Engineering, =20 Seoul National University, Seoul Korea=20 EMail: ckim@popeye.snu.ac.kr=20 =20 Changhoi Koo =20 =20 =20 Na, et al. Expires - January 2005 = [Page 11]=20 =0C Internet Draft Generic RO Model = July 2004=20 =20 =20 Global Standards & Research Team =20 Telecommunication R&D Center, =20 Samsung Electronics, KOREA =20 Email : chkoo@samsung.com=20 =20 =20 =20 =20 =20 =20 Na, et al. Expires - January 2005 = [Page 12]=20 =0C ------=_NextPart_000_03A9_01C4684A.BE1E1E50-- From nemo-bounces@ietf.org Mon Jul 12 22:36: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 WAA16700 for ; Mon, 12 Jul 2004 22:36: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 1BkCdS-0007AH-GV; Mon, 12 Jul 2004 22:03:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkCOJ-00014q-Sq for nemo@megatron.ietf.org; Mon, 12 Jul 2004 21:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12008 for ; Mon, 12 Jul 2004 21:47:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkCOI-0001AL-04 for nemo@ietf.org; Mon, 12 Jul 2004 21:47:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkCNM-0000se-00 for nemo@ietf.org; Mon, 12 Jul 2004 21:46:32 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1BkCMU-0000Vl-00 for nemo@ietf.org; Mon, 12 Jul 2004 21:45:38 -0400 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id i6D1j7al023426 for ; Tue, 13 Jul 2004 10:45:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id i6D1j7f26418 for ; Tue, 13 Jul 2004 10:45:07 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id i6D1j7k23848 for ; Tue, 13 Jul 2004 10:45:07 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id i6D1j6827548 for nemo@ietf.org; Tue, 13 Jul 2004 10:45:06 +0900 (JST) Received: from nancy (localhost [127.0.0.1]) by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id i6D1j6527525 for ; Tue, 13 Jul 2004 10:45:06 +0900 (JST) Message-Id: <200407130145.i6D1j6527525@soml23.jp.panasonic.com> Date: Tue, 13 Jul 2004 10:45:06 +0900 From: Masayuki Kumazawa To: nemo@ietf.org X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] New draft : draft-kumazawa-nemo-tbdnd-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi All, I would like to inform you that we have submitted a new I-D on token based duplicate network detection for split mobile network. The draft is now available at the following URL: http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-00.txt In the NEMO working group mailing list, split mobile network and Duplicate Network Detection (DND) test for it have been discussed. The objective of this document is to propose one solution for the DND. The solution described in this document requires sharing of a token corresponding to a Mobile Network Prefix between Mobile Routers within a network and a Home Agent. The token is updated periodically, Mobile Routers which exist outside or move away can't obtain it and share the prefix. Thanks and regards, Masayuki From nemo-bounces@ietf.org Mon Jul 12 23:21: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 XAA19846 for ; Mon, 12 Jul 2004 23:21: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 1BkDey-0007S2-RP; Mon, 12 Jul 2004 23:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkDSn-0002iq-NA for nemo@megatron.ietf.org; Mon, 12 Jul 2004 22:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17857 for ; Mon, 12 Jul 2004 22:56:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkDSl-0004ST-Vg for nemo@ietf.org; Mon, 12 Jul 2004 22:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkDQs-0003sI-00 for nemo@ietf.org; Mon, 12 Jul 2004 22:54:14 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BkDPm-0003F0-00 for nemo@ietf.org; Mon, 12 Jul 2004 22:53:06 -0400 Received: from psl.com.sg ([10.81.113.126]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i6D2obf3022867 for ; Tue, 13 Jul 2004 10:50:37 +0800 (SGT) Message-ID: <40F34EF4.6080007@psl.com.sg> Date: Tue, 13 Jul 2004 10:54:44 +0800 From: Benjamin Koh Tien-Ming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] New draft submitted: draft-koh-dihap-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 Hi! A new draft was submitted and can be found at: http://www.ietf.org/internet-drafts/draft-koh-dihap-00.txt All feedback are welcome! Abstract This draft describes a proposed Dynamic Inter Home Agent solution to provide redundancy and load balancing of Home Agents. The proposed solution recommends additional communication between home agents that may be located far apart in terms of network topology but still belonging to or are trusted by the same administrative domains (service providers). While the mobile node is roaming away from its home network, intervening home agents in the path of the bidirectional tunnel between the mobile node and its registered home agent may detect its presence. The intervening home agents that are affiliated to the current home agent of the mobile node then proceed to update it of their availability to serve as home agent for the mobile node. Regards, Ben From nemo-bounces@ietf.org Tue Jul 13 21:35: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 VAA22551 for ; Tue, 13 Jul 2004 21:35: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 1BkV0m-0004Z7-Sz; Tue, 13 Jul 2004 17:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkTVH-0003BZ-RH; Tue, 13 Jul 2004 16:03:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10328; Tue, 13 Jul 2004 16:03:49 -0400 (EDT) Message-Id: <200407132003.QAA10328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 13 Jul 2004 16:03:49 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-00.txt Pages : 33 Date : 2004-7-13 This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-13145203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-13145203.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Jul 14 00:22: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 AAA12902 for ; Wed, 14 Jul 2004 00:22: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 1Bkb68-0006aQ-NH; Wed, 14 Jul 2004 00:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkahA-000620-5c for nemo@megatron.ietf.org; Tue, 13 Jul 2004 23:44:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08316 for ; Tue, 13 Jul 2004 23:44:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkah7-0006IO-US for nemo@ietf.org; Tue, 13 Jul 2004 23:44:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkaD8-0000q4-00 for nemo@ietf.org; Tue, 13 Jul 2004 23:13:35 -0400 Received: from jules.nautilus6.org ([203.178.138.2] helo=bender) by ietf-mx with esmtp (Exim 4.12) id 1BkZho-0003b5-00 for nemo@ietf.org; Tue, 13 Jul 2004 22:41:12 -0400 Received: from bender (bender [127.0.0.1]) by bender (Postfix) with SMTP id 6D62BA177D; Wed, 14 Jul 2004 11:40:36 +0900 (JST) Date: Wed, 14 Jul 2004 11:40:36 +0900 From: Romain KUNTZ To: nemo@ietf.org Message-Id: <20040714114036.05eced69.kuntz@sfc.wide.ad.jp> 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Eun Kyoung , Thierry Ernst , Koshiro MITSUYA , "tu-ka@sfc.wide.ad.jp" Subject: [nemo] New draft submitted: draft-kuntz-nemo-multihoming-test-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, We just submitted a new draft. This draft presents the NEMO basic support test results in multihoming: we focused on multiple mobile routers and multiple NEMO-Prefixes. In this draft we share our conclusions and issues, and try to discuss how we can solve them. Any feedback is of course welcome. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kuntz-nemo-multihoming-test-00.txt Title : Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support Author(s) : R. Kuntz, et al. Filename : draft-kuntz-nemo-multihoming-test-00.txt Pages : 20 Date : 2004-7-13 Abstract: This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers and mobile networks with multiple NEMO-Prefixes. Best Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Wed Jul 14 11:25: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 LAA23930 for ; Wed, 14 Jul 2004 11:25: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 1BklO4-00037W-P8; Wed, 14 Jul 2004 11:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BklIF-00026o-H9 for nemo@megatron.ietf.org; Wed, 14 Jul 2004 11:03:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22485 for ; Wed, 14 Jul 2004 11:03:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BklID-0006sE-RA for nemo@ietf.org; Wed, 14 Jul 2004 11:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BklHH-0006U8-00 for nemo@ietf.org; Wed, 14 Jul 2004 11:02:36 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1BklGB-0005mH-00 for nemo@ietf.org; Wed, 14 Jul 2004 11:01:28 -0400 Received: from [129.94.230.70] (helo=IBMD64CB19E466) by mobqos.ee.unsw.edu.au with esmtp (Exim 3.35 #1 (Debian)) id 1BklFa-0002TR-00 for ; Thu, 15 Jul 2004 01:00:50 +1000 From: "Eranga Perera" To: Date: Thu, 15 Jul 2004 00:59:35 -0700 Message-ID: <000001c46a41$acc16330$0200a8c0@IBMD64CB19E466> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C46A07.00628B30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,DATE_IN_FUTURE_12_24, HTML_90_100,HTML_MESSAGE,MIME_HTML_MOSTLY autolearn=no version=2.60 Subject: [nemo] test X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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_0001_01C46A07.00628B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0001_01C46A07.00628B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_0001_01C46A07.00628B30-- From nemo-bounces@ietf.org Wed Jul 14 22:19: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 WAA01261 for ; Wed, 14 Jul 2004 22:19: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 1Bkvjc-0005CY-AI; Wed, 14 Jul 2004 22:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkvd7-00034l-B9 for nemo@megatron.ietf.org; Wed, 14 Jul 2004 22:05:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00551 for ; Wed, 14 Jul 2004 22:05:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkvd5-0000kD-Dg for nemo@ietf.org; Wed, 14 Jul 2004 22:05:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkvcL-0000QT-00 for nemo@ietf.org; Wed, 14 Jul 2004 22:05:02 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BkvbW-00003A-00 for nemo@ietf.org; Wed, 14 Jul 2004 22:04:10 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i6F21WGf018869; Thu, 15 Jul 2004 10:01:32 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id B9429B24138; Thu, 15 Jul 2004 10:11:04 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-VP9XqUqD2OELwzWfC2Iy" Organization: Panasonic Singapore Laboratories Message-Id: <1089857463.8373.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 15 Jul 2004 10:11:04 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-access-router-option-01.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-VP9XqUqD2OELwzWfC2Iy Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, After more than 1 year of dormant state, a new version is finally ready. In this version, we explain how the idea of using ARO can be extended to achieve MR-CN, and also VMN-CN optimization. For your reading pleasure, and comments/criticism are welcome and appreciated. /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ng-nemo-access-router-option-01.txt Date: Wed, 14 Jul 2004 15:34:20 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securing Nested Tunnels Optimization with Access Router Option Author(s) : C. Ng, T. Tanaka Filename : draft-ng-nemo-access-router-option-01.txt Pages : 47 Date : 2004-7-14 Through the establishment of bi-directional tunnels between a mobile router and home agent, global connectivity can be extended to nodes within a network in motion. However, the multiple levels of bi- directional tunnels in nested mobile networks lead to undesirable effects. This memo proposes using a new mobility header option called the Access Router Option to allow a mobile router to inform its home agent the home-address of the access router it is currently attached to. From there, this memo lays out a mechanism that allows mobile routers to securely achieve nested tunnels optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-access-router-option-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ng-nemo-access-router-option-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ng-nemo-access-router-option-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-7-14153144.I-D@ietf.org> ________________________________________________________________________ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-VP9XqUqD2OELwzWfC2Iy Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-14153144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ng-nemo-access-router-option-01.txt --=-VP9XqUqD2OELwzWfC2Iy Content-Type: Message/External-body; name="draft-ng-nemo-access-router-option-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-14153144.I-D@ietf.org> --=-VP9XqUqD2OELwzWfC2Iy-- From nemo-bounces@ietf.org Fri Jul 16 02:40: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 CAA08886 for ; Fri, 16 Jul 2004 02:40: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 1BlML1-0001hP-4U; Fri, 16 Jul 2004 02:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlMHx-0001Ej-49 for nemo@megatron.ietf.org; Fri, 16 Jul 2004 02:33:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08496 for ; Fri, 16 Jul 2004 02:33:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlMHu-00049z-Ks for nemo@ietf.org; Fri, 16 Jul 2004 02:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlMGv-0003pE-00 for nemo@ietf.org; Fri, 16 Jul 2004 02:32:42 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BlMFr-0003C1-00 for nemo@ietf.org; Fri, 16 Jul 2004 02:31:35 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2F3425D019 for ; Fri, 16 Jul 2004 15:31:03 +0900 (JST) Date: Fri, 16 Jul 2004 15:30:42 +0900 From: Thierry Ernst To: nemo Message-Id: <20040716153042.55f34df8.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] draft-ietf-nemo-home-network-models-00 (NEMO Home Network models) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 draft authors, Here are a couple of comments on draft-ietf-nemo-home-network-models-00. - why some of the new terms (Extended Home Network) are defined in section 1 and not in section 2 "terminology" ? (section 2 is the actual formal definition). I would recommend to move the text in 1 after the text in 2, and to use words easier to understand as far as the introduction is concerned. - you should watch section 7 of draft-ietf-terminology, some of the definitions have been included (to the request of the authors of the usage draft), so they shouldn't appear in draft-ietf-nemo-home-network-models. So, my recommendation is to remove the entire section 2 and to move it to the terminology draft. - "NEMO" should always be capitalized (not Nemo) - should give a number to figures, and refer to them in the text. #>------------------------------------------ Abstract: "NEMO and NEMO Design mailing lists" -> NEMO appears 2 times #>------------------------------------------ Section 1 -> Figures or direct reference to section 4 and 5 would be useful to describe "Extended Home Network" and "Aggregated Home Network" Extended Home Network: In this disposition, the Home Network is but one subnet -> isn't there one work missing before "but" ? When at Home -> I don't think Home should be capitalized here Also, it is valid for a Mobile Router to register using an address from one of its own NEMO-Prefixes in all three cases. -> might be useful to say "using a **home** address". Also, I guess the address is from an ingress iface of the MR. "but are by no mean at limiting its scope of application" -> I don't think this sentence construction is correct #>------------------------------------------ Section 2 The following terms used in this document are defined in the mobile network terminology document [9]: mobile router (MR) mobile network mobile host (MH) -> this is not exact, those terms are defined in RFC 3753 Home Link: The link attached to the interface at the Home Agent on which the Home Prefix is configured. The interface can be a virtual interface, in which case the Home Link is a virtual Home Link. -> the interface of who ? The MR ? The ingress or the egress ? Home Network: The Network formed by the application of the Home Prefix on the Home Link. With NEMO, the concept of Home Network is extended as explained below. -> What is the "home prefix" ? Also, I think there is no need to capitalize "network" -> in any case, the definition is not clear to me. Shouldn't the home network be defined as the network where the HA is located in ? I think that in many places "home network" should be replaced with "home link". Only the home link is meaningful to me. Mobile Home Network: A Mobile Network that is also a Home Network. The MR that own the NEMO-Prefix acts as a Home Agent for it. -> What about "A mobile network that also serve as a home network" or "a home networks that is also a mobile network" ? -> "s" missiing in "own" #>------------------------------------------ Section 3 With basic NEMO -> this is meaningless. Say "With NEMO Basic Support". This appears in other places (e.g. Appendix) #>------------------------------------------ Section 4 extended Home Network -> you forgot to capitalize "extended" Home Network -> why isn't this called "home link" ? There is only one such link. -> to me, the home network is the network in which the HA is located. So, the disctinction is important Section 4.1: If the Home Address of the Mobile Router is derived from one of its Mobile Networks -> you mean "derived from its NEMO-Prefixes (?) Alternate procedures for ensuring the connectivity of the Mobile Networks when at Home are described in Section 6. In Particular, it is -> end of sentence is missing ! -> there is a section 4.1 but not section 4.2 ... #>------------------------------------------ Section 5 -> the figure is not clear about showing the difference between "Extended Home Network" -> there is a section 5.1 but not section 5.2 ... Mobile Link -> I don't think this as been defined. I propose to replace this with "NEMO-link" as defined in draft-ietf-nemo-terminology #>------------------------------------------ Section 6 or one of the prefixes of its Mobile Network(s) -> or one of its NEMO-Prefixes Thierry. From nemo-bounces@ietf.org Fri Jul 16 15:53: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 PAA28497 for ; Fri, 16 Jul 2004 15:53: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 1BlYfD-00070D-Mt; Fri, 16 Jul 2004 15:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlY6F-0006y6-0f for nemo@megatron.ietf.org; Fri, 16 Jul 2004 15:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25417 for ; Fri, 16 Jul 2004 15:10:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlY6C-0006Cc-2F for nemo@ietf.org; Fri, 16 Jul 2004 15:10:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlY5X-0005sX-00 for nemo@ietf.org; Fri, 16 Jul 2004 15:09:43 -0400 Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx with esmtp (Exim 4.12) id 1BlY4f-0005Xk-00 for nemo@ietf.org; Fri, 16 Jul 2004 15:08:50 -0400 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with ESMTP id i6GJ8oWH013055 for ; Fri, 16 Jul 2004 12:08:50 -0700 (PDT) Date: Fri, 16 Jul 2004 12:08:50 -0700 (PDT) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Mailman-Approved-At: Fri, 16 Jul 2004 15:46:34 -0400 Subject: [nemo] test, please discard X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org From nemo-bounces@ietf.org Fri Jul 16 19:05: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 TAA17252 for ; Fri, 16 Jul 2004 19:05: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 1Blbgg-0007rk-92; Fri, 16 Jul 2004 19:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Blbe1-0007OM-DQ for nemo@megatron.ietf.org; Fri, 16 Jul 2004 18:57:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16916 for ; Fri, 16 Jul 2004 18:57:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blbdx-00078A-OE for nemo@ietf.org; Fri, 16 Jul 2004 18:57:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blbd3-0006oY-00 for nemo@ietf.org; Fri, 16 Jul 2004 18:56:34 -0400 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx with esmtp (Exim 4.12) id 1BlbcD-0006UZ-00 for nemo@ietf.org; Fri, 16 Jul 2004 18:55:41 -0400 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with ESMTP id i6GMtc7h024552 for ; Fri, 16 Jul 2004 15:55:38 -0700 (PDT) Date: Fri, 16 Jul 2004 15:55:38 -0700 (PDT) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] new draft submitted X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, We have submitted a new draft on the security analysis and mechanisms of RRH, a proposed route optimization solution. Your comments are appreciated. http://www.ietf.org/internet-drafts/draft-zhao-nemo-rrh-security-00.txt Abstract: In this draft, we begin with an extensive security analysis on a NEMO RO proposal, RRH, and then propose effective security mechanisms to resist those new threats introduced by the RRH header in the nested mobile network. Thanks. fan From nemo-bounces@ietf.org Fri Jul 16 19:29: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 TAA19542 for ; Fri, 16 Jul 2004 19:29: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 1Blc5o-0003MZ-5u; Fri, 16 Jul 2004 19:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Blc53-0003F1-7X for nemo@megatron.ietf.org; Fri, 16 Jul 2004 19:25:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19218 for ; Fri, 16 Jul 2004 19:25:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blc4z-00014k-MM for nemo@ietf.org; Fri, 16 Jul 2004 19:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blc3x-0000jE-00 for nemo@ietf.org; Fri, 16 Jul 2004 19:24:21 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Blc2z-0007lS-00 for nemo@ietf.org; Fri, 16 Jul 2004 19:23:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6GNMoP06805; Fri, 16 Jul 2004 16:22:50 -0700 X-mProtect: <200407162322> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14181.americas.nokia.com (172.18.141.81, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj7KuRF; Fri, 16 Jul 2004 16:22:49 PDT Message-ID: <40F8633F.6010205@iprg.nokia.com> Date: Fri, 16 Jul 2004 16:22:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] draft-ietf-nemo-home-network-models-00 (NEMO Home Network models) References: <20040716153042.55f34df8.ernst@sfc.wide.ad.jp> In-Reply-To: <20040716153042.55f34df8.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 hi Thierry, Pascal has the xml source for the latest draft. He went on vacation yesterday. I think all of your comments can be addressed once he gets back. regarding the technical content, the draft is ready for a WG last call. Vijay Thierry Ernst wrote: > Dear draft authors, > > Here are a couple of comments on draft-ietf-nemo-home-network-models-00. > > > > - why some of the new terms (Extended Home Network) are defined in > section 1 and not in section 2 "terminology" ? (section 2 is the actual > formal definition). I would recommend to move the text in 1 after the > text in 2, and to use words easier to understand as far as the > introduction is concerned. > > - you should watch section 7 of draft-ietf-terminology, some of the > definitions have been included (to the request of the authors of the > usage draft), so they shouldn't appear in > draft-ietf-nemo-home-network-models. So, my recommendation is to remove > the entire section 2 and to move it to the terminology draft. > > - "NEMO" should always be capitalized (not Nemo) > > - should give a number to figures, and refer to them in the text. > > > #>------------------------------------------ Abstract: > > "NEMO and NEMO Design mailing lists" > -> NEMO appears 2 times > > #>------------------------------------------ Section 1 > > -> Figures or direct reference to section 4 and 5 would be useful to > describe "Extended Home Network" and "Aggregated Home Network" > > Extended Home Network: In this disposition, the Home Network is but > one subnet > -> isn't there one work missing before "but" ? > > When at Home > > -> I don't think Home should be capitalized here > > Also, it is valid for a Mobile Router to register using an address > from one of its own NEMO-Prefixes in all three cases. > > -> might be useful to say "using a **home** address". Also, I guess the > address is from an ingress iface of the MR. > > "but are by no mean at limiting its scope of application" > -> I don't think this sentence construction is correct > > #>------------------------------------------ Section 2 > > > The following terms used in this document are defined in the mobile > network terminology document [9]: > > mobile router (MR) > > mobile network > > mobile host (MH) > -> this is not exact, those terms are defined in RFC 3753 > > > > Home Link: The link attached to the interface at the Home Agent on > which the Home Prefix is configured. The interface can be a > virtual interface, in which case the Home Link is a virtual Home > Link. > -> the interface of who ? The MR ? The ingress or the egress ? > > Home Network: The Network formed by the application of the Home > Prefix on the Home Link. With NEMO, the concept of Home Network is > extended as explained below. > -> What is the "home prefix" ? Also, I think there is no need to > capitalize "network" > -> in any case, the definition is not clear to me. Shouldn't the home > network be defined as the network where the HA is located in ? I think > that in many places "home network" should be replaced with "home link". > Only the home link is meaningful to me. > > > Mobile Home Network: A Mobile Network that is also a Home Network. > The MR that own the NEMO-Prefix acts as a Home Agent for it. > -> What about "A mobile network that also serve as a home network" or "a > home networks that is also a mobile network" ? > > -> "s" missiing in "own" > > #>------------------------------------------ Section 3 > > With basic NEMO > > -> this is meaningless. Say "With NEMO Basic Support". This appears in > other places (e.g. Appendix) > > > #>------------------------------------------ Section 4 > > extended Home Network > -> you forgot to capitalize "extended" > > Home Network > -> why isn't this called "home link" ? There is only one such link. > -> to me, the home network is the network in which the HA is located. > So, the disctinction is important > > > Section 4.1: > If the Home Address of the Mobile Router is derived from one of its > Mobile Networks > -> you mean "derived from its NEMO-Prefixes (?) > > Alternate procedures for ensuring the connectivity of the Mobile > Networks when at Home are described in Section 6. In Particular, it > is > -> end of sentence is missing ! > > -> there is a section 4.1 but not section 4.2 ... > > > #>------------------------------------------ Section 5 > > -> the figure is not clear about showing the difference between "Extended Home Network" > > -> there is a section 5.1 but not section 5.2 ... > > Mobile Link > -> I don't think this as been defined. I propose to replace this with > "NEMO-link" as defined in draft-ietf-nemo-terminology > > > #>------------------------------------------ Section 6 > > or one of the prefixes of its Mobile Network(s) > -> or one of its NEMO-Prefixes > > > > Thierry. > > From nemo-bounces@ietf.org Fri Jul 16 21:03: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 VAA24537 for ; Fri, 16 Jul 2004 21:03: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 1BldUT-00074g-7k; Fri, 16 Jul 2004 20:55:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BldTE-0006wp-OT for nemo@megatron.ietf.org; Fri, 16 Jul 2004 20:54:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24147 for ; Fri, 16 Jul 2004 20:54:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BldTA-00075n-VU for nemo@ietf.org; Fri, 16 Jul 2004 20:54:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BldSC-0006mZ-00 for nemo@ietf.org; Fri, 16 Jul 2004 20:53:29 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BldRN-0006To-00 for nemo@ietf.org; Fri, 16 Jul 2004 20:52:37 -0400 Received: from [192.168.0.11] (1.182.210.220.dy.bbexcite.jp [220.210.182.1]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i6H0oi4w000611 for ; Sat, 17 Jul 2004 09:50:44 +0900 Date: Sat, 17 Jul 2004 09:55:04 +0900 From: Ryuji Wakikawa To: nemo@ietf.org Message-Id: <20040717094046.712F.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.10.04 [ja] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Route Optimization by CR X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 We submitted a new draft on providing route optimization by CR titled Optimized Route Cache Protocol (ORC). ORC is based on the similar idea to HAHA protocol. MR uses an anchor router (either HA or CR) for route optimization. ORC provides MR initiated route optimization. It includes dynamically CR discovery and dynamic binding registration depending on NEMO communication model. http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt BTW, CR was clearly explained in Pascal's RO Taxonomy draft. Your comments are appreciated. Please send comments. thanks ryuji From nemo-bounces@ietf.org Fri Jul 16 21:13: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 VAA25068 for ; Fri, 16 Jul 2004 21:13: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 1Bldjv-0000bX-BH; Fri, 16 Jul 2004 21:11:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bldhn-0000Ek-Fv for nemo@megatron.ietf.org; Fri, 16 Jul 2004 21:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24896 for ; Fri, 16 Jul 2004 21:09:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bldhj-0003mm-ML for nemo@ietf.org; Fri, 16 Jul 2004 21:09:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bldgo-0003T0-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:08:35 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bldfn-0002rs-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:07:31 -0400 Received: from [192.168.0.11] (1.182.210.220.dy.bbexcite.jp [220.210.182.1]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i6H15b4w000822; Sat, 17 Jul 2004 10:05:37 +0900 Date: Sat, 17 Jul 2004 10:09:58 +0900 From: Ryuji Wakikawa To: nemo@ietf.org Message-Id: <20040717095520.7131.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.10.04 [ja] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ryuji@sfc.wide.ad.jp, carlw@mcsr-labs.org Subject: [nemo] new ID on IPv4 Care-of Address Registration X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 again. There are several proposals (Doors, hybrid mip4/6) to live MR on IPv4 only network. However, our ID focus on reducing tunnel overhead and non infrastructural assumptions. What we assume to infrastructure is that HA has both IPv4 and IPv6 address. We believe this is reasonable assumption for HA service providers. http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-v4tunnel-00.txt Please send your comments. Thanks! ryuji From nemo-bounces@ietf.org Fri Jul 16 21:21: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 VAA25562 for ; Fri, 16 Jul 2004 21:21: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 1BldrF-00020S-Nf; Fri, 16 Jul 2004 21:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BldpW-0001l6-7n for nemo@megatron.ietf.org; Fri, 16 Jul 2004 21:17:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25303 for ; Fri, 16 Jul 2004 21:17:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BldpS-0006OP-Bd for nemo@ietf.org; Fri, 16 Jul 2004 21:17:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BldoZ-000650-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:16:36 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bldnk-0005lK-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:15:44 -0400 Received: from samurai.local.sfc.wide.ad.jp (1.182.210.220.dy.bbexcite.jp [220.210.182.1]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i6H1Dl4v000914; Sat, 17 Jul 2004 10:13:52 +0900 Date: Sat, 17 Jul 2004 10:15:41 +0900 Message-ID: From: Ryuji Wakikawa To: ernst@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] draft-ietf-nemo-home-network-models-00 (NEMO Home Network models) In-Reply-To: <40F8633F.6010205@iprg.nokia.com> References: <20040716153042.55f34df8.ernst@sfc.wide.ad.jp> <40F8633F.6010205@iprg.nokia.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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Thierry and Vijay. I agree on WG last call. We can update editorial changes after Pascal returns. regards, ryuji At Fri, 16 Jul 2004 16:22:39 -0700, vijay wrote: > > hi Thierry, > > Pascal has the xml source for the latest draft. He went on > vacation yesterday. I think all of your comments can be > addressed once he gets back. > > regarding the technical content, the draft is ready for a > WG last call. > > Vijay > > Thierry Ernst wrote: > > > Dear draft authors, > > > > Here are a couple of comments on draft-ietf-nemo-home-network-models-00. > > > > > > > > - why some of the new terms (Extended Home Network) are defined in > > section 1 and not in section 2 "terminology" ? (section 2 is the actual > > formal definition). I would recommend to move the text in 1 after the > > text in 2, and to use words easier to understand as far as the > > introduction is concerned. > > > > - you should watch section 7 of draft-ietf-terminology, some of the > > definitions have been included (to the request of the authors of the > > usage draft), so they shouldn't appear in > > draft-ietf-nemo-home-network-models. So, my recommendation is to remove > > the entire section 2 and to move it to the terminology draft. > > > > - "NEMO" should always be capitalized (not Nemo) > > > > - should give a number to figures, and refer to them in the text. > > > > > > #>------------------------------------------ Abstract: > > > > "NEMO and NEMO Design mailing lists" > > -> NEMO appears 2 times > > > > #>------------------------------------------ Section 1 > > > > -> Figures or direct reference to section 4 and 5 would be useful to > > describe "Extended Home Network" and "Aggregated Home Network" > > > > Extended Home Network: In this disposition, the Home Network is but > > one subnet > > -> isn't there one work missing before "but" ? > > > > When at Home > > > > -> I don't think Home should be capitalized here > > > > Also, it is valid for a Mobile Router to register using an address > > from one of its own NEMO-Prefixes in all three cases. > > > > -> might be useful to say "using a **home** address". Also, I guess the > > address is from an ingress iface of the MR. > > > > "but are by no mean at limiting its scope of application" > > -> I don't think this sentence construction is correct > > > > #>------------------------------------------ Section 2 > > > > > > The following terms used in this document are defined in the mobile > > network terminology document [9]: > > > > mobile router (MR) > > > > mobile network > > > > mobile host (MH) > > -> this is not exact, those terms are defined in RFC 3753 > > > > > > > > Home Link: The link attached to the interface at the Home Agent on > > which the Home Prefix is configured. The interface can be a > > virtual interface, in which case the Home Link is a virtual Home > > Link. > > -> the interface of who ? The MR ? The ingress or the egress ? > > > > Home Network: The Network formed by the application of the Home > > Prefix on the Home Link. With NEMO, the concept of Home Network is > > extended as explained below. > > -> What is the "home prefix" ? Also, I think there is no need to > > capitalize "network" > > -> in any case, the definition is not clear to me. Shouldn't the home > > network be defined as the network where the HA is located in ? I think > > that in many places "home network" should be replaced with "home link". > > Only the home link is meaningful to me. > > > > > > Mobile Home Network: A Mobile Network that is also a Home Network. > > The MR that own the NEMO-Prefix acts as a Home Agent for it. > > -> What about "A mobile network that also serve as a home network" or "a > > home networks that is also a mobile network" ? > > > > -> "s" missiing in "own" > > > > #>------------------------------------------ Section 3 > > > > With basic NEMO > > > > -> this is meaningless. Say "With NEMO Basic Support". This appears in > > other places (e.g. Appendix) > > > > > > #>------------------------------------------ Section 4 > > > > extended Home Network > > -> you forgot to capitalize "extended" > > > > Home Network > > -> why isn't this called "home link" ? There is only one such link. > > -> to me, the home network is the network in which the HA is located. > > So, the disctinction is important > > > > > > Section 4.1: > > If the Home Address of the Mobile Router is derived from one of its > > Mobile Networks > > -> you mean "derived from its NEMO-Prefixes (?) > > > > Alternate procedures for ensuring the connectivity of the Mobile > > Networks when at Home are described in Section 6. In Particular, it > > is > > -> end of sentence is missing ! > > > > -> there is a section 4.1 but not section 4.2 ... > > > > > > #>------------------------------------------ Section 5 > > > > -> the figure is not clear about showing the difference between "Extended Home Network" > > > > -> there is a section 5.1 but not section 5.2 ... > > > > Mobile Link > > -> I don't think this as been defined. I propose to replace this with > > "NEMO-link" as defined in draft-ietf-nemo-terminology > > > > > > #>------------------------------------------ Section 6 > > > > or one of the prefixes of its Mobile Network(s) > > -> or one of its NEMO-Prefixes > > > > > > > > Thierry. > > > > > From nemo-bounces@ietf.org Fri Jul 16 21:47:28 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 VAA26598 for ; Fri, 16 Jul 2004 21:47: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 1BleEX-00058K-L2; Fri, 16 Jul 2004 21:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BleDj-00051w-84 for nemo@megatron.ietf.org; Fri, 16 Jul 2004 21:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26350 for ; Fri, 16 Jul 2004 21:42:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BleDf-0006Dj-E3 for nemo@ietf.org; Fri, 16 Jul 2004 21:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BleCj-0005uY-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:41:33 -0400 Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1BleBo-0005ah-00 for nemo@ietf.org; Fri, 16 Jul 2004 21:40:37 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id CA14D61F6 for ; Fri, 16 Jul 2004 18:40:02 -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 67419-09 for ; Fri, 16 Jul 2004 18:40:01 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id A806761F2; Fri, 16 Jul 2004 18:40:01 -0700 (PDT) Received: from [192.103.17.194] (unknown [192.103.17.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id D2F4C61B5 for ; Fri, 16 Jul 2004 18:39:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) To: IETF NEMO WG Message-Id: <4515932A-D792-11D8-92D7-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-52073523; protocol="application/pkcs7-signature" From: "T.J.Kniveton" Date: Fri, 16 Jul 2004 18:40:23 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: -1.8 X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] home-network-models grammar & spelling X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-7-52073523 Content-Type: multipart/mixed; boundary=Apple-Mail-6-52073431 --Apple-Mail-6-52073431 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Here are some suggestions on grammar and spelling changes to the draft. I will just attach my edited version, and you can diff it against the existing version. My comments are in [brackets]. General comments: The document is generally good. However, I find that in parts it is a bit vague, and doesn't give enough motivation to help people decide which, and more importantly, why, they should choose a particular configuration. I tried to make comments in-line in these cases. Since parts of the draft deal with address management and allocation issues, the draft walks a line between Informational and BCP (which I find a bit strange, since there are very few, and no commercial, deployments at this point from which we could deduce these BCPs. Thus, we need some more experience to have a really authoritative document on this subject. Maybe it's just me, but I had a hard time parsing much of the document. I had to read certain sections multiple times, and was still left with ambiguities in my mind regarding what was meant. Since there are many examples of what you "may" do, but not much guidance as to which you should pick, I, as an implementor, would have a hard time taking much information from the document until *after* I had already figured out which type of network to set up at home. By that point, I probably wouldn't need the assistance of this document because I would have figured it out. However, I do like the examples you show, and I think they are useful in the implementation process. --Apple-Mail-6-52073431 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-nemo-home-network-models-00-tj1.txt" Content-Disposition: attachment; filename=draft-ietf-nemo-home-network-models-00-tj1.txt Content-Transfer-Encoding: quoted-printable Network Mobility P. Thubert Internet-Draft Cisco Systems Expires: September 30, 2004 R. Wakikawa Keio University V. Devarapalli Nokia April 1, 2004 NEMO Home Network models draft-ietf-nemo-home-network-models-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers that conform the NEMO Basic Support draft [7]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the NEMO and NEMO Design Team mailing lists. Thubert, et al. Expires September 30, 2004 [Page 1] =0C Internet-Draft Home Network models with NEMO basic April 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 6 4. Extended Home Network . . . . . . . . . . . . . . . . . . . . 7 4.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Aggregated Home . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 11 7. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Changes from version 00 to 01 . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 A. Returning Home emulation in the virtual case . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Thubert, et al. Expires September 30, 2004 [Page 2] =0C Internet-Draft Home Network models with NEMO basic April 2004 1. Introduction This document assumes that the reader is familiar with Mobile IPv6 = [6], and with the concept of Mobile Router defined in the NEMO terminology document [9]. Four different organizations of the Home Network, including a hierachical construction, are documented: Extended Home Network: In this disposition, the Home Network is but one subnet of a larger aggregation that encompasses the Mobile Networks, called extended Home Network. When at Home, a Mobile Router performs normal routing between the Home Link and the Mobile Networks. [The above paragraph does not define, to my mind, what an extended home = network is. it's almost self-referential. I suggest re-wording it.] Aggregated Home Network: In this disposition, the Home Network actually overlaps with the Mobile Networks. When at Home, a Mobile Router acts as a bridge between the Home Link and the Mobile Networks. Virtual Home Network: In this disposition, there is no physical Home Link at all for the Mobile Routers to come back home to. [Then = what is there? elaborate.] Mobile Home Network: In this disposition, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent and further delegated into Mobile Networks of shorter prefix and the same high-order bits. = Each subnet is owned by a Mobile Router that registers it using the NEMO protocol and acts as a Home Agent for that network. [Isn't the word "subnet" deprecated in IPv6?] In all cases, the Home Agents collectively advertise only the aggregation of the Mobile Networks, rather than each individual = prefix. The dichotomy is kept within the Home Agents and the Mobile Routers, as opposed to advertised by means of routing protocols to other parties. It is also valid for a Mobile Router to register [to what? what kind = of registration?] using an address from one of its own NEMO-Prefixes in all three cases. The examples provided here illustrate configurations of the NEMO = Basic Support draft [7], but are not meant to limit its scope of application. Thubert, et al. Expires September 30, 2004 [Page 3] =0C Internet-Draft Home Network models with NEMO basic April 2004 2. Terminology and concepts The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119 [5]. The following terms used in this document are defined in the IPv6 Addressing Architecture document [4]: link-local unicast address link-local scope multicast address The following terms used in this document are defined in the mobile IPv6 specification [6]: home agent (HA) The following terms used in this document are defined in the mobile network terminology document [9]: mobile router (MR) mobile network mobile host (MH) This draft uses the following additional or modified terminology: Home Link: The link attached to the interface at the Home Agent on which the Home Prefix is configured. The interface can be a virtual interface, in which case the Home Link is a virtual Home Link. Home Network: The Network formed by the application of the Home Prefix on the Home Link. With NEMO, the concept of Home Network is extended as explained below. Home Address: With Mobile IPv6, a Home Address is derived from the Home Network prefix. This is generalized in NEMO, with some limitations: A Home Address can be either derived from the Home Network or from one of the Mobile Router's NEMO-prefixes. MRHA Tunnel: The bi-directional tunnel between a Mobile Router and its Home Agent Thubert, et al. Expires September 30, 2004 [Page 4] =0C Internet-Draft Home Network models with NEMO basic April 2004 Mobile Aggregated Prefix: An aggregation of NEMO-Prefixes. Aggregated Home Network: The Home Network associated with a Mobile Aggregated Prefix. This Aggregation is advertised as a subnet on the Home Link, and thus used as Home Network for NEMO purposes. Extended Home Network: The network associated with the aggregation of one or more Home Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home Network that is a subnet, the extended Home Network is an aggregation and is further subnetted. Virtual Home Network: The Home Network associated with a Virtual Network. The Extended Home Network and the Aggregated Home Network can be configured as Virtual Home Network. Mobile Home Network: A Mobile Network that is also a Home Network. The MR that owns the NEMO-Prefix acts as a Home Agent for it. Thubert, et al. Expires September 30, 2004 [Page 5] =0C Internet-Draft Home Network models with NEMO basic April 2004 3. General Expectations With Mobile IPv6, the Home Network is generally a physical network interconnecting the Home Agents and the Mobile Nodes that are at Home. NEMO extends the concept of Home so that it is not only a flat subnet composed of Home Addresses but an aggregation that is itself divided into mobile and Home Networks. This aggregation is still referred to as Home. As an example, say that the aggregation has a global routing prefix of m =3D 48 bits (A:B:C::/48), with subnet ID size of n =3D 16 bits ( = n + m =3D 64). [Wouldn't this be the *host* ID and not the subnet ID, which is 16 bits? = The subnet (prefix) is the 48 bit part.] Say that a Mobile Router, MR1, owns the NEMO-Prefix A:B:C:1::/64. With basic NEMO, and depending on the deployment, MR1 may register using a Home Address from the Home network, A:B:C:0::1, or a Home Address, A:B:C:1::1, from one of its NEMO-Prefixes. In a given deployment, one subnet may be reserved for the Home Link (e.g. A:B:C:0::/64) while the others are attributed to Mobile Routers as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be to configure the Aggregation of Mobile Networks as the subnet on the Home Link, and let the Mobile Routers manage the overlapping networks. Finally, the aggregation could be configured on a virtual network, with no physical Home Link at all, in which case Home means topologically and administratively close to the Home Agent that owns the virtual network. The following sections provide additional information on these forms of Home Network: Thubert, et al. Expires September 30, 2004 [Page 6] =0C Internet-Draft Home Network models with NEMO basic April 2004 4. Extended Home Network One simple approach can be to reserve one or several subnets from an aggregation for the Home Link, and to use the other subnets as NEMO-Prefixes. In that case, the Home Network and the Mobile Networks do not overlap. The aggregation is called an extended Home Network. | route v /48 A:B:C::/48 HA | /64 A:B:C:0::/64 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN /64 /64 /64 /64 A:B:C:i::/64 0 < i <=3D N < = 256 extended Home Network <-----------------------------------------------------------> Home Net Mobile Net Mobile Net ... Mobile Net <------------><------------><------------> ... <------------> In that configuration: o There is one physical Home Network and multiple Mobile Networks o The Home and the NEMO-prefixes are tailored to allow for IPv6 Stateless Address Autoconfiguration with typical interface identifier length for the type of interface (can be for example / 64). o The prefix length of the extended Home Network is shorter than that of the Home Network and the NEMO-prefixes, since it is an aggregation (can be for example /48). o The Mobile Routers are assigned individually a Home Address from the Home Network and use is to register their NEMO-Prefix(es). In that case, the Home Agent performs DAD in the Home Network as prescribed by Mobile IPv6 for the Home Addresses. o Alternatively, a Mobile Router could also form a Home Address from one of its prefixes and use it to register, performing DAD on its ingress network. [I haven't heard the term ingress network before. Can we say ingress = interface?] Thubert, et al. Expires September 30, 2004 [Page 7] =0C Internet-Draft Home Network models with NEMO basic April 2004 4.1 Returning Home In the extended Home Network model, the Home Network is configured on a physical interface of the Home Agent, the Home Link. A Mobile Router returns Home by connecting directly to the Home Link, and dropping the MRHA tunnel. At that point, the MR does not = participate in the routing of packets to the Mobile Network; the Home = Agent takes over this responsibility. If the Home Address of the Mobile Router is derived from one of its Mobile Networks, then the MR may connect to the Home Link using an egress interface and autoconfigure an address on the Home Link. The MR recognizes the prefix of its Home Agent in order to decide that it is Home. Note that in that case the Home Address does not match the Home Prefix. [What is the point of this? Seems overly complicated.] When at Home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations. [This isn't true in some of the scenarios you describe in this = document.] In particular, if the HA has the necessary information to continue routing to the NEMO-Prefixes in the absence of MR-HA registration, = for instance if the Home Address of the Mobile Router is derived from the Home Network, and if the HA uses a static route to the NEMO-Prefix(es) via that address, then the participation of the MR to the Home IGP is not required. [This sentence should be split into 2 or 3.] [This is the first time you mention IGP. It is not defined; there are no = normative references. This should be fixed.] But in the general case, when the MR is at Home, it resumes IGP operations on the Home Link in order to advertise its Mobile Networks. [I have no context to be able to understand the above statement.] Alternate procedures for ensuring the connectivity of the Mobile Networks when at Home are described in Section 6. In particular, it is [There is some text missing here.] Thubert, et al. Expires September 30, 2004 [Page 8] =0C Internet-Draft Home Network models with NEMO basic April 2004 5. Aggregated Home One other approach is to consider that the Aggregation of all the NEMO-prefixes is used plainly as the Home Network, refered to as the Aggregated Home Network. This means that the Mobile Aggregated Prefix is configured on the Home Link and advertised by the Home Agent as a subnet. [prefix?] HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <=3D N Aggregated Home <-----------------------------------------------------------> Mobile Net Mobile Net Mobile Net ... Mobile Net <------------><------------><------------> ... <------------> Note: a Mobile Router coming Home sees overlapping prefixes between the ingress and the egress interface and some specific support may be needed. A node on the Home Link will compute that the Aggregated Home Network is actually a subnet on the Home Link and may use it for autoconfiguration purposes. Such a node may also install a connected route to the Aggregated Home Network over the Home Link. As a result, unless the node has a better (longest match) route to a given NEMO-Prefix, it will lookup all MNNs using Neighbor Discovery over the Home Link. Thus, the Home Agent MUST intercept all the packets to MNNs on the registered prefixes [what are "registered prefixes"?]. In order = to do so, the Home Agent MAY perform ND proxying for all addresses in all registered Mobile Network Prefixes, and protect the NEMO-Prefix space from autoconfiguration by uncontrolled visitors on the Home Link. Alternatives based on a routing protocol or ICMP redirect may apply in some cases. Thubert, et al. Expires September 30, 2004 [Page 9] =0C Internet-Draft Home Network models with NEMO basic April 2004 5.1 Returning Home The Aggregated Home Prefix is configured on a physical interface of the Home Agent, the Home Link. As a consequence, the Home Agent has a connected route to the Aggregated Home Network over the Home Link. A Mobile Router returns Home by connecting directly to the Home Link, and dropping the MRHA tunnel. The Mobile Router recognizes its Home Link by a prefix match with its Home Agent. Note that it must expect a shorter prefix than that of its Mobile Networks, even if its Home Address is formed out of one of its NEMO-Prefixes, but that the Home Address matches the Home Network Prefix. [split into 2 sentences] When a Mobile Router connects to the Home Link using its egress interface, it MAY set up a bridge between its ingress interface(s) and the Home Link. Alternatively, the Mobile Router MAY perform ND proxying for all addresses in its NEMO-Prefixes, between the egress and the related ingress interface. Since the prefixes on the egress and ingress interfaces are overlapping, routing is disallowed. HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <=3D= N Bridging between egress and ingress Alternatively, if the MR has a single ingress Interface, the Mobile Router may use the Mobile Link to connect to the Home Link, merging the two links in a single consistent network. HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- /64 /64 /64 /64 Aggreg|i /64 0 < i <=3D= N ------ ------ ------ ------ MR1 MR2 MRi MRN | | | | Merging the Home and the Mobile Networks This fits the connected route model, since the Aggregated Home is truly located on that network. Thubert, et al. Expires September 30, 2004 [Page 10] =0C Internet-Draft Home Network models with NEMO basic April 2004 6. Virtual Home Network The Home Link can be configured on the Home Agent on a virtual link, in which case there's no physical Home Link for Mobile Routers to return Home or for Home Agents to discover each others and perform the ND level interactions as described in Mobile IPv6. [6] /48 eg: A:B:C::/48 HA | /64 A:C:C:E::/64 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN /64 /64 /64 /64 A:B:C:i::/64 0 < i <=3D= N Virtual Home Network The Extended Home network and the Aggregated Home network models can be adapted for virtual links. There is no change in the way Home Addresses are allocated. As in the case of a physical link, the Home Address of a Mobile router is constructed based on the Home Prefix or one of the prefixes of its Mobile Network(s). There are certain advantages to making the Home Link a virtual link: A virtual link may not experience any disruption related to physical maintenance or to hardware problems, so it is more available than a physical link. The high availability of the Home Link is critical for the mobility service. [I disagree. A virtual home link is exactly available, in terms of L2 = connectivity, as a home link which is broken and down 100% of the time. = The only exception is if the OS does not allow prefixes to be assigned = to a link that does not have an L1 connection, which are rare.] The Home Agent does not have to defend the Mobile Router's Home Address through Proxy Neighbor Discovery. The Home Agent does not also have to perform Duplicate Address Detection (DAD) for the Mobile Router's Home Address when it receives a Binding Update from the Mobile Router. The Mobile Router does not have to implement the Returning Home procedure (section 11.5.4 of Mobile IPv6. [6]). In order for a Mobile Router to emulate returning Home, it can connect to one or more access link(s) configured for that purpose on the Home Agent. The Mobile Router, after connecting to the access link, SHOULD not send any routing protocol updates on the egress interface because the routing information from the Mobile Router Thubert, et al. Expires September 30, 2004 [Page 11] =0C Internet-Draft Home Network models with NEMO basic April 2004 might adversely affect IPv6 route aggregation on the Home Network. However, the Mobile Router must register its binding as if it was accessing a foreign link. [What is the point of this? How is the MR supposed to distinguish these = links from any other access links? Do they use some special prefix?] There are also some drawbacks to the virtual Home Link approach: There can be only one Home Agent since Mobile IPv6 relies on Neighbor Discovery on the Home Link for other HA discovery and for Duplicate Address Detection. The Home Agent must maintain a Binding Cache entry for a Mobile Router and forwarding state for its Mobile Network even when the Mobile Router is directly connected to it. All traffic to and from the Mobile Network is sent through the bi-directional tunnel regardless of the Mobile Router location. This results in a tunneling overhead even though the Mobile Router is connected to the Home Network. Some solutions can be proposed in order to perform an equivalent of returning Home on a virtual Home Network. One such approach is sketched in Appendix [which appendix? A? B?] as an illustration. Thubert, et al. Expires September 30, 2004 [Page 12] =0C Internet-Draft Home Network models with NEMO basic April 2004 7. Mobile Home In this disposition, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent(s) and further subnetted into Mobile Networks. As a result, only the Home Agent(s) responsible for the most global (shortest prefix) aggregation receive all the packets for all the NEMO-prefixes, which are leaves in the hierarchy tree. Each subnet is owned by a Mobile Router that registers it using NEMO while acting as a Home Agent for that network. This Mobile Router is at Home at the uppermost level of hierarchy. This = configuration is referred to as Mobile Home. An example of that is the Cab Co configuration. Say a Taxi Company owns a /32 prefix. This prefix is advertised at a fixed point, the Headquarters. Regional offices are deployed around the world. Even though these regional offices are relatively stable in terms of location and prefix requirement--this changes every few years-- making them mobile allows a simpler management when a move has to take place, or should the ISP service change. Finally, each regional office owns a number of taxis, each one equipped with a mobile router and an associated /64 prefix. To illustrate this, here is a possible addressing scheme: global Home Network CAB:C0::/32 owned by HQ = <-------------------------------------------------------------------> HQ extended Home Net Mobile Home for SFO office (casa) CAB:C0:CA5A::/48 CAB:C0:5F0::/48 <----------------------------> ... = <--------------------------------> | Home for offices HQ | CAB:C0:CA5A:CA5A::/64 MN | <----------------------><----> | CAB:C0:CA5A:CA5A::CA5A | CAB:C0:CA5A:CA5A::CA5B | are HAs on link with for each office a route like | | CAB:C0:CA5A:CA5A::5F0 <---------------------- via is the Home addr of SFO office Thubert, et al. Expires September 30, 2004 [Page 13] =0C Internet-Draft Home Network models with NEMO basic April 2004 and recursively for each Office, say San Francisco (SFO) as example: Mobile Home Network CAB:C0:5f0::/48 owned by SFO office <------------------------------------------------------------------> HQ Home Network Mobile Networks for taxis for offices CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/6 <-------------------><-------------------> ... <-------------------> CAB:C0:5F0:5F0::5F0 | is HA on link with for | each taxi a route like | | CAB:C0:5F0:5F0::CAB1 <------ via is the Home addrSsync of CAB 1 [what is addrSsync?] Note that the hierarchy occurs at a configuration level and may not be reflected in the actual connection between nodes. For instance in the Cab Co case, cabs are roaming within the city, each one attaching to a different hot spot, while the regional office is connected to the infrastructure using its own ISP connection. But it is also possible to reflect the organizational hierarchy in a moving cloud of the Mobile Router. If a Mobile Home Agent acts as = root-MR for a nested configuration of its own MRs, then the communication between MRs is confined within the nested structure. This can be illustrated in the case of a fleet at sea. Say that now SFO is a communication ship of a fleet, using a satellite link to join the infrastructure, and that the cabs are Mobile Routers installed on smaller ships, equipped with short-range radios. If SFO is also the root-MR of a nested structure of cabs, the communication between cabs is relayed by SFO and does not require the satellite link. SFO recursively terminates the nested tunnels to the cabs and reencapsulates all the packets between the nested cloud and correspondents in the infrastructure in a single tunnel to CA5A, this providing for nested NEMO Route Optimization. [Cognitive disconnect: you just told me to imagine SFO being a comm = ship, and each cab as a small ship. Then, in the following paragraph, = you go back to the cab metaphor.] Thubert, et al. Expires September 30, 2004 [Page 14] =0C Internet-Draft Home Network models with NEMO basic April 2004 8. Changes from version 00 to 01 Added Mobile Home Section Thubert, et al. Expires September 30, 2004 [Page 15] =0C Internet-Draft Home Network models with NEMO basic April 2004 9. Acknowledgements The authors wish to thank: Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick Wetterwald and Alexandru Petrescu for their contributions. References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. [7] Devarapalli, V., "Nemo Basic Support Protocol", draft-ietf-nemo-basic-support-02 (work in progress), December 2003. [8] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02 (work in progress), February 2004. [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004. [10] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004. Thubert, et al. Expires September 30, 2004 [Page 16] =0C Internet-Draft Home Network models with NEMO basic April 2004 Authors' Addresses Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 FRANCE EMail: pthubert@cisco.com Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN EMail: ryuji@sfc.wide.ad.jp Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA EMail: vijay.devarapalli@nokia.com Thubert, et al. Expires September 30, 2004 [Page 17] =0C Internet-Draft Home Network models with NEMO basic April 2004 Appendix A. Returning Home emulation in the virtual case When a Home Link is virtual, all traffic to and from the Mobile Network is sent through the bi-directional tunnel even at the Home Link. This section describes one possible mechanism that extends basic NEMO to eliminate this tunneling overhead. Although the Home Link is virtual, the Home Agent has at least one physical link to communicate with the external world. One or several of such links, called the virtual Home Access Links, are conceptually associated with the virtual Home Link and considered as part of Home. When accessing one of its virtual Home Access Links, a Mobile Router autoconfigures a Care-of Address from a Router Advertisement as it would do on any visited link, in order to perform the next binding flow. If the Mobile Router is configured to recognize the virtual Home Access Links as part of Home, it deregisters by sending a Binding update with null lifetime sourced at the CareOf. Alternatively, the Home Agent may indicate that the MR has moved to the virtual Home Access Links as a status code in the binding acknowledgement. The status code implies that Home Agent successsful de-register the binding at the virtual Home Access Link. Detection of the virtual Home Access Links is achieved by a prefix comparison(s) between the care-of address and the prefix(es) on the virtual Home Access Link(s). With both approaches, the result of the binding flow is a deregistration. Consequently, both the Mobile Router and the Home Agent disable the bi-directional tunnel. At that point, the Home Agent configures its forwarding in order to reach the Mobile Router and its mobile networks at Home. For instance, this may take the form of a route to the Mobile Network prefixes via the MR Home Address, and a connected host route to the MR Home Address via the virtual Home Access link. After successful binding de-registration, the Mobile Router MUST receive packets meant to the Mobile Router's Home Address at the Virtual Home Link. How to intercept packets addressed to the Home Address depends on implementations of the Mobile Router. If the Home Address is not configured at the egress interface, the Mobile Router MUST use proxy Neighbor Discovery to intercept all packets addressed to the Home Address on the virtual Home Link. Otherwise, the Mobile Router does not have to perform any special operation at the virtual Home Link. Thubert, et al. Expires September 30, 2004 [Page 18] =0C Internet-Draft Home Network models with NEMO basic April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Thubert, et al. Expires September 30, 2004 [Page 19] =0C Internet-Draft Home Network models with NEMO basic April 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thubert, et al. Expires September 30, 2004 [Page 20] =0C --Apple-Mail-6-52073431 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit TJ --Apple-Mail-6-52073431-- --Apple-Mail-7-52073523 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNzAxNDAy M1owIwYJKoZIhvcNAQkEMRYEFOWk77mlrJsmqOV4tbnqyVO7Bew3MIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBp0j8wxFwcfkkMvl7Jkxff4f5/40f6uPx3KyPMDbqp9 XmDLqmxqZgXl6RDcG5UaEmDpaSb2XLnGvy/1A6STW+8g1fsLbeW5+TUhQ1h5/3iAe/TaFXLGvb0j 1ZyDEXPUjwzdXzg1dG1qRSPzoo8P3pUSqNxJYBt3oCW+Bz9TgYG/AAAAAAAA --Apple-Mail-7-52073523-- From nemo-bounces@ietf.org Sat Jul 17 14:44: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 OAA00161 for ; Sat, 17 Jul 2004 14:44: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 1Blu88-0003Xi-K0; Sat, 17 Jul 2004 14:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Blu5a-0003G2-Db for nemo@megatron.ietf.org; Sat, 17 Jul 2004 14:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29940 for ; Sat, 17 Jul 2004 14:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Blu5Z-0007n5-9z for nemo@ietf.org; Sat, 17 Jul 2004 14:39:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Blu4d-0007XW-00 for nemo@ietf.org; Sat, 17 Jul 2004 14:38:16 -0400 Received: from [203.253.31.197] (helo=ssu.ac.kr) by ietf-mx with smtp (Exim 4.12) id 1Blu3p-0007HQ-00 for nemo@ietf.org; Sat, 17 Jul 2004 14:37:26 -0400 Received: from ssu.ac.kr by ietf.org with ESMTP (BeeHive 1.4.1) for nemo@ietf.org; Sun, 18 Jul 2004 03:37:20 +0900 Message-ID: <001801c46c2d$1687c060$9501a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: Date: Sun, 18 Jul 2004 03:37:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C46C78.85E46670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT autolearn=no version=2.60 Subject: [nemo] a 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 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C46C78.85E46670 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgcmVsYXRlZCB0byBtdWx0aWhv bWluZyBpc3N1ZXMgdG8gdGhlIE1JUDYgV0csIGJ1dCBpdCBtaWdodCBiZSBpbnRlcmVzdGVkIHRv IHRoZSBORU1PIFdHIHRvby4gQW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCB3aWxsIGJlIGFwcHJl Y2lhdGVkLiBUaGFua3MuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWhvbmctbWlwNi1tdWx0aWhvbWluZy1zY2VuYXJpb3MtMDAudHh0DQoNClNvdWh3YW4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KU291aHdhbiBKdW5nDQpBc3NvY2lhdGUgUHJvZmVzc29yICAgICAgICAgICAgICAgICAgICAg IGVtYWlsOnNvdWh3YW5qQHNzdS5hYy5rcg0KU2Nob29sIG9mIEVsZWN0cm9uaWMgRW5naW5lZXJp bmcgICAgIHBob25lOiArODItMi04MjAtMDcxNA0KU29vbmdzaWwgVW5pdmVyc2l0eSAgICAgICAg ICAgICAgICAgICAgICAgICBmYXg6ICs4Mi0yLTgyMS03NjUzDQoxLTEgU2FuZ2RvLWRvbmcsIERv bmdqYWsta3UsIA0KU2VvdWwgMTU2LTc0Mw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 ------=_NextPart_000_0015_01C46C78.85E46670 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+RGVhciBhbGwsPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5XZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHJlbGF0ZWQgdG8g bXVsdGlob21pbmcgaXNzdWVzIHRvIHRoZSBNSVA2IFdHLCBidXQgDQppdCBtaWdodCBiZSZuYnNw O2ludGVyZXN0ZWQgdG8gdGhlIE5FTU8gV0cgdG9vLiBBbnkgY29tbWVudHMgb24gdGhlIGRyYWZ0 IHdpbGwgDQpiZSBhcHByZWNpYXRlZC4gVGhhbmtzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1ob25nLW1pcDYtbXVsdGlob21pbmctc2NlbmFyaW9zLTAwLnR4dCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9uZy1taXA2LW11bHRpaG9taW5nLXNjZW5hcmlv cy0wMC50eHQ8L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Tb3Vod2FuPC9ESVY+ DQo8RElWPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxCUj5Tb3Vod2FuIA0KSnVuZzxCUj5Bc3NvY2lhdGUgDQpQcm9mZXNzb3ImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQplbWFpbDpzb3Vod2FuakBzc3UuYWMua3I8QlI+U2Nob29sIG9mIEVsZWN0cm9u aWMgDQpFbmdpbmVlcmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaG9uZTogKzgyLTItODIw LTA3MTQ8QlI+U29vbmdzaWwgDQpVbml2ZXJzaXR5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KZmF4OiArODItMi04MjEtNzY1MzxCUj4xLTEgU2FuZ2RvLWRvbmcsIERvbmdqYWsta3Us IDxCUj5TZW91bCANCjE1Ni03NDM8QlI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0015_01C46C78.85E46670-- From nemo-bounces@ietf.org Mon Jul 19 06:33: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 GAA02508 for ; Mon, 19 Jul 2004 06:33: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 1BmVP4-00048L-MQ; Mon, 19 Jul 2004 06:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmVNM-00041s-3Y for nemo@megatron.ietf.org; Mon, 19 Jul 2004 06:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02132 for ; Mon, 19 Jul 2004 06:28:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmVNJ-0005Dg-C1 for nemo@ietf.org; Mon, 19 Jul 2004 06:28:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmVMY-0004zk-00 for nemo@ietf.org; Mon, 19 Jul 2004 06:27:14 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BmVLr-0004iR-00 for nemo@ietf.org; Mon, 19 Jul 2004 06:26:31 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 65FD52760D; Mon, 19 Jul 2004 11:27:55 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 4EBA12760B; Mon, 19 Jul 2004 11:27:55 +0200 (CEST) In-Reply-To: <20040712184738.62b08869.ernst@sfc.wide.ad.jp> References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3C174B4E-D96E-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Draft Agenda and CFP Date: Mon, 19 Jul 2004 12:27:28 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: nemo , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Thierry, T.J., El 12/07/2004, a las 11:47, Thierry Ernst escribi=F3: > > > 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 > When did the last call ended? i couldn't find it in the archives... i sent some comments a while ago, but i didn't receive any answer You can find them at: http://www1.ietf.org/mail-archive/web/nemo/current/msg00910.html regards, marcelo > - 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. > > From nemo-bounces@ietf.org Mon Jul 19 19:50: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 TAA10333 for ; Mon, 19 Jul 2004 19:50: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 1BmhNg-00033r-EI; Mon, 19 Jul 2004 19:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmf1o-0003FF-OG for nemo@megatron.ietf.org; Mon, 19 Jul 2004 16:46: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 QAA01839 for ; Mon, 19 Jul 2004 16:46:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmez1-0002lJ-Gv for nemo@ietf.org; Mon, 19 Jul 2004 16:43:38 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BmdiI-00019K-Om for nemo@ietf.org; Mon, 19 Jul 2004 15:22:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6JJINa17701; Mon, 19 Jul 2004 12:18:23 -0700 X-mProtect: <200407191918> 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 smtpd1IQ5xx; Mon, 19 Jul 2004 12:18:21 PDT Message-ID: <40FC1FF6.7060305@iprg.nokia.com> Date: Mon, 19 Jul 2004 12:24:38 -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: "T.J.Kniveton" Subject: Re: [nemo] home-network-models grammar & spelling References: <4515932A-D792-11D8-92D7-000A95DA08F2@kniveton.com> In-Reply-To: <4515932A-D792-11D8-92D7-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 hi TJ, thanks for reviewing the document. I will try to address a few of your comments. T.J.Kniveton wrote: > Since parts of the draft deal with address management and allocation > issues, the draft walks a line between Informational and BCP (which I > find a bit strange, since there are very few, and no commercial, > deployments at this point from which we could deduce these BCPs. Thus, > we need some more experience to have a really authoritative document on > this subject. I agree. it is definitely is not a BCP. > > Maybe it's just me, but I had a hard time parsing much of the document. > I had to read certain sections multiple times, and was still left with > ambiguities in my mind regarding what was meant. Since there are many > examples of what you "may" do, exactly. it describes various way of configuring the home link for NEMO support. it also suggests "returning home" procedures for each case. > but not much guidance as to which you > should pick, we werent going to do that. just list them all and describe the pros and cons. do you think we should? it would be very hard to get WG concensus on that. > Virtual Home Network: In this disposition, there is no physical Home > Link at all for the Mobile Routers to come back home to. [Then what is there? elaborate.] it is supposed to say, the home link is virtual. will fix this. > > Mobile Home Network: In this disposition, there is a bitwise > hierarchy of Home Networks. A global Home Network is advertised to > the infrastructure by a head Home Agent and further delegated into > Mobile Networks of shorter prefix and the same high-order bits. Each subnet is owned by a Mobile Router that > registers it using the NEMO protocol and acts as a Home Agent for > that network. > [Isn't the word "subnet" deprecated in IPv6?] havent heard about this. can you provide a reference to this? 2461bis and 2462bis still talk about "subnets". > > As an example, say that the aggregation has a global routing prefix > of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + > m = 64). > [Wouldn't this be the *host* ID and not the subnet ID, which is 16 bits? The subnet (prefix) is the 48 bit part.] in the above example interface ID is 64 bits, subnet ID is 16 bits and the prefix is 48 bits. the following is from RFC 3513. 2.5.4 Global Unicast Addresses The general format for IPv6 global unicast addresses is as follows: | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ > > o Alternatively, a Mobile Router could also form a Home Address from > one of its prefixes and use it to register, performing DAD > on its ingress network. > [I haven't heard the term ingress network before. Can we say ingress interface?] agreed. > 4.1 Returning Home > > In the extended Home Network model, the Home Network is configured on > a physical interface of the Home Agent, the Home Link. > > A Mobile Router returns Home by connecting directly to the Home Link, > and dropping the MRHA tunnel. At that point, the MR does not participate in the routing of packets to the Mobile Network; the Home Agent takes over this responsibility. > > If the Home Address of the Mobile Router is derived from one of its > Mobile Networks, then the MR may connect to the Home Link using an > egress interface and autoconfigure an address on the Home Link. The > MR recognizes the prefix of its Home Agent in order to decide that it > is Home. Note that in that case the Home Address does not match the > Home Prefix. > [What is the point of this? Seems overly complicated.] the NEMO basic support allows the MR to configure a HoA from its Mobile Network Prefix (NEMO-prefix). the above only tries to explain the returning home procedure for such a case. > Thus, the Home Agent MUST intercept all the packets to MNNs on > the registered prefixes [what are "registered prefixes"?]. those prefixes that the MR included in the Binding Update to the Home Agent. but I agree, it needs to be clarified. > There are certain advantages to making the Home Link a virtual link: > > A virtual link may not experience any disruption related to > physical maintenance or to hardware problems, so it is more > available than a physical link. The high availability of the Home > Link is critical for the mobility service. > > [I disagree. A virtual home link is exactly available, in terms of L2 connectivity, as a home link which is broken and down 100% of the time. The only exception is if the OS does not allow prefixes to be assigned to a link that does not have an L1 connection, which are rare.] I agree. Ryuji, Pascal? Vijay From nemo-bounces@ietf.org Tue Jul 20 06: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 GAA06268 for ; Tue, 20 Jul 2004 06: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 1BmrmL-0008FE-9y; Tue, 20 Jul 2004 06:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmrkd-0007Ve-LO for nemo@megatron.ietf.org; Tue, 20 Jul 2004 06:21: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 GAA05943 for ; Tue, 20 Jul 2004 06:21:32 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmrkk-0005ck-4u for nemo@ietf.org; Tue, 20 Jul 2004 06:21:43 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A7C222A021; Tue, 20 Jul 2004 12:22:33 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 8583A29E0E; Tue, 20 Jul 2004 12:22:33 +0200 (CEST) In-Reply-To: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Date: Tue, 20 Jul 2004 12:22:32 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Some comments about this draft... - General comment: Is this draft about IPv4 or IPv6 or both? I mean, i =20= think that there are lots of IPv6 specific points, but there are also =20= some IPv4 considerations (or at least that how i understand it, for =20 instance the case of reference [9] perhaps?). Perhaps explicitly =20 stating in the introduction the IP protocol version considered could be =20= helpful - Section 2. I am not sure how valuable is to include the discussion about whether =20= the MNNs are multihomed or not. I mean, this is basically a study on =20 the mobile network, i don't think that host multihoming issues are =20 interesting. Moreover, i don't agree that a node with multiple =20 addresses can be called a multihomed node, imho this is a node within a =20= multihomed network in many cases. What does "companion document" means? (same question for the document =20= referred in section 3) Should these docs be considered part of this =20 spec? - Section 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix The (1,n,1) mobile network has only one MR advertising a single NEMO-prefix. The MR, however, is associated to multiple HAs, possibly one HA per Home Address, or one HA per egress interface. = No assumption is made on whether or not the HAs belongs to the same administrative domain (it may be justified to locate HAs in = distinct ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical Prefix from a Different Origin] [9]) I don't understand the case where there is a single prefix and multiple =20= HAs placed in different administrative domains. I mean, if the HAs are =20= in different administrative domains, they will have different prefixes, =20= so there will be multiple nemo-prefixes in the nemo. The case =20 considered in reference [9] is about the same prefix that it is =20 announced with different ASN as origin. This can be AFAIU, because the =20= announcing site don't have its own ASN, so the prefix is announced with =20= the provider's ASN, but i don't think that this case is related to the =20= topic here considered. Bottom line is that i don't see that the case where there is a single =20= nemo prefix with multiple HAs in different administrative domains makes =20= much sense. I would suggest to remove The last sentence (starting from =20= "No assumption....) . I am not suggesting to ban the scenario neither, =20= just don't explicitly mention it. - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes The (n,1,n) mobile network has more than one MR advertising = different global routes and different NEMO-prefixes. Why do the MRs have to announce _different_ global routes and =20 _different_ prefixes? I mean wouldn't be possible that all the MRs announce the same global =20= routes (like a default route, for instance) and the same prefixes - Section 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix The (n,n,1) mobile network has more than one MR advertising = different global routes. Same comment than above. The mobile network is associated with multiple HAs at any one time. No assumptions are made on whether or not the HAs belongs to the same administrative domain. However, the MRs advertises the same NEMO-prefix. Same comment than Section 2.3. - Section 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple =20 NEMO-Prefixes The (n,n,n) mobile network has multiple MRs advertising different global routes and different NEMO-prefixes. Same comment than in Section 2.6. - Section 3 Perhaps it would be worthy to include a brief description of the goals =20= and benefits of multihoming, in order to make the document self =20 contained. I don't understand the difference between Load sharing and load =20 balancing in the case of a nemo. Perhaps it would be worthy to include a reference to RFC 3582 =09 - Section 3.1 Case x=3D1 I would say that this scenario also achieves other goals, such as load =20= sharing, load balancing, and preference setting, since the MR can =20 receive load through the different media simultaneously and it can =20 choose which traffic to route through each media based on preferences Case x=3DN The train example: why this case doesn't provides ubiquity support? i =20= mean, it is stated that different ISPs can be used... Moreover, if load sharing is provided, why preference settings are not =20= supported? i mean,. if multiple access are simultaneously available, =20 the MR can choose to use one link or the other to route traffic based =20= on preferences, right? The PAN example. Again, why preference setting is not one of the =20 achieved benefits in this scenario? The PAN can choose to send some =20 traffic through GPRS and other through WLAN (which it would make a lot =20= of sense imho). Same for load sharing or load balancing The same comments about additional benefits also apply to some of the =20= remaining examples - Section 3.2 Prerequisites Preference settings. I would add that multiple tunnels must be maintained simultaneously in =20= this section too. A mechanism must be provided to the user or the application to decide which of the available bi-directional tunnel should be used. Well, the preferences can also be set in the MR or the routing system =20= (as in current IPv4 multihoming), or even in the MNN (using RFC 3484 =20 policy table for instance). - Section 4.1 Path survival Only the case (0,0,0) is analyzed and a solution is referenced, why is =20= so? are the other cases less interesting or is simply the lack of =20 proposals for other scenarios? imho, there are other relevant =20 scenarios, and i would considered all the relevant scenarios or none of =20= them at all. - section 4.3 Ingress filtering The scenario considered in this section makes several assumptions that =20= i would challenge in the general case: - It assumes that there are several MR (there may be problems with =20 ingress filtering even in a scenario with a single MR, if the MR does =20= not considers the source address when forwarding packets) - It assumes that each MR announces a single prefix (which imho it may =20= not be so) - It assumes that each MR has a single tunnel and each MR has a tunnel =20= with a different HA (imho, a general approach to multihoming should =20= consider the case where each MR has multiple tunnels and that multiple =20= MR have tunnels with the same HA) - It assumes that the NEMO is composed of a single link, since it =20 assumes that all the routers within the nemo announce a single prefix. =20= I mean what happens in the scenario where a MNN is a router? would this =20= router announce a single prefix too? this would imply that alll the =20 node below this router only see a single prefix, so they don't really =20= benefit from multihoming. Are those assumptions being assumed and if so why this is so? wouldn't =20= make sense to consider a more general scenario? I am not sure that i understand why reference [12] is a useful approach =20= to deal with the issue presented in this section, could you expand on =20= this? Later on it is stated that: o Switching addresses is time consuming since nodes have to wait = for addresses to get deprecated [13]. Well, i guess you can announce a prefix with lifetime set to 0, so you =20= don't have to wait until its lifetime expires, right? - Section 4.4 Failure Detection imho i think there is a topic related with this section that is =20 missing, which is the ubiquity support and media availability =20 detection. I mean, one of the reasons for nemo multihoming is ubiquity =20= support, so it is likely that available media will change over time. A =20= mechanism to detect available media is required. This would be similar =20= to a failure detection mechanism perhaps? This section only considers the case of failures in the first link, =20 shouldn't it also be considered other failure modes? - Section 4.10 Impact on the Routing Infrastructure In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple routes directed to the mobile network may be advertised in the Internet. this is possible in IPv4 today, but it is not really acceptable in =20 IPv6, (that is what multi6 is trying to avoid, at least for end sites) Moreover, this is generally possible for the same site (for instance an =20= ISP with multiple connection) but i don't see how this would work for =20= different ISP announcing the same prefix, this seems more like =20 anycasting This may provide shorter paths, but this would add a burden in routing tables as the route would be published in the Internet Router Registry for multiple ASs. What is the Internet Router Registry? - Appendix A.1 s/Eric Nordmark/Erik Nordmark - Appendix B.1 It is stated that: In the case where multiple MRs are on the mobile network, each MR = has to detect the presence of other MR. A MR can do so by listening for Router Advertisement message on its *ingress* interfaces. In can see that this covers the case where both MR are on the same =20 link. However, what if the MRs are in different links, would this be =20 enough or using routing protocols is needed? - Appendix B.2 It is stated that: When a MR detects that the link be which its current bi-directional tunnel with its HA is using is down, i think this needs some rephrasing - Appendix B.2.2 AFAIU, in this section is being assumed that each MR has a different =20 nemo-prefix assigned, is this correct? I mean, what happens if there is s single nemo prefix? What happens if there are multiple nemo prefixes but all the MR =20 announce all of them? How does the MR creates a CoA of the "other" MR in this case? El 14/07/2004, a las 4:28, Thierry Ernst escribi=F3: > > Dear all, > > I think this problem statement for multihoming in NEMO would interest > some of you. This is now a NEMO WG document, so we will most likely > discuss the document during our NEMO WG meeting, on Monday August 2nd. > > I guess the NEMO WG would appreciate if some of you could join the > discussion, so that we make sure there is a good interaction between > both WGs. > > > Thierry. > > -- =20 > Thierry Ernst, PhD > WIDE at Keio University, Japan > IETF NEMO WG co-chair =20 > http://www.ietf.org/html.charters/nemo-charter.html > WIDE NAUTILUS WG co-chair http://www.nautilus6.org > > > De: Internet-Drafts@ietf.org > Fecha: 13 de julio de 2004 22:03:49 GMT+02:00 > Para: i-d-announce@ietf.org > Cc: nemo@ietf.org > Asunto: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > This draft is a work item of the Network Mobility Working Group of the = =20 > IETF. > > Title : Analysis of Multihoming in Network Mobility = Support > Author(s) : C. Ng, et al. > Filename : draft-ietf-nemo-multihoming-issues-00.txt > Pages : 33 > Date : 2004-7-13 > =09 > This document is an analysis of multihoming in the context of network > mobility (NEMO). As there are many situations in which mobile > networks may be multihomed, a taxonomy is proposed to classify the > possible configurations. We also describe possible deployment > scenarios and we attempt to identify issues that arise when mobile > networks are multihomed while mobility supports is taken care by =20= > NEMO > Basic Support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-=20 > issues-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of = =20 > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE = /internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-7-13145203.I-D@ietf.org> > > > From nemo-bounces@ietf.org Tue Jul 20 08:30: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 IAA14453 for ; Tue, 20 Jul 2004 08:30: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 1BmtbQ-0000Tm-TT; Tue, 20 Jul 2004 08:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmtT6-000636-CZ for nemo@megatron.ietf.org; Tue, 20 Jul 2004 08:11: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 IAA13395 for ; Tue, 20 Jul 2004 08:11:34 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmtTD-0007L8-82 for nemo@ietf.org; Tue, 20 Jul 2004 08:11:44 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4B4A05D50D; Tue, 20 Jul 2004 21:11:02 +0900 (JST) Date: Tue, 20 Jul 2004 21:10:48 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Message-Id: <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Content-Transfer-Encoding: 7bit Cc: "Paik, Eun Kyoung" , chan X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Thanks to your comments Marcelo. > - General comment: Is this draft about IPv4 or IPv6 or both? I mean, i > think that there are lots of IPv6 specific points, but there are also > some IPv4 considerations (or at least that how i understand it, for > instance the case of reference [9] perhaps?). Perhaps explicitly > stating in the introduction the IP protocol version considered could be > helpful Sure, we will fix this. > - Section 2. > > I am not sure how valuable is to include the discussion about whether > the MNNs are multihomed or not. I mean, this is basically a study on > the mobile network, i don't think that host multihoming issues are > interesting. Moreover, i don't agree that a node with multiple > addresses can be called a multihomed node, imho this is a node within a > multihomed network in many cases. This is a good point, but if we want to benefit from multihoming, we (not necessarily the NEMO WG) will need to consider some issues that impact on MNNs. So, the purpose of draft-ietf-nemo-multihoming is to list all such issues. After that, we will have to decide what issues should be solved, then which ones should be addressed by the NEMO WG, and how to solve the other issues within the IETF community. > What does "companion document" means? (same question for the document > referred in section 3) Should these docs be considered part of this > spec? Arrrh, there is a typo here: The text says "companion document [7]" as below: [6] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. An update of this draft should show off soon. You can get the update from: http://www.nautilus6.org/doc/drafts/draft-multihoming-generic-goals-and-benefits-01.txt [7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of Multihoming in Mobile IPv6", draft-montavont-mobileip-multihoming-pb-statement-01 (work in progress), Feb 2004. An update of this draft should show off soon. You can get the update from: http://www.nautilus6.org/doc/drafts/draft-montavont-mobileip-multihoming-pb-statement-01.txt > - Section 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix > > The (1,n,1) mobile network has only one MR advertising a single > NEMO-prefix. The MR, however, is associated to multiple HAs, > possibly one HA per Home Address, or one HA per egress interface. No > assumption is made on whether or not the HAs belongs to the same > administrative domain (it may be justified to locate HAs in distinct > ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical > Prefix from a Different Origin] [9]) > > I don't understand the case where there is a single prefix and multiple > HAs placed in different administrative domains. I mean, if the HAs are > in different administrative domains, they will have different prefixes, > so there will be multiple nemo-prefixes in the nemo. The case > considered in reference [9] is about the same prefix that it is > announced with different ASN as origin. This can be AFAIU, because the > announcing site don't have its own ASN, so the prefix is announced with > the provider's ASN, but i don't think that this case is related to the > topic here considered. OK, we might need to look at this case and ref [9] a bit closer. > Bottom line is that i don't see that the case where there is a single > nemo prefix with multiple HAs in different administrative domains makes > much sense. I would suggest to remove The last sentence (starting from > "No assumption....) . I am not suggesting to ban the scenario neither, > just don't explicitly mention it. We thought that mentioning the scenario would have helped to avoid a discussion on this ;-) > - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes > > The (n,1,n) mobile network has more than one MR advertising different > global routes and different NEMO-prefixes. > > Why do the MRs have to announce _different_ global routes and > _different_ prefixes? > I mean wouldn't be possible that all the MRs announce the same global > routes (like a default route, for instance) and the same prefixes Of course that is possible, so that would be case (n,1,1). Here, we just list the case in order to list the issues (the issues are discussed later); after that we will have to decide what are good practices and what aren't. > - Section 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix > > The (n,n,1) mobile network has more than one MR advertising different > global routes. > > Same comment than above. > > The mobile network is associated with multiple HAs at > any one time. No assumptions are made on whether or not the HAs > belongs to the same administrative domain. However, the MRs > advertises the same NEMO-prefix. > > Same comment than Section 2.3. > > - Section 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple > NEMO-Prefixes > > The (n,n,n) mobile network has multiple MRs advertising different > global routes and different NEMO-prefixes. > > Same comment than in Section 2.6. > > - Section 3 > > Perhaps it would be worthy to include a brief description of the goals > and benefits of multihoming, in order to make the document self > contained. > I don't understand the difference between Load sharing and load > balancing in the case of a nemo. > Perhaps it would be worthy to include a reference to RFC 3582 Ref [6]-01 does this, so we just refer to ref [6] right now. We will have to decide the future of ref [6], though. If [6] is published, there is no reason to put in more text in draft-ietf-nemo-multihoming IMHO. RFC 3582 is referenced from [6]-01, [6] will need to be improved to catch the differences or using the same definition. > - Section 3.1 > > Case x=1 > > I would say that this scenario also achieves other goals, such as load > sharing, load balancing, and preference setting, since the MR can > receive load through the different media simultaneously and it can > choose which traffic to route through each media based on preferences > > Case x=N > > The train example: why this case doesn't provides ubiquity support? i > mean, it is stated that different ISPs can be used... > Moreover, if load sharing is provided, why preference settings are not > supported? i mean,. if multiple access are simultaneously available, > the MR can choose to use one link or the other to route traffic based > on preferences, right? > > The PAN example. Again, why preference setting is not one of the > achieved benefits in this scenario? The PAN can choose to send some > traffic through GPRS and other through WLAN (which it would make a lot > of sense imho). Same for load sharing or load balancing > > The same comments about additional benefits also apply to some of the > remaining examples OK, we didn't cite some benefits, it doesn't mean it's not possible. I agree we need to improve this. > > - Section 3.2 Prerequisites > > Preference settings. > > I would add that multiple tunnels must be maintained simultaneously in > this section too. > > A mechanism must be provided to the user or the application to > decide which of the available bi-directional tunnel should be > used. > > Well, the preferences can also be set in the MR or the routing system > (as in current IPv4 multihoming), or even in the MNN (using RFC 3484 > policy table for instance). OK to all the above. > - Section 4.1 Path survival > Only the case (0,0,0) is analyzed and a solution is referenced, why is > so? are the other cases less interesting or is simply the lack of > proposals for other scenarios? imho, there are other relevant > scenarios, and i would considered all the relevant scenarios or none of > them at all. OK. That may be too many scenarios to list, though ? > - section 4.3 Ingress filtering > > The scenario considered in this section makes several assumptions that > i would challenge in the general case: > - It assumes that there are several MR (there may be problems with > ingress filtering even in a scenario with a single MR, if the MR does > not considers the source address when forwarding packets) > - It assumes that each MR announces a single prefix (which imho it may > not be so) > - It assumes that each MR has a single tunnel and each MR has a tunnel > with a different HA (imho, a general approach to multihoming should > consider the case where each MR has multiple tunnels and that multiple > MR have tunnels with the same HA) > - It assumes that the NEMO is composed of a single link, since it > assumes that all the routers within the nemo announce a single prefix. > I mean what happens in the scenario where a MNN is a router? would this > router announce a single prefix too? this would imply that alll the > node below this router only see a single prefix, so they don't really > benefit from multihoming. > > Are those assumptions being assumed and if so why this is so? wouldn't > make sense to consider a more general scenario? It's not assumed. If the reader thinks so, we should change the text to reflect that this is an instance case, used for commodity, in order to explain the issue. Any suggestion to improve the text ? - listing ALL the cases that lead to the issue - listing SOME of the cases that lead to the issue - listing NO case - have a table at the end summarizing which issue happens in which case > I am not sure that i understand why reference [12] is a useful approach > to deal with the issue presented in this section, could you expand on > this? We will take a look on this. > Later on it is stated that: > > o Switching addresses is time consuming since nodes have to wait for > addresses to get deprecated [13]. > > Well, i guess you can announce a prefix with lifetime set to 0, so you > don't have to wait until its lifetime expires, right? Right, that's a way to solve the issue, isn't it ? The point is that if you don't set the lifetime appropriately, it would happen. We should be clearer on this. > - Section 4.4 Failure Detection > > imho i think there is a topic related with this section that is > missing, which is the ubiquity support and media availability > detection. I mean, one of the reasons for nemo multihoming is ubiquity > support, so it is likely that available media will change over time. A > mechanism to detect available media is required. This would be similar > to a failure detection mechanism perhaps? May be our section "Failure detection" could be split in two, etc. We will take a look at it. > > This section only considers the case of failures in the first link, > shouldn't it also be considered other failure modes? Probably, yes. > - Section 4.10 Impact on the Routing Infrastructure > > In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple > routes directed to the mobile network may be advertised in the > Internet. > > this is possible in IPv4 today, but it is not really acceptable in > IPv6, (that is what multi6 is trying to avoid, at least for end sites) > Moreover, this is generally possible for the same site (for instance an > ISP with multiple connection) but i don't see how this would work for > different ISP announcing the same prefix, this seems more like > anycasting Basically, the reasons why we pointed out to multi6 is clearly a way to say that more investigation is needed on this issue, and that there is a work in progress in that WG. We will definitely put in more text here, following the progress of Multi6. > This may provide shorter paths, but this would add a > burden in routing tables as the route would be published in the > Internet Router Registry for multiple ASs. > > What is the Internet Router Registry? Ah, don't know myself ;-) > - Appendix A.1 > > s/Eric Nordmark/Erik Nordmark > > - Appendix B.1 > > It is stated that: > > In the case where multiple MRs are on the mobile network, each MR has > to detect the presence of other MR. A MR can do so by listening for > Router Advertisement message on its *ingress* interfaces. > > In can see that this covers the case where both MR are on the same > link. However, what if the MRs are in different links, would this be > enough or using routing protocols is needed? > > - Appendix B.2 > > It is stated that: > > When a MR detects that the link be which its current bi-directional > tunnel with its HA is using is down, > > i think this needs some rephrasing > > - Appendix B.2.2 > > AFAIU, in this section is being assumed that each MR has a different > nemo-prefix assigned, is this correct? > I mean, what happens if there is s single nemo prefix? > What happens if there are multiple nemo prefixes but all the MR > announce all of them? > How does the MR creates a CoA of the "other" MR in this case? > I guess we will need a careful look on the appendix. Thanks again for all your valuable comments. Thierry. From nemo-bounces@ietf.org Tue Jul 20 09:35: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 JAA18885 for ; Tue, 20 Jul 2004 09:35: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 1Bmuia-0006Dq-Nk; Tue, 20 Jul 2004 09:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmug5-0002wv-6V for nemo@megatron.ietf.org; Tue, 20 Jul 2004 09:29: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 JAA18519 for ; Tue, 20 Jul 2004 09:29:03 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmugA-0008T8-Oh for nemo@ietf.org; Tue, 20 Jul 2004 09:29:14 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9912729C91; Tue, 20 Jul 2004 15:30:00 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 72DD429C82; Tue, 20 Jul 2004 15:30:00 +0200 (CEST) In-Reply-To: <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Date: Tue, 20 Jul 2004 15:29:58 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Paik, Eun Kyoung" , chan X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 [...] >> - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple >> NEMO-Prefixes >> >> The (n,1,n) mobile network has more than one MR advertising >> different >> global routes and different NEMO-prefixes. >> >> Why do the MRs have to announce _different_ global routes and >> _different_ prefixes? >> I mean wouldn't be possible that all the MRs announce the same global >> routes (like a default route, for instance) and the same prefixes > > Of course that is possible, so that would be case (n,1,1). Here, we > just > list the case in order to list the issues (the issues are discussed > later); after that we will have to decide what are good practices and > what aren't. > Ok, so i would suggest to remove the "different" from "different global routes" and from "different NEMO-prefixes" so that the more general case is presented, agree? > >> - Section 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix >> >> The (n,n,1) mobile network has more than one MR advertising >> different >> global routes. >> >> Same comment than above. >> >> The mobile network is associated with multiple HAs at >> any one time. No assumptions are made on whether or not the HAs >> belongs to the same administrative domain. However, the MRs >> advertises the same NEMO-prefix. >> >> Same comment than Section 2.3. >> >> - Section 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple >> NEMO-Prefixes >> >> The (n,n,n) mobile network has multiple MRs advertising different >> global routes and different NEMO-prefixes. >> >> Same comment than in Section 2.6. > > [...[ >> Only the case (0,0,0) is analyzed and a solution is referenced, why is >> so? are the other cases less interesting or is simply the lack of >> proposals for other scenarios? imho, there are other relevant >> scenarios, and i would considered all the relevant scenarios or none >> of >> them at all. > > OK. That may be too many scenarios to list, though ? > Perhaps moving the solutions to the appendix would make the document more clear? >> - section 4.3 Ingress filtering >> >> The scenario considered in this section makes several assumptions that >> i would challenge in the general case: >> - It assumes that there are several MR (there may be problems with >> ingress filtering even in a scenario with a single MR, if the MR does >> not considers the source address when forwarding packets) >> - It assumes that each MR announces a single prefix (which imho it may >> not be so) >> - It assumes that each MR has a single tunnel and each MR has a tunnel >> with a different HA (imho, a general approach to multihoming should >> consider the case where each MR has multiple tunnels and that multiple >> MR have tunnels with the same HA) >> - It assumes that the NEMO is composed of a single link, since it >> assumes that all the routers within the nemo announce a single prefix. >> I mean what happens in the scenario where a MNN is a router? would >> this >> router announce a single prefix too? this would imply that alll the >> node below this router only see a single prefix, so they don't really >> benefit from multihoming. >> >> Are those assumptions being assumed and if so why this is so? wouldn't >> make sense to consider a more general scenario? > > It's not assumed. If the reader thinks so, we should change the text to > reflect that this is an instance case, used for commodity, in order to > explain the issue. > Any suggestion to improve the text ? > - listing ALL the cases that lead to the issue > - listing SOME of the cases that lead to the issue > - listing NO case > - have a table at the end summarizing which issue happens in which case > Well, i guess that there may be problems with ingress filtering as long as there are multiple NEMO prefixes available so i would add the multiprefix concern in the initial sentence i guess. I agree that an example is useful to understand the issue, but perhaps adding a bit of general description of the problem before going to the example could provide a broader view. Perhaps mentioning that there are other relevant scenarios where could be issues would also help. [...] >> >> - Appendix B.2.2 >> >> AFAIU, in this section is being assumed that each MR has a different >> nemo-prefix assigned, is this correct? >> I mean, what happens if there is s single nemo prefix? >> What happens if there are multiple nemo prefixes but all the MR >> announce all of them? >> How does the MR creates a CoA of the "other" MR in this case? >> > > I guess we will need a careful look on the appendix. > I think that the approach presented in this appendix is very interesting. However i wonder if this should be placed in an appendix of a analysis document. I would say that this should be moved to a separate document covering the nemo multihoming support approach and that this document should study in detail the proposed approach in all the relevant scenarios in order to verity that it provides the desired capabilities. Regards, marcelo > Thanks again for all your valuable comments. > > Thierry. > > From nemo-bounces@ietf.org Tue Jul 20 13:31: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 NAA07532 for ; Tue, 20 Jul 2004 13:31: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 1BmyIq-0002zH-T0; Tue, 20 Jul 2004 13:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmy8N-0000Ad-Pq for nemo@megatron.ietf.org; Tue, 20 Jul 2004 13:10: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 NAA06170 for ; Tue, 20 Jul 2004 13:10:28 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmy8X-0003NN-Nw for nemo@ietf.org; Tue, 20 Jul 2004 13:10:43 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6KH9ul15754; Tue, 20 Jul 2004 10:09:56 -0700 X-mProtect: <200407201709> 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 smtpdyeaMqW; Tue, 20 Jul 2004 10:09:54 PDT Message-ID: <40FD535F.1090500@iprg.nokia.com> Date: Tue, 20 Jul 2004 10:16:15 -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: Thierry Ernst Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] comments on draft-ietf-nemo-terminology X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi Thierry, I have some comments on version 01 of the terminology draft. I am not sure if you have submitted version 02 of the draft. > Abstract > > This document defines a terminology for discussing network mobility > problems and solution requirements. maybe the above sentence is enough for the abstract. what follows is repeated (similar text) in the Introduction. > Network mobility arises when a > router connecting an entire network to the Internet dynamically > changes its point of attachment to the Internet therefrom causing the > reachability of the entire network to be changed in the topology. > Such kind of network is referred to as a mobile network. Without > appropriate mechanisms, sessions established between nodes in the > mobile network and the global Internet cannot be maintained while the > mobile router changes its point of attachment. > > Within the term Mobile Network Node (MNN), we can distinguish between > LFN, VMN and LMN. the terms LFN, VMN and LMN are introduced here without expanding them. > 3.3 MONET [DEPRECIATED] s/DEPRECIATED/DEPRECATED/ > > 3.5 Egress Interface (E-face) > > As defined in [2]) > > 3.6 Ingress Interface (I-face) > > As defined in [2]) lets not re-define these two terms. Ingress and Egress are widely used terms and everybody understands them. > 3.7 NEMO-prefix (MNP) > > An acronym for Mobile Network Prefix (as defined in [2]) why introduce this term if we are not re-defining it? MNP has been widely used on the mailing list and in the NEMO Basic Support spec. I prefer MNP (Mobile Network Prefix) over NEMO-prefix. > > 3.8 NEMO-link > > A link (subnet) located within the mobile network. including nested mobile networks? > > 3.10 Node behind the MR > > Any MNN located in a mobile network, beside the MRs connecting the > mobile network to the Internet. this is not a term. I think this should be removed. > 3.14 NEMO-enabled (NEMO-node) > > A node that has been extended with network mobility support > capabilities and that may take special actions based on that (details > of the capabilities are not known yet, but it may be implementing > some sort of Route Optimization). I had a hard time understanding this section. does the node do some kind of Route Optimization inside the Mobile Network (without involving a Mobile IPv6 Home Agent)? if there was some discussion regarding this on the mailing list, please let me know. > 7.5 Mobile Aggregated Prefix > > An aggregation of Mobile Network Prefixes. > > 7.6 Aggregated Home Network > > The Home Network associated with a Mobile Aggregated Prefix. This > Aggregation is advertised as a subnet on the Home Link, and thus used > as Home Network for Nemo purposes. > > 7.7 Extended Home Network > > The network associated with the aggregation of one or more Home > Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home > Network that is a subnet, the extended Home Network is an aggregation > and is further subnetted. > > 7.8 Virtual Home Network > > The Home Network associated with a Virtual Network. The Extended Home > Network and the Aggregated Home Network can be configured as Virtual > Home Network. the above four terms to appear only in draft-ietf-nemo-home-network-models. it is hard to explain these terms without figures. the above four terms, as they are currently described in the terminology draft will only mystify the readers. > - Added TMLR as depreciated term (everyone should use root-MR > instead) replace with - Deprecated TLMR. > - Added NEMO-prefix this I disagree with. I think MNP should be used. Vijay From nemo-bounces@ietf.org Tue Jul 20 14:53: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 OAA15397 for ; Tue, 20 Jul 2004 14:53: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 1BmzaE-0000rG-MW; Tue, 20 Jul 2004 14: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 1BmzSU-0006uc-88 for nemo@megatron.ietf.org; Tue, 20 Jul 2004 14:35: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 OAA13978 for ; Tue, 20 Jul 2004 14:35:20 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmzSf-0004ri-3T for nemo@ietf.org; Tue, 20 Jul 2004 14:35:34 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i6KIa7JW012485; Tue, 20 Jul 2004 11:36:07 -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 i6KIZG4S000585; Tue, 20 Jul 2004 13:35: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 853DD88CF7E; Tue, 20 Jul 2004 20:35:16 +0200 (CEST) Message-ID: <40FD65DE.4020402@motorola.com> Date: Tue, 20 Jul 2004 20:35: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: Vijay Devarapalli Subject: Re: [nemo] comments on draft-ietf-nemo-terminology References: <40FD535F.1090500@iprg.nokia.com> In-Reply-To: <40FD535F.1090500@iprg.nokia.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="------------ms090708080408010707080100" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms090708080408010707080100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> - Added NEMO-prefix > > this I disagree with. I think MNP should be used. I agree that MNP should be used instead of NEMO-prefix. At least the basic spec uses it, so. And then people are free to just use "prefix". Talking terminology... I'm remembering when monet was proposed and there was suggestion against this term (because collision with other terms) and then nemo was proposed instead. I was opposing change at that time because I thought monet was already established, and I liked its artistic touch. Someone even said something like "fine arts vs. crazy captain" :-) I don't know now whether the change was good or bad, but maybe yes. And thinking right now that "mobile network" really has collisions with "telecom mobile networks" (the ones that _support_ mobile devices, but don't actually move themselves - ok they do, with respect to the Rotation Axis, which moves too with respect to self). And thinking it would be better to use "moving network" instead of "mobile network"; but who knows which term will stick. Alex --------------ms090708080408010707080100 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3 MjAxODM1MTBaMCMGCSqGSIb3DQEJBDEWBBSdNUUKU5u7SCSLOjQLmZZyZRTCQDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYB+HxZN5trRcoJ6FKz6ZSN3ynZb+uTF/5zpkUMy eTBE8ZfNeCixCoeculrUC8jtrol3PWuG+g1xnoGXbR00GDZoqIPmf++G9k+Kb1y3zoXruv3b MjcSgaNiLRzCaaIeMT/hbhAS+sjS9M+isqosmr9COTtxitUCxlLE6hELRw6CTQAAAAAAAA== --------------ms090708080408010707080100-- From nemo-bounces@ietf.org Tue Jul 20 18:53: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 SAA22718 for ; Tue, 20 Jul 2004 18:53: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 1Bn1Od-0007gz-O1; Tue, 20 Jul 2004 16:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0nv-0002Cc-5f for nemo@megatron.ietf.org; Tue, 20 Jul 2004 16:01: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 QAA22469 for ; Tue, 20 Jul 2004 16:01:32 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn0o6-0006PR-6H for nemo@ietf.org; Tue, 20 Jul 2004 16:01:47 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 693E139FEC; Tue, 20 Jul 2004 21:01:31 +0200 (CEST) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 4574D39FEB; Tue, 20 Jul 2004 21:01:31 +0200 (CEST) Message-ID: <40FD79FD.9070505@it.uc3m.es> Date: Tue, 20 Jul 2004 22:01:01 +0200 From: Ignacio Soto Campos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Route Optimization by CR References: <20040717094046.712F.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20040717094046.712F.RYUJI@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: 386e0819b1192672467565a524848168 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 Ryuji, Some questions about this draft. - Section 4.1 In addition, when a mobile network node starts communication with a correspondent node, a mobile router may dynamically discover a correspondent router for the correspondent node. The discovery is triggered when a mobile router receives tunneled packets from its Home Agent. The mobile router first sends a correspondent router Discovery Request to the correspondent router anycast address. The anycast address is created with the prefix address of the correspondent node and the well-known anycast identifier. The prefix length for the anycast address is always 64. When one of correspondent router receives the Correspondent Router Discovery Request, it replies back a Correspondent Router Discovery Reply including all correspondent routers of the administrative domain of which the correspondent node is located. I am trying to understand the mechanism for dynamic correspondent router discovery. If the anycast address is created with the prefix address of the correspondent node, does this mean that you need a correspondent router in the CN subnet to be able to use dynamic discovery of correspondent routers? if not, how any other router can know that it must attend that anycast address? - Section 4.3 Once a mobile router registers its binding to a correspondent router, it forwards packets destined to an address which is in range of correspondent router's managed prefix. This forwarding is done in an IP-in-IP tunnel, right? - Appendix A Correspondent routers can intercept packets that are from transit AS. For instance, if a correspondent node in AS3 send packets to the mobile network, the packets are routed towards the home agent since there are no correspondent routers in AS3. However, on the way to the home agent, a correspondent router in AS1 which is the transit AS of AS3, can intercept the packets and tunnels them directly to the mobile router. This seems to imply that route optimization can be initiated in the correspondent router, but I suppose that route optimization is always initiated by the mobile router. But then, how a mobile router can discover a correspondent router that is in a different AS from the correspondent node? - Appendix B In Figure 2 and 3, If I understand correctly, the Correspondent node in the upper part of both figures should be a mobile router. Best regards and thank you, Ignacio Ryuji Wakikawa wrote: > Hello > > We submitted a new draft on providing route optimization by CR titled > Optimized Route Cache Protocol (ORC). > > ORC is based on the similar idea to HAHA protocol. MR uses an anchor > router (either HA or CR) for route optimization. > > ORC provides MR initiated route optimization. It includes dynamically CR > discovery and dynamic binding registration depending on NEMO > communication model. > > http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt > > BTW, CR was clearly explained in Pascal's RO Taxonomy draft. > > Your comments are appreciated. Please send comments. > > thanks > ryuji > > From nemo-bounces@ietf.org Tue Jul 20 23:14: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 XAA10229 for ; Tue, 20 Jul 2004 23:14: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 1Bn77H-000269-6o; Tue, 20 Jul 2004 22:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn5Kn-0000eT-Id for nemo@megatron.ietf.org; Tue, 20 Jul 2004 20:51: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 UAA14608 for ; Tue, 20 Jul 2004 20:51:47 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn5Kz-00047V-EY for nemo@ietf.org; Tue, 20 Jul 2004 20:52:04 -0400 Received: from [203.178.128.189] (n128-189.sfc.wide.ad.jp [203.178.128.189]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i6L0nX4v004206; Wed, 21 Jul 2004 09:49:33 +0900 In-Reply-To: <40FD79FD.9070505@it.uc3m.es> References: <20040717094046.712F.RYUJI@sfc.wide.ad.jp> <40FD79FD.9070505@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20E5F898-DAB0-11D8-9468-000D936735C4@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Route Optimization by CR Date: Wed, 21 Jul 2004 09:51:40 +0900 To: Ignacio Soto Campos X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Ignacio please find my inline comments. On 2004/07/21, at 5:01, Ignacio Soto Campos wrote: > Hi Ryuji, > > Some questions about this draft. > > - Section 4.1 > > In addition, when a mobile network node starts communication with > a correspondent node, a mobile router may dynamically discover a > correspondent router for the correspondent node. The discovery is > triggered when a mobile router receives tunneled packets from its > Home Agent. The mobile router first sends a correspondent router > Discovery Request to the correspondent router anycast address. > The anycast address is created with the prefix address of the > correspondent node and the well-known anycast identifier. The > prefix length for the anycast address is always 64. When one of > correspondent router receives the Correspondent Router Discovery > Request, it replies back a Correspondent Router Discovery Reply > including all correspondent routers of the administrative domain of > which the correspondent node is located. > > I am trying to understand the mechanism for dynamic correspondent > router discovery. If the anycast address is created with the prefix > address of the correspondent node, does this mean that you need a > correspondent router in the CN subnet to be able to use dynamic > discovery of correspondent routers? if not, how any other router can > know that it must attend that anycast address? In our current spec., you always need a CR in the CN subnet (which prefix len is 64) The CR contain addresses of other CRs in the CR discovery reply messages. MR needs prefix address and prefix length to generate the CR anycast address, but MR can not retrieve the prefix length from packets originated by CN. Thus, we make the assumption for CR discovery that a CR is always placed in the edge network of CN. If MR statically knows CR, no reason to place CR in edge networks. > - Section 4.3 > > Once a mobile router registers its binding to a correspondent > router, > it forwards packets destined to an address which is in range of > correspondent router's managed prefix. > > This forwarding is done in an IP-in-IP tunnel, right? > Yes. > > - Appendix A > > Correspondent routers can intercept packets that are from transit > AS. For instance, if a correspondent node in AS3 send packets to the > mobile network, the packets are routed towards the home agent since > there are no correspondent routers in AS3. However, on the way to > the home agent, a correspondent router in AS1 which is the transit > AS > of AS3, can intercept the packets and tunnels them directly to the > mobile router. > > This seems to imply that route optimization can be initiated in the > correspondent router, but I suppose that route optimization is always > initiated by the mobile router. But then, how a mobile router can > discover a correspondent router that is in a different AS from the > correspondent node? MR does not attempt to discover a CR in a different AS. Some BGP routers may have CR functions and intercept packets sent from another AS, while routing packets. Since this RO is blindly occurred, we needs to investigate security issue and do not complete it yet. That's why we put this into Appendix. > - Appendix B > > In Figure 2 and 3, If I understand correctly, the Correspondent node > in the upper part of both figures should be a mobile router. Yes, right. Thanks. regards, ryuji > Best regards and thank you, > > Ignacio > > > > Ryuji Wakikawa wrote: > >> Hello >> We submitted a new draft on providing route optimization by CR titled >> Optimized Route Cache Protocol (ORC). >> ORC is based on the similar idea to HAHA protocol. MR uses an anchor >> router (either HA or CR) for route optimization. ORC provides MR >> initiated route optimization. It includes dynamically CR >> discovery and dynamic binding registration depending on NEMO >> communication model. >> http://www.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt >> BTW, CR was clearly explained in Pascal's RO Taxonomy draft. >> Your comments are appreciated. Please send comments. >> thanks >> ryuji > From nemo-bounces@ietf.org Tue Jul 20 23:57: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 XAA14331 for ; Tue, 20 Jul 2004 23:57: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 1Bn8CW-0005Ph-2I; Tue, 20 Jul 2004 23:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7pJ-0001Hu-U9 for nemo@megatron.ietf.org; Tue, 20 Jul 2004 23:31: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 XAA12409 for ; Tue, 20 Jul 2004 23:31:27 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn7pa-0003Gi-6K for nemo@ietf.org; Tue, 20 Jul 2004 23:31:47 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6L3Sha8006182; Wed, 21 Jul 2004 11:28:43 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id DF08EB24138; Wed, 21 Jul 2004 11:38:00 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1090381080.8700.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 11:38:00 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Eun Kyoung Paik , 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: 7bit Hello Marcelo, Thank you for your very valuable comments. See responses inline. /rgds /cwng On Tue, 2004-07-20 at 21:29, marcelo bagnulo braun wrote: > [...] > > >> - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple > >> NEMO-Prefixes > >> > >> The (n,1,n) mobile network has more than one MR advertising > >> different > >> global routes and different NEMO-prefixes. > >> > >> Why do the MRs have to announce _different_ global routes and > >> _different_ prefixes? > >> I mean wouldn't be possible that all the MRs announce the same global > >> routes (like a default route, for instance) and the same prefixes > > > > Of course that is possible, so that would be case (n,1,1). Here, we > > just > > list the case in order to list the issues (the issues are discussed > > later); after that we will have to decide what are good practices and > > what aren't. > > > > Ok, so i would suggest to remove the "different" from "different global > routes" and from "different NEMO-prefixes" so that the more general > case is presented, agree? > Hmm, how about: "different" -> "multiple"? Agree that MRs need not necessarily announce different prefixes. > >> Only the case (0,0,0) is analyzed and a solution is referenced, why is > >> so? are the other cases less interesting or is simply the lack of > >> proposals for other scenarios? imho, there are other relevant > >> scenarios, and i would considered all the relevant scenarios or none > >> of > >> them at all. > > > > OK. That may be too many scenarios to list, though ? > > > > Perhaps moving the solutions to the appendix would make the document > more clear? > > >> - section 4.3 Ingress filtering > >> > >> The scenario considered in this section makes several assumptions that > >> i would challenge in the general case: > >> - It assumes that there are several MR (there may be problems with > >> ingress filtering even in a scenario with a single MR, if the MR does > >> not considers the source address when forwarding packets) > >> - It assumes that each MR announces a single prefix (which imho it may > >> not be so) > >> - It assumes that each MR has a single tunnel and each MR has a tunnel > >> with a different HA (imho, a general approach to multihoming should > >> consider the case where each MR has multiple tunnels and that multiple > >> MR have tunnels with the same HA) > >> - It assumes that the NEMO is composed of a single link, since it > >> assumes that all the routers within the nemo announce a single prefix. > >> I mean what happens in the scenario where a MNN is a router? would > >> this > >> router announce a single prefix too? this would imply that alll the > >> node below this router only see a single prefix, so they don't really > >> benefit from multihoming. > >> > >> Are those assumptions being assumed and if so why this is so? wouldn't > >> make sense to consider a more general scenario? > > > > It's not assumed. If the reader thinks so, we should change the text to > > reflect that this is an instance case, used for commodity, in order to > > explain the issue. > > > Any suggestion to improve the text ? > > - listing ALL the cases that lead to the issue > > - listing SOME of the cases that lead to the issue > > - listing NO case > > - have a table at the end summarizing which issue happens in which case > > > > Well, i guess that there may be problems with ingress filtering as long > as there are multiple NEMO prefixes available so i would add the > multiprefix concern in the initial sentence i guess. > > I agree that an example is useful to understand the issue, but perhaps > adding a bit of general description of the problem before going to the > example could provide a broader view. Perhaps mentioning that there are > other relevant scenarios where could be issues would also help. > Point noted. I need to ponder a bit more on the various assumptions you listed, especially the part on MNN = router. > [...] > > >> > >> - Appendix B.2.2 > >> > >> AFAIU, in this section is being assumed that each MR has a different > >> nemo-prefix assigned, is this correct? > >> I mean, what happens if there is s single nemo prefix? > >> What happens if there are multiple nemo prefixes but all the MR > >> announce all of them? > >> How does the MR creates a CoA of the "other" MR in this case? > >> > > > > I guess we will need a careful look on the appendix. > > > > I think that the approach presented in this appendix is very > interesting. However i wonder if this should be placed in an appendix > of a analysis document. I would say that this should be moved to a > separate document covering the nemo multihoming support approach and > that this document should study in detail the proposed approach in all > the relevant scenarios in order to verity that it provides the desired > capabilities. > This solution has always been with the draft since its initial incarnation (i.e. draft-ng-nemo-multihoming-issues-00.txt). I agree that having it in a separate document is the more desirable approach. /rgds /cwng From nemo-bounces@ietf.org Wed Jul 21 04:10: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 EAA26535 for ; Wed, 21 Jul 2004 04:10: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 1BnBt5-0000eE-ED; Wed, 21 Jul 2004 03:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBiw-0002VV-B6 for nemo@megatron.ietf.org; Wed, 21 Jul 2004 03:41: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 DAA24821 for ; Wed, 21 Jul 2004 03:41:08 -0400 (EDT) Received: from jules.nautilus6.org ([203.178.138.2] helo=bender) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnBjE-0006Et-0G for nemo@ietf.org; Wed, 21 Jul 2004 03:41:29 -0400 Received: from bender (bender [127.0.0.1]) by bender (Postfix) with SMTP id 19818A182F for ; Wed, 21 Jul 2004 16:41:54 +0900 (JST) Date: Wed, 21 Jul 2004 16:41:53 +0900 From: Romain KUNTZ To: nemo@ietf.org Subject: Re: [nemo] New draft submitted: draft-koh-dihap-00.txt Message-Id: <20040721164153.25858f62.kuntz@sfc.wide.ad.jp> In-Reply-To: <40F34EF4.6080007@psl.com.sg> References: <40F34EF4.6080007@psl.com.sg> 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: 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, On Tue, 13 Jul 2004 10:54:44 +0800 Benjamin Koh Tien-Ming wrote: > A new draft was submitted and can be found at: > http://www.ietf.org/internet-drafts/draft-koh-dihap-00.txt > > All feedback are welcome! I have just a question about this draft: - Once the MN changed its home agent, how does the packets from a CN are routed to the new home agent ? I mean, unless the MN changes its home address, the CN will go on sending packets to the former home network! If the MN changes its home address, current transport sessions between MN and CN are terminated... Maybe I missed something reading the draft? - If Home Agents operates in solo mode, I guess each HA has to update all others HA Home Interface List each time its own Home Interface List change, otherwise HAs will not be synchronised. Isn't it a little bit too expensive ? Best regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Wed Jul 21 04:45: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 EAA28815 for ; Wed, 21 Jul 2004 04:45: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 1BnCUd-0007QM-0y; Wed, 21 Jul 2004 04:30:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnCM2-0001ut-Tr for nemo@megatron.ietf.org; Wed, 21 Jul 2004 04:21: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 EAA27276 for ; Wed, 21 Jul 2004 04:21: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 1BnCML-0006x6-HM for nemo@ietf.org; Wed, 21 Jul 2004 04:21:54 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 44F355D283 for ; Wed, 21 Jul 2004 17:21:02 +0900 (JST) Date: Wed, 21 Jul 2004 17:20:46 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] comments on draft-ietf-nemo-terminology Message-Id: <20040721172046.7ff91e1e.ernst@sfc.wide.ad.jp> In-Reply-To: <40FD535F.1090500@iprg.nokia.com> References: <40FD535F.1090500@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 Vijay, > I have some comments on version 01 of the terminology draft. I am not > sure if you have submitted version 02 of the draft. I've never submitted version 02, but I'm working on it, thanks to your comments (basically, I needed more comments in oder to update this draft and address all the open issues. > > Abstract > > > > This document defines a terminology for discussing network mobility > > problems and solution requirements. > > maybe the above sentence is enough for the abstract. what follows is > repeated (similar text) in the Introduction. > > > Network mobility arises when a > > router connecting an entire network to the Internet dynamically > > changes its point of attachment to the Internet therefrom causing the > > reachability of the entire network to be changed in the topology. > > Such kind of network is referred to as a mobile network. Without > > appropriate mechanisms, sessions established between nodes in the > > mobile network and the global Internet cannot be maintained while the > > mobile router changes its point of attachment. > > > > > > Within the term Mobile Network Node (MNN), we can distinguish between > > LFN, VMN and LMN. > > the terms LFN, VMN and LMN are introduced here without expanding them. > > > 3.3 MONET [DEPRECIATED] > > s/DEPRECIATED/DEPRECATED/ > > > > > 3.5 Egress Interface (E-face) > > > > As defined in [2]) > > > > 3.6 Ingress Interface (I-face) > > > > As defined in [2]) > > lets not re-define these two terms. Ingress and Egress are widely used > terms and everybody understands them. I don't understand your point. It's not re-defined, it's just listed, saying report to [2] for the proper definition. > > 3.7 NEMO-prefix (MNP) > > > > An acronym for Mobile Network Prefix (as defined in [2]) > > why introduce this term if we are not re-defining it? MNP has been > widely used on the mailing list and in the NEMO Basic Support spec. I > prefer MNP (Mobile Network Prefix) over NEMO-prefix. This is an abbreviation for Mobile Network Prefix, so the defintion is the one in "Mobile Network Prefix". May be I can state this in a different way. regarding NEMO-Prefix vs MNP, this is a long history of mails (I cannot point the month, nor the subject line without doing a search - I don't have time for it know, so if someone knows, please post this to us). Alexandru has constantly opposed NEMO-Prefix, as TJ, if I recall, but some have supported NEMO-Prefix if I'm not mistaken. In any case, I proposed this term at the IETF meeting and there was no opposition. So, what's the purpose of the meetings if people don't oppose to the propositions made there ? > > 3.8 NEMO-link > > > > A link (subnet) located within the mobile network. > > including nested mobile networks? Don't know. We may need to ellaborate on the ML. > > > > 3.10 Node behind the MR > > > > Any MNN located in a mobile network, beside the MRs connecting the > > mobile network to the Internet. > > this is not a term. I think this should be removed. It's true it's not a term, but many people use this expression in papers, etc, so it makes sense to tell what that means. May be another section would be more appropriate. > > 3.14 NEMO-enabled (NEMO-node) > > > > A node that has been extended with network mobility support > > capabilities and that may take special actions based on that (details > > of the capabilities are not known yet, but it may be implementing > > some sort of Route Optimization). > > I had a hard time understanding this section. does the node do some > kind of Route Optimization inside the Mobile Network (without > involving a Mobile IPv6 Home Agent)? if there was some discussion > regarding this on the mailing list, please let me know. MR is a NEMO-enabled node. Thanks to NEMO Basic Support, MNNs are not needed to be NEMO-enabled. With RO, we don't know yet. So, to answer your question, the assumed extensions are not necessarily for RO. I think the definition is pretty clear, but I would consider suggestions, otherwise. > > 7.5 Mobile Aggregated Prefix > > > > An aggregation of Mobile Network Prefixes. > > > > 7.6 Aggregated Home Network > > > > The Home Network associated with a Mobile Aggregated Prefix. This > > Aggregation is advertised as a subnet on the Home Link, and thus used > > as Home Network for Nemo purposes. > > > > 7.7 Extended Home Network > > > > The network associated with the aggregation of one or more Home > > Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home > > Network that is a subnet, the extended Home Network is an aggregation > > and is further subnetted. > > > > 7.8 Virtual Home Network > > > > The Home Network associated with a Virtual Network. The Extended Home > > Network and the Aggregated Home Network can be configured as Virtual > > Home Network. > > the above four terms to appear only in > draft-ietf-nemo-home-network-models. it is hard to explain these terms > without figures. the above four terms, as they are currently described > in the terminology draft will only mystify the readers. OK, I would like the authors of draft-ietf-nemo-home-network-model to speak one voice. I've put this text here after it was suggested to do it. I still believe it's the right place. I'm not sure that draft-ietf-nemo-home-network-model will be the only document to use these terms in the future. Who knows, it could be used in RO Analysis, Multihoming analysis, Nested Analysis. I personnaly vote to include all WG terms that we are aware if in draft-ietf-nemo-terminology. > > - Added TMLR as depreciated term (everyone should use root-MR > > instead) > > replace with > - Deprecated TLMR. > > > - Added NEMO-prefix > > this I disagree with. I think MNP should be used. Let's see what other people think. To me, the debate was closed since NEMO-Prefix was proposed (and accepted [no opposition is supposed to be acceptation or not ?]) at the IETF. Thierry. From nemo-bounces@ietf.org Wed Jul 21 04:49: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 EAA29077 for ; Wed, 21 Jul 2004 04:49: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 1BnCbu-0003xq-DA; Wed, 21 Jul 2004 04:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnCSx-0006gd-94 for nemo@megatron.ietf.org; Wed, 21 Jul 2004 04:28: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 EAA27711 for ; Wed, 21 Jul 2004 04:28: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 1BnCTG-00072j-8q for nemo@ietf.org; Wed, 21 Jul 2004 04:29:02 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 24D775D2B9; Wed, 21 Jul 2004 17:28:11 +0900 (JST) Date: Wed, 21 Jul 2004 17:27:55 +0900 From: Thierry Ernst To: nemo Message-Id: <20040721172755.22f410b6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: tj Subject: [nemo] WG last call on draft-ietf-nemo-terminology-01 and draft-ietf-requirements-02.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 Dear all, I would like to explicitly elicit your comments on draft-ietf-nemo-terminology-01 and draft-ietf-nemo-requirements-02.txt so that I can revise the draft and send it to the IESG (as Informational). I will keep a track of the issues you raise on the ML. Please take a look at: http://www.sfc.wide.ad.jp/~ernst/nemo/ To raise issues, please sent a mail to the NEMO ML and put an appropriate subject line. I recommend: For draft-..-terminology: e.g. "LC-Term: NEMO-Prefix vs MNP" For draft-...-requirements: e.g. "LC-Req: One-Liner Requirements" I will be away for a long week-end, so don't be surprised your issues don't show on the page quickly. I will mostly deal with that next week. Thierry. From nemo-bounces@ietf.org Wed Jul 21 08:50: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 IAA14254 for ; Wed, 21 Jul 2004 08:50: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 1BnGWj-0004qh-2e; Wed, 21 Jul 2004 08:48:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnGUp-0003hE-O7 for nemo@megatron.ietf.org; Wed, 21 Jul 2004 08:46: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 IAA13929 for ; Wed, 21 Jul 2004 08:46:53 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnGVA-0002BD-OV for nemo@ietf.org; Wed, 21 Jul 2004 08:47:17 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6LCiDd5027205; Wed, 21 Jul 2004 20:44:13 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id D4550B24138; Wed, 21 Jul 2004 20:53:29 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1090414409.26287.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 20:53:29 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , 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: 7bit Hello marcelo, some responses to your comment on Appendix B. On Tue, 2004-07-20 at 18:22, marcelo bagnulo braun wrote: > Hi, > It is stated that: > > In the case where multiple MRs are on the mobile network, each MR has > to detect the presence of other MR. A MR can do so by listening for > Router Advertisement message on its *ingress* interfaces. > > In can see that this covers the case where both MR are on the same > link. However, what if the MRs are in different links, would this be > enough or using routing protocols is needed? > When two MRs are on different links, this implies there must be a third router within the NEMO, right? Anycase, this is a bit complicated, as you now thread into nested NEMO. More serious thought need to into it, but I suspect we might end up re-inventing MANET if one goes deeper into such cases. Suffice to say that the mechanism in Appendix B would not work if only one MR is advertising a global route on any link of the NEMO. > - Appendix B.2 > > It is stated that: > > When a MR detects that the link be which its current bi-directional > tunnel with its HA is using is down, > > i think this needs some rephrasing Yep, like "be"->"by" > > - Appendix B.2.2 > > AFAIU, in this section is being assumed that each MR has a different > nemo-prefix assigned, is this correct? Not really. No assumption is made on the number of prefixes. > I mean, what happens if there is s single nemo prefix? > What happens if there are multiple nemo prefixes but all the MR > announce all of them? > How does the MR creates a CoA of the "other" MR in this case? In the case where the other MR advertises all the prefixes it owns, there is no need to do recovery, since an alternate route exits for all the prefixes anyway (through the other MR). The MR can simply set Lifetime=0 and forces all MNNs to use the other router as their default router. No harm done. In the case where at least one prefix was not advertised by the other MR, it will autoconfigures an address based on the prefix advertised by the alternate MR, and use it as the CoA. The BU it sent will only register the prefix that was not advertised by the other MR. Any problem here? /rgds /cwng From nemo-bounces@ietf.org Wed Jul 21 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 JAA17131 for ; Wed, 21 Jul 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 1BnHFE-0001yv-3g; Wed, 21 Jul 2004 09:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnHDf-0001HH-R6 for nemo@megatron.ietf.org; Wed, 21 Jul 2004 09:33: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 JAA16855 for ; Wed, 21 Jul 2004 09:33:13 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnHE0-0002lJ-Bz for nemo@ietf.org; Wed, 21 Jul 2004 09:33:37 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 635862A0AF; Wed, 21 Jul 2004 15:34:12 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 49F472A0AC; Wed, 21 Jul 2004 15:34:12 +0200 (CEST) In-Reply-To: <1090381080.8700.38.camel@localhost> References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> <1090381080.8700.38.camel@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Date: Wed, 21 Jul 2004 15:34:12 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Eun Kyoung Paik , 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 Chan-Wah, El 21/07/2004, a las 5:38, Chan-Wah Ng escribi=F3: >> >>>> - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple >>>> NEMO-Prefixes >>>> >>>> The (n,1,n) mobile network has more than one MR advertising >>>> different >>>> global routes and different NEMO-prefixes. >>>> >>>> Why do the MRs have to announce _different_ global routes and >>>> _different_ prefixes? >>>> I mean wouldn't be possible that all the MRs announce the same=20 >>>> global >>>> routes (like a default route, for instance) and the same prefixes >>> >>> Of course that is possible, so that would be case (n,1,1). Here, we >>> just >>> list the case in order to list the issues (the issues are discussed >>> later); after that we will have to decide what are good practices = and >>> what aren't. >>> >> >> Ok, so i would suggest to remove the "different" from "different=20 >> global >> routes" and from "different NEMO-prefixes" so that the more general >> case is presented, agree? >> > > Hmm, how about: "different" -> "multiple"? Agree that MRs need not > necessarily announce different prefixes. > In this case the resulting text would be: The (n,1,n) mobile network has more than one MR advertising multiple global routes and multiple NEMO-prefixes. I wonder if this cannot be interpreted as if each one of the MR is=20 advertising more than one prefix, precluding the case where each MR=20 advertises a single prefix (each MR advertising a different prefix) I don't want to get into excesive detail with this, but perhaps=20 something like the text below can be general enough: The (n,1,n) mobile network has more than one MR and multiple global routes and multiple NEMO-prefixes are advertised. [...] > This solution has always been with the draft since its initial > incarnation (i.e. draft-ng-nemo-multihoming-issues-00.txt). I agree > that having it in a separate document is the more desirable approach. > Well as i mentioned, i guess that this approach deserves to be fully=20 developed, and all the relevant senarios need to be considered, and=20 imho an appendix is not the place to include all this detailed=20 information. Regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Wed Jul 21 10: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 KAA22449 for ; Wed, 21 Jul 2004 10: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 1BnHwC-0002mK-1s; Wed, 21 Jul 2004 10:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnHrE-0000Bk-BA for nemo@megatron.ietf.org; Wed, 21 Jul 2004 10:14: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 KAA20020 for ; Wed, 21 Jul 2004 10:14:06 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnHrZ-0003Ls-9p for nemo@ietf.org; Wed, 21 Jul 2004 10:14:31 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6LEBOfb027926; Wed, 21 Jul 2004 22:11:24 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 43356B24138; Wed, 21 Jul 2004 22:20:40 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <20040720211048.4ae88371.ernst@sfc.wide.ad.jp> <1090381080.8700.38.camel@localhost> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Laboratories Message-Id: <1090419639.26287.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 22:20:39 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i6LEBOfb027926 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Eun Kyoung Paik , 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 Hello Marcelo, On Wed, 2004-07-21 at 21:34, marcelo bagnulo braun wrote: > Hi Chan-Wah, >=20 > El 21/07/2004, a las 5:38, Chan-Wah Ng escribi=F3: > >> > >>>> - Section 2.6 (n,1,n): Multiple MRs, Single HA, Multiple > >>>> NEMO-Prefixes > >>>> > >>>> The (n,1,n) mobile network has more than one MR advertising > >>>> different > >>>> global routes and different NEMO-prefixes. > >>>> > >>>> Why do the MRs have to announce _different_ global routes and > >>>> _different_ prefixes? > >>>> I mean wouldn't be possible that all the MRs announce the same=20 > >>>> global > >>>> routes (like a default route, for instance) and the same prefixes > >>> > >>> Of course that is possible, so that would be case (n,1,1). Here, we > >>> just > >>> list the case in order to list the issues (the issues are discussed > >>> later); after that we will have to decide what are good practices a= nd > >>> what aren't. > >>> > >> > >> Ok, so i would suggest to remove the "different" from "different=20 > >> global > >> routes" and from "different NEMO-prefixes" so that the more general > >> case is presented, agree? > >> > > > > Hmm, how about: "different" -> "multiple"? Agree that MRs need not > > necessarily announce different prefixes. > > >=20 > In this case the resulting text would be: >=20 > The (n,1,n) mobile network has more than one MR advertising > multiple global routes and multiple NEMO-prefixes. >=20 > I wonder if this cannot be interpreted as if each one of the MR is=20 > advertising more than one prefix, precluding the case where each MR=20 > advertises a single prefix (each MR advertising a different prefix) > I don't want to get into excesive detail with this, but perhaps=20 > something like the text below can be general enough: >=20 > The (n,1,n) mobile network has more than one MR and > multiple global routes and multiple NEMO-prefixes are advertised. >=20 Looks good! Thanks! > [...] >=20 > > This solution has always been with the draft since its initial > > incarnation (i.e. draft-ng-nemo-multihoming-issues-00.txt). I agree > > that having it in a separate document is the more desirable approach. > > >=20 > Well as i mentioned, i guess that this approach deserves to be fully=20 > developed, and all the relevant senarios need to be considered, and=20 > imho an appendix is not the place to include all this detailed=20 > information. >=20 I'll most certainly agree.=20 /rgds /cwng From nemo-bounces@ietf.org Wed Jul 21 11:25: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 LAA26661 for ; Wed, 21 Jul 2004 11:25: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 1BnIoh-0006l4-RG; Wed, 21 Jul 2004 11:15:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnIlh-0005Y3-Ak for nemo@megatron.ietf.org; Wed, 21 Jul 2004 11: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 LAA25496 for ; Wed, 21 Jul 2004 11:12:26 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnIm2-0004E0-PA for nemo@ietf.org; Wed, 21 Jul 2004 11:12:52 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4D6342A14D; Wed, 21 Jul 2004 17:13:27 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 36D592A147; Wed, 21 Jul 2004 17:13:27 +0200 (CEST) In-Reply-To: <1090414409.26287.14.camel@localhost> References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <1090414409.26287.14.camel@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <839DB36E-DB28-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: About the multihoming solution on Appendix B (wasRe: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Date: Wed, 21 Jul 2004 17:13:26 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , 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 El 21/07/2004, a las 14:53, Chan-Wah Ng escribi=F3: > Hello marcelo, > > some responses to your comment on Appendix B. > > On Tue, 2004-07-20 at 18:22, marcelo bagnulo braun wrote: >> Hi, > >> It is stated that: >> >> In the case where multiple MRs are on the mobile network, each MR=20= >> has >> to detect the presence of other MR. A MR can do so by listening=20= >> for >> Router Advertisement message on its *ingress* interfaces. >> >> In can see that this covers the case where both MR are on the same >> link. However, what if the MRs are in different links, would this be >> enough or using routing protocols is needed? >> > > When two MRs are on different links, this implies there must be a = third > router within the NEMO, right? > > Anycase, this is a bit complicated, as you now thread into nested > NEMO. More serious thought need to into it, but I suspect we might=20= > end > up re-inventing MANET if one goes deeper into such cases. Suffice to > say that the mechanism in Appendix B would not work if only one MR is > advertising a global route on any link of the NEMO. > Well, my observation was more general. I mean, RA are link scoped, so=20 when you have more than one link, some info may be lost. In this case,=20= the info lost is the info about what router is announcing which prefix,=20= i guess. Suppose a case where you have three MR and three different=20 prefixes and each MR is in a different link and regular routers in=20 between. Suppose now that only a single MR is working, how do the other=20= MR identfy which prefix they have to use to configure the new CoA? In this case, there are three prefixes being announced and a MR whose=20 link has failed, knows that his prefix is not to be used, but it has=20 not enough info to decide which one of the other two prefixes to use to=20= configure the new CoA. Agree? You probably need a mechanism to allow a MR to withdraw its own prefix=20= when it discovers that its link is no longer working. But for this you=20= cannot use RA, you need to move to router renumbering or dhcp, i guess Another issue that it is not covered in this solution is the ingress=20 filtering compatibility. I eman, in the regular situation, when the two=20= prefixes are available, you may have problems with ingress filtering,=20 unless you use source address based routing or something similar,=20 right? i guess you need additional mechanisms to deal with this, like=20 tunnels between the MR in order to forward the packet through the MR=20 that is linked to the provider that has delegated the Nemo prefix that=20= is included in the source address of the packet. >> >> - Appendix B.2.2 >> >> AFAIU, in this section is being assumed that each MR has a different >> nemo-prefix assigned, is this correct? > > Not really. No assumption is made on the number of prefixes. > >> I mean, what happens if there is s single nemo prefix? >> What happens if there are multiple nemo prefixes but all the MR >> announce all of them? >> How does the MR creates a CoA of the "other" MR in this case? > > > In the case where the other MR advertises all the prefixes it owns, > there is no need to do recovery, since an alternate route exits for = all > the prefixes anyway (through the other MR). The MR can simply set > Lifetime=3D0 and forces all MNNs to use the other router as their = default > router. No harm done. > > In the case where at least one prefix was not advertised by the other > MR, it will autoconfigures an address based on the prefix advertised = by > the alternate MR, and use it as the CoA. The BU it sent will only > register the prefix that was not advertised by the other MR. > > Any problem here? > Well, the point is that when there is a single prefix in the nemo, you=20= don't need this solution :-), at least not all of it. You still need=20 the mechanisms to detect failures in the tunnel. Depending on the number of home agents, you may need a routing protocol=20= to discover which HA to use. Something similar happens when there are multiple prefixes but all of=20 them are supported by all the HAs. In this case, you don't need this=20 double tunneling stuff, and the mechanism that is used for the single=20 prefix case will work fine here also. In addition, you can probably optimize the double tunneling issue when=20= there is a single HA, since this HA knows both MR. imho this is a very=20= common case, especially when you are using multihoming to provide=20 ubiquity rather than fault tolerance. My point is that there are several scenarios that have different=20 approaches and require different variations/optimizations, so it would=20= be good to describe all of them and define which tools are required in=20= each scenario. makes sense to you? regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Wed Jul 21 13:16: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 NAA04725 for ; Wed, 21 Jul 2004 13:16: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 1BnKbw-0003q0-5J; Wed, 21 Jul 2004 13:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKb3-0003Yl-SV for nemo@megatron.ietf.org; Wed, 21 Jul 2004 13:09: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 NAA04216 for ; Wed, 21 Jul 2004 13:09:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnKbO-0005nw-OW for nemo@ietf.org; Wed, 21 Jul 2004 13:10:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6LH8wv32236; Wed, 21 Jul 2004 10:08:58 -0700 X-mProtect: <200407211708> 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 smtpdnGx60P; Wed, 21 Jul 2004 10:08:57 PDT Message-ID: <40FEA4AC.4050607@iprg.nokia.com> Date: Wed, 21 Jul 2004 10:15:24 -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: Thierry Ernst Subject: Re: [nemo] comments on draft-ietf-nemo-terminology References: <40FD535F.1090500@iprg.nokia.com> <20040721172046.7ff91e1e.ernst@sfc.wide.ad.jp> In-Reply-To: <20040721172046.7ff91e1e.ernst@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: 14582b0692e7f70ce7111d04db3781c8 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 Thierry Ernst wrote: >>>3.5 Egress Interface (E-face) >>> >>> As defined in [2]) >>> >>>3.6 Ingress Interface (I-face) >>> >>> As defined in [2]) >> >>lets not re-define these two terms. Ingress and Egress are widely used >>terms and everybody understands them. > > > I don't understand your point. It's not re-defined, it's just listed, > saying report to [2] for the proper definition. the objection was to E-face and I-face. RFC 3753 does not contain E-face and I-face. > >>>3.7 NEMO-prefix (MNP) >>> >>> An acronym for Mobile Network Prefix (as defined in [2]) >> >>why introduce this term if we are not re-defining it? MNP has been >>widely used on the mailing list and in the NEMO Basic Support spec. I >>prefer MNP (Mobile Network Prefix) over NEMO-prefix. > > > This is an abbreviation for Mobile Network Prefix, so the defintion is > the one in "Mobile Network Prefix". May be I can state this in a > different way. > > regarding NEMO-Prefix vs MNP, this is a long history of mails (I cannot > point the month, nor the subject line without doing a search - I don't > have time for it know, so if someone knows, please post this to us). > Alexandru has constantly opposed NEMO-Prefix, as TJ, if I recall, but > some have supported NEMO-Prefix if I'm not mistaken. In any case, I > proposed this term at the IETF meeting and there was no opposition. > > So, what's the purpose of the meetings if people don't oppose to the > propositions made there ? not everyone attends all meetings (I didnt attend the meeting in Seoul). I think decisions taken during a WG meeting do not hold until they are confirmed on the mailing list. >>>7.5 Mobile Aggregated Prefix >>> >>> An aggregation of Mobile Network Prefixes. >>> >>>7.6 Aggregated Home Network >>> >>> The Home Network associated with a Mobile Aggregated Prefix. This >>> Aggregation is advertised as a subnet on the Home Link, and thus used >>> as Home Network for Nemo purposes. >>> >>>7.7 Extended Home Network >>> >>> The network associated with the aggregation of one or more Home >>> Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home >>> Network that is a subnet, the extended Home Network is an aggregation >>> and is further subnetted. >>> >>>7.8 Virtual Home Network >>> >>> The Home Network associated with a Virtual Network. The Extended Home >>> Network and the Aggregated Home Network can be configured as Virtual >>> Home Network. >> >>the above four terms to appear only in >>draft-ietf-nemo-home-network-models. it is hard to explain these terms >>without figures. the above four terms, as they are currently described >>in the terminology draft will only mystify the readers. > > > OK, I would like the authors of draft-ietf-nemo-home-network-model to > speak one voice. I've put this text here after it was suggested to do > it. I still believe it's the right place. I'm not sure that > draft-ietf-nemo-home-network-model will be the only document to use > these terms in the future. Who knows, it could be used in RO Analysis, > Multihoming analysis, Nested Analysis. it should atleast say, the details are in the home-network-models draft. the way the terms appear here is too cryptic for the readers. you definitely need figures to explain these terms. > I personnaly vote to include all WG terms that we are aware if in > draft-ietf-nemo-terminology. I am not so sure about that. a terminology draft is good as an handy reference. IMHO, each draft that describes a protocol (especially Proposed Standards) should be self-contained. Vijay From nemo-bounces@ietf.org Wed Jul 21 22:27: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 WAA24534 for ; Wed, 21 Jul 2004 22:27: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 1BnTCA-0004yT-EV; Wed, 21 Jul 2004 22:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnT9o-0002vQ-M9 for nemo@megatron.ietf.org; Wed, 21 Jul 2004 22:18: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 WAA23966 for ; Wed, 21 Jul 2004 22:18:02 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnTAH-0000km-9r for nemo@ietf.org; Wed, 21 Jul 2004 22:18:34 -0400 Received: from psl.com.sg ([10.81.113.126]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6M2FNqe006458 for ; Thu, 22 Jul 2004 10:15:24 +0800 (SGT) Message-ID: <40FF243E.7030300@psl.com.sg> Date: Thu, 22 Jul 2004 10:19:42 +0800 From: Benjamin Koh Tien-Ming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] New draft submitted: draft-koh-dihap-00.txt References: <40F34EF4.6080007@psl.com.sg> <20040721164153.25858f62.kuntz@sfc.wide.ad.jp> In-Reply-To: <20040721164153.25858f62.kuntz@sfc.wide.ad.jp> X-Enigmail-Version: 0.83.3.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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi! Thanks for the feedback! Replies inline. Regards, Ben Romain KUNTZ wrote: > Hi, > > On Tue, 13 Jul 2004 10:54:44 +0800 > Benjamin Koh Tien-Ming wrote: > > >>A new draft was submitted and can be found at: >>http://www.ietf.org/internet-drafts/draft-koh-dihap-00.txt >> >>All feedback are welcome! > > > I have just a question about this draft: > - Once the MN changed its home agent, how does the packets from a CN are > routed to the new home agent ? I mean, unless the MN changes its home > address, the CN will go on sending packets to the former home network! > If the MN changes its home address, current transport sessions between > MN and CN are terminated... Maybe I missed something reading the draft? No, this is a problem. Currently I'm unsure as to how the internet routing fabric will turn out. Will the MN be allowed to maintain its home address in a geographical/hierarchical different location? I did not explicitly tackle this question as I'm still not sure to the answer. If all IPv6 prefixes are to be hierarchical then it is likely that the MN has to change its home address. However, if similar IPv6 prefixes are allowed to be scattered then it's possible for the new HA to also advertise for MN in its new vicinity. > - If Home Agents operates in solo mode, I guess each HA has to update > all others HA Home Interface List each time its own Home Interface List > change, otherwise HAs will not be synchronised. Isn't it a little bit > too expensive ? The HA is only responsible for it's own Home Interface List (HIL). If it detects a nearby visiting MN (VMN), it informs the current HA of the VMN periodically for as long as the VMN is still in the vicinity (detectable). In solo operation, HAs do not need to update each others HIL unless it fulfils the above scenario (detects VMN). Did I answer your question? If I understand it wrongly please correct me. Thanks! > Best regards, > From nemo-bounces@ietf.org Wed Jul 21 23:23: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 XAA28366 for ; Wed, 21 Jul 2004 23:23: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 1BnU4s-0002PD-Dw; Wed, 21 Jul 2004 23:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnU2x-0001et-1Z for nemo@megatron.ietf.org; Wed, 21 Jul 2004 23:15: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 XAA27945 for ; Wed, 21 Jul 2004 23:15:00 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnU3P-0001bI-Jd for nemo@ietf.org; Wed, 21 Jul 2004 23:15:32 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6M3CLkR008477; Thu, 22 Jul 2004 11:12:21 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 5FD96B24126; Thu, 22 Jul 2004 11:21:37 +0800 (SGT) Subject: Re: About the multihoming solution on Appendix B (wasRe: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: <839DB36E-DB28-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> <1090414409.26287.14.camel@localhost> <839DB36E-DB28-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Laboratories Message-Id: <1090466496.8906.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 22 Jul 2004 11:21:36 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i6M3CLkR008477 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , 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 On Wed, 2004-07-21 at 23:13, marcelo bagnulo braun wrote: > El 21/07/2004, a las 14:53, Chan-Wah Ng escribi=F3: >=20 > > Hello marcelo, > > > > some responses to your comment on Appendix B. > > > > On Tue, 2004-07-20 at 18:22, marcelo bagnulo braun wrote: > >> Hi, > > > >> It is stated that: > >> > >> In the case where multiple MRs are on the mobile network, each M= R=20 > >> has > >> to detect the presence of other MR. A MR can do so by listening= =20 > >> for > >> Router Advertisement message on its *ingress* interfaces. > >> > >> In can see that this covers the case where both MR are on the same > >> link. However, what if the MRs are in different links, would this be > >> enough or using routing protocols is needed? > >> > > > > When two MRs are on different links, this implies there must be a thi= rd > > router within the NEMO, right? > > > > Anycase, this is a bit complicated, as you now thread into nested > > NEMO. More serious thought need to into it, but I suspect we might=20 > > end > > up re-inventing MANET if one goes deeper into such cases. Suffice to > > say that the mechanism in Appendix B would not work if only one MR is > > advertising a global route on any link of the NEMO. > > >=20 >=20 > Well, my observation was more general. I mean, RA are link scoped, so=20 > when you have more than one link, some info may be lost. In this case,=20 > the info lost is the info about what router is announcing which prefix,= =20 > i guess. Suppose a case where you have three MR and three different=20 > prefixes and each MR is in a different link and regular routers in=20 > between. Suppose now that only a single MR is working, how do the other= =20 > MR identfy which prefix they have to use to configure the new CoA? > In this case, there are three prefixes being announced and a MR whose=20 > link has failed, knows that his prefix is not to be used, but it has=20 > not enough info to decide which one of the other two prefixes to use to= =20 > configure the new CoA. > Agree? Yes. > You probably need a mechanism to allow a MR to withdraw its own prefix=20 > when it discovers that its link is no longer working. But for this you=20 > cannot use RA, you need to move to router renumbering or dhcp, i guess >=20 That is one area I wish to avoid (to keep the solution simple), but from our discussion it seems unavoidable. > Another issue that it is not covered in this solution is the ingress=20 > filtering compatibility. I eman, in the regular situation, when the two= =20 > prefixes are available, you may have problems with ingress filtering,=20 > unless you use source address based routing or something similar,=20 > right? i guess you need additional mechanisms to deal with this, like=20 > tunnels between the MR in order to forward the packet through the MR=20 > that is linked to the provider that has delegated the Nemo prefix that=20 > is included in the source address of the packet. Point noted. > >> >=20 > >> - Appendix B.2.2 > >> > >> AFAIU, in this section is being assumed that each MR has a different > >> nemo-prefix assigned, is this correct? > > > > Not really. No assumption is made on the number of prefixes. > > > >> I mean, what happens if there is s single nemo prefix? > >> What happens if there are multiple nemo prefixes but all the MR > >> announce all of them? > >> How does the MR creates a CoA of the "other" MR in this case? > > > > > > In the case where the other MR advertises all the prefixes it owns, > > there is no need to do recovery, since an alternate route exits for a= ll > > the prefixes anyway (through the other MR). The MR can simply set > > Lifetime=3D0 and forces all MNNs to use the other router as their def= ault > > router. No harm done. > > > > In the case where at least one prefix was not advertised by the other > > MR, it will autoconfigures an address based on the prefix advertised = by > > the alternate MR, and use it as the CoA. The BU it sent will only > > register the prefix that was not advertised by the other MR. > > > > Any problem here? > > >=20 > Well, the point is that when there is a single prefix in the nemo, you=20 > don't need this solution :-), at least not all of it. You still need=20 > the mechanisms to detect failures in the tunnel. > Depending on the number of home agents, you may need a routing protocol= =20 > to discover which HA to use. > Something similar happens when there are multiple prefixes but all of=20 > them are supported by all the HAs. In this case, you don't need this=20 > double tunneling stuff, and the mechanism that is used for the single=20 > prefix case will work fine here also. >=20 > In addition, you can probably optimize the double tunneling issue when=20 > there is a single HA, since this HA knows both MR. imho this is a very=20 > common case, especially when you are using multihoming to provide=20 > ubiquity rather than fault tolerance. >=20 > My point is that there are several scenarios that have different=20 > approaches and require different variations/optimizations, so it would=20 > be good to describe all of them and define which tools are required in=20 > each scenario. >=20 > makes sense to you? >=20 Yes. Great, thank you for these discussions, it certainly helps me to see how the solution should be further developed. /rgds /cwng From nemo-bounces@ietf.org Thu Jul 22 21:25: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 VAA06956 for ; Thu, 22 Jul 2004 21:25: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 1BnobP-0000XO-BW; Thu, 22 Jul 2004 21:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnoUk-00064K-Ir for nemo@megatron.ietf.org; Thu, 22 Jul 2004 21:05: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 VAA05862 for ; Thu, 22 Jul 2004 21:05:04 -0400 (EDT) Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnoVP-00037O-8P for nemo@ietf.org; Thu, 22 Jul 2004 21:05:48 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i6N14d029885; Fri, 23 Jul 2004 10:04:39 +0900 (JST) Received: from pbg4.local.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i6N13bs27523; Fri, 23 Jul 2004 10:03:37 +0900 (JST) Date: Fri, 23 Jul 2004 10:04:36 +0900 Message-ID: From: Nobuo OGASHIWA To: nemo Subject: Re: [nemo] Draft Agenda and CFP In-Reply-To: <20040712184738.62b08869.ernst@sfc.wide.ad.jp> References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Thierry Ernst , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted an updated draft. http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome-fixed-network-01.txt Abstract Multi-homing technology improves the availability of host and network connectivity. Since the node and network behavior of mobile networking and fixed networking are different, the different architecture has been discussed and proposed. This document proposes the common architecture both for mobile and fixed networking environment, using the mobile IP and NEMO. The proposed architecture only requires a modification of the mobile IP and NEMO so that multiple-CoA can be used. In addition, multiple HAs which are located in different place, are required for redundancy. It is nice if we can have a presentation solot for the draft. We have sent a request to WG chairs. We appreciate any comments, questions or suggestions. Regards, Nobuo Ogashiwa At Mon, 12 Jul 2004 18:47:38 +0900, Thierry Ernst wrote: > > > > 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 > - 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 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 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 responsability > of the author to send a note to the NEMO ML. > > Regards, > NEMO Chairs. > > From nemo-bounces@ietf.org Fri Jul 23 06:22: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 GAA07595 for ; Fri, 23 Jul 2004 06:22: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 1Bnx6M-0004ir-Up; Fri, 23 Jul 2004 06:16:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnwxs-00086g-Vc for nemo@megatron.ietf.org; Fri, 23 Jul 2004 06:07: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 GAA06670 for ; Fri, 23 Jul 2004 06:07:42 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnwyP-0002VU-OT for nemo@ietf.org; Fri, 23 Jul 2004 06:08:31 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 722DA27511; Fri, 23 Jul 2004 11:09:00 +0200 (CEST) Received: from [163.117.139.233] (unknown [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 5D679274F5; Fri, 23 Jul 2004 11:09:00 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Fri, 23 Jul 2004 12:08:31 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Nobuo, some comments about this draft First of all, i am not sure i understand if this work really belongs to =20= this working group... I mean the tittle is: Multi-homing for small scale fixed network Using =20= Mobile IP and NEMO this is also stated in section 1- Motivation when it is stated that: Therefore, we propose a multi-homing architecture using the mobile IP and NEMO for small-scale fixed network. Along the rest of the document the focus is to the fixed network case, =20= like for instance in section 1.3, it is explicitly stated that the nemo =20= protocol will be used in fixed networks So this solution is for "fixed" network, not for nemo, right? it uses =20= the nemo basic support protocol but it is not a solution for a =20 multihomed nemo, right? If this is so, i don't thing this draft belongs to this wg Second, this draft presents two scenarios: - First with a single HA. In this case, the single HA (and its site) is =20= single point of failure, so the fault tolerance gaol is not fulfill - Second the case with multiple HA geographically distributed. In order =20= to work, this requires that each HA announces the multihomed network =20 prefix to the interdomain routing, which clearly beats the scalability =20= goal. So i fail to understand the benefit of this solution w.r.t. announcing =20= the prefix through multiple ISPs by the endsite in terms of scalability Regards, marcelo El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=F3: > > Dear all, > > We have submitted an updated draft. > > =20 > http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome-=20= > fixed-network-01.txt > > Abstract > > Multi-homing technology improves the availability of host and > network connectivity. Since the node and network behavior of > mobile networking and fixed networking are different, the > different architecture has been discussed and proposed. This > document proposes the common architecture both for mobile and > fixed networking environment, using the mobile IP and NEMO. The > proposed architecture only requires a modification of the mobile > IP and NEMO so that multiple-CoA can be used. In addition, > multiple HAs which are located in different place, are required > for redundancy. > > > It is nice if we can have a presentation solot for the draft. > We have sent a request to WG chairs. > > We appreciate any comments, questions or suggestions. > > > Regards, > > Nobuo Ogashiwa > > > > At Mon, 12 Jul 2004 18:47:38 +0900, > Thierry Ernst wrote: >> >> >> >> 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 >> - 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 =20= >> 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. >> >> > From nemo-bounces@ietf.org Fri Jul 23 11:44: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 LAA03659 for ; Fri, 23 Jul 2004 11:44: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 1Bo22t-0005Ma-Gs; Fri, 23 Jul 2004 11: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 1Bo1yj-0002v0-Cd for nemo@megatron.ietf.org; Fri, 23 Jul 2004 11:28: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 LAA01996 for ; Fri, 23 Jul 2004 11:28:54 -0400 (EDT) Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo1zN-0000Ct-DM for nemo@ietf.org; Fri, 23 Jul 2004 11:29:46 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i6NFSf020073; Sat, 24 Jul 2004 00:28:42 +0900 (JST) Received: from dhcp209.inetcore.com.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i6NFRds05407; Sat, 24 Jul 2004 00:27:39 +0900 (JST) Date: Sat, 24 Jul 2004 00:28:38 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <4043F4C2-DC90-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 Dear Marcelo, Please read inline comments. At Fri, 23 Jul 2004 12:08:31 +0200, marcelo bagnulo braun wrote: > > Hi Nobuo, > > some comments about this draft > > First of all, i am not sure i understand if this work really belongs to > this working group... > I mean the tittle is: Multi-homing for small scale fixed network Using > Mobile IP and NEMO > > this is also stated in section 1- Motivation when it is stated that: > > Therefore, we propose a multi-homing > architecture using the mobile IP and NEMO for small-scale fixed > network. > > Along the rest of the document the focus is to the fixed network case, > like for instance in section 1.3, it is explicitly stated that the nemo > protocol will be used in fixed networks > > So this solution is for "fixed" network, not for nemo, right? it uses > the nemo basic support protocol but it is not a solution for a > multihomed nemo, right? > > If this is so, i don't thing this draft belongs to this wg I think that our architecture is an one of application of the NEMO. The draft describes requirements to the NEMO and solutions for practical deployment of the NEMO from the viewpoint of one of NEMO application. I mean, I think that the value of our draft is just like value of scenarios docments. Secondly, the one of purposes of our architecture is redundancy. The draft is focusing a fixed network, however, the solution can be applyed to both fixed and mobile network. Moreover, changing upstream ISP keeping network connectivity in case of fixed network is just like movement of a network. I think this is a kind of network mobility and is an one of important application of NEMO. These are why I think this draft belongs to the NEMO wg. > Second, this draft presents two scenarios: > - First with a single HA. In this case, the single HA (and its site) is > single point of failure, so the fault tolerance gaol is not fulfill Yes. Right. > - Second the case with multiple HA geographically distributed. In order > to work, this requires that each HA announces the multihomed network > prefix to the interdomain routing, which clearly beats the scalability > goal. > So i fail to understand the benefit of this solution w.r.t. announcing > the prefix through multiple ISPs by the endsite in terms of scalability I don't know why you think "which clearly beats the scalability goal", and I'm not sure what kind of scalability you are describing above line. As we mentioned in the draft, mobile network prefixes can be aggregated when advartisement. Therefore, there is no problem with a scalability of number of route entries. Sorry if I miss understand what you attempt to point out. It would be nice if you point out lack of description or unclear description in the draft. Regards, Nobuo Ogashiwa > > > Regards, marcelo > > > El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > > > > > Dear all, > > > > We have submitted an updated draft. > > > > > > http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome- > > fixed-network-01.txt > > > > Abstract > > > > Multi-homing technology improves the availability of host and > > network connectivity. Since the node and network behavior of > > mobile networking and fixed networking are different, the > > different architecture has been discussed and proposed. This > > document proposes the common architecture both for mobile and > > fixed networking environment, using the mobile IP and NEMO. The > > proposed architecture only requires a modification of the mobile > > IP and NEMO so that multiple-CoA can be used. In addition, > > multiple HAs which are located in different place, are required > > for redundancy. > > > > > > It is nice if we can have a presentation solot for the draft. > > We have sent a request to WG chairs. > > > > We appreciate any comments, questions or suggestions. > > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > > > > At Mon, 12 Jul 2004 18:47:38 +0900, > > Thierry Ernst wrote: > >> > >> > >> > >> 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 > >> - 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 > >> 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 > >> 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 > >> responsability > >> of the author to send a note to the NEMO ML. > >> > >> Regards, > >> NEMO Chairs. > >> > >> > > > From nemo-bounces@ietf.org Fri Jul 23 12:33: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 MAA07543 for ; Fri, 23 Jul 2004 12:33: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 1Bo2sO-00031U-Ou; Fri, 23 Jul 2004 12:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo2lC-00084H-L8 for nemo@megatron.ietf.org; Fri, 23 Jul 2004 12:19: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 MAA06261 for ; Fri, 23 Jul 2004 12:18:59 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo2lz-0001KA-Id for nemo@ietf.org; Fri, 23 Jul 2004 12:19:52 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF6AE2755D; Fri, 23 Jul 2004 17:20:30 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp02.uc3m.es (Postfix) with ESMTP id 9CE6627526; Fri, 23 Jul 2004 17:20:30 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Fri, 23 Jul 2004 18:20:02 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 >> Second, this draft presents two scenarios: >> - First with a single HA. In this case, the single HA (and its site) >> is >> single point of failure, so the fault tolerance gaol is not fulfill > > Yes. Right. > >> - Second the case with multiple HA geographically distributed. In >> order >> to work, this requires that each HA announces the multihomed network >> prefix to the interdomain routing, which clearly beats the scalability >> goal. >> So i fail to understand the benefit of this solution w.r.t. announcing >> the prefix through multiple ISPs by the endsite in terms of >> scalability > > I don't know why you think "which clearly beats the scalability goal", > and I'm not sure what kind of scalability you are describing above > line. > > As we mentioned in the draft, mobile network prefixes can be aggregated > when advartisement. Therefore, there is no problem with a scalability > of > number of route entries. > > Sorry if I miss understand what you attempt to point out. > It would be nice if you point out lack of description or unclear > description in the draft. > > ok, perhaps i am misunderstanding something here... are you assuming that the HA belongs to the ISP network or to the end site? when there are multiple HAs, are you assuming that they belong to the the same ISP, to different ISPs or to the end site? regards, marcelo > > Regards, > > Nobuo Ogashiwa > >> >> >> Regards, marcelo >> >> >> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: >> >>> >>> Dear all, >>> >>> We have submitted an updated draft. >>> >>> >>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome- >>> fixed-network-01.txt >>> >>> Abstract >>> >>> Multi-homing technology improves the availability of host and >>> network connectivity. Since the node and network behavior of >>> mobile networking and fixed networking are different, the >>> different architecture has been discussed and proposed. This >>> document proposes the common architecture both for mobile and >>> fixed networking environment, using the mobile IP and NEMO. The >>> proposed architecture only requires a modification of the mobile >>> IP and NEMO so that multiple-CoA can be used. In addition, >>> multiple HAs which are located in different place, are required >>> for redundancy. >>> >>> >>> It is nice if we can have a presentation solot for the draft. >>> We have sent a request to WG chairs. >>> >>> We appreciate any comments, questions or suggestions. >>> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>> >>> At Mon, 12 Jul 2004 18:47:38 +0900, >>> Thierry Ernst wrote: >>>> >>>> >>>> >>>> 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 >>>> - 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 >>>> 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 >>>> 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 >>>> responsability >>>> of the author to send a note to the NEMO ML. >>>> >>>> Regards, >>>> NEMO Chairs. >>>> >>>> >>> >> > > From nemo-bounces@ietf.org Fri Jul 23 13:54: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 NAA13470 for ; Fri, 23 Jul 2004 13:54: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 1Bo4B4-0000zQ-UW; Fri, 23 Jul 2004 13:49:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo45r-0007se-NI for nemo@megatron.ietf.org; Fri, 23 Jul 2004 13:44: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 NAA11727 for ; Fri, 23 Jul 2004 13:44:26 -0400 (EDT) Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo46e-0002qv-1W for nemo@ietf.org; Fri, 23 Jul 2004 13:45:17 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i6NHiF002695; Sat, 24 Jul 2004 02:44:15 +0900 (JST) Received: from dhcp209.inetcore.com.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i6NHhDs08272; Sat, 24 Jul 2004 02:43:13 +0900 (JST) Date: Sat, 24 Jul 2004 02:44:12 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <2699A758-DCC4-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Dear Marcelo, > > > > Sorry if I miss understand what you attempt to point out. > > It would be nice if you point out lack of description or unclear > > description in the draft. > > > > ok, perhaps i am misunderstanding something here... are you assuming > that the HA belongs to the ISP network or to the end site? when there We are assuming that the HA belongs to the ISP network. > are multiple HAs, are you assuming that they belong to the the same > ISP, to different ISPs or to the end site? Basically, We are assuming that HAs belong to different ISPs when there are multiple HAs. However, you can also set up multiple HAs in same ISP. Regards, Nobuo Ogashiwa > > regards, marcelo > > > > > > > Regards, > > > > Nobuo Ogashiwa > > > >> > >> > >> Regards, marcelo > >> > >> > >> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >> > >>> > >>> Dear all, > >>> > >>> We have submitted an updated draft. > >>> > >>> > >>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome- > >>> fixed-network-01.txt > >>> > >>> Abstract > >>> > >>> Multi-homing technology improves the availability of host and > >>> network connectivity. Since the node and network behavior of > >>> mobile networking and fixed networking are different, the > >>> different architecture has been discussed and proposed. This > >>> document proposes the common architecture both for mobile and > >>> fixed networking environment, using the mobile IP and NEMO. The > >>> proposed architecture only requires a modification of the mobile > >>> IP and NEMO so that multiple-CoA can be used. In addition, > >>> multiple HAs which are located in different place, are required > >>> for redundancy. > >>> > >>> > >>> It is nice if we can have a presentation solot for the draft. > >>> We have sent a request to WG chairs. > >>> > >>> We appreciate any comments, questions or suggestions. > >>> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>> > >>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>> Thierry Ernst wrote: > >>>> > >>>> > >>>> > >>>> 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 > >>>> - 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 > >>>> 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 > >>>> 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 > >>>> responsability > >>>> of the author to send a note to the NEMO ML. > >>>> > >>>> Regards, > >>>> NEMO Chairs. > >>>> > >>>> > >>> > >> > > > > > From nemo-bounces@ietf.org Fri Jul 23 17: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 RAA27974 for ; Fri, 23 Jul 2004 17: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 1Bo7IG-0008Bq-K1; Fri, 23 Jul 2004 17: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 1Bo7EM-0007DS-RO for nemo@megatron.ietf.org; Fri, 23 Jul 2004 17:05: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 RAA27318 for ; Fri, 23 Jul 2004 17:05:24 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo7FB-0006ig-MG for nemo@ietf.org; Fri, 23 Jul 2004 17:06:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6NKvg532124; Fri, 23 Jul 2004 13:57:42 -0700 X-mProtect: <200407232057> 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 smtpdYlx9eZ; Fri, 23 Jul 2004 13:57:40 PDT Message-ID: <41017D52.7090504@iprg.nokia.com> Date: Fri, 23 Jul 2004 14:04:18 -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: souhwanj@ssu.ac.kr, IETF NEMO WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [nemo] comments on draft-jung-nemo-threat-analysis X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, a couple of comments on draft-jung-nemo-threat-analysis section 3.2.1 describes an attack where a MNN uses another MNN's source address to tunnel packets through the MR-HA tunnel. is this specific to NEMO? how is it different from a node A using another node's (say node B) source address, both being on the same link? section 4.1 > If one of the tunnel paths is broken for any reason, the MR(MR1) associated > with the faulty path loses Internet connection, and should find an > alternative bi-directional tunnel path through another MR2. In this case, > MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD > not respond to the unsolicited RA messages to its egress interface, > but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD > listen the RA from alternative MR2 on its ingress interface. > At this point, a malicious MR may advertise a RA with a fake CoA to MR1. > Then the MR1 will get a wrong CoA information. couldnt understand the statement "MR SHOULD not respond to the unsolicted RA message to its egress interface". infact NEMO basic support says (section 5.6) However, a Mobile Router MUST NOT ignore Router Advertisements received on the egress interface. Vijay From nemo-bounces@ietf.org Sat Jul 24 09:06:42 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 JAA18268 for ; Sat, 24 Jul 2004 09:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoMD0-0007V4-Li; Sat, 24 Jul 2004 09:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoMC3-0007M9-JL for nemo@megatron.ietf.org; Sat, 24 Jul 2004 09:04: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 JAA18097 for ; Sat, 24 Jul 2004 09:04:02 -0400 (EDT) Received: from [203.253.31.197] (helo=ssu.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BoMCz-0008UQ-3p for nemo@ietf.org; Sat, 24 Jul 2004 09:05:04 -0400 Received: from ssu.ac.kr by ietf.org with ESMTP (BeeHive 1.4.1) for nemo@ietf.org; Sat, 24 Jul 2004 22:03:55 +0900 Message-ID: <007801c4717e$abd35bb0$4f01a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" , "IETF NEMO WG" References: <41017D52.7090504@iprg.nokia.com> Date: Sat, 24 Jul 2004 22:00:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: base64 Subject: [nemo] Re: comments on draft-jung-nemo-threat-analysis X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: base64 SGkgVmlqYXksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NClBsZWFzZSBzZWUgbXkgYW5z d2VyIGluIGJldHdlZW4gdGhlIGxpbmVzLg0KDQo+IGEgY291cGxlIG9mIGNvbW1lbnRzIG9uIGRy YWZ0LWp1bmctbmVtby10aHJlYXQtYW5hbHlzaXMNCj4gDQo+IHNlY3Rpb24gMy4yLjEgZGVzY3Jp YmVzIGFuIGF0dGFjayB3aGVyZSBhIE1OTiB1c2VzIGFub3RoZXIgTU5OJ3MNCj4gc291cmNlIGFk ZHJlc3MgdG8gdHVubmVsIHBhY2tldHMgdGhyb3VnaCB0aGUgTVItSEEgdHVubmVsLiBpcw0KPiB0 aGlzIHNwZWNpZmljIHRvIE5FTU8/IGhvdyBpcyBpdCBkaWZmZXJlbnQgZnJvbSBhIG5vZGUgQSB1 c2luZw0KPiBhbm90aGVyIG5vZGUncyAoc2F5IG5vZGUgQikgc291cmNlIGFkZHJlc3MsIGJvdGgg YmVpbmcgb24gdGhlIHNhbWUNCj4gbGluaz8gDQoNCkluIE1JUDYsIHRoZXJlIGFyZSBubyBpbnRl cm1lZGlhdGUgbm9kZXMgbGlrZSBNUiBhbmQgSEEob2YgTVIpLCB0aGVyZWZvcmUsIHRoZSB2aWN0 aW0gbWF5IGVhc2lseSBsb2NhdGUgdGhlIGF0dGFja2VyIGlmIHRoZSBhdHRhY2tlciBpcyBsb2Nh dGVkIGluIHRoZSBzYW1lIGxvY2FsIGxpbmsgd2l0aCB0aGUgc3Bvb2ZlZCBub2RlLiBCdXQsIGlu IHRoZSBhdHRhY2sgSSBkZXNjcmliZWQsIHRoZSB2aWN0aW0gaGFzIG5vIHdheSB0byBsb2NhdGUg dGhlIGF0dGFja2VyLCBiZWNhdXNlIHRoZSBzcG9vZmVkIGFkZHJlc3MgY291bGQgYmUgdGhlIGFk ZHJlc3Mgb2YgYW55IG5vZGUgaW4gdGhlIEludGVybmV0LiBJIHRoaW5rIHRoaXMgbWFrZXMgYSBi aWcgZGlmZmVyZW5jZSBmcm9tIE1JUDYgY2FzZS4NCg0KPiBzZWN0aW9uIDQuMQ0KPiANCj4gPiBJ ZiBvbmUgb2YgdGhlIHR1bm5lbCBwYXRocyBpcyBicm9rZW4gZm9yIGFueSByZWFzb24sIHRoZSBN UihNUjEpIGFzc29jaWF0ZWQgDQo+ID4gd2l0aCB0aGUgZmF1bHR5IHBhdGggbG9zZXMgSW50ZXJu ZXQgY29ubmVjdGlvbiwgYW5kIHNob3VsZCBmaW5kIGFuDQo+ID4gYWx0ZXJuYXRpdmUgYmktZGly ZWN0aW9uYWwgdHVubmVsIHBhdGggdGhyb3VnaCBhbm90aGVyIE1SMi4gSW4gdGhpcyBjYXNlLCAN Cj4gPiBNUjEgYmVjb21lcyBhIG5lc3RlZCBNUiBvZiBNUjIuIE5FTU8gYmFzaWMgZHJhZnRbM10g ZGVzY3JpYmVzIHRoYXQgTVIgU0hPVUxEIA0KPiA+IG5vdCByZXNwb25kIHRvIHRoZSB1bnNvbGlj aXRlZCBSQSBtZXNzYWdlcyB0byBpdHMgZWdyZXNzIGludGVyZmFjZSwgDQo+ID4gYnV0IGFjY29y ZGluZyB0byB0aGUgTVIgb3BlcmF0aW9ucyBieSBtdWx0aWhvbWluZyBkcmFmdCBCLjIuMiBbNl0s IHRoZSBNUjEgU0hPVUxEIA0KPiA+IGxpc3RlbiB0aGUgUkEgZnJvbSBhbHRlcm5hdGl2ZSBNUjIg b24gaXRzIGluZ3Jlc3MgaW50ZXJmYWNlLiANCj4gPiBBdCB0aGlzIHBvaW50LCBhIG1hbGljaW91 cyBNUiBtYXkgYWR2ZXJ0aXNlIGEgUkEgd2l0aCBhIGZha2UgQ29BIHRvIE1SMS4gDQo+ID4gVGhl biB0aGUgTVIxIHdpbGwgZ2V0IGEgd3JvbmcgQ29BIGluZm9ybWF0aW9uLg0KPiANCj4gY291bGRu dCB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgIk1SIFNIT1VMRCBub3QgcmVzcG9uZCB0byB0aGUN Cj4gdW5zb2xpY3RlZCBSQSBtZXNzYWdlIHRvIGl0cyBlZ3Jlc3MgaW50ZXJmYWNlIi4gaW5mYWN0 IE5FTU8NCj4gYmFzaWMgc3VwcG9ydCBzYXlzIChzZWN0aW9uIDUuNikNCj4gDQo+ICAgICBIb3dl dmVyLCBhIE1vYmlsZSBSb3V0ZXIgTVVTVCBOT1QgaWdub3JlIFJvdXRlcg0KPiAgICAgQWR2ZXJ0 aXNlbWVudHMgcmVjZWl2ZWQgb24gdGhlIGVncmVzcyBpbnRlcmZhY2UuDQo+IA0KDQpTb3JyeSBm b3Igbm90IGV4YWN0bHkgY2l0aW5nIHRoZSBzdGF0ZW1lbnRzLiBUaGUgc3RhdGVtZW50cyBJIHRy eSB0byBtZW50aW9uIGZyb20gdGhlIGJhc2ljIGRyYWZ0IGlzIChzZWN0aW9uIDUuNikNCg0KIkEg TW9iaWxlIFJvdXRlciBTSE9VTEQgTk9UIHNlbmQgdW5zb2xpY2l0ZWQgUm91dGVyIEFkdmVydGlz ZW1lbnRzDQogICBhbmQgU0hPVUxEIE5PVCByZXBseSB0byBSb3V0ZXIgU29saWNpdGF0aW9ucyBv biBhbnkgZWdyZXNzIGludGVyZmFjZQ0KICAgd2hlbiB0aGF0IGludGVyZmFjZSBpcyBhdHRhY2hl ZCB0byBhIHZpc2l0ZWQgbGluay4iDQoNCkFueXdheSwgdGhlIGZhdWx0eSBNUiBzaG91bGQgZmlu ZCB0aGUgbmVpZ2hib3IgTVIsIHRoZSBhdHRhY2sgaXMgc3RpbGwgdmFsaWQsIHJpZ2h0PyANCg0K U291aHdhbg== From nemo-bounces@ietf.org Sun Jul 25 01:28: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 BAA03207 for ; Sun, 25 Jul 2004 01:28: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 1BobT1-00022G-BF; Sun, 25 Jul 2004 01:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BobMh-0001Ua-96 for nemo@megatron.ietf.org; Sun, 25 Jul 2004 01:16: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 BAA02786 for ; Sun, 25 Jul 2004 01:16:02 -0400 (EDT) Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BobNo-0003mZ-9a for nemo@ietf.org; Sun, 25 Jul 2004 01:17:13 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i6P5EePf015600; Sun, 25 Jul 2004 05:14:41 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072513152601478 ; Sun, 25 Jul 2004 13:15:26 +0800 Received: from pgsmsx401.gar.corp.intel.com ([172.30.190.29]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jul 2004 13:15:27 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 25 Jul 2004 13:15:25 +0800 Message-ID: <777DEAB49FEBEA4D8A3DABE83697355BD7E6B3@pgsmsx401.gar.corp.intel.com> Thread-Topic: Nemo Digest, Vol 3, Issue 14 Thread-Index: AcRvN2r4DxYUpRMTQFijJmyeCvlmhACzDkrg From: "Tan, Tat Kin" To: , X-OriginalArrivalTime: 25 Jul 2004 05:15:27.0023 (UTC) FILETIME=[656D03F0:01C47206] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: Nemo Digest, Vol 3, Issue 14 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 have yet to read the new draft submitted by Benjamin but this is interesting questions. I do not know if my understanding of NEMO is good enough but I have some thoughts about this. If I would to develop based on Kuntz's questions, my another question would be like this: - Assuming MNN has been talking to CN. - CN knows the Home Address of MNN and hence sent all communication packets to MNN's Home Link. - the home agent of MNN knows the whereabouts of MNN and routed packets via a bi-derectional channels to the MR of which MNN attached to. - MNN reverse tunnel and talked to CN. Both CN and MNN does not need to know each's physical location. The Home Agent will do the routings. - Now, supposed the MR of which the MNN had moved. Per example by Kuntz, CN will have no idea of the move and continue talking to MNN via HA. HA does not know MR has moved until receiving MR's BU. - up to now, packets will be lost because MR has moved! - supposed, it will be even worst if MR moved but not MNN! MNN now become a VMN to some other Mobile Network and could then attached to some foreign MR (named MR2) My question would be,=20 - CN still sending packets to HA, packet lost because there is a lost of the time "before BU is sent from MNN from MR2". Is this correct? - when MR moved, does the bi-directional channel move together? I do not think so cause a new CoA will be given to MR on a new link. Am I right? Cause a tunnel has an end-point address of the MR's former CoA. So again like Kuntz said, CN will still continue (or perhaps HA will still continue) sending packets to the old bi-directional channel. How would this be tackled? Apology if I m not making any sense, Cheers, Tatkin ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Jul 2004 16:41:53 +0900 From: Romain KUNTZ Subject: Re: [nemo] New draft submitted: draft-koh-dihap-00.txt To: nemo@ietf.org Message-ID: <20040721164153.25858f62.kuntz@sfc.wide.ad.jp> Content-Type: text/plain; charset=3DUS-ASCII Hi, On Tue, 13 Jul 2004 10:54:44 +0800 Benjamin Koh Tien-Ming wrote: > A new draft was submitted and can be found at: > http://www.ietf.org/internet-drafts/draft-koh-dihap-00.txt >=20 > All feedback are welcome! I have just a question about this draft: - Once the MN changed its home agent, how does the packets from a CN are routed to the new home agent ? I mean, unless the MN changes its home address, the CN will go on sending packets to the former home network! If the MN changes its home address, current transport sessions between MN and CN are terminated... Maybe I missed something reading the draft? - If Home Agents operates in solo mode, I guess each HA has to update all others HA Home Interface List each time its own Home Interface List change, otherwise HAs will not be synchronised. Isn't it a little bit too expensive ? Best regards, --=20 Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Sun Jul 25 22:35: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 WAA10649 for ; Sun, 25 Jul 2004 22:35: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 1BovI8-0003wM-Oq; Sun, 25 Jul 2004 22:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BovHe-0003pH-8q for nemo@megatron.ietf.org; Sun, 25 Jul 2004 22:32: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 WAA10434 for ; Sun, 25 Jul 2004 22:32:08 -0400 (EDT) Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BovIw-0006Qi-Q7 for nemo@ietf.org; Sun, 25 Jul 2004 22:33:31 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i6Q2Vs005248; Mon, 26 Jul 2004 11:31:54 +0900 (JST) Received: from dhcp209.inetcore.com.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i6Q2Uns13667; Mon, 26 Jul 2004 11:30:49 +0900 (JST) Date: Mon, 26 Jul 2004 11:31:51 +0900 Message-ID: From: Nobuo OGASHIWA To: Thierry Ernst , tj User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: nemo Subject: [nemo] draft 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 Dear NEMO WG chairs, Would you mind to inform us whether could we acquire a presentation slot or not? I think it would be nice if you send the draft agenda to the WG ML before the WG agenda cut-off deadline. Regards, Nobuo Ogashiwa From nemo-bounces@ietf.org Mon Jul 26 05:33: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 FAA11050 for ; Mon, 26 Jul 2004 05:33: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 1Bp1or-0007BZ-Gb; Mon, 26 Jul 2004 05:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp1lV-0006T5-I4 for nemo@megatron.ietf.org; Mon, 26 Jul 2004 05:27: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 FAA10799 for ; Mon, 26 Jul 2004 05:27:22 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp1mq-0002kw-PT for nemo@ietf.org; Mon, 26 Jul 2004 05:28:50 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9F3BF3A0DA; Mon, 26 Jul 2004 11:26:51 +0200 (CEST) Received: from [163.117.139.233] (unknown [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 8605B3A0D9; Mon, 26 Jul 2004 11:26:51 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Mon, 26 Jul 2004 11:28:29 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable El 23/07/2004, a las 19:44, Nobuo OGASHIWA escribi=C3=B3: > > Dear Marcelo, > >>> >>> Sorry if I miss understand what you attempt to point out. >>> It would be nice if you point out lack of description or unclear >>> description in the draft. >>> >> >> ok, perhaps i am misunderstanding something here... are you assuming >> that the HA belongs to the ISP network or to the end site? when there > > We are assuming that the HA belongs to the ISP network. > >> are multiple HAs, are you assuming that they belong to the the same >> ISP, to different ISPs or to the end site? > > Basically, We are assuming that HAs belong to different ISPs > when there are multiple HAs. Ok, this means that the nemo has multiple NEMo prefixes, one per each =20= HA i.e. one per ISP, right? The other option would be that multiple ISP have to be injecting the =20 same prefix, which option are you considering here? Regards, marcelo > However, you can also set up multiple HAs in same ISP. > > > Regards, > > Nobuo Ogashiwa > > >> >> regards, marcelo >> >> >> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>>> >>>> >>>> Regards, marcelo >>>> >>>> >>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=E2=99=AD: >>>> >>>>> >>>>> Dear all, >>>>> >>>>> We have submitted an updated draft. >>>>> >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-=20 >>>>> multihome- >>>>> fixed-network-01.txt >>>>> >>>>> Abstract >>>>> >>>>> Multi-homing technology improves the availability of host and >>>>> network connectivity. Since the node and network behavior of >>>>> mobile networking and fixed networking are different, the >>>>> different architecture has been discussed and proposed. This >>>>> document proposes the common architecture both for mobile and >>>>> fixed networking environment, using the mobile IP and NEMO. =20= >>>>> The >>>>> proposed architecture only requires a modification of the =20 >>>>> mobile >>>>> IP and NEMO so that multiple-CoA can be used. In addition, >>>>> multiple HAs which are located in different place, are =20 >>>>> required >>>>> for redundancy. >>>>> >>>>> >>>>> It is nice if we can have a presentation solot for the draft. >>>>> We have sent a request to WG chairs. >>>>> >>>>> We appreciate any comments, questions or suggestions. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>> >>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>> Thierry Ernst wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> The San Diego meeting is fast approaching. The NEMO WG is =20 >>>>>> 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 >>>>>> - 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 =20 >>>>>> (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 >>>>>> chairs >>>>>> by July 20th. Requests must be justified and will be accepted =20 >>>>>> 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 >>>>>> to >>>>>> submit one before the deadline, please inform TJ and myself so =20= >>>>>> that >>>>>> we >>>>>> can list all the ACTIVE drafts in the reading list. >>>>>> >>>>>> Note that I've seen a couple of drafts passing on the =20 >>>>>> 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 >>>>>> responsability >>>>>> of the author to send a note to the NEMO ML. >>>>>> >>>>>> Regards, >>>>>> NEMO Chairs. >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From nemo-bounces@ietf.org Mon Jul 26 10:30: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 KAA03026 for ; Mon, 26 Jul 2004 10:30: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 1Bp6RD-0000MF-Lf; Mon, 26 Jul 2004 10:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp6ML-0007Os-Hn for nemo@megatron.ietf.org; Mon, 26 Jul 2004 10: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 KAA02344 for ; Mon, 26 Jul 2004 10:21:39 -0400 (EDT) Received: from mail0.jaist.ac.jp ([150.65.5.97]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp69W-00087m-Dj for nemo@ietf.org; Mon, 26 Jul 2004 10:08:31 -0400 Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i6QE6p021778; Mon, 26 Jul 2004 23:06:51 +0900 (JST) Received: from pbg4.local.local (nofx.jaist.ac.jp [150.65.118.43]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i6QE5ls14168; Mon, 26 Jul 2004 23:05:47 +0900 (JST) Date: Mon, 26 Jul 2004 23:06:48 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <278B98DA-DEE6-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 Dear Marcelo, At Mon, 26 Jul 2004 11:28:29 +0200, marcelo bagnulo braun wrote: > > > El 23/07/2004, a las 19:44, Nobuo OGASHIWA escribi.ANs: > > > > > Dear Marcelo, > > > >>> > >>> Sorry if I miss understand what you attempt to point out. > >>> It would be nice if you point out lack of description or unclear > >>> description in the draft. > >>> > >> > >> ok, perhaps i am misunderstanding something here... are you assuming > >> that the HA belongs to the ISP network or to the end site? when there > > > > We are assuming that the HA belongs to the ISP network. > > > >> are multiple HAs, are you assuming that they belong to the the same > >> ISP, to different ISPs or to the end site? > > > > Basically, We are assuming that HAs belong to different ISPs > > when there are multiple HAs. > > Ok, this means that the nemo has multiple NEMo prefixes, one per each > HA i.e. one per ISP, right? > The other option would be that multiple ISP have to be injecting the > same prefix, which option are you considering here? Our assumption is the latter option. Regards, Nobuo Ogashiwa > Regards, marcelo > > > > However, you can also set up multiple HAs in same ISP. > > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > >> > >> regards, marcelo > >> > >> > >> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>>> > >>>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>> > >>>>> > >>>>> Dear all, > >>>>> > >>>>> We have submitted an updated draft. > >>>>> > >>>>> > >>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- > >>>>> multihome- > >>>>> fixed-network-01.txt > >>>>> > >>>>> Abstract > >>>>> > >>>>> Multi-homing technology improves the availability of host and > >>>>> network connectivity. Since the node and network behavior of > >>>>> mobile networking and fixed networking are different, the > >>>>> different architecture has been discussed and proposed. This > >>>>> document proposes the common architecture both for mobile and > >>>>> fixed networking environment, using the mobile IP and NEMO. > >>>>> The > >>>>> proposed architecture only requires a modification of the > >>>>> mobile > >>>>> IP and NEMO so that multiple-CoA can be used. In addition, > >>>>> multiple HAs which are located in different place, are > >>>>> required > >>>>> for redundancy. > >>>>> > >>>>> > >>>>> It is nice if we can have a presentation solot for the draft. > >>>>> We have sent a request to WG chairs. > >>>>> > >>>>> We appreciate any comments, questions or suggestions. > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>> > >>>>> > >>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>> Thierry Ernst wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> 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 > >>>>>> - 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 > >>>>>> 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 > >>>>>> 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 > >>>>>> responsability > >>>>>> of the author to send a note to the NEMO ML. > >>>>>> > >>>>>> Regards, > >>>>>> NEMO Chairs. > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > > > From nemo-bounces@ietf.org Mon Jul 26 11:07: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 LAA10475 for ; Mon, 26 Jul 2004 11:07: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 1Bp6up-0008If-VR; Mon, 26 Jul 2004 10:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp6pn-0006H4-JR for nemo@megatron.ietf.org; Mon, 26 Jul 2004 10:52: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 KAA06844 for ; Mon, 26 Jul 2004 10:52:08 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp6rB-0003nN-Tk for nemo@ietf.org; Mon, 26 Jul 2004 10:53:39 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9720B3A10B; Mon, 26 Jul 2004 16:51:37 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 752693A10A; Mon, 26 Jul 2004 16:51:37 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Mon, 26 Jul 2004 16:53:15 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 >> Ok, this means that the nemo has multiple NEMo prefixes, one per each >> HA i.e. one per ISP, right? >> The other option would be that multiple ISP have to be injecting the >> same prefix, which option are you considering here? > > > Our assumption is the latter option. > Ok, then who does the prefix belongs to? to ISP1 or to ISP2? moreover, what is the length of the prefix being injected? I can see several possibilities here: - a /48 for each multihomed site (of course if you have two multihomed customers that use the same two ISPs and they both have obtained its prefix from the same ISP and they have obtained aggregatable prefixes, you can aggregate those two prefixes into one, but i am not sure how likely this situation would be). Now if you inject a /48 (or a /47), you are basically doing current IPv4 multihoming solution with its scalability limitations - a /32. At this case i can think of a couple of possibilities: The /32 belong to one of the ISPs. This case doesn't makes much business sense imho, since this would mean that the ISP that is announcing the prefix but does not owns the prefix will receive all the traffic for that prefix even the traffic addressed to no multihomed customers. The other option i can think of is that there is a special /32 assigned to the clients multihomed with these two ISPs. Now this is pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs (if i remember correctly). The problem with this is that you need an important amount of /32 (more exactly the number of combinations of 2 of all providers available, and then all the combinations of three and so on). The other question that i have in this context, i fail to understand what do you need nemo or mip6 for doing this in any case... (so i guess i still don't understand you proposal : -( regards, marcelo > > Regards, > > Nobuo Ogashiwa > > > > >> Regards, marcelo >> >> >>> However, you can also set up multiple HAs in same ISP. >>> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>>> >>>> regards, marcelo >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>>> >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: >>>>>> >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> We have submitted an updated draft. >>>>>>> >>>>>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- >>>>>>> multihome- >>>>>>> fixed-network-01.txt >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> Multi-homing technology improves the availability of host >>>>>>> and >>>>>>> network connectivity. Since the node and network behavior of >>>>>>> mobile networking and fixed networking are different, the >>>>>>> different architecture has been discussed and proposed. This >>>>>>> document proposes the common architecture both for mobile >>>>>>> and >>>>>>> fixed networking environment, using the mobile IP and NEMO. >>>>>>> The >>>>>>> proposed architecture only requires a modification of the >>>>>>> mobile >>>>>>> IP and NEMO so that multiple-CoA can be used. In addition, >>>>>>> multiple HAs which are located in different place, are >>>>>>> required >>>>>>> for redundancy. >>>>>>> >>>>>>> >>>>>>> It is nice if we can have a presentation solot for the draft. >>>>>>> We have sent a request to WG chairs. >>>>>>> >>>>>>> We appreciate any comments, questions or suggestions. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>> >>>>>>> >>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>> Thierry Ernst wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> - 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> responsability >>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>> >>>>>>>> Regards, >>>>>>>> NEMO Chairs. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Mon Jul 26 12:59: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 MAA06615 for ; Mon, 26 Jul 2004 12:59: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 1Bp8T0-0004VF-AP; Mon, 26 Jul 2004 12:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp87a-0004Mo-JG for nemo@megatron.ietf.org; Mon, 26 Jul 2004 12: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 MAA25152 for ; Mon, 26 Jul 2004 12:14:35 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp88y-00029q-51 for nemo@ietf.org; Mon, 26 Jul 2004 12:16:07 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 11BB21D30F7; Tue, 27 Jul 2004 01:15:03 +0900 (JST) Date: Tue, 27 Jul 2004 01:14:30 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <86012C65-DF13-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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 Dear Marcelo, At Mon, 26 Jul 2004 16:53:15 +0200, marcelo bagnulo braun wrote: > > >> Ok, this means that the nemo has multiple NEMo prefixes, one per each > >> HA i.e. one per ISP, right? > >> The other option would be that multiple ISP have to be injecting the > >> same prefix, which option are you considering here? > > > > > > Our assumption is the latter option. > > > > Ok, then who does the prefix belongs to? to ISP1 or to ISP2? I would like to make sure the assumptions of your questions before answer all questions. ISP1 and ISP2 you are talking about are directly connected to the MR? If so, the answer of the above question is neither ISP1 nor ISP2. In our assumption, ISPs directly connected to the MR don't need to assign prefixes but need to assign just care-of addresses. Yet another organization which manages the HAs assign the mobile network prefixes. HAs might be geographically arranged into several ISPs, however the prefix which are advertised from HAs are differ from the ISP's one. Sorry if the description in the draft made any confusion. Would you mind to point out lines that is hard to understand? Regards, Nobuo Ogashiwa > moreover, what is the length of the prefix being injected? > > I can see several possibilities here: > - a /48 for each multihomed site (of course if you have two multihomed > customers that use the same two ISPs and they both have obtained its > prefix from the same ISP and they have obtained aggregatable prefixes, > you can aggregate those two prefixes into one, but i am not sure how > likely this situation would be). Now if you inject a /48 (or a /47), > you are basically doing current IPv4 multihoming solution with its > scalability limitations > - a /32. At this case i can think of a couple of possibilities: > The /32 belong to one of the ISPs. This case doesn't makes much > business sense imho, since this would mean that the ISP that is > announcing the prefix but does not owns the prefix will receive all the > traffic for that prefix even the traffic addressed to no multihomed > customers. > The other option i can think of is that there is a special /32 > assigned to the clients multihomed with these two ISPs. Now this is > pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs > (if i remember correctly). The problem with this is that you need an > important amount of /32 (more exactly the number of combinations of 2 > of all providers available, and then all the combinations of three and > so on). The other question that i have in this context, i fail to > understand what do you need nemo or mip6 for doing this in any case... > (so i guess i still don't understand you proposal : -( > > regards, marcelo > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > > > > > >> Regards, marcelo > >> > >> > >>> However, you can also set up multiple HAs in same ISP. > >>> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>>> > >>>> regards, marcelo > >>>> > >>>> > >>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>>> > >>>>>> > >>>>>> Regards, marcelo > >>>>>> > >>>>>> > >>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>> > >>>>>>> > >>>>>>> Dear all, > >>>>>>> > >>>>>>> We have submitted an updated draft. > >>>>>>> > >>>>>>> > >>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- > >>>>>>> multihome- > >>>>>>> fixed-network-01.txt > >>>>>>> > >>>>>>> Abstract > >>>>>>> > >>>>>>> Multi-homing technology improves the availability of host > >>>>>>> and > >>>>>>> network connectivity. Since the node and network behavior of > >>>>>>> mobile networking and fixed networking are different, the > >>>>>>> different architecture has been discussed and proposed. This > >>>>>>> document proposes the common architecture both for mobile > >>>>>>> and > >>>>>>> fixed networking environment, using the mobile IP and NEMO. > >>>>>>> The > >>>>>>> proposed architecture only requires a modification of the > >>>>>>> mobile > >>>>>>> IP and NEMO so that multiple-CoA can be used. In addition, > >>>>>>> multiple HAs which are located in different place, are > >>>>>>> required > >>>>>>> for redundancy. > >>>>>>> > >>>>>>> > >>>>>>> It is nice if we can have a presentation solot for the draft. > >>>>>>> We have sent a request to WG chairs. > >>>>>>> > >>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Nobuo Ogashiwa > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>> Thierry Ernst wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 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 > >>>>>>>> - 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 > >>>>>>>> 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 > >>>>>>>> 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 > >>>>>>>> responsability > >>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> NEMO Chairs. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Mon Jul 26 13:05:42 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 NAA08375 for ; Mon, 26 Jul 2004 13:05:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp8Wf-0006aY-Py; Mon, 26 Jul 2004 12:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp8MO-0000K2-Ue for nemo@megatron.ietf.org; Mon, 26 Jul 2004 12:29: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 MAA28879 for ; Mon, 26 Jul 2004 12:29:53 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp8Nn-0003Ts-Pu for nemo@ietf.org; Mon, 26 Jul 2004 12:31:25 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A75713A1FC; Mon, 26 Jul 2004 18:29:22 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 872903A1F0; Mon, 26 Jul 2004 18:29:22 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Mon, 26 Jul 2004 18:31:00 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable El 26/07/2004, a las 18:14, Nobuo OGASHIWA escribi=C3=B3: > > Dear Marcelo, > > At Mon, 26 Jul 2004 16:53:15 +0200, > marcelo bagnulo braun wrote: >> >>>> Ok, this means that the nemo has multiple NEMo prefixes, one per=20 >>>> each >>>> HA i.e. one per ISP, right? >>>> The other option would be that multiple ISP have to be injecting = the >>>> same prefix, which option are you considering here? >>> >>> >>> Our assumption is the latter option. >>> >> >> Ok, then who does the prefix belongs to? to ISP1 or to ISP2? > > I would like to make sure the assumptions of your questions before > answer all questions. > > ISP1 and ISP2 you are talking about are directly connected to the MR? No, i was asking about the isps that host the HAs (I mean i am considering the scenario where you have multiple HAs in=20 different ISPs) > If so, the answer of the above question is neither ISP1 nor ISP2. > In our assumption, ISPs directly connected to the MR don't need to > assign prefixes but need to assign just care-of addresses. > Yet another organization which manages the HAs assign the mobile > network prefixes. > HAs might be geographically arranged into several ISPs, > however the prefix which are advertised from HAs are differ from the > ISP's one. Ok, but the nemo prefix must be extracted from some prefix (which is=20 the prefix that announces the HA). My question is who does this prefix=20= belongs to? Regards, marcelo > > > > Sorry if the description in the draft made any confusion. > Would you mind to point out lines that is hard to understand? > > > Regards, > > Nobuo Ogashiwa > > > >> moreover, what is the length of the prefix being injected? >> >> I can see several possibilities here: >> - a /48 for each multihomed site (of course if you have two = multihomed >> customers that use the same two ISPs and they both have obtained its >> prefix from the same ISP and they have obtained aggregatable = prefixes, >> you can aggregate those two prefixes into one, but i am not sure how >> likely this situation would be). Now if you inject a /48 (or a /47), >> you are basically doing current IPv4 multihoming solution with its >> scalability limitations >> - a /32. At this case i can think of a couple of possibilities: >> The /32 belong to one of the ISPs. This case doesn't makes much >> business sense imho, since this would mean that the ISP that is >> announcing the prefix but does not owns the prefix will receive all=20= >> the >> traffic for that prefix even the traffic addressed to no multihomed >> customers. >> The other option i can think of is that there is a special /32 >> assigned to the clients multihomed with these two ISPs. Now this is >> pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs >> (if i remember correctly). The problem with this is that you need an >> important amount of /32 (more exactly the number of combinations of 2 >> of all providers available, and then all the combinations of three = and >> so on). The other question that i have in this context, i fail to >> understand what do you need nemo or mip6 for doing this in any = case... >> (so i guess i still don't understand you proposal : -( >> >> regards, marcelo >> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>> >>> >>>> Regards, marcelo >>>> >>>> >>>>> However, you can also set up multiple HAs in same ISP. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>>> >>>>>> regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=E2=99=AD: >>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> We have submitted an updated draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- >>>>>>>>> multihome- >>>>>>>>> fixed-network-01.txt >>>>>>>>> >>>>>>>>> Abstract >>>>>>>>> >>>>>>>>> Multi-homing technology improves the availability of host >>>>>>>>> and >>>>>>>>> network connectivity. Since the node and network behavior=20= >>>>>>>>> of >>>>>>>>> mobile networking and fixed networking are different, the >>>>>>>>> different architecture has been discussed and proposed.=20= >>>>>>>>> This >>>>>>>>> document proposes the common architecture both for mobile >>>>>>>>> and >>>>>>>>> fixed networking environment, using the mobile IP and=20 >>>>>>>>> NEMO. >>>>>>>>> The >>>>>>>>> proposed architecture only requires a modification of the >>>>>>>>> mobile >>>>>>>>> IP and NEMO so that multiple-CoA can be used. In = addition, >>>>>>>>> multiple HAs which are located in different place, are >>>>>>>>> required >>>>>>>>> for redundancy. >>>>>>>>> >>>>>>>>> >>>>>>>>> It is nice if we can have a presentation solot for the draft. >>>>>>>>> We have sent a request to WG chairs. >>>>>>>>> >>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nobuo Ogashiwa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>> Thierry Ernst wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> - 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 >>>>>>>>>> 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 >>>>>>>>>> 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=20= >>>>>>>>>> the >>>>>>>>>> NEMO >>>>>>>>>> ML. According to the new secretariat policy, it's now the >>>>>>>>>> responsability >>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> NEMO Chairs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Mon Jul 26 13:31: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 NAA13271 for ; Mon, 26 Jul 2004 13:31: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 1Bp911-0008LA-6b; Mon, 26 Jul 2004 13:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp8lx-0001ug-IU for nemo@megatron.ietf.org; Mon, 26 Jul 2004 12:56: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 MAA05963 for ; Mon, 26 Jul 2004 12:56:18 -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 1Bp8nD-0006Dd-6J for nemo@ietf.org; Mon, 26 Jul 2004 12:57:50 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 5FD1A6219 for ; Mon, 26 Jul 2004 09:55:57 -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 57373-01 for ; Mon, 26 Jul 2004 09:55:56 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 4D99A61E5; Mon, 26 Jul 2004 09:55:56 -0700 (PDT) Received: from [192.103.19.182] (unknown [192.103.19.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 502326121 for ; Mon, 26 Jul 2004 09:55:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) To: IETF NEMO WG Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-884607373; protocol="application/pkcs7-signature" From: "T.J.Kniveton" Date: Mon, 26 Jul 2004 09:55:56 -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: cd3fc8e909678b38737fc606dec187f0 Subject: [nemo] Agenda and Presentations X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-7-884607373 Content-Type: multipart/mixed; boundary=Apple-Mail-6-884607275 --Apple-Mail-6-884607275 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit [Thierry: Does this sound OK to you?] Hello, Attached is the current version of the NEMO Agenda for IETF60. Due to the large number of requests to speak about new and updated drafts, we are going to try something a little different. After the slots for charter items and WG business, we will have a number of brief presentations. If there is enough interest, we can schedule an additional BAR BOF on Route Optimization outside of normal meeting times, where authors can talk about their work more. Thierry will also be speaking about RO in the IRTF meeting. We have listed the authors requesting slots, and tried to fit everyone in. We'll re-shuffle as necessary, depending on time constraints. If you are listed and would like to give a brief update, please be aware - 5 minutes is a strict deadline - Please consider talking about: x The title of your draft and a brief overview x What is your draft addressing and what are you solving / trying to accomplish x Current issues, mailing list discussion x Implementation status and number of implementations, if applicable - Submit a presentation, 1-3 slides recommended, to Thierry and myself by this Thursday noon, PDT Thanks, TJ & Thierry --Apple-Mail-6-884607275 Content-Type: text/plain; x-unix-mode=0644; name="nemo-agenda.txt" Content-Disposition: attachment; filename=nemo-agenda.txt Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------------------------< NEMO Agenda - IETF 60, San Diego - August 2, 2004 17:30-19:30 ------------------------------------------------------------------------------------------< o Introduction and Agenda Bashing .................................................... 5 min [Chairmen: Thierry Ernst, T.J. Kniveton] o NEMO working group status and milestones; WG documents ............................. 5 min Working Group charter and direction ................................................ 5 min [Chairmen] o NEMO Basic Support Specification Status ............................................ 5 min http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt [Vijay Devarapalli] o Results of Last Call for Terminology and Requirements ............................. 15 min http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt [Thierry Ernst] - Results of WG last call, what need to be done on the current doc - is section 5 "NEMO Basic Support One-liner Requirements" still meaningful? o NEMO Home Network Models .......................................................... 10 min http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.txt [Vijay Devarapalli/Ryuji Wakikawa] - SNMP and NEMO MIB [] (5 minutes) - Prefix Delegation for Mobile Networks [Ralph Droms?] (5 minutes) o Analysis of Multihoming in NEMO ................................................... 10 min http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt [Chan-Wah Ng] - document status - does doc fits the WG expectations - consider which issues are important to solve o Multihoming Testing Reports ....................................................... 10 min [EunKyoung Paik] o Analysis of Solution Space for Route Optimization and Multihoming Introduction [TJ Kniveton] ......................................................... 5 min - Tree Discovery [Pascal Thubert] .................................................. 5 min http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt - RO Analysis [Jongkeun Na] ........................................................ 5 min http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt - Split Networks [Masayuki Kumazawa] ............................................... 5 min http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-00.txt - Dynamic Inter Home Agent Protocol [Benjamin Koh Tien-Ming] ....................... 5 min http://www.ietf.org/internet-drafts/draft-koh-dihap-00.txt - Evaluating Multiple Mobile Routers and Multiple Prefixes in NEMO Basic Support ... 5 min [Eun Kyoung and Romain Kuntz] http://www.ietf.org/internet-drafts/draft-kuntz-nemo-multihoming-test-00.txt - [Nobuo OGASHIWA] ................................................................. 5 min http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome-fixed-network-01.txt o Open Mic ........................................................................... 5 min o Conclusion and next steps.......................................................... 15 min [Chairmen] --Apple-Mail-6-884607275-- --Apple-Mail-7-884607373 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyNjE2NTU1 N1owIwYJKoZIhvcNAQkEMRYEFFMLYnru+CGcUmTk4P/APAwXT7R2MIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgGLVpcrk6ERsqpNygvkhFkyAvWZFblYP5muqEGcA2GBL 757C4shrSj0Yg0z5bmUr492fIXlwv1tVxpmBlvSW/o2LD2KYPsvy73qDtN6plPUMtwc+YHCG9EU7 P/uxTDg7R2Dldnw4FYBvq4yKfGF/JQLP4i6VOnbufT65ZEogH5SCAAAAAAAA --Apple-Mail-7-884607373-- From nemo-bounces@ietf.org Mon Jul 26 19:49: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 TAA21144 for ; Mon, 26 Jul 2004 19:49: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 1BpFB1-0001iv-68; Mon, 26 Jul 2004 19:46:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpF42-0000M3-3L for nemo@megatron.ietf.org; Mon, 26 Jul 2004 19:39: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 TAA20676 for ; Mon, 26 Jul 2004 19:39:24 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpF5V-0002uG-L0 for nemo@ietf.org; Mon, 26 Jul 2004 19:40:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6QNcoW24697; Mon, 26 Jul 2004 16:38:50 -0700 X-mProtect: <200407262338> 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 smtpddYXSKc; Mon, 26 Jul 2004 16:38:48 PDT Message-ID: <410597A5.2000109@iprg.nokia.com> Date: Mon, 26 Jul 2004 16:45:41 -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: Souhwan Jung References: <41017D52.7090504@iprg.nokia.com> <007801c4717e$abd35bb0$4f01a8c0@SOUHWANSENSQ> In-Reply-To: <007801c4717e$abd35bb0$4f01a8c0@SOUHWANSENSQ> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG Subject: [nemo] Re: comments on draft-jung-nemo-threat-analysis X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Souhwan Jung wrote: >>section 3.2.1 describes an attack where a MNN uses another MNN's >>source address to tunnel packets through the MR-HA tunnel. is >>this specific to NEMO? how is it different from a node A using >>another node's (say node B) source address, both being on the same >>link? > > > In MIP6, there are no intermediate nodes like MR and HA(of MR), > therefore, the victim may easily locate the attacker if the > attacker is located in the same local link with the spoofed node. this is only if we assume ingress filtering is turned on on the IPv6 link. > But, in the attack I described, the victim has no way to locate > the attacker, because the spoofed address could be the address > of any node in the Internet. I think this makes a big difference > from MIP6 case. okay, I now understand the attack. this has been fixed in the latest basic support draft. http://people.nokia.net/vijayd/nemo/issue23.txt >>>If one of the tunnel paths is broken for any reason, the MR(MR1) associated >>>with the faulty path loses Internet connection, and should find an >>>alternative bi-directional tunnel path through another MR2. In this case, >>>MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD >>>not respond to the unsolicited RA messages to its egress interface, >>>but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD >>>listen the RA from alternative MR2 on its ingress interface. >>>At this point, a malicious MR may advertise a RA with a fake CoA to MR1. >>>Then the MR1 will get a wrong CoA information. >> >>couldnt understand the statement "MR SHOULD not respond to the >>unsolicted RA message to its egress interface". infact NEMO >>basic support says (section 5.6) >> >> However, a Mobile Router MUST NOT ignore Router >> Advertisements received on the egress interface. >> > > > Sorry for not exactly citing the statements. The statements I try to mention from the basic draft is (section 5.6) > > "A Mobile Router SHOULD NOT send unsolicited Router Advertisements > and SHOULD NOT reply to Router Solicitations on any egress interface > when that interface is attached to a visited link." > > Anyway, the faulty MR should find the neighbor MR, the attack is still valid, right? once MR1 becomes a nested MR of MR2, MR1's egress interface is connected to MR2's ingress interface. - MR2 responds to router solicitations on the ingress interface - MR2 ignores router solicitations on the egress interface - MR1 processes router advertisements received on its egress interface - MR1 ignores router solicitations on the egress interface so what is the problem? Vijay From nemo-bounces@ietf.org Mon Jul 26 21:42: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 VAA26079 for ; Mon, 26 Jul 2004 21:42: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 1BpGwE-0004OR-PC; Mon, 26 Jul 2004 21:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpGvi-0004El-7c for nemo@megatron.ietf.org; Mon, 26 Jul 2004 21:38: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 VAA25942 for ; Mon, 26 Jul 2004 21:38:55 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpGxC-0004wF-IN for nemo@ietf.org; Mon, 26 Jul 2004 21:40:31 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 218D71D30F7; Tue, 27 Jul 2004 10:39:19 +0900 (JST) Date: Tue, 27 Jul 2004 10:38:46 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <2E02DACD-DF21-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 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 Dear Marcelo, At Mon, 26 Jul 2004 18:31:00 +0200, marcelo bagnulo braun wrote: > > > El 26/07/2004, a las 18:14, Nobuo OGASHIWA escribi.ANs: > > > > > Dear Marcelo, > > > > At Mon, 26 Jul 2004 16:53:15 +0200, > > marcelo bagnulo braun wrote: > >> > >>>> Ok, this means that the nemo has multiple NEMo prefixes, one per > >>>> each > >>>> HA i.e. one per ISP, right? > >>>> The other option would be that multiple ISP have to be injecting the > >>>> same prefix, which option are you considering here? > >>> > >>> > >>> Our assumption is the latter option. > >>> > >> > >> Ok, then who does the prefix belongs to? to ISP1 or to ISP2? > > > > I would like to make sure the assumptions of your questions before > > answer all questions. > > > > ISP1 and ISP2 you are talking about are directly connected to the MR? > > No, i was asking about the isps that host the HAs > (I mean i am considering the scenario where you have multiple HAs in > different ISPs) Ok. > > If so, the answer of the above question is neither ISP1 nor ISP2. > > In our assumption, ISPs directly connected to the MR don't need to > > assign prefixes but need to assign just care-of addresses. > > Yet another organization which manages the HAs assign the mobile > > network prefixes. > > HAs might be geographically arranged into several ISPs, > > however the prefix which are advertised from HAs are differ from the > > ISP's one. > > Ok, but the nemo prefix must be extracted from some prefix (which is > the prefix that announces the HA). My question is who does this prefix > belongs to? We think there are two cases. case 1) the prefix belongs to ISP1 or ISP2 In this case, ISP1 has a large address block. Aggregatable nemo prefixes are extracted from this large address block as a part of this address block. ISP1 and ISP2 contract to each other. Under the contract, ISP1 setup a HA into the ISP2's network and ISP2 advertise the aggregatable nemo prefix extracted from ISP1's address block. I think you are assuming this case. right? case 2) the prefix belongs to the yet another service provider (xSP) In this case, the xSP has an address block just for multihoming service. The xSP contract to the ISP1 and the ISP2. Under the contract, xSP setup HAs into ISP1 and ISP2's network, and the xSP's address block is advertised from the ISP1 and ISP2. We are assuming this case. Regards, Nobuo Ogashiwa > Regards, marcelo > > > > > > > > > Sorry if the description in the draft made any confusion. > > Would you mind to point out lines that is hard to understand? > > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > > > >> moreover, what is the length of the prefix being injected? > >> > >> I can see several possibilities here: > >> - a /48 for each multihomed site (of course if you have two multihomed > >> customers that use the same two ISPs and they both have obtained its > >> prefix from the same ISP and they have obtained aggregatable prefixes, > >> you can aggregate those two prefixes into one, but i am not sure how > >> likely this situation would be). Now if you inject a /48 (or a /47), > >> you are basically doing current IPv4 multihoming solution with its > >> scalability limitations > >> - a /32. At this case i can think of a couple of possibilities: > >> The /32 belong to one of the ISPs. This case doesn't makes much > >> business sense imho, since this would mean that the ISP that is > >> announcing the prefix but does not owns the prefix will receive all > >> the > >> traffic for that prefix even the traffic addressed to no multihomed > >> customers. > >> The other option i can think of is that there is a special /32 > >> assigned to the clients multihomed with these two ISPs. Now this is > >> pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs > >> (if i remember correctly). The problem with this is that you need an > >> important amount of /32 (more exactly the number of combinations of 2 > >> of all providers available, and then all the combinations of three and > >> so on). The other question that i have in this context, i fail to > >> understand what do you need nemo or mip6 for doing this in any case... > >> (so i guess i still don't understand you proposal : -( > >> > >> regards, marcelo > >> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>> > >>> > >>>> Regards, marcelo > >>>> > >>>> > >>>>> However, you can also set up multiple HAs in same ISP. > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>> > >>>>>> > >>>>>> regards, marcelo > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Nobuo Ogashiwa > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Regards, marcelo > >>>>>>>> > >>>>>>>> > >>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Dear all, > >>>>>>>>> > >>>>>>>>> We have submitted an updated draft. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- > >>>>>>>>> multihome- > >>>>>>>>> fixed-network-01.txt > >>>>>>>>> > >>>>>>>>> Abstract > >>>>>>>>> > >>>>>>>>> Multi-homing technology improves the availability of host > >>>>>>>>> and > >>>>>>>>> network connectivity. Since the node and network behavior > >>>>>>>>> of > >>>>>>>>> mobile networking and fixed networking are different, the > >>>>>>>>> different architecture has been discussed and proposed. > >>>>>>>>> This > >>>>>>>>> document proposes the common architecture both for mobile > >>>>>>>>> and > >>>>>>>>> fixed networking environment, using the mobile IP and > >>>>>>>>> NEMO. > >>>>>>>>> The > >>>>>>>>> proposed architecture only requires a modification of the > >>>>>>>>> mobile > >>>>>>>>> IP and NEMO so that multiple-CoA can be used. In addition, > >>>>>>>>> multiple HAs which are located in different place, are > >>>>>>>>> required > >>>>>>>>> for redundancy. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It is nice if we can have a presentation solot for the draft. > >>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>> > >>>>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Nobuo Ogashiwa > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 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 > >>>>>>>>>> - 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 > >>>>>>>>>> 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 > >>>>>>>>>> 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 > >>>>>>>>>> responsability > >>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> NEMO Chairs. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Tue Jul 27 07:17: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 HAA05588 for ; Tue, 27 Jul 2004 07:17: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 1BpPvb-0005iL-4X; Tue, 27 Jul 2004 07:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPud-0005a7-F6 for nemo@megatron.ietf.org; Tue, 27 Jul 2004 07:14: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 HAA05443 for ; Tue, 27 Jul 2004 07:14:26 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPwD-0005Tj-Oa for nemo@ietf.org; Tue, 27 Jul 2004 07:16:06 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8F1EF3A38F; Tue, 27 Jul 2004 13:13:54 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 7777B3A37F; Tue, 27 Jul 2004 13:13:54 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Tue, 27 Jul 2004 13:15:33 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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 > > case 2) the prefix belongs to the yet another service provider (xSP) > > In this case, the xSP has an address block just for multihoming > service. > The xSP contract to the ISP1 and the ISP2. > Under the contract, xSP setup HAs into ISP1 and ISP2's network, and > the xSP's address block is advertised from the ISP1 and ISP2. > > We are assuming this case. > Ok. Then the ISP1 and ISP2 announce the complete block of the xSP i.e. a /32 or they just announce the /48 that corresponds to the nemo that is multihomed? thanks for your answers, regards, marcelo > > Regards, > > Nobuo Ogashiwa > > > >> Regards, marcelo >> >>> >>> >>> >>> Sorry if the description in the draft made any confusion. >>> Would you mind to point out lines that is hard to understand? >>> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>> >>>> moreover, what is the length of the prefix being injected? >>>> >>>> I can see several possibilities here: >>>> - a /48 for each multihomed site (of course if you have two >>>> multihomed >>>> customers that use the same two ISPs and they both have obtained its >>>> prefix from the same ISP and they have obtained aggregatable >>>> prefixes, >>>> you can aggregate those two prefixes into one, but i am not sure how >>>> likely this situation would be). Now if you inject a /48 (or a /47), >>>> you are basically doing current IPv4 multihoming solution with its >>>> scalability limitations >>>> - a /32. At this case i can think of a couple of possibilities: >>>> The /32 belong to one of the ISPs. This case doesn't makes much >>>> business sense imho, since this would mean that the ISP that is >>>> announcing the prefix but does not owns the prefix will receive all >>>> the >>>> traffic for that prefix even the traffic addressed to no multihomed >>>> customers. >>>> The other option i can think of is that there is a special /32 >>>> assigned to the clients multihomed with these two ISPs. Now this is >>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs >>>> (if i remember correctly). The problem with this is that you need an >>>> important amount of /32 (more exactly the number of combinations of >>>> 2 >>>> of all providers available, and then all the combinations of three >>>> and >>>> so on). The other question that i have in this context, i fail to >>>> understand what do you need nemo or mip6 for doing this in any >>>> case... >>>> (so i guess i still don't understand you proposal : -( >>>> >>>> regards, marcelo >>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>> >>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nobuo Ogashiwa >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- >>>>>>>>>>> multihome- >>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>> >>>>>>>>>>> Abstract >>>>>>>>>>> >>>>>>>>>>> Multi-homing technology improves the availability of >>>>>>>>>>> host >>>>>>>>>>> and >>>>>>>>>>> network connectivity. Since the node and network >>>>>>>>>>> behavior >>>>>>>>>>> of >>>>>>>>>>> mobile networking and fixed networking are different, >>>>>>>>>>> the >>>>>>>>>>> different architecture has been discussed and proposed. >>>>>>>>>>> This >>>>>>>>>>> document proposes the common architecture both for >>>>>>>>>>> mobile >>>>>>>>>>> and >>>>>>>>>>> fixed networking environment, using the mobile IP and >>>>>>>>>>> NEMO. >>>>>>>>>>> The >>>>>>>>>>> proposed architecture only requires a modification of >>>>>>>>>>> the >>>>>>>>>>> mobile >>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In >>>>>>>>>>> addition, >>>>>>>>>>> multiple HAs which are located in different place, are >>>>>>>>>>> required >>>>>>>>>>> for redundancy. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It is nice if we can have a presentation solot for the draft. >>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>> >>>>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> - 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 >>>>>>>>>>>> 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 >>>>>>>>>>>> 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 >>>>>>>>>>>> responsability >>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Tue Jul 27 11:04:42 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 LAA19541 for ; Tue, 27 Jul 2004 11:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpTO5-0006Jd-8P; Tue, 27 Jul 2004 10:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpTGF-0004y4-LA for nemo@megatron.ietf.org; Tue, 27 Jul 2004 10:48: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 KAA18370 for ; Tue, 27 Jul 2004 10:48:57 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpTHr-0000w7-NN for nemo@ietf.org; Tue, 27 Jul 2004 10:50:40 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 8AE291D30F7; Tue, 27 Jul 2004 23:49:27 +0900 (JST) Date: Tue, 27 Jul 2004 23:48:54 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <46CFC2F8-DFBE-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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 Dear Marcelo, At Tue, 27 Jul 2004 13:15:33 +0200, marcelo bagnulo braun wrote: > > case 2) the prefix belongs to the yet another service provider (xSP) > > > > In this case, the xSP has an address block just for multihoming > > service. > > The xSP contract to the ISP1 and the ISP2. > > Under the contract, xSP setup HAs into ISP1 and ISP2's network, and > > the xSP's address block is advertised from the ISP1 and ISP2. > > > > We are assuming this case. > > Ok. > Then the ISP1 and ISP2 announce the complete block of the xSP i.e. a > /32 or they just announce the /48 that corresponds to the nemo that is > multihomed? Basically, our assumption is the former. Regards, Nobuo Ogashiwa > thanks for your answers, > regards, marcelo > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > > > >> Regards, marcelo > >> > >>> > >>> > >>> > >>> Sorry if the description in the draft made any confusion. > >>> Would you mind to point out lines that is hard to understand? > >>> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>> > >>>> moreover, what is the length of the prefix being injected? > >>>> > >>>> I can see several possibilities here: > >>>> - a /48 for each multihomed site (of course if you have two > >>>> multihomed > >>>> customers that use the same two ISPs and they both have obtained its > >>>> prefix from the same ISP and they have obtained aggregatable > >>>> prefixes, > >>>> you can aggregate those two prefixes into one, but i am not sure how > >>>> likely this situation would be). Now if you inject a /48 (or a /47), > >>>> you are basically doing current IPv4 multihoming solution with its > >>>> scalability limitations > >>>> - a /32. At this case i can think of a couple of possibilities: > >>>> The /32 belong to one of the ISPs. This case doesn't makes much > >>>> business sense imho, since this would mean that the ISP that is > >>>> announcing the prefix but does not owns the prefix will receive all > >>>> the > >>>> traffic for that prefix even the traffic addressed to no multihomed > >>>> customers. > >>>> The other option i can think of is that there is a special /32 > >>>> assigned to the clients multihomed with these two ISPs. Now this is > >>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs > >>>> (if i remember correctly). The problem with this is that you need an > >>>> important amount of /32 (more exactly the number of combinations of > >>>> 2 > >>>> of all providers available, and then all the combinations of three > >>>> and > >>>> so on). The other question that i have in this context, i fail to > >>>> understand what do you need nemo or mip6 for doing this in any > >>>> case... > >>>> (so i guess i still don't understand you proposal : -( > >>>> > >>>> regards, marcelo > >>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Regards, marcelo > >>>>>> > >>>>>> > >>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Nobuo Ogashiwa > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> regards, marcelo > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Nobuo Ogashiwa > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Regards, marcelo > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Dear all, > >>>>>>>>>>> > >>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- > >>>>>>>>>>> multihome- > >>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>> > >>>>>>>>>>> Abstract > >>>>>>>>>>> > >>>>>>>>>>> Multi-homing technology improves the availability of > >>>>>>>>>>> host > >>>>>>>>>>> and > >>>>>>>>>>> network connectivity. Since the node and network > >>>>>>>>>>> behavior > >>>>>>>>>>> of > >>>>>>>>>>> mobile networking and fixed networking are different, > >>>>>>>>>>> the > >>>>>>>>>>> different architecture has been discussed and proposed. > >>>>>>>>>>> This > >>>>>>>>>>> document proposes the common architecture both for > >>>>>>>>>>> mobile > >>>>>>>>>>> and > >>>>>>>>>>> fixed networking environment, using the mobile IP and > >>>>>>>>>>> NEMO. > >>>>>>>>>>> The > >>>>>>>>>>> proposed architecture only requires a modification of > >>>>>>>>>>> the > >>>>>>>>>>> mobile > >>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In > >>>>>>>>>>> addition, > >>>>>>>>>>> multiple HAs which are located in different place, are > >>>>>>>>>>> required > >>>>>>>>>>> for redundancy. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> It is nice if we can have a presentation solot for the draft. > >>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>> > >>>>>>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> > >>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 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 > >>>>>>>>>>>> - 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 > >>>>>>>>>>>> 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 > >>>>>>>>>>>> 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 > >>>>>>>>>>>> responsability > >>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Tue Jul 27 11:21: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 LAA20832 for ; Tue, 27 Jul 2004 11:21: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 1BpTeT-0000wB-Vn; Tue, 27 Jul 2004 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpTS0-00077g-Ji for nemo@megatron.ietf.org; Tue, 27 Jul 2004 11:01: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 LAA19346 for ; Tue, 27 Jul 2004 11:01:06 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpTTa-0001DZ-LG for nemo@ietf.org; Tue, 27 Jul 2004 11:02:49 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B7DE03A2BC; Tue, 27 Jul 2004 17:00:33 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 9F8343A2B7; Tue, 27 Jul 2004 17:00:33 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Tue, 27 Jul 2004 17:02:12 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable El 27/07/2004, a las 16:48, Nobuo OGASHIWA escribi=C3=B3: > > Dear Marcelo, > > At Tue, 27 Jul 2004 13:15:33 +0200, > marcelo bagnulo braun wrote: >>> case 2) the prefix belongs to the yet another service provider (xSP) >>> >>> In this case, the xSP has an address block just for multihoming >>> service. >>> The xSP contract to the ISP1 and the ISP2. >>> Under the contract, xSP setup HAs into ISP1 and ISP2's network, and >>> the xSP's address block is advertised from the ISP1 and ISP2. >>> >>> We are assuming this case. >> >> Ok. >> Then the ISP1 and ISP2 announce the complete block of the xSP i.e. a >> /32 or they just announce the /48 that corresponds to the nemo that = is >> multihomed? > > Basically, our assumption is the former. > Ok this means that xSP needs to have as many /32 as possible=20 combinations of two providers which a site may multihome. I mean, suppose that in a city there are n ISPs, then there are=20 n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right? Perhaps these are too many /32s? And i am only considering sites that multihome to 2 isps, you may need=20= to consider the case when they multihome to 3, 4,... Anyway, why do you need nemo or mipv6 to build such a solution? I mean, imagine that you assign a /32 to each combination of any two=20 ISPs in a city, and you assign a /48 of this /32 of each site that=20 multihome to those two ISP. All you need now is that these two isps=20 announce the /32. You don't need nemo for this AFAICS. Regards, marcelo > Regards, > > Nobuo Ogashiwa > > >> thanks for your answers, >> regards, marcelo >> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>> >>>> Regards, marcelo >>>> >>>>> >>>>> >>>>> >>>>> Sorry if the description in the draft made any confusion. >>>>> Would you mind to point out lines that is hard to understand? >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>> >>>>>> moreover, what is the length of the prefix being injected? >>>>>> >>>>>> I can see several possibilities here: >>>>>> - a /48 for each multihomed site (of course if you have two >>>>>> multihomed >>>>>> customers that use the same two ISPs and they both have obtained=20= >>>>>> its >>>>>> prefix from the same ISP and they have obtained aggregatable >>>>>> prefixes, >>>>>> you can aggregate those two prefixes into one, but i am not sure=20= >>>>>> how >>>>>> likely this situation would be). Now if you inject a /48 (or a=20 >>>>>> /47), >>>>>> you are basically doing current IPv4 multihoming solution with = its >>>>>> scalability limitations >>>>>> - a /32. At this case i can think of a couple of possibilities: >>>>>> The /32 belong to one of the ISPs. This case doesn't makes much >>>>>> business sense imho, since this would mean that the ISP that is >>>>>> announcing the prefix but does not owns the prefix will receive=20= >>>>>> all >>>>>> the >>>>>> traffic for that prefix even the traffic addressed to no=20 >>>>>> multihomed >>>>>> customers. >>>>>> The other option i can think of is that there is a special /32 >>>>>> assigned to the clients multihomed with these two ISPs. Now this=20= >>>>>> is >>>>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR=20= >>>>>> RFCs >>>>>> (if i remember correctly). The problem with this is that you need=20= >>>>>> an >>>>>> important amount of /32 (more exactly the number of combinations=20= >>>>>> of >>>>>> 2 >>>>>> of all providers available, and then all the combinations of = three >>>>>> and >>>>>> so on). The other question that i have in this context, i fail to >>>>>> understand what do you need nemo or mip6 for doing this in any >>>>>> case... >>>>>> (so i guess i still don't understand you proposal : -( >>>>>> >>>>>> regards, marcelo >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nobuo Ogashiwa >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=E2=99=AD: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>> >>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> = http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- >>>>>>>>>>>>> multihome- >>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>> >>>>>>>>>>>>> Abstract >>>>>>>>>>>>> >>>>>>>>>>>>> Multi-homing technology improves the availability of >>>>>>>>>>>>> host >>>>>>>>>>>>> and >>>>>>>>>>>>> network connectivity. Since the node and network >>>>>>>>>>>>> behavior >>>>>>>>>>>>> of >>>>>>>>>>>>> mobile networking and fixed networking are different, >>>>>>>>>>>>> the >>>>>>>>>>>>> different architecture has been discussed and=20 >>>>>>>>>>>>> proposed. >>>>>>>>>>>>> This >>>>>>>>>>>>> document proposes the common architecture both for >>>>>>>>>>>>> mobile >>>>>>>>>>>>> and >>>>>>>>>>>>> fixed networking environment, using the mobile IP and >>>>>>>>>>>>> NEMO. >>>>>>>>>>>>> The >>>>>>>>>>>>> proposed architecture only requires a modification of >>>>>>>>>>>>> the >>>>>>>>>>>>> mobile >>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In >>>>>>>>>>>>> addition, >>>>>>>>>>>>> multiple HAs which are located in different place, = are >>>>>>>>>>>>> required >>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is nice if we can have a presentation solot for the=20 >>>>>>>>>>>>> draft. >>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>> >>>>>>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> - 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=20= >>>>>>>>>>>>>> the >>>>>>>>>>>>>> above >>>>>>>>>>>>>> listed topic, or to add an item, please send your request=20= >>>>>>>>>>>>>> to >>>>>>>>>>>>>> both >>>>>>>>>>>>>> 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=20 >>>>>>>>>>>>>> meeting, >>>>>>>>>>>>>> or >>>>>>>>>>>>>> intend >>>>>>>>>>>>>> to >>>>>>>>>>>>>> submit one before the deadline, please inform TJ and=20 >>>>>>>>>>>>>> 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=20= >>>>>>>>>>>>>> on >>>>>>>>>>>>>> the >>>>>>>>>>>>>> NEMO >>>>>>>>>>>>>> ML. According to the new secretariat policy, it's now the >>>>>>>>>>>>>> responsability >>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Tue Jul 27 12:20: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 MAA25676 for ; Tue, 27 Jul 2004 12:20: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 1BpUOC-0004ty-5G; Tue, 27 Jul 2004 12:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpUIX-0003fV-46 for nemo@megatron.ietf.org; Tue, 27 Jul 2004 11:55: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 LAA24115 for ; Tue, 27 Jul 2004 11:55:22 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpUK6-0002fb-HL for nemo@ietf.org; Tue, 27 Jul 2004 11:57:06 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id A18E31D30F7; Wed, 28 Jul 2004 00:55:49 +0900 (JST) Date: Wed, 28 Jul 2004 00:55:16 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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 At Tue, 27 Jul 2004 17:02:12 +0200, marcelo bagnulo braun wrote: > > > El 27/07/2004, a las 16:48, Nobuo OGASHIWA escribi.ANs: > > > > > Dear Marcelo, > > > > At Tue, 27 Jul 2004 13:15:33 +0200, > > marcelo bagnulo braun wrote: > >>> case 2) the prefix belongs to the yet another service provider (xSP) > >>> > >>> In this case, the xSP has an address block just for multihoming > >>> service. > >>> The xSP contract to the ISP1 and the ISP2. > >>> Under the contract, xSP setup HAs into ISP1 and ISP2's network, and > >>> the xSP's address block is advertised from the ISP1 and ISP2. > >>> > >>> We are assuming this case. > >> > >> Ok. > >> Then the ISP1 and ISP2 announce the complete block of the xSP i.e. a > >> /32 or they just announce the /48 that corresponds to the nemo that is > >> multihomed? > > > > Basically, our assumption is the former. > > > > Ok this means that xSP needs to have as many /32 as possible > combinations of two providers which a site may multihome. > I mean, suppose that in a city there are n ISPs, then there are > n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right? No. In this case, the xSP needs to have a exactry one /32 prefix. If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B, HA-C) are setup into those three ISP's network. On the other hand if a multihomed user (user1) has multiple links connected to ISP-X and ISP-Y, and the user1 contract to the xSP, then the user1 uses a nemo prefix as mobile network prefix, which is extracted from xSP's address block, and the user1 receive traffic via HA-A, HA-B, HA-C. In this case, the number of tunnels is 6 because the user1 has two direct connection to ISP-X and ISP-y and user1 can use three HAs, HA-A, HA-B and HA-C. If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct connection, and contract to xSP for tunnel connection, then user2 also uses a nemo prefix extracted from xSP's address block and receive packets via HA-A, HA-B, HA-C. In this case, the number of tunnels is 9. I mean, regardless of number of directly connected links, every multihomed users contract to the xSP can use every HAs which are setup by the xSP, and every ISPs contract to the xSP have to advertise a same address block. Regards, Nobuo Ogashiwa > Perhaps these are too many /32s? > And i am only considering sites that multihome to 2 isps, you may need > to consider the case when they multihome to 3, 4,... > > Anyway, why do you need nemo or mipv6 to build such a solution? > I mean, imagine that you assign a /32 to each combination of any two > ISPs in a city, and you assign a /48 of this /32 of each site that > multihome to those two ISP. All you need now is that these two isps > announce the /32. You don't need nemo for this AFAICS. > > Regards, marcelo > > > Regards, > > > > Nobuo Ogashiwa > > > > > >> thanks for your answers, > >> regards, marcelo > >> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>> > >>>> Regards, marcelo > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Sorry if the description in the draft made any confusion. > >>>>> Would you mind to point out lines that is hard to understand? > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>> > >>>>> > >>>>>> moreover, what is the length of the prefix being injected? > >>>>>> > >>>>>> I can see several possibilities here: > >>>>>> - a /48 for each multihomed site (of course if you have two > >>>>>> multihomed > >>>>>> customers that use the same two ISPs and they both have obtained > >>>>>> its > >>>>>> prefix from the same ISP and they have obtained aggregatable > >>>>>> prefixes, > >>>>>> you can aggregate those two prefixes into one, but i am not sure > >>>>>> how > >>>>>> likely this situation would be). Now if you inject a /48 (or a > >>>>>> /47), > >>>>>> you are basically doing current IPv4 multihoming solution with its > >>>>>> scalability limitations > >>>>>> - a /32. At this case i can think of a couple of possibilities: > >>>>>> The /32 belong to one of the ISPs. This case doesn't makes much > >>>>>> business sense imho, since this would mean that the ISP that is > >>>>>> announcing the prefix but does not owns the prefix will receive > >>>>>> all > >>>>>> the > >>>>>> traffic for that prefix even the traffic addressed to no > >>>>>> multihomed > >>>>>> customers. > >>>>>> The other option i can think of is that there is a special /32 > >>>>>> assigned to the clients multihomed with these two ISPs. Now this > >>>>>> is > >>>>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR > >>>>>> RFCs > >>>>>> (if i remember correctly). The problem with this is that you need > >>>>>> an > >>>>>> important amount of /32 (more exactly the number of combinations > >>>>>> of > >>>>>> 2 > >>>>>> of all providers available, and then all the combinations of three > >>>>>> and > >>>>>> so on). The other question that i have in this context, i fail to > >>>>>> understand what do you need nemo or mip6 for doing this in any > >>>>>> case... > >>>>>> (so i guess i still don't understand you proposal : -( > >>>>>> > >>>>>> regards, marcelo > >>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Nobuo Ogashiwa > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Regards, marcelo > >>>>>>>> > >>>>>>>> > >>>>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Nobuo Ogashiwa > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> regards, marcelo > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> > >>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Dear all, > >>>>>>>>>>>>> > >>>>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- > >>>>>>>>>>>>> multihome- > >>>>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>>>> > >>>>>>>>>>>>> Abstract > >>>>>>>>>>>>> > >>>>>>>>>>>>> Multi-homing technology improves the availability of > >>>>>>>>>>>>> host > >>>>>>>>>>>>> and > >>>>>>>>>>>>> network connectivity. Since the node and network > >>>>>>>>>>>>> behavior > >>>>>>>>>>>>> of > >>>>>>>>>>>>> mobile networking and fixed networking are different, > >>>>>>>>>>>>> the > >>>>>>>>>>>>> different architecture has been discussed and > >>>>>>>>>>>>> proposed. > >>>>>>>>>>>>> This > >>>>>>>>>>>>> document proposes the common architecture both for > >>>>>>>>>>>>> mobile > >>>>>>>>>>>>> and > >>>>>>>>>>>>> fixed networking environment, using the mobile IP and > >>>>>>>>>>>>> NEMO. > >>>>>>>>>>>>> The > >>>>>>>>>>>>> proposed architecture only requires a modification of > >>>>>>>>>>>>> the > >>>>>>>>>>>>> mobile > >>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In > >>>>>>>>>>>>> addition, > >>>>>>>>>>>>> multiple HAs which are located in different place, are > >>>>>>>>>>>>> required > >>>>>>>>>>>>> for redundancy. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> It is nice if we can have a presentation solot for the > >>>>>>>>>>>>> draft. > >>>>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> - 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 > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> responsability > >>>>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Tue Jul 27 12:36: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 MAA27086 for ; Tue, 27 Jul 2004 12:36: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 1BpUhm-0000y2-Vb; Tue, 27 Jul 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 1BpUWB-0005zW-16 for nemo@megatron.ietf.org; Tue, 27 Jul 2004 12:09: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 MAA25020 for ; Tue, 27 Jul 2004 12:09:28 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpUXn-0002xl-US for nemo@ietf.org; Tue, 27 Jul 2004 12:11:12 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2AEDF3A36D; Tue, 27 Jul 2004 18:08:58 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 093F03A37E; Tue, 27 Jul 2004 18:08:58 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Tue, 27 Jul 2004 18:10:37 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 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 >> Ok this means that xSP needs to have as many /32 as possible >> combinations of two providers which a site may multihome. >> I mean, suppose that in a city there are n ISPs, then there are >> n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right? > > No. In this case, the xSP needs to have a exactry one /32 prefix. > > If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B, HA-C) > are setup into those three ISP's network. > > On the other hand if a multihomed user (user1) has multiple links > connected to > ISP-X and ISP-Y, and the user1 contract to the xSP, then > the user1 uses a nemo prefix as mobile network prefix, which is > extracted > from xSP's address block, and the user1 receive traffic via HA-A, > HA-B, HA-C. > In this case, the number of tunnels is 6 because the user1 has > two direct connection to ISP-X and ISP-y and user1 can use three HAs, > HA-A, HA-B and HA-C. > > If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct > connection, > and contract to xSP for tunnel connection, then user2 also uses > a nemo prefix extracted from xSP's address block and receive packets > via > HA-A, HA-B, HA-C. > In this case, the number of tunnels is 9. > > I mean, regardless of number of directly connected links, > every multihomed users contract to the xSP can use every HAs > which are setup by the xSP, > and every ISPs contract to the xSP have to advertise a same address > block. > > i used the wrong terminology, sorry The point was not about ISPs that are connected to the end site, but about ISPs where the XSP places HA into. So the point is, using the new terminology xSP needs to have as many /32 as possible combinations of two providers which a multihomed site can have HAs placed into I mean, suppose that in a city there are n ISPs that can host HAs, then there are n(n-1)/2 combinations of 2 ISPs which a multihomed site can place its HAs So you need n(n-1)/2 prefixes assigned for this solution, right? regards, marcelo > Regards, > > Nobuo Ogashiwa > > >> Perhaps these are too many /32s? >> And i am only considering sites that multihome to 2 isps, you may need >> to consider the case when they multihome to 3, 4,... >> >> Anyway, why do you need nemo or mipv6 to build such a solution? >> I mean, imagine that you assign a /32 to each combination of any two >> ISPs in a city, and you assign a /48 of this /32 of each site that >> multihome to those two ISP. All you need now is that these two isps >> announce the /32. You don't need nemo for this AFAICS. >> >> Regards, marcelo >> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>>> thanks for your answers, >>>> regards, marcelo >>>> >>>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>> >>>>>> Regards, marcelo >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sorry if the description in the draft made any confusion. >>>>>>> Would you mind to point out lines that is hard to understand? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>> >>>>>>> >>>>>>>> moreover, what is the length of the prefix being injected? >>>>>>>> >>>>>>>> I can see several possibilities here: >>>>>>>> - a /48 for each multihomed site (of course if you have two >>>>>>>> multihomed >>>>>>>> customers that use the same two ISPs and they both have obtained >>>>>>>> its >>>>>>>> prefix from the same ISP and they have obtained aggregatable >>>>>>>> prefixes, >>>>>>>> you can aggregate those two prefixes into one, but i am not sure >>>>>>>> how >>>>>>>> likely this situation would be). Now if you inject a /48 (or a >>>>>>>> /47), >>>>>>>> you are basically doing current IPv4 multihoming solution with >>>>>>>> its >>>>>>>> scalability limitations >>>>>>>> - a /32. At this case i can think of a couple of possibilities: >>>>>>>> The /32 belong to one of the ISPs. This case doesn't makes >>>>>>>> much >>>>>>>> business sense imho, since this would mean that the ISP that is >>>>>>>> announcing the prefix but does not owns the prefix will receive >>>>>>>> all >>>>>>>> the >>>>>>>> traffic for that prefix even the traffic addressed to no >>>>>>>> multihomed >>>>>>>> customers. >>>>>>>> The other option i can think of is that there is a special /32 >>>>>>>> assigned to the clients multihomed with these two ISPs. Now this >>>>>>>> is >>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR >>>>>>>> RFCs >>>>>>>> (if i remember correctly). The problem with this is that you >>>>>>>> need >>>>>>>> an >>>>>>>> important amount of /32 (more exactly the number of combinations >>>>>>>> of >>>>>>>> 2 >>>>>>>> of all providers available, and then all the combinations of >>>>>>>> three >>>>>>>> and >>>>>>>> so on). The other question that i have in this context, i fail >>>>>>>> to >>>>>>>> understand what do you need nemo or mip6 for doing this in any >>>>>>>> case... >>>>>>>> (so i guess i still don't understand you proposal : -( >>>>>>>> >>>>>>>> regards, marcelo >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nobuo Ogashiwa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> regards, marcelo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6- >>>>>>>>>>>>>>> nemo- >>>>>>>>>>>>>>> multihome- >>>>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Abstract >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Multi-homing technology improves the availability of >>>>>>>>>>>>>>> host >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> network connectivity. Since the node and network >>>>>>>>>>>>>>> behavior >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> mobile networking and fixed networking are >>>>>>>>>>>>>>> different, >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> different architecture has been discussed and >>>>>>>>>>>>>>> proposed. >>>>>>>>>>>>>>> This >>>>>>>>>>>>>>> document proposes the common architecture both for >>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> fixed networking environment, using the mobile IP >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> NEMO. >>>>>>>>>>>>>>> The >>>>>>>>>>>>>>> proposed architecture only requires a modification >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In >>>>>>>>>>>>>>> addition, >>>>>>>>>>>>>>> multiple HAs which are located in different place, >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> required >>>>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is nice if we can have a presentation solot for the >>>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> - 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 >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> responsability >>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Tue Jul 27 13:34: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 NAA00950 for ; Tue, 27 Jul 2004 13:34: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 1BpVnQ-0004Zt-My; Tue, 27 Jul 2004 13:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpVgI-0003hv-Ps for nemo@megatron.ietf.org; Tue, 27 Jul 2004 13:24: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 NAA00432 for ; Tue, 27 Jul 2004 13:24:00 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpVhw-0004bk-94 for nemo@ietf.org; Tue, 27 Jul 2004 13:25:45 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id E478D1D30F7; Wed, 28 Jul 2004 02:24:30 +0900 (JST) Date: Wed, 28 Jul 2004 02:23:57 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <7F4AD81F-DFE7-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 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 Dear Marcelo, At Tue, 27 Jul 2004 18:10:37 +0200, marcelo bagnulo braun wrote: > > >> Ok this means that xSP needs to have as many /32 as possible > >> combinations of two providers which a site may multihome. > >> I mean, suppose that in a city there are n ISPs, then there are > >> n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right? > > > > No. In this case, the xSP needs to have a exactry one /32 prefix. > > > > If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B, HA-C) > > are setup into those three ISP's network. > > > > On the other hand if a multihomed user (user1) has multiple links > > connected to > > ISP-X and ISP-Y, and the user1 contract to the xSP, then > > the user1 uses a nemo prefix as mobile network prefix, which is > > extracted > > from xSP's address block, and the user1 receive traffic via HA-A, > > HA-B, HA-C. > > In this case, the number of tunnels is 6 because the user1 has > > two direct connection to ISP-X and ISP-y and user1 can use three HAs, > > HA-A, HA-B and HA-C. > > > > If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct > > connection, > > and contract to xSP for tunnel connection, then user2 also uses > > a nemo prefix extracted from xSP's address block and receive packets > > via > > HA-A, HA-B, HA-C. > > In this case, the number of tunnels is 9. > > > > I mean, regardless of number of directly connected links, > > every multihomed users contract to the xSP can use every HAs > > which are setup by the xSP, > > and every ISPs contract to the xSP have to advertise a same address > > block. > > > > > > i used the wrong terminology, sorry > The point was not about ISPs that are connected to the end site, but > about ISPs where the XSP places HA into. Ok. I get your point about the terminology. But, still I don't know why you think xSP needs many /32 prefixes. The conceptual topology in our solution is just like full meshed VPN connections between every HAs and every users (MRs), those HAs act as border gateway routers of xSP, which advertise a same prefix. Note that every MRs are connected to every HAs so the number of virtual links is number of HAs x number of MRs. I mean, I think the conceptual topology of xSP consists of multiple HAs, multiple MRs, full meshed virtual links between HAs and MRs, and subnetworks under MRs, which have nemo prefix. And also I think that hosting HAs equals to peering, and prefixes of subnetworks are aggregated into a single /32 prefix then advertised from each HAs to peer ISPs. In other word, every HAs of xSP advertise same /32 prefix to peer ISPs. So I think that, regardless of the number of HAs, xSP doesn't need to have many /32 prefixes. Regards, Nobuo Ogashiwa > So the point is, using the new terminology > > xSP needs to have as many /32 as possible > combinations of two providers which a multihomed site can have HAs > placed into > I mean, suppose that in a city there are n ISPs that can host HAs, then > there are > n(n-1)/2 combinations of 2 ISPs which a multihomed site can place its > HAs > So you need n(n-1)/2 prefixes assigned for this solution, right? > > regards, marcelo > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > >> Perhaps these are too many /32s? > >> And i am only considering sites that multihome to 2 isps, you may need > >> to consider the case when they multihome to 3, 4,... > >> > >> Anyway, why do you need nemo or mipv6 to build such a solution? > >> I mean, imagine that you assign a /32 to each combination of any two > >> ISPs in a city, and you assign a /48 of this /32 of each site that > >> multihome to those two ISP. All you need now is that these two isps > >> announce the /32. You don't need nemo for this AFAICS. > >> > >> Regards, marcelo > >> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>>> thanks for your answers, > >>>> regards, marcelo > >>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Nobuo Ogashiwa > >>>>> > >>>>> > >>>>> > >>>>>> Regards, marcelo > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Sorry if the description in the draft made any confusion. > >>>>>>> Would you mind to point out lines that is hard to understand? > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Nobuo Ogashiwa > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> moreover, what is the length of the prefix being injected? > >>>>>>>> > >>>>>>>> I can see several possibilities here: > >>>>>>>> - a /48 for each multihomed site (of course if you have two > >>>>>>>> multihomed > >>>>>>>> customers that use the same two ISPs and they both have obtained > >>>>>>>> its > >>>>>>>> prefix from the same ISP and they have obtained aggregatable > >>>>>>>> prefixes, > >>>>>>>> you can aggregate those two prefixes into one, but i am not sure > >>>>>>>> how > >>>>>>>> likely this situation would be). Now if you inject a /48 (or a > >>>>>>>> /47), > >>>>>>>> you are basically doing current IPv4 multihoming solution with > >>>>>>>> its > >>>>>>>> scalability limitations > >>>>>>>> - a /32. At this case i can think of a couple of possibilities: > >>>>>>>> The /32 belong to one of the ISPs. This case doesn't makes > >>>>>>>> much > >>>>>>>> business sense imho, since this would mean that the ISP that is > >>>>>>>> announcing the prefix but does not owns the prefix will receive > >>>>>>>> all > >>>>>>>> the > >>>>>>>> traffic for that prefix even the traffic addressed to no > >>>>>>>> multihomed > >>>>>>>> customers. > >>>>>>>> The other option i can think of is that there is a special /32 > >>>>>>>> assigned to the clients multihomed with these two ISPs. Now this > >>>>>>>> is > >>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the CIDR > >>>>>>>> RFCs > >>>>>>>> (if i remember correctly). The problem with this is that you > >>>>>>>> need > >>>>>>>> an > >>>>>>>> important amount of /32 (more exactly the number of combinations > >>>>>>>> of > >>>>>>>> 2 > >>>>>>>> of all providers available, and then all the combinations of > >>>>>>>> three > >>>>>>>> and > >>>>>>>> so on). The other question that i have in this context, i fail > >>>>>>>> to > >>>>>>>> understand what do you need nemo or mip6 for doing this in any > >>>>>>>> case... > >>>>>>>> (so i guess i still don't understand you proposal : -( > >>>>>>>> > >>>>>>>> regards, marcelo > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Nobuo Ogashiwa > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Regards, marcelo > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> > >>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Dear all, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6- > >>>>>>>>>>>>>>> nemo- > >>>>>>>>>>>>>>> multihome- > >>>>>>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Abstract > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Multi-homing technology improves the availability of > >>>>>>>>>>>>>>> host > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> network connectivity. Since the node and network > >>>>>>>>>>>>>>> behavior > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>> mobile networking and fixed networking are > >>>>>>>>>>>>>>> different, > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> different architecture has been discussed and > >>>>>>>>>>>>>>> proposed. > >>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>> document proposes the common architecture both for > >>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> fixed networking environment, using the mobile IP > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> NEMO. > >>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>> proposed architecture only requires a modification > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In > >>>>>>>>>>>>>>> addition, > >>>>>>>>>>>>>>> multiple HAs which are located in different place, > >>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>> required > >>>>>>>>>>>>>>> for redundancy. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> It is nice if we can have a presentation solot for the > >>>>>>>>>>>>>>> draft. > >>>>>>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>> - 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 > >>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>> responsability > >>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Wed Jul 28 05:43: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 FAA17338 for ; Wed, 28 Jul 2004 05:43: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 1Bpkw7-0005rW-A2; Wed, 28 Jul 2004 05:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpkuw-0005Zw-Ur for nemo@megatron.ietf.org; Wed, 28 Jul 2004 05:40: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 FAA17165 for ; Wed, 28 Jul 2004 05:40:08 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpkwc-0002q1-In for nemo@ietf.org; Wed, 28 Jul 2004 05:42:01 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3037B3A493; Wed, 28 Jul 2004 11:39:26 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 12FFC3A491; Wed, 28 Jul 2004 11:39:26 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Wed, 28 Jul 2004 11:41:06 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable El 27/07/2004, a las 19:23, Nobuo OGASHIWA escribi=C3=B3: > > Dear Marcelo, > > At Tue, 27 Jul 2004 18:10:37 +0200, > marcelo bagnulo braun wrote: >> >>>> Ok this means that xSP needs to have as many /32 as possible >>>> combinations of two providers which a site may multihome. >>>> I mean, suppose that in a city there are n ISPs, then there are >>>> n(n-1)/2 combinations of 2 ISPs which a site can multihome to,=20 >>>> right? >>> >>> No. In this case, the xSP needs to have a exactry one /32 prefix. >>> >>> If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B,=20 >>> HA-C) >>> are setup into those three ISP's network. >>> >>> On the other hand if a multihomed user (user1) has multiple links >>> connected to >>> ISP-X and ISP-Y, and the user1 contract to the xSP, then >>> the user1 uses a nemo prefix as mobile network prefix, which is >>> extracted >>> from xSP's address block, and the user1 receive traffic via HA-A, >>> HA-B, HA-C. >>> In this case, the number of tunnels is 6 because the user1 has >>> two direct connection to ISP-X and ISP-y and user1 can use three = HAs, >>> HA-A, HA-B and HA-C. >>> >>> If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct >>> connection, >>> and contract to xSP for tunnel connection, then user2 also uses >>> a nemo prefix extracted from xSP's address block and receive packets >>> via >>> HA-A, HA-B, HA-C. >>> In this case, the number of tunnels is 9. >>> >>> I mean, regardless of number of directly connected links, >>> every multihomed users contract to the xSP can use every HAs >>> which are setup by the xSP, >>> and every ISPs contract to the xSP have to advertise a same address >>> block. >>> >>> >> >> i used the wrong terminology, sorry >> The point was not about ISPs that are connected to the end site, but >> about ISPs where the XSP places HA into. > > Ok. I get your point about the terminology. > > But, still I don't know why you think xSP needs many /32 prefixes. > The conceptual topology in our solution is just like full meshed > VPN connections between every HAs and every users (MRs), > those HAs act as border gateway routers of xSP, which advertise > a same prefix. > Note that every MRs are connected to every HAs so > the number of virtual links is number of HAs x number of MRs. > > I mean, I think the conceptual topology of xSP consists of multiple=20 > HAs, > multiple MRs, full meshed virtual links between HAs and MRs, > and subnetworks under MRs, which have nemo prefix. > And also I think that hosting HAs equals to peering, > and prefixes of subnetworks are aggregated into > a single /32 prefix then advertised from each HAs to peer ISPs. > In other word, every HAs of xSP advertise same /32 prefix to peer = ISPs. > So I think that, regardless of the number of HAs, xSP doesn't need > to have many /32 prefixes. > > I am concerned about two issues here: - First, the number of /32 required Suppose that we have two multihomed sites mhsite1 and mhsite2 The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2. mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a=20 Pref1:mhstie1::/48 from a prefix Pref1::/32 In order to make this work, ISP1 and ISP2 have to announce a route to=20 Pref1::/32 through BGP, agree? Now we consider mhsite2. mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3 mhsite2 obtains multihoming services from xSP also, the question now=20 is: is it possible for mhsite2 to obtain a /48 form Pref1::/32? Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48 In order to obtain traffic from its both ISP, both ISP2 and ISP3 have=20 to announce Pref1::/32, right? this would mean that ISP1, ISP2 and ISP3 will be announcing a route to=20= Pref1::/32 through BGP, right? This means that eventually ISP1 will carry traffic directed to mhsite1=20= right? This doesn't make any business sense AFAICS, i mean mhsite1 is not=20 paying money to ISP1, so why ISP1 would carry traffic for mhsite1? - The second point that i am concerned about is what do you need nemo=20 at all for building this solution? I mean suppose that mhsite is connected to ISP1 and ISP2, suppose that=20= there is a Pref::/32 assigned to the multihomed users of those two=20 ISPs, then all you need is that: - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 - ISP1 and ISP2 announce Pref::/32 through BGP AFAICS, you obtain the same solution without having to deal with HAs=20 nor nemo, what i am missing? regards, marcelo > Regards, > > Nobuo Ogashiwa > > > >> So the point is, using the new terminology >> >> xSP needs to have as many /32 as possible >> combinations of two providers which a multihomed site can have HAs >> placed into >> I mean, suppose that in a city there are n ISPs that can host HAs,=20 >> then >> there are >> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place its >> HAs >> So you need n(n-1)/2 prefixes assigned for this solution, right? >> >> regards, marcelo >> >> >> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>>> Perhaps these are too many /32s? >>>> And i am only considering sites that multihome to 2 isps, you may=20= >>>> need >>>> to consider the case when they multihome to 3, 4,... >>>> >>>> Anyway, why do you need nemo or mipv6 to build such a solution? >>>> I mean, imagine that you assign a /32 to each combination of any = two >>>> ISPs in a city, and you assign a /48 of this /32 of each site that >>>> multihome to those two ISP. All you need now is that these two isps >>>> announce the /32. You don't need nemo for this AFAICS. >>>> >>>> Regards, marcelo >>>> >>>>> Regards, >>>>> >>>>> Nobuo Ogashiwa >>>>> >>>>> >>>>>> thanks for your answers, >>>>>> regards, marcelo >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nobuo Ogashiwa >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry if the description in the draft made any confusion. >>>>>>>>> Would you mind to point out lines that is hard to understand? >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nobuo Ogashiwa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> moreover, what is the length of the prefix being injected? >>>>>>>>>> >>>>>>>>>> I can see several possibilities here: >>>>>>>>>> - a /48 for each multihomed site (of course if you have two >>>>>>>>>> multihomed >>>>>>>>>> customers that use the same two ISPs and they both have=20 >>>>>>>>>> obtained >>>>>>>>>> its >>>>>>>>>> prefix from the same ISP and they have obtained aggregatable >>>>>>>>>> prefixes, >>>>>>>>>> you can aggregate those two prefixes into one, but i am not=20= >>>>>>>>>> sure >>>>>>>>>> how >>>>>>>>>> likely this situation would be). Now if you inject a /48 (or = a >>>>>>>>>> /47), >>>>>>>>>> you are basically doing current IPv4 multihoming solution = with >>>>>>>>>> its >>>>>>>>>> scalability limitations >>>>>>>>>> - a /32. At this case i can think of a couple of=20 >>>>>>>>>> possibilities: >>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't makes >>>>>>>>>> much >>>>>>>>>> business sense imho, since this would mean that the ISP that=20= >>>>>>>>>> is >>>>>>>>>> announcing the prefix but does not owns the prefix will=20 >>>>>>>>>> receive >>>>>>>>>> all >>>>>>>>>> the >>>>>>>>>> traffic for that prefix even the traffic addressed to no >>>>>>>>>> multihomed >>>>>>>>>> customers. >>>>>>>>>> The other option i can think of is that there is a special=20= >>>>>>>>>> /32 >>>>>>>>>> assigned to the clients multihomed with these two ISPs. Now=20= >>>>>>>>>> this >>>>>>>>>> is >>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the=20 >>>>>>>>>> CIDR >>>>>>>>>> RFCs >>>>>>>>>> (if i remember correctly). The problem with this is that you >>>>>>>>>> need >>>>>>>>>> an >>>>>>>>>> important amount of /32 (more exactly the number of=20 >>>>>>>>>> combinations >>>>>>>>>> of >>>>>>>>>> 2 >>>>>>>>>> of all providers available, and then all the combinations of >>>>>>>>>> three >>>>>>>>>> and >>>>>>>>>> so on). The other question that i have in this context, i = fail >>>>>>>>>> to >>>>>>>>>> understand what do you need nemo or mip6 for doing this in = any >>>>>>>>>> case... >>>>>>>>>> (so i guess i still don't understand you proposal : -( >>>>>>>>>> >>>>>>>>>> regards, marcelo >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=E2=99=AD= : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6- >>>>>>>>>>>>>>>>> nemo- >>>>>>>>>>>>>>>>> multihome- >>>>>>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Abstract >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Multi-homing technology improves the availability=20= >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> host >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> network connectivity. Since the node and network >>>>>>>>>>>>>>>>> behavior >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> mobile networking and fixed networking are >>>>>>>>>>>>>>>>> different, >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> different architecture has been discussed and >>>>>>>>>>>>>>>>> proposed. >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>> document proposes the common architecture both = for >>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> fixed networking environment, using the mobile IP >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> NEMO. >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>> proposed architecture only requires a = modification >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In >>>>>>>>>>>>>>>>> addition, >>>>>>>>>>>>>>>>> multiple HAs which are located in different = place, >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> required >>>>>>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for the >>>>>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> - 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=20 >>>>>>>>>>>>>>>>>> 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=20= >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>> listed topic, or to add an item, please send your >>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> responsability >>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nemo-bounces@ietf.org Wed Jul 28 06:44: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 GAA19974 for ; Wed, 28 Jul 2004 06:44: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 1Bplsx-0005oq-Tg; Wed, 28 Jul 2004 06:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bplo3-0005FO-96 for nemo@megatron.ietf.org; Wed, 28 Jul 2004 06:37: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 GAA19608 for ; Wed, 28 Jul 2004 06:37:02 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bplpn-0003cA-UC for nemo@ietf.org; Wed, 28 Jul 2004 06:38:56 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 53DE73A76C; Wed, 28 Jul 2004 12:36:32 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 2163D3A772; Wed, 28 Jul 2004 12:36:25 +0200 (CEST) In-Reply-To: <3FB01DAC-E07A-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Wed, 28 Jul 2004 12:38:06 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22f8e36c8d8be0bcbb9bf02fb6ce7335 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable oops, i made a typo below... El 28/07/2004, a las 11:41, marcelo bagnulo braun escribi=C3=B3: > > El 27/07/2004, a las 19:23, Nobuo OGASHIWA escribi=C3=B3: > >> >> Dear Marcelo, >> >> At Tue, 27 Jul 2004 18:10:37 +0200, >> marcelo bagnulo braun wrote: >>> >>>>> Ok this means that xSP needs to have as many /32 as possible >>>>> combinations of two providers which a site may multihome. >>>>> I mean, suppose that in a city there are n ISPs, then there are >>>>> n(n-1)/2 combinations of 2 ISPs which a site can multihome to,=20 >>>>> right? >>>> >>>> No. In this case, the xSP needs to have a exactry one /32 prefix. >>>> >>>> If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B,=20= >>>> HA-C) >>>> are setup into those three ISP's network. >>>> >>>> On the other hand if a multihomed user (user1) has multiple links >>>> connected to >>>> ISP-X and ISP-Y, and the user1 contract to the xSP, then >>>> the user1 uses a nemo prefix as mobile network prefix, which is >>>> extracted >>>> from xSP's address block, and the user1 receive traffic via HA-A, >>>> HA-B, HA-C. >>>> In this case, the number of tunnels is 6 because the user1 has >>>> two direct connection to ISP-X and ISP-y and user1 can use three=20 >>>> HAs, >>>> HA-A, HA-B and HA-C. >>>> >>>> If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct >>>> connection, >>>> and contract to xSP for tunnel connection, then user2 also uses >>>> a nemo prefix extracted from xSP's address block and receive = packets >>>> via >>>> HA-A, HA-B, HA-C. >>>> In this case, the number of tunnels is 9. >>>> >>>> I mean, regardless of number of directly connected links, >>>> every multihomed users contract to the xSP can use every HAs >>>> which are setup by the xSP, >>>> and every ISPs contract to the xSP have to advertise a same address >>>> block. >>>> >>>> >>> >>> i used the wrong terminology, sorry >>> The point was not about ISPs that are connected to the end site, but >>> about ISPs where the XSP places HA into. >> >> Ok. I get your point about the terminology. >> >> But, still I don't know why you think xSP needs many /32 prefixes. >> The conceptual topology in our solution is just like full meshed >> VPN connections between every HAs and every users (MRs), >> those HAs act as border gateway routers of xSP, which advertise >> a same prefix. >> Note that every MRs are connected to every HAs so >> the number of virtual links is number of HAs x number of MRs. >> >> I mean, I think the conceptual topology of xSP consists of multiple=20= >> HAs, >> multiple MRs, full meshed virtual links between HAs and MRs, >> and subnetworks under MRs, which have nemo prefix. >> And also I think that hosting HAs equals to peering, >> and prefixes of subnetworks are aggregated into >> a single /32 prefix then advertised from each HAs to peer ISPs. >> In other word, every HAs of xSP advertise same /32 prefix to peer=20 >> ISPs. >> So I think that, regardless of the number of HAs, xSP doesn't need >> to have many /32 prefixes. >> >> > > I am concerned about two issues here: > > - First, the number of /32 required > > Suppose that we have two multihomed sites mhsite1 and mhsite2 > > The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2. > mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a=20= > Pref1:mhstie1::/48 from a prefix Pref1::/32 > In order to make this work, ISP1 and ISP2 have to announce a route to=20= > Pref1::/32 through BGP, > agree? > > Now we consider mhsite2. > mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3 > mhsite2 obtains multihoming services from xSP also, the question now=20= > is: is it possible for mhsite2 to obtain a /48 form Pref1::/32? > Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48 > In order to obtain traffic from its both ISP, both ISP2 and ISP3 have=20= > to announce Pref1::/32, right? > > this would mean that ISP1, ISP2 and ISP3 will be announcing a route to=20= > Pref1::/32 through BGP, right? > This means that eventually ISP1 will carry traffic directed to mhsite1=20= > right? = ^^^^^^^^ Should be mhsite2 instead of mhsite1, sorry for that. > This doesn't make any business sense AFAICS, i mean mhsite1 is not=20 > paying money to ISP1, so why ISP1 would carry traffic for mhsite1? ^^^^^^^^ Should be mhsite2 here too regards, marcelo > - The second point that i am concerned about is what do you need nemo=20= > at all for building this solution? > > I mean suppose that mhsite is connected to ISP1 and ISP2, suppose that=20= > there is a Pref::/32 assigned to the multihomed users of those two=20 > ISPs, then all you need is that: > - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 > - ISP1 and ISP2 announce Pref::/32 through BGP > > AFAICS, you obtain the same solution without having to deal with HAs=20= > nor nemo, what i am missing? > > regards, marcelo > >> Regards, >> >> Nobuo Ogashiwa >> >> >> >>> So the point is, using the new terminology >>> >>> xSP needs to have as many /32 as possible >>> combinations of two providers which a multihomed site can have HAs >>> placed into >>> I mean, suppose that in a city there are n ISPs that can host HAs,=20= >>> then >>> there are >>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place = its >>> HAs >>> So you need n(n-1)/2 prefixes assigned for this solution, right? >>> >>> regards, marcelo >>> >>> >>> >>>> Regards, >>>> >>>> Nobuo Ogashiwa >>>> >>>> >>>>> Perhaps these are too many /32s? >>>>> And i am only considering sites that multihome to 2 isps, you may=20= >>>>> need >>>>> to consider the case when they multihome to 3, 4,... >>>>> >>>>> Anyway, why do you need nemo or mipv6 to build such a solution? >>>>> I mean, imagine that you assign a /32 to each combination of any=20= >>>>> two >>>>> ISPs in a city, and you assign a /48 of this /32 of each site that >>>>> multihome to those two ISP. All you need now is that these two = isps >>>>> announce the /32. You don't need nemo for this AFAICS. >>>>> >>>>> Regards, marcelo >>>>> >>>>>> Regards, >>>>>> >>>>>> Nobuo Ogashiwa >>>>>> >>>>>> >>>>>>> thanks for your answers, >>>>>>> regards, marcelo >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Nobuo Ogashiwa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sorry if the description in the draft made any confusion. >>>>>>>>>> Would you mind to point out lines that is hard to understand? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> moreover, what is the length of the prefix being injected? >>>>>>>>>>> >>>>>>>>>>> I can see several possibilities here: >>>>>>>>>>> - a /48 for each multihomed site (of course if you have two >>>>>>>>>>> multihomed >>>>>>>>>>> customers that use the same two ISPs and they both have=20 >>>>>>>>>>> obtained >>>>>>>>>>> its >>>>>>>>>>> prefix from the same ISP and they have obtained aggregatable >>>>>>>>>>> prefixes, >>>>>>>>>>> you can aggregate those two prefixes into one, but i am not=20= >>>>>>>>>>> sure >>>>>>>>>>> how >>>>>>>>>>> likely this situation would be). Now if you inject a /48 (or=20= >>>>>>>>>>> a >>>>>>>>>>> /47), >>>>>>>>>>> you are basically doing current IPv4 multihoming solution=20 >>>>>>>>>>> with >>>>>>>>>>> its >>>>>>>>>>> scalability limitations >>>>>>>>>>> - a /32. At this case i can think of a couple of=20 >>>>>>>>>>> possibilities: >>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't makes >>>>>>>>>>> much >>>>>>>>>>> business sense imho, since this would mean that the ISP that=20= >>>>>>>>>>> is >>>>>>>>>>> announcing the prefix but does not owns the prefix will=20 >>>>>>>>>>> receive >>>>>>>>>>> all >>>>>>>>>>> the >>>>>>>>>>> traffic for that prefix even the traffic addressed to no >>>>>>>>>>> multihomed >>>>>>>>>>> customers. >>>>>>>>>>> The other option i can think of is that there is a special=20= >>>>>>>>>>> /32 >>>>>>>>>>> assigned to the clients multihomed with these two ISPs. Now=20= >>>>>>>>>>> this >>>>>>>>>>> is >>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the=20= >>>>>>>>>>> CIDR >>>>>>>>>>> RFCs >>>>>>>>>>> (if i remember correctly). The problem with this is that you >>>>>>>>>>> need >>>>>>>>>>> an >>>>>>>>>>> important amount of /32 (more exactly the number of=20 >>>>>>>>>>> combinations >>>>>>>>>>> of >>>>>>>>>>> 2 >>>>>>>>>>> of all providers available, and then all the combinations of >>>>>>>>>>> three >>>>>>>>>>> and >>>>>>>>>>> so on). The other question that i have in this context, i=20 >>>>>>>>>>> fail >>>>>>>>>>> to >>>>>>>>>>> understand what do you need nemo or mip6 for doing this in=20= >>>>>>>>>>> any >>>>>>>>>>> case... >>>>>>>>>>> (so i guess i still don't understand you proposal : -( >>>>>>>>>>> >>>>>>>>>>> regards, marcelo >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi=E2=99=AD= : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> = http://www.ietf.org/internet-drafts/draft-nagami-mip6- >>>>>>>>>>>>>>>>>> nemo- >>>>>>>>>>>>>>>>>> multihome- >>>>>>>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Abstract >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Multi-homing technology improves the=20 >>>>>>>>>>>>>>>>>> availability of >>>>>>>>>>>>>>>>>> host >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> network connectivity. Since the node and network >>>>>>>>>>>>>>>>>> behavior >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> mobile networking and fixed networking are >>>>>>>>>>>>>>>>>> different, >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> different architecture has been discussed and >>>>>>>>>>>>>>>>>> proposed. >>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>> document proposes the common architecture both=20= >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> fixed networking environment, using the mobile = IP >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> NEMO. >>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>> proposed architecture only requires a=20 >>>>>>>>>>>>>>>>>> modification >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In >>>>>>>>>>>>>>>>>> addition, >>>>>>>>>>>>>>>>>> multiple HAs which are located in different=20 >>>>>>>>>>>>>>>>>> place, >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> required >>>>>>>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for = the >>>>>>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We appreciate any comments, questions or suggestions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The San Diego meeting is fast approaching. The NEMO=20= >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> - 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=20 >>>>>>>>>>>>>>>>>>> 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=20= >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>>> listed topic, or to add an item, please send your >>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>>> chairs >>>>>>>>>>>>>>>>>>> by July 20th. Requests must be justified and will be >>>>>>>>>>>>>>>>>>> accepted >>>>>>>>>>>>>>>>>>> based >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> priorities of the WG and time allowed during our=20 >>>>>>>>>>>>>>>>>>> slot. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ----------- Submitted Drafts >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, if you have submitted a new draft since last >>>>>>>>>>>>>>>>>>> meeting, >>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>> intend >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> responsability >>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From nemo-bounces@ietf.org Wed Jul 28 09:12: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 JAA28212 for ; Wed, 28 Jul 2004 09:12: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 1BpoCG-0002QO-Nh; Wed, 28 Jul 2004 09:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpoC8-0002JH-SL for nemo@megatron.ietf.org; Wed, 28 Jul 2004 09:10: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 JAA28133 for ; Wed, 28 Jul 2004 09:10:07 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpoDw-0006KF-Ne for nemo@ietf.org; Wed, 28 Jul 2004 09:12:01 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 84F2F1D3121; Wed, 28 Jul 2004 22:10:31 +0900 (JST) Date: Wed, 28 Jul 2004 22:09:56 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <35D2A94C-E082-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 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 Dear Marcelo, At Wed, 28 Jul 2004 12:38:06 +0200, marcelo bagnulo braun wrote: > > oops, i made a typo below... > > El 28/07/2004, a las 11:41, marcelo bagnulo braun escribi.ANs: > > > > > El 27/07/2004, a las 19:23, Nobuo OGASHIWA escribi.ANs: > > > >> > >> Dear Marcelo, > >> > >> At Tue, 27 Jul 2004 18:10:37 +0200, > >> marcelo bagnulo braun wrote: > >>> > >>>>> Ok this means that xSP needs to have as many /32 as possible > >>>>> combinations of two providers which a site may multihome. > >>>>> I mean, suppose that in a city there are n ISPs, then there are > >>>>> n(n-1)/2 combinations of 2 ISPs which a site can multihome to, > >>>>> right? > >>>> > >>>> No. In this case, the xSP needs to have a exactry one /32 prefix. > >>>> > >>>> If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B, > >>>> HA-C) > >>>> are setup into those three ISP's network. > >>>> > >>>> On the other hand if a multihomed user (user1) has multiple links > >>>> connected to > >>>> ISP-X and ISP-Y, and the user1 contract to the xSP, then > >>>> the user1 uses a nemo prefix as mobile network prefix, which is > >>>> extracted > >>>> from xSP's address block, and the user1 receive traffic via HA-A, > >>>> HA-B, HA-C. > >>>> In this case, the number of tunnels is 6 because the user1 has > >>>> two direct connection to ISP-X and ISP-y and user1 can use three > >>>> HAs, > >>>> HA-A, HA-B and HA-C. > >>>> > >>>> If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct > >>>> connection, > >>>> and contract to xSP for tunnel connection, then user2 also uses > >>>> a nemo prefix extracted from xSP's address block and receive packets > >>>> via > >>>> HA-A, HA-B, HA-C. > >>>> In this case, the number of tunnels is 9. > >>>> > >>>> I mean, regardless of number of directly connected links, > >>>> every multihomed users contract to the xSP can use every HAs > >>>> which are setup by the xSP, > >>>> and every ISPs contract to the xSP have to advertise a same address > >>>> block. > >>>> > >>>> > >>> > >>> i used the wrong terminology, sorry > >>> The point was not about ISPs that are connected to the end site, but > >>> about ISPs where the XSP places HA into. > >> > >> Ok. I get your point about the terminology. > >> > >> But, still I don't know why you think xSP needs many /32 prefixes. > >> The conceptual topology in our solution is just like full meshed > >> VPN connections between every HAs and every users (MRs), > >> those HAs act as border gateway routers of xSP, which advertise > >> a same prefix. > >> Note that every MRs are connected to every HAs so > >> the number of virtual links is number of HAs x number of MRs. > >> > >> I mean, I think the conceptual topology of xSP consists of multiple > >> HAs, > >> multiple MRs, full meshed virtual links between HAs and MRs, > >> and subnetworks under MRs, which have nemo prefix. > >> And also I think that hosting HAs equals to peering, > >> and prefixes of subnetworks are aggregated into > >> a single /32 prefix then advertised from each HAs to peer ISPs. > >> In other word, every HAs of xSP advertise same /32 prefix to peer > >> ISPs. > >> So I think that, regardless of the number of HAs, xSP doesn't need > >> to have many /32 prefixes. > >> > >> > > > > I am concerned about two issues here: > > > > - First, the number of /32 required > > > > Suppose that we have two multihomed sites mhsite1 and mhsite2 > > > > The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2. > > mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a > > Pref1:mhstie1::/48 from a prefix Pref1::/32 > > In order to make this work, ISP1 and ISP2 have to announce a route to > > Pref1::/32 through BGP, > > agree? In our assumption, the organization that has HAs and place HAs in ISP is not multihomed site but xSP. Multihomed sites aquire a right to use HAs when contract to the xSP. > > Now we consider mhsite2. > > mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3 > > mhsite2 obtains multihoming services from xSP also, the question now > > is: is it possible for mhsite2 to obtain a /48 form Pref1::/32? > > Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48 > > In order to obtain traffic from its both ISP, both ISP2 and ISP3 have > > to announce Pref1::/32, right? > > this would mean that ISP1, ISP2 and ISP3 will be announcing a route to > > Pref1::/32 through BGP, right? > > This means that eventually ISP1 will carry traffic directed to mhsite1 > > right? > ^^^^^^^^ > Should be mhsite2 instead of mhsite1, sorry for that. > > This doesn't make any business sense AFAICS, i mean mhsite1 is not > > paying money to ISP1, so why ISP1 would carry traffic for mhsite1? > ^^^^^^^^ > Should be mhsite2 here too As I mentioned above, in our assumption, the organization that has HAs and place HAs in ISP is not multihomed site but xSP. I mean, mhsite2 and mhsite1 use same HAs, and every ISPs that host HAs announce a same route through BGP. Regards, Nobuo Ogashiwa > > regards, marcelo > > > - The second point that i am concerned about is what do you need nemo > > at all for building this solution? > > > > I mean suppose that mhsite is connected to ISP1 and ISP2, suppose that > > there is a Pref::/32 assigned to the multihomed users of those two > > ISPs, then all you need is that: > > - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 > > - ISP1 and ISP2 announce Pref::/32 through BGP > > > > AFAICS, you obtain the same solution without having to deal with HAs > > nor nemo, what i am missing? > > > > regards, marcelo > > > >> Regards, > >> > >> Nobuo Ogashiwa > >> > >> > >> > >>> So the point is, using the new terminology > >>> > >>> xSP needs to have as many /32 as possible > >>> combinations of two providers which a multihomed site can have HAs > >>> placed into > >>> I mean, suppose that in a city there are n ISPs that can host HAs, > >>> then > >>> there are > >>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place its > >>> HAs > >>> So you need n(n-1)/2 prefixes assigned for this solution, right? > >>> > >>> regards, marcelo > >>> > >>> > >>> > >>>> Regards, > >>>> > >>>> Nobuo Ogashiwa > >>>> > >>>> > >>>>> Perhaps these are too many /32s? > >>>>> And i am only considering sites that multihome to 2 isps, you may > >>>>> need > >>>>> to consider the case when they multihome to 3, 4,... > >>>>> > >>>>> Anyway, why do you need nemo or mipv6 to build such a solution? > >>>>> I mean, imagine that you assign a /32 to each combination of any > >>>>> two > >>>>> ISPs in a city, and you assign a /48 of this /32 of each site that > >>>>> multihome to those two ISP. All you need now is that these two isps > >>>>> announce the /32. You don't need nemo for this AFAICS. > >>>>> > >>>>> Regards, marcelo > >>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Nobuo Ogashiwa > >>>>>> > >>>>>> > >>>>>>> thanks for your answers, > >>>>>>> regards, marcelo > >>>>>>> > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Nobuo Ogashiwa > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Regards, marcelo > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Sorry if the description in the draft made any confusion. > >>>>>>>>>> Would you mind to point out lines that is hard to understand? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> moreover, what is the length of the prefix being injected? > >>>>>>>>>>> > >>>>>>>>>>> I can see several possibilities here: > >>>>>>>>>>> - a /48 for each multihomed site (of course if you have two > >>>>>>>>>>> multihomed > >>>>>>>>>>> customers that use the same two ISPs and they both have > >>>>>>>>>>> obtained > >>>>>>>>>>> its > >>>>>>>>>>> prefix from the same ISP and they have obtained aggregatable > >>>>>>>>>>> prefixes, > >>>>>>>>>>> you can aggregate those two prefixes into one, but i am not > >>>>>>>>>>> sure > >>>>>>>>>>> how > >>>>>>>>>>> likely this situation would be). Now if you inject a /48 (or > >>>>>>>>>>> a > >>>>>>>>>>> /47), > >>>>>>>>>>> you are basically doing current IPv4 multihoming solution > >>>>>>>>>>> with > >>>>>>>>>>> its > >>>>>>>>>>> scalability limitations > >>>>>>>>>>> - a /32. At this case i can think of a couple of > >>>>>>>>>>> possibilities: > >>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't makes > >>>>>>>>>>> much > >>>>>>>>>>> business sense imho, since this would mean that the ISP that > >>>>>>>>>>> is > >>>>>>>>>>> announcing the prefix but does not owns the prefix will > >>>>>>>>>>> receive > >>>>>>>>>>> all > >>>>>>>>>>> the > >>>>>>>>>>> traffic for that prefix even the traffic addressed to no > >>>>>>>>>>> multihomed > >>>>>>>>>>> customers. > >>>>>>>>>>> The other option i can think of is that there is a special > >>>>>>>>>>> /32 > >>>>>>>>>>> assigned to the clients multihomed with these two ISPs. Now > >>>>>>>>>>> this > >>>>>>>>>>> is > >>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the > >>>>>>>>>>> CIDR > >>>>>>>>>>> RFCs > >>>>>>>>>>> (if i remember correctly). The problem with this is that you > >>>>>>>>>>> need > >>>>>>>>>>> an > >>>>>>>>>>> important amount of /32 (more exactly the number of > >>>>>>>>>>> combinations > >>>>>>>>>>> of > >>>>>>>>>>> 2 > >>>>>>>>>>> of all providers available, and then all the combinations of > >>>>>>>>>>> three > >>>>>>>>>>> and > >>>>>>>>>>> so on). The other question that i have in this context, i > >>>>>>>>>>> fail > >>>>>>>>>>> to > >>>>>>>>>>> understand what do you need nemo or mip6 for doing this in > >>>>>>>>>>> any > >>>>>>>>>>> case... > >>>>>>>>>>> (so i guess i still don't understand you proposal : -( > >>>>>>>>>>> > >>>>>>>>>>> regards, marcelo > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Dear all, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6- > >>>>>>>>>>>>>>>>>> nemo- > >>>>>>>>>>>>>>>>>> multihome- > >>>>>>>>>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Abstract > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Multi-homing technology improves the > >>>>>>>>>>>>>>>>>> availability of > >>>>>>>>>>>>>>>>>> host > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> network connectivity. Since the node and network > >>>>>>>>>>>>>>>>>> behavior > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> mobile networking and fixed networking are > >>>>>>>>>>>>>>>>>> different, > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> different architecture has been discussed and > >>>>>>>>>>>>>>>>>> proposed. > >>>>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>>> document proposes the common architecture both > >>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> fixed networking environment, using the mobile IP > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> NEMO. > >>>>>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>>>>> proposed architecture only requires a > >>>>>>>>>>>>>>>>>> modification > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. In > >>>>>>>>>>>>>>>>>> addition, > >>>>>>>>>>>>>>>>>> multiple HAs which are located in different > >>>>>>>>>>>>>>>>>> place, > >>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>> required > >>>>>>>>>>>>>>>>>> for redundancy. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for the > >>>>>>>>>>>>>>>>>> draft. > >>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> We appreciate any comments, questions or suggestions. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>> - 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 > >>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>> responsability > >>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > > From nemo-bounces@ietf.org Wed Jul 28 09:47:28 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 JAA29941 for ; Wed, 28 Jul 2004 09:47: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 1Bpok6-0006sm-K3; Wed, 28 Jul 2004 09:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpoeJ-0005yZ-7J for nemo@megatron.ietf.org; Wed, 28 Jul 2004 09:39: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 JAA29633 for ; Wed, 28 Jul 2004 09:39:13 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpog7-0006pd-KB for nemo@ietf.org; Wed, 28 Jul 2004 09:41:08 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 59FD63A25B; Wed, 28 Jul 2004 15:38:42 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 411673A257; Wed, 28 Jul 2004 15:38:42 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Wed, 28 Jul 2004 15:40:23 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >>>> >>> >>> I am concerned about two issues here: >>> >>> - First, the number of /32 required >>> >>> Suppose that we have two multihomed sites mhsite1 and mhsite2 >>> >>> The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2. >>> mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a >>> Pref1:mhstie1::/48 from a prefix Pref1::/32 >>> In order to make this work, ISP1 and ISP2 have to announce a route = to >>> Pref1::/32 through BGP, >>> agree? > > In our assumption, the organization that has HAs and place HAs in ISP > is not multihomed site but xSP. Multihomed sites aquire a right to > use HAs when contract to the xSP. > > > >>> Now we consider mhsite2. >>> mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3 >>> mhsite2 obtains multihoming services from xSP also, the question now >>> is: is it possible for mhsite2 to obtain a /48 form Pref1::/32? >>> Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48 >>> In order to obtain traffic from its both ISP, both ISP2 and ISP3 = have >>> to announce Pref1::/32, right? >>> this would mean that ISP1, ISP2 and ISP3 will be announcing a route =20= >>> to >>> Pref1::/32 through BGP, right? >>> This means that eventually ISP1 will carry traffic directed to =20 >>> mhsite1 >>> right? >> =20 >> ^^^^^^^^ >> Should be mhsite2 instead of mhsite1, sorry for that. > >>> This doesn't make any business sense AFAICS, i mean mhsite1 is not >>> paying money to ISP1, so why ISP1 would carry traffic for mhsite1? >> ^^^^^^^^ >> Should be mhsite2 here too > > As I mentioned above, in our assumption, the organization that has HAs > and place HAs in ISP is not multihomed site but xSP. I mean, mhsite2 > and mhsite1 use same HAs, and every ISPs that host HAs announce a same > route through BGP. > > Which implies that an ISP hosting a HA may end up carrying traffic for =20= non customers site, which imho makes no business sense. In addition, i still don't see what does the nemo protocol is needed =10But i guess that your proposal is more clear for me now. Thanks for your answers, regards, marcelo > > Regards, > > Nobuo Ogashiwa > > >> >> regards, marcelo >> >>> - The second point that i am concerned about is what do you need = nemo >>> at all for building this solution? >>> >>> I mean suppose that mhsite is connected to ISP1 and ISP2, suppose =20= >>> that >>> there is a Pref::/32 assigned to the multihomed users of those two >>> ISPs, then all you need is that: >>> - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 >>> - ISP1 and ISP2 announce Pref::/32 through BGP >>> >>> AFAICS, you obtain the same solution without having to deal with HAs >>> nor nemo, what i am missing? >>> >>> regards, marcelo >>> >>>> Regards, >>>> >>>> Nobuo Ogashiwa >>>> >>>> >>>> >>>>> So the point is, using the new terminology >>>>> >>>>> xSP needs to have as many /32 as possible >>>>> combinations of two providers which a multihomed site can have HAs >>>>> placed into >>>>> I mean, suppose that in a city there are n ISPs that can host HAs, >>>>> then >>>>> there are >>>>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place =20= >>>>> its >>>>> HAs >>>>> So you need n(n-1)/2 prefixes assigned for this solution, right? >>>>> >>>>> regards, marcelo >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> Nobuo Ogashiwa >>>>>> >>>>>> >>>>>>> Perhaps these are too many /32s? >>>>>>> And i am only considering sites that multihome to 2 isps, you = may >>>>>>> need >>>>>>> to consider the case when they multihome to 3, 4,... >>>>>>> >>>>>>> Anyway, why do you need nemo or mipv6 to build such a solution? >>>>>>> I mean, imagine that you assign a /32 to each combination of any >>>>>>> two >>>>>>> ISPs in a city, and you assign a /48 of this /32 of each site =20= >>>>>>> that >>>>>>> multihome to those two ISP. All you need now is that these two =20= >>>>>>> isps >>>>>>> announce the /32. You don't need nemo for this AFAICS. >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Nobuo Ogashiwa >>>>>>>> >>>>>>>> >>>>>>>>> thanks for your answers, >>>>>>>>> regards, marcelo >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Regards, marcelo >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sorry if the description in the draft made any confusion. >>>>>>>>>>>> Would you mind to point out lines that is hard to =20 >>>>>>>>>>>> understand? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> moreover, what is the length of the prefix being injected? >>>>>>>>>>>>> >>>>>>>>>>>>> I can see several possibilities here: >>>>>>>>>>>>> - a /48 for each multihomed site (of course if you have = two >>>>>>>>>>>>> multihomed >>>>>>>>>>>>> customers that use the same two ISPs and they both have >>>>>>>>>>>>> obtained >>>>>>>>>>>>> its >>>>>>>>>>>>> prefix from the same ISP and they have obtained =20 >>>>>>>>>>>>> aggregatable >>>>>>>>>>>>> prefixes, >>>>>>>>>>>>> you can aggregate those two prefixes into one, but i am = not >>>>>>>>>>>>> sure >>>>>>>>>>>>> how >>>>>>>>>>>>> likely this situation would be). Now if you inject a /48 =20= >>>>>>>>>>>>> (or >>>>>>>>>>>>> a >>>>>>>>>>>>> /47), >>>>>>>>>>>>> you are basically doing current IPv4 multihoming solution >>>>>>>>>>>>> with >>>>>>>>>>>>> its >>>>>>>>>>>>> scalability limitations >>>>>>>>>>>>> - a /32. At this case i can think of a couple of >>>>>>>>>>>>> possibilities: >>>>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't =20 >>>>>>>>>>>>> makes >>>>>>>>>>>>> much >>>>>>>>>>>>> business sense imho, since this would mean that the ISP =20= >>>>>>>>>>>>> that >>>>>>>>>>>>> is >>>>>>>>>>>>> announcing the prefix but does not owns the prefix will >>>>>>>>>>>>> receive >>>>>>>>>>>>> all >>>>>>>>>>>>> the >>>>>>>>>>>>> traffic for that prefix even the traffic addressed to no >>>>>>>>>>>>> multihomed >>>>>>>>>>>>> customers. >>>>>>>>>>>>> The other option i can think of is that there is a =20 >>>>>>>>>>>>> special >>>>>>>>>>>>> /32 >>>>>>>>>>>>> assigned to the clients multihomed with these two ISPs. = Now >>>>>>>>>>>>> this >>>>>>>>>>>>> is >>>>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the >>>>>>>>>>>>> CIDR >>>>>>>>>>>>> RFCs >>>>>>>>>>>>> (if i remember correctly). The problem with this is that =20= >>>>>>>>>>>>> you >>>>>>>>>>>>> need >>>>>>>>>>>>> an >>>>>>>>>>>>> important amount of /32 (more exactly the number of >>>>>>>>>>>>> combinations >>>>>>>>>>>>> of >>>>>>>>>>>>> 2 >>>>>>>>>>>>> of all providers available, and then all the combinations =20= >>>>>>>>>>>>> of >>>>>>>>>>>>> three >>>>>>>>>>>>> and >>>>>>>>>>>>> so on). The other question that i have in this context, i >>>>>>>>>>>>> fail >>>>>>>>>>>>> to >>>>>>>>>>>>> understand what do you need nemo or mip6 for doing this in >>>>>>>>>>>>> any >>>>>>>>>>>>> case... >>>>>>>>>>>>> (so i guess i still don't understand you proposal : -( >>>>>>>>>>>>> >>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA = escribi=1B$B"u=1B(B: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami-=20= >>>>>>>>>>>>>>>>>>>> mip6- >>>>>>>>>>>>>>>>>>>> nemo- >>>>>>>>>>>>>>>>>>>> multihome- >>>>>>>>>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Abstract >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Multi-homing technology improves the >>>>>>>>>>>>>>>>>>>> availability of >>>>>>>>>>>>>>>>>>>> host >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> network connectivity. Since the node and =20 >>>>>>>>>>>>>>>>>>>> network >>>>>>>>>>>>>>>>>>>> behavior >>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> mobile networking and fixed networking are >>>>>>>>>>>>>>>>>>>> different, >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> different architecture has been discussed and >>>>>>>>>>>>>>>>>>>> proposed. >>>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>> document proposes the common architecture both >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> fixed networking environment, using the mobile = =20 >>>>>>>>>>>>>>>>>>>> IP >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> NEMO. >>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>> proposed architecture only requires a >>>>>>>>>>>>>>>>>>>> modification >>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. =20= >>>>>>>>>>>>>>>>>>>> In >>>>>>>>>>>>>>>>>>>> addition, >>>>>>>>>>>>>>>>>>>> multiple HAs which are located in different >>>>>>>>>>>>>>>>>>>> place, >>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> required >>>>>>>>>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for =20= >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We appreciate any comments, questions or =20 >>>>>>>>>>>>>>>>>>>> suggestions. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> - 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 =20 >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> chairs >>>>>>>>>>>>>>>>>>>>> by July 20th. Requests must be justified and will =20= >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> submit one before the deadline, please inform TJ =20= >>>>>>>>>>>>>>>>>>>>> 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 =20= >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> IETF-Announce >>>>>>>>>>>>>>>>>>>>> Mailing List, but these drafts were usually not >>>>>>>>>>>>>>>>>>>>> announced >>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> NEMO >>>>>>>>>>>>>>>>>>>>> ML. According to the new secretariat policy, it's =20= >>>>>>>>>>>>>>>>>>>>> now >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> responsability >>>>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > From nemo-bounces@ietf.org Wed Jul 28 10:10: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 KAA01781 for ; Wed, 28 Jul 2004 10:10: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 1Bpp5f-0005C8-21; Wed, 28 Jul 2004 10:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpp3T-0004K0-HO for nemo@megatron.ietf.org; Wed, 28 Jul 2004 10:05: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 KAA01176 for ; Wed, 28 Jul 2004 10:05:13 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpp5I-0007Hx-Jy for nemo@ietf.org; Wed, 28 Jul 2004 10:07:08 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 129B53A3D4; Wed, 28 Jul 2004 16:04:43 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id DBF9D3A3D2; Wed, 28 Jul 2004 16:04:42 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4F1F9EA0-E09F-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Agenda and Presentations Date: Wed, 28 Jul 2004 16:06:23 +0200 To: "T.J.Kniveton" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 TJ, El 26/07/2004, a las 18:55, T.J.Kniveton escribi=F3: > [Thierry: Does this sound OK to you?] > > Hello, > > Attached is the current version of the NEMO Agenda for IETF60. Due to=20= > the large number of requests to speak about new and updated drafts, we=20= > are going to try something a little different. After the slots for=20 > charter items and WG business, we will have a number of brief=20 > presentations. If there is enough interest, we can schedule an=20 > additional BAR BOF on Route Optimization outside of normal meeting=20 > times, I think that a RO Bar BOF would be very interesting. regards, marcelo > where authors can talk about their work more. Thierry will also be=20 > speaking about RO in the IRTF meeting. > > We have listed the authors requesting slots, and tried to fit everyone=20= > in. We'll re-shuffle as necessary, depending on time constraints. If=20= > you are listed and would like to give a brief update, please be aware > > - 5 minutes is a strict deadline > - Please consider talking about: > x The title of your draft and a brief overview > x What is your draft addressing and what are you solving / trying to=20= > accomplish > x Current issues, mailing list discussion > x Implementation status and number of implementations, if applicable > - Submit a presentation, 1-3 slides recommended, to Thierry and myself=20= > by this Thursday noon, PDT > > Thanks, > TJ & Thierry > > = From nemo-bounces@ietf.org Wed Jul 28 11:43: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 LAA08275 for ; Wed, 28 Jul 2004 11: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 1BpqUb-0004yc-CG; Wed, 28 Jul 2004 11:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpqMe-0003k4-Lt for nemo@megatron.ietf.org; Wed, 28 Jul 2004 11:29: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 LAA07360 for ; Wed, 28 Jul 2004 11:29: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 1BpqOT-0000KI-Ix for nemo@ietf.org; Wed, 28 Jul 2004 11:31:02 -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 D54835D11D for ; Thu, 29 Jul 2004 00:28:34 +0900 (JST) Date: Thu, 29 Jul 2004 00:26:45 +0900 (JST) Message-Id: <20040729.002645.13116872.watari@sfc.wide.ad.jp> To: nemo@ietf.org From: Masafumi Watari 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on RO Taxonomy 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 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 Wed Jul 28 11:59: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 LAA09588 for ; Wed, 28 Jul 2004 11:59: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 1Bpqjw-0007RF-5d; Wed, 28 Jul 2004 11:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpqZk-0005ru-SP for nemo@megatron.ietf.org; Wed, 28 Jul 2004 11:42: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 LAA08222 for ; Wed, 28 Jul 2004 11:42:37 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpqbZ-0000Yu-9E for nemo@ietf.org; Wed, 28 Jul 2004 11:44:34 -0400 Received: from pbg4.local.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 0A43C1D3121; Thu, 29 Jul 2004 00:43:09 +0900 (JST) Date: Thu, 29 Jul 2004 00:42:33 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 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 Dear Marcelo, At Wed, 28 Jul 2004 15:40:23 +0200, marcelo bagnulo braun wrote: > > >>>> > >>> > >>> I am concerned about two issues here: > >>> > >>> - First, the number of /32 required > >>> > >>> Suppose that we have two multihomed sites mhsite1 and mhsite2 > >>> > >>> The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2. > >>> mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a > >>> Pref1:mhstie1::/48 from a prefix Pref1::/32 > >>> In order to make this work, ISP1 and ISP2 have to announce a route to > >>> Pref1::/32 through BGP, > >>> agree? > > > > In our assumption, the organization that has HAs and place HAs in ISP > > is not multihomed site but xSP. Multihomed sites aquire a right to > > use HAs when contract to the xSP. > > > > > > > >>> Now we consider mhsite2. > >>> mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3 > >>> mhsite2 obtains multihoming services from xSP also, the question now > >>> is: is it possible for mhsite2 to obtain a /48 form Pref1::/32? > >>> Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48 > >>> In order to obtain traffic from its both ISP, both ISP2 and ISP3 have > >>> to announce Pref1::/32, right? > >>> this would mean that ISP1, ISP2 and ISP3 will be announcing a route > >>> to > >>> Pref1::/32 through BGP, right? > >>> This means that eventually ISP1 will carry traffic directed to > >>> mhsite1 > >>> right? > >> > >> ^^^^^^^^ > >> Should be mhsite2 instead of mhsite1, sorry for that. > > > >>> This doesn't make any business sense AFAICS, i mean mhsite1 is not > >>> paying money to ISP1, so why ISP1 would carry traffic for mhsite1? > >> ^^^^^^^^ > >> Should be mhsite2 here too > > > > As I mentioned above, in our assumption, the organization that has HAs > > and place HAs in ISP is not multihomed site but xSP. I mean, mhsite2 > > and mhsite1 use same HAs, and every ISPs that host HAs announce a same > > route through BGP. > > > > > > Which implies that an ISP hosting a HA may end up carrying traffic for > non customers site, which imho makes no business sense. I am assuming that under the contract to ISPs, the xSP pays for transit service and hosting. > In addition, i still don't see what does the nemo protocol is needed In our architecture, regardless of whether we use the NEMO protocol or not, a protocol to inform CoA, HoA, BID from MR to HA and a protocol to synchronize Binding Caches among HAs are required. The MIP6 and the NEMO with multiple CoA option and HAHA protocol satisfy our requirements. So we will use the NEMO protocol. One of purposes of our architecture is to accomplish redundant connection. So, keeping connectivity to the Internet, anytime, multihomed user can switch the ISP to use. (or unfortunatly a ISP goes down) At this time, the xSP have to be informed the multihomed user's care-of addresses to setup tunnles to the user's MR. Furthermore, to accomplish redundant connection, HA should not be a single point of failure. This is why we need HAHA protocol. Regards, Nobuo Ogashiwa > But i guess that your proposal is more clear for me now. > > Thanks for your answers, > regards, marcelo > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > >> > >> regards, marcelo > >> > >>> - The second point that i am concerned about is what do you need nemo > >>> at all for building this solution? > >>> > >>> I mean suppose that mhsite is connected to ISP1 and ISP2, suppose > >>> that > >>> there is a Pref::/32 assigned to the multihomed users of those two > >>> ISPs, then all you need is that: > >>> - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 > >>> - ISP1 and ISP2 announce Pref::/32 through BGP > >>> > >>> AFAICS, you obtain the same solution without having to deal with HAs > >>> nor nemo, what i am missing? > >>> > >>> regards, marcelo > >>> > >>>> Regards, > >>>> > >>>> Nobuo Ogashiwa > >>>> > >>>> > >>>> > >>>>> So the point is, using the new terminology > >>>>> > >>>>> xSP needs to have as many /32 as possible > >>>>> combinations of two providers which a multihomed site can have HAs > >>>>> placed into > >>>>> I mean, suppose that in a city there are n ISPs that can host HAs, > >>>>> then > >>>>> there are > >>>>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place > >>>>> its > >>>>> HAs > >>>>> So you need n(n-1)/2 prefixes assigned for this solution, right? > >>>>> > >>>>> regards, marcelo > >>>>> > >>>>> > >>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Nobuo Ogashiwa > >>>>>> > >>>>>> > >>>>>>> Perhaps these are too many /32s? > >>>>>>> And i am only considering sites that multihome to 2 isps, you may > >>>>>>> need > >>>>>>> to consider the case when they multihome to 3, 4,... > >>>>>>> > >>>>>>> Anyway, why do you need nemo or mipv6 to build such a solution? > >>>>>>> I mean, imagine that you assign a /32 to each combination of any > >>>>>>> two > >>>>>>> ISPs in a city, and you assign a /48 of this /32 of each site > >>>>>>> that > >>>>>>> multihome to those two ISP. All you need now is that these two > >>>>>>> isps > >>>>>>> announce the /32. You don't need nemo for this AFAICS. > >>>>>>> > >>>>>>> Regards, marcelo > >>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Nobuo Ogashiwa > >>>>>>>> > >>>>>>>> > >>>>>>>>> thanks for your answers, > >>>>>>>>> regards, marcelo > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Regards, marcelo > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Sorry if the description in the draft made any confusion. > >>>>>>>>>>>> Would you mind to point out lines that is hard to > >>>>>>>>>>>> understand? > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> moreover, what is the length of the prefix being injected? > >>>>>>>>>>>>> > >>>>>>>>>>>>> I can see several possibilities here: > >>>>>>>>>>>>> - a /48 for each multihomed site (of course if you have two > >>>>>>>>>>>>> multihomed > >>>>>>>>>>>>> customers that use the same two ISPs and they both have > >>>>>>>>>>>>> obtained > >>>>>>>>>>>>> its > >>>>>>>>>>>>> prefix from the same ISP and they have obtained > >>>>>>>>>>>>> aggregatable > >>>>>>>>>>>>> prefixes, > >>>>>>>>>>>>> you can aggregate those two prefixes into one, but i am not > >>>>>>>>>>>>> sure > >>>>>>>>>>>>> how > >>>>>>>>>>>>> likely this situation would be). Now if you inject a /48 > >>>>>>>>>>>>> (or > >>>>>>>>>>>>> a > >>>>>>>>>>>>> /47), > >>>>>>>>>>>>> you are basically doing current IPv4 multihoming solution > >>>>>>>>>>>>> with > >>>>>>>>>>>>> its > >>>>>>>>>>>>> scalability limitations > >>>>>>>>>>>>> - a /32. At this case i can think of a couple of > >>>>>>>>>>>>> possibilities: > >>>>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't > >>>>>>>>>>>>> makes > >>>>>>>>>>>>> much > >>>>>>>>>>>>> business sense imho, since this would mean that the ISP > >>>>>>>>>>>>> that > >>>>>>>>>>>>> is > >>>>>>>>>>>>> announcing the prefix but does not owns the prefix will > >>>>>>>>>>>>> receive > >>>>>>>>>>>>> all > >>>>>>>>>>>>> the > >>>>>>>>>>>>> traffic for that prefix even the traffic addressed to no > >>>>>>>>>>>>> multihomed > >>>>>>>>>>>>> customers. > >>>>>>>>>>>>> The other option i can think of is that there is a > >>>>>>>>>>>>> special > >>>>>>>>>>>>> /32 > >>>>>>>>>>>>> assigned to the clients multihomed with these two ISPs. Now > >>>>>>>>>>>>> this > >>>>>>>>>>>>> is > >>>>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the > >>>>>>>>>>>>> CIDR > >>>>>>>>>>>>> RFCs > >>>>>>>>>>>>> (if i remember correctly). The problem with this is that > >>>>>>>>>>>>> you > >>>>>>>>>>>>> need > >>>>>>>>>>>>> an > >>>>>>>>>>>>> important amount of /32 (more exactly the number of > >>>>>>>>>>>>> combinations > >>>>>>>>>>>>> of > >>>>>>>>>>>>> 2 > >>>>>>>>>>>>> of all providers available, and then all the combinations > >>>>>>>>>>>>> of > >>>>>>>>>>>>> three > >>>>>>>>>>>>> and > >>>>>>>>>>>>> so on). The other question that i have in this context, i > >>>>>>>>>>>>> fail > >>>>>>>>>>>>> to > >>>>>>>>>>>>> understand what do you need nemo or mip6 for doing this in > >>>>>>>>>>>>> any > >>>>>>>>>>>>> case... > >>>>>>>>>>>>> (so i guess i still don't understand you proposal : -( > >>>>>>>>>>>>> > >>>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Dear all, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami- > >>>>>>>>>>>>>>>>>>>> mip6- > >>>>>>>>>>>>>>>>>>>> nemo- > >>>>>>>>>>>>>>>>>>>> multihome- > >>>>>>>>>>>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Abstract > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Multi-homing technology improves the > >>>>>>>>>>>>>>>>>>>> availability of > >>>>>>>>>>>>>>>>>>>> host > >>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> network connectivity. Since the node and > >>>>>>>>>>>>>>>>>>>> network > >>>>>>>>>>>>>>>>>>>> behavior > >>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> mobile networking and fixed networking are > >>>>>>>>>>>>>>>>>>>> different, > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> different architecture has been discussed and > >>>>>>>>>>>>>>>>>>>> proposed. > >>>>>>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>>>>> document proposes the common architecture both > >>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> fixed networking environment, using the mobile > >>>>>>>>>>>>>>>>>>>> IP > >>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> NEMO. > >>>>>>>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>>>>>>> proposed architecture only requires a > >>>>>>>>>>>>>>>>>>>> modification > >>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. > >>>>>>>>>>>>>>>>>>>> In > >>>>>>>>>>>>>>>>>>>> addition, > >>>>>>>>>>>>>>>>>>>> multiple HAs which are located in different > >>>>>>>>>>>>>>>>>>>> place, > >>>>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>> required > >>>>>>>>>>>>>>>>>>>> for redundancy. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> draft. > >>>>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> We appreciate any comments, questions or > >>>>>>>>>>>>>>>>>>>> suggestions. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>> - 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 > >>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>> responsability > >>>>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > > > From nemo-bounces@ietf.org Wed Jul 28 12:21: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 MAA12686 for ; Wed, 28 Jul 2004 12:21: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 1Bpqzo-0001ia-L3; Wed, 28 Jul 2004 12:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpqqG-0008KK-Uo for nemo@megatron.ietf.org; Wed, 28 Jul 2004 11:59: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 LAA09624 for ; Wed, 28 Jul 2004 11:59:42 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpqs6-0000rK-RL for nemo@ietf.org; Wed, 28 Jul 2004 12:01:39 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 89B243A502; Wed, 28 Jul 2004 17:59:12 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 6EE653A500; Wed, 28 Jul 2004 17:59:12 +0200 (CEST) In-Reply-To: References: <20040705124248.6b770d2e.ernst@sfc.wide.ad.jp> <6910A7E8-CFBA-11D8-B9D5-000A95DA08F2@kniveton.com> <20040712184738.62b08869.ernst@sfc.wide.ad.jp> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <4DCF86EA-E0AF-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP Date: Wed, 28 Jul 2004 18:00:53 +0200 To: Nobuo OGASHIWA X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >> >> Which implies that an ISP hosting a HA may end up carrying traffic = for >> non customers site, which imho makes no business sense. > > I am assuming that under the contract to ISPs, the xSP pays for > transit service and hosting. > So, you are assuming that the xSP defines where to put the HAs, not the=20= multihomed site? If not, you may end up in a situation where ISP1 has 100 HAs ISP2 has=20 300 Has and ISP3 has 3 Has, which may be difficult to solve, i guess > >> In addition, i still don't see what does the nemo protocol is needed > > In our architecture, regardless of whether we use the NEMO protocol or > not, a protocol to inform CoA, HoA, BID from MR to HA and a protocol > to synchronize Binding Caches among HAs are required. The MIP6 and > the NEMO with multiple CoA option and HAHA protocol satisfy our > requirements. So we will use the NEMO protocol. > > One of purposes of our architecture is to accomplish redundant=20 > connection. > So, keeping connectivity to the Internet, anytime, multihomed user can > switch the ISP to use. (or unfortunatly a ISP goes down) At this time, > the xSP have to be informed the multihomed user's care-of addresses > to setup tunnles to the user's MR. > > Furthermore, to accomplish redundant connection, HA should not be a > single point of failure. This is why we need HAHA protocol. Yes i see that but imho a solution where two ISPs announce the prefix=20 reserved for multihomed users of those providers would provide several=20= benefits: - optimized routing - lower overhead - less points of failure (you only rely on the ISPs, not in the HAs) - simplicity - cheaper (you don't have to pay to the XSP) Regards, marcelo > > > > Regards, > > Nobuo Ogashiwa > > > >> =10But i guess that your proposal is more clear for me now. >> >> Thanks for your answers, >> regards, marcelo >> >>> >>> Regards, >>> >>> Nobuo Ogashiwa >>> >>> >>>> >>>> regards, marcelo >>>> >>>>> - The second point that i am concerned about is what do you need=20= >>>>> nemo >>>>> at all for building this solution? >>>>> >>>>> I mean suppose that mhsite is connected to ISP1 and ISP2, suppose >>>>> that >>>>> there is a Pref::/32 assigned to the multihomed users of those two >>>>> ISPs, then all you need is that: >>>>> - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 >>>>> - ISP1 and ISP2 announce Pref::/32 through BGP >>>>> >>>>> AFAICS, you obtain the same solution without having to deal with=20= >>>>> HAs >>>>> nor nemo, what i am missing? >>>>> >>>>> regards, marcelo >>>>> >>>>>> Regards, >>>>>> >>>>>> Nobuo Ogashiwa >>>>>> >>>>>> >>>>>> >>>>>>> So the point is, using the new terminology >>>>>>> >>>>>>> xSP needs to have as many /32 as possible >>>>>>> combinations of two providers which a multihomed site can have=20= >>>>>>> HAs >>>>>>> placed into >>>>>>> I mean, suppose that in a city there are n ISPs that can host=20 >>>>>>> HAs, >>>>>>> then >>>>>>> there are >>>>>>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can = place >>>>>>> its >>>>>>> HAs >>>>>>> So you need n(n-1)/2 prefixes assigned for this solution, right? >>>>>>> >>>>>>> regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Nobuo Ogashiwa >>>>>>>> >>>>>>>> >>>>>>>>> Perhaps these are too many /32s? >>>>>>>>> And i am only considering sites that multihome to 2 isps, you=20= >>>>>>>>> may >>>>>>>>> need >>>>>>>>> to consider the case when they multihome to 3, 4,... >>>>>>>>> >>>>>>>>> Anyway, why do you need nemo or mipv6 to build such a = solution? >>>>>>>>> I mean, imagine that you assign a /32 to each combination of=20= >>>>>>>>> any >>>>>>>>> two >>>>>>>>> ISPs in a city, and you assign a /48 of this /32 of each site >>>>>>>>> that >>>>>>>>> multihome to those two ISP. All you need now is that these two >>>>>>>>> isps >>>>>>>>> announce the /32. You don't need nemo for this AFAICS. >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> thanks for your answers, >>>>>>>>>>> regards, marcelo >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry if the description in the draft made any confusion. >>>>>>>>>>>>>> Would you mind to point out lines that is hard to >>>>>>>>>>>>>> understand? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> moreover, what is the length of the prefix being=20 >>>>>>>>>>>>>>> injected? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can see several possibilities here: >>>>>>>>>>>>>>> - a /48 for each multihomed site (of course if you have=20= >>>>>>>>>>>>>>> two >>>>>>>>>>>>>>> multihomed >>>>>>>>>>>>>>> customers that use the same two ISPs and they both have >>>>>>>>>>>>>>> obtained >>>>>>>>>>>>>>> its >>>>>>>>>>>>>>> prefix from the same ISP and they have obtained >>>>>>>>>>>>>>> aggregatable >>>>>>>>>>>>>>> prefixes, >>>>>>>>>>>>>>> you can aggregate those two prefixes into one, but i am=20= >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> sure >>>>>>>>>>>>>>> how >>>>>>>>>>>>>>> likely this situation would be). Now if you inject a /48 >>>>>>>>>>>>>>> (or >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> /47), >>>>>>>>>>>>>>> you are basically doing current IPv4 multihoming = solution >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> its >>>>>>>>>>>>>>> scalability limitations >>>>>>>>>>>>>>> - a /32. At this case i can think of a couple of >>>>>>>>>>>>>>> possibilities: >>>>>>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't >>>>>>>>>>>>>>> makes >>>>>>>>>>>>>>> much >>>>>>>>>>>>>>> business sense imho, since this would mean that the ISP >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> announcing the prefix but does not owns the prefix will >>>>>>>>>>>>>>> receive >>>>>>>>>>>>>>> all >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> traffic for that prefix even the traffic addressed to no >>>>>>>>>>>>>>> multihomed >>>>>>>>>>>>>>> customers. >>>>>>>>>>>>>>> The other option i can think of is that there is a >>>>>>>>>>>>>>> special >>>>>>>>>>>>>>> /32 >>>>>>>>>>>>>>> assigned to the clients multihomed with these two ISPs.=20= >>>>>>>>>>>>>>> Now >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of=20= >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> CIDR >>>>>>>>>>>>>>> RFCs >>>>>>>>>>>>>>> (if i remember correctly). The problem with this is that >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> need >>>>>>>>>>>>>>> an >>>>>>>>>>>>>>> important amount of /32 (more exactly the number of >>>>>>>>>>>>>>> combinations >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> 2 >>>>>>>>>>>>>>> of all providers available, and then all the = combinations >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> three >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> so on). The other question that i have in this context, = i >>>>>>>>>>>>>>> fail >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> understand what do you need nemo or mip6 for doing this=20= >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> any >>>>>>>>>>>>>>> case... >>>>>>>>>>>>>>> (so i guess i still don't understand you proposal : -( >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> However, you can also set up multiple HAs in same = ISP. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> regards, marcelo >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, marcelo >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA = escribi=1B$B"u=1B(B: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We have submitted an updated draft. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami- >>>>>>>>>>>>>>>>>>>>>> mip6- >>>>>>>>>>>>>>>>>>>>>> nemo- >>>>>>>>>>>>>>>>>>>>>> multihome- >>>>>>>>>>>>>>>>>>>>>> fixed-network-01.txt >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Abstract >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Multi-homing technology improves the >>>>>>>>>>>>>>>>>>>>>> availability of >>>>>>>>>>>>>>>>>>>>>> host >>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> network connectivity. Since the node and >>>>>>>>>>>>>>>>>>>>>> network >>>>>>>>>>>>>>>>>>>>>> behavior >>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>> mobile networking and fixed networking are >>>>>>>>>>>>>>>>>>>>>> different, >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> different architecture has been discussed = and >>>>>>>>>>>>>>>>>>>>>> proposed. >>>>>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>>>> document proposes the common architecture=20 >>>>>>>>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> fixed networking environment, using the=20 >>>>>>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>>>>>> IP >>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> NEMO. >>>>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>>>> proposed architecture only requires a >>>>>>>>>>>>>>>>>>>>>> modification >>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> mobile >>>>>>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be = used. >>>>>>>>>>>>>>>>>>>>>> In >>>>>>>>>>>>>>>>>>>>>> addition, >>>>>>>>>>>>>>>>>>>>>> multiple HAs which are located in different >>>>>>>>>>>>>>>>>>>>>> place, >>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>> required >>>>>>>>>>>>>>>>>>>>>> for redundancy. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot = for >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We appreciate any comments, questions or >>>>>>>>>>>>>>>>>>>>>> suggestions. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, >>>>>>>>>>>>>>>>>>>>>> Thierry Ernst wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The San Diego meeting is fast approaching. The=20= >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>> - 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=20 >>>>>>>>>>>>>>>>>>>>>>> related >>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> above >>>>>>>>>>>>>>>>>>>>>>> listed topic, or to add an item, please send = your >>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>>>>>>> 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=20 >>>>>>>>>>>>>>>>>>>>>>> last >>>>>>>>>>>>>>>>>>>>>>> meeting, >>>>>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>>>>>> intend >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>> submit one before the deadline, please inform TJ >>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>> myself >>>>>>>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>> can list all the ACTIVE drafts in the reading=20 >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>> responsability >>>>>>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>> NEMO Chairs. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > From nemo-bounces@ietf.org Wed Jul 28 21:16:38 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 VAA20337 for ; Wed, 28 Jul 2004 21:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpzS1-0003OT-1A; Wed, 28 Jul 2004 21:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpzQK-0002uH-01 for nemo@megatron.ietf.org; Wed, 28 Jul 2004 21:09: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 VAA20051 for ; Wed, 28 Jul 2004 21:09:30 -0400 (EDT) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpzSE-0002RV-Hs for nemo@ietf.org; Wed, 28 Jul 2004 21:11:31 -0400 Received: from dhcp209.inetcore.com.local (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id DB1471D3121; Thu, 29 Jul 2004 10:09:56 +0900 (JST) Date: Thu, 29 Jul 2004 10:09:21 +0900 Message-ID: From: Nobuo OGASHIWA To: marcelo bagnulo braun Subject: Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP In-Reply-To: <4DCF86EA-E0AF-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> <4043F4C2-DC90-11D8-A131-000D93ACD0FE@it.uc3m.es> <2699A758-DCC4-11D8-A131-000D93ACD0FE@it.uc3m.es> <278B98DA-DEE6-11D8-A131-000D93ACD0FE@it.uc3m.es> <86012C65-DF13-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E02DACD-DF21-11D8-A131-000D93ACD0FE@it.uc3m.es> <46CFC2F8-DFBE-11D8-A131-000D93ACD0FE@it.uc3m.es> <7F4AD81F-DFE7-11D8-A131-000D93ACD0FE@it.uc3m.es> <3FB01DAC-E07A-11D8-A131-000D93ACD0FE@it.uc3m.es> <35D2A94C-E082-11D8-A131-000D93ACD0FE@it.uc3m.es> <4DCF86EA-E0AF-11D8-A131-000D93ACD0FE@it.uc3m.es> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.3.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 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 Dear Marcelo, At Wed, 28 Jul 2004 18:00:53 +0200, marcelo bagnulo braun wrote: > > >> > >> Which implies that an ISP hosting a HA may end up carrying traffic for > >> non customers site, which imho makes no business sense. > > > > I am assuming that under the contract to ISPs, the xSP pays for > > transit service and hosting. > > > > So, you are assuming that the xSP defines where to put the HAs, not the > multihomed site? yes. > If not, you may end up in a situation where ISP1 has 100 HAs ISP2 has > 300 Has and ISP3 has 3 Has, which may be difficult to solve, i guess > > > > >> In addition, i still don't see what does the nemo protocol is needed > > > > In our architecture, regardless of whether we use the NEMO protocol or > > not, a protocol to inform CoA, HoA, BID from MR to HA and a protocol > > to synchronize Binding Caches among HAs are required. The MIP6 and > > the NEMO with multiple CoA option and HAHA protocol satisfy our > > requirements. So we will use the NEMO protocol. > > > > One of purposes of our architecture is to accomplish redundant > > connection. > > So, keeping connectivity to the Internet, anytime, multihomed user can > > switch the ISP to use. (or unfortunatly a ISP goes down) At this time, > > the xSP have to be informed the multihomed user's care-of addresses > > to setup tunnles to the user's MR. > > > > Furthermore, to accomplish redundant connection, HA should not be a > > single point of failure. This is why we need HAHA protocol. > > Yes i see that but imho a solution where two ISPs announce the prefix > reserved for multihomed users of those providers would provide several > benefits: > - optimized routing > - lower overhead > - less points of failure (you only rely on the ISPs, not in the HAs) > - simplicity > - cheaper (you don't have to pay to the XSP) I think it is good suggestion. But, one of purposes of our architecture is to make it possible for multihomed user to control in-comming traffic. That is, to make it possible for multihomed user to decide a tunnel to use for specific flow, packet, or application. To accomplish, a protocol to control HA will be required. We are now discussing about such protocols. Anyway, I think that HA or something like HA will be required to accomplish the purpose. Regards, Nobuo Ogashiwa > Regards, marcelo > > > > > > > > > Regards, > > > > Nobuo Ogashiwa > > > > > > > >> But i guess that your proposal is more clear for me now. > >> > >> Thanks for your answers, > >> regards, marcelo > >> > >>> > >>> Regards, > >>> > >>> Nobuo Ogashiwa > >>> > >>> > >>>> > >>>> regards, marcelo > >>>> > >>>>> - The second point that i am concerned about is what do you need > >>>>> nemo > >>>>> at all for building this solution? > >>>>> > >>>>> I mean suppose that mhsite is connected to ISP1 and ISP2, suppose > >>>>> that > >>>>> there is a Pref::/32 assigned to the multihomed users of those two > >>>>> ISPs, then all you need is that: > >>>>> - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48 > >>>>> - ISP1 and ISP2 announce Pref::/32 through BGP > >>>>> > >>>>> AFAICS, you obtain the same solution without having to deal with > >>>>> HAs > >>>>> nor nemo, what i am missing? > >>>>> > >>>>> regards, marcelo > >>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Nobuo Ogashiwa > >>>>>> > >>>>>> > >>>>>> > >>>>>>> So the point is, using the new terminology > >>>>>>> > >>>>>>> xSP needs to have as many /32 as possible > >>>>>>> combinations of two providers which a multihomed site can have > >>>>>>> HAs > >>>>>>> placed into > >>>>>>> I mean, suppose that in a city there are n ISPs that can host > >>>>>>> HAs, > >>>>>>> then > >>>>>>> there are > >>>>>>> n(n-1)/2 combinations of 2 ISPs which a multihomed site can place > >>>>>>> its > >>>>>>> HAs > >>>>>>> So you need n(n-1)/2 prefixes assigned for this solution, right? > >>>>>>> > >>>>>>> regards, marcelo > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Nobuo Ogashiwa > >>>>>>>> > >>>>>>>> > >>>>>>>>> Perhaps these are too many /32s? > >>>>>>>>> And i am only considering sites that multihome to 2 isps, you > >>>>>>>>> may > >>>>>>>>> need > >>>>>>>>> to consider the case when they multihome to 3, 4,... > >>>>>>>>> > >>>>>>>>> Anyway, why do you need nemo or mipv6 to build such a solution? > >>>>>>>>> I mean, imagine that you assign a /32 to each combination of > >>>>>>>>> any > >>>>>>>>> two > >>>>>>>>> ISPs in a city, and you assign a /48 of this /32 of each site > >>>>>>>>> that > >>>>>>>>> multihome to those two ISP. All you need now is that these two > >>>>>>>>> isps > >>>>>>>>> announce the /32. You don't need nemo for this AFAICS. > >>>>>>>>> > >>>>>>>>> Regards, marcelo > >>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> thanks for your answers, > >>>>>>>>>>> regards, marcelo > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sorry if the description in the draft made any confusion. > >>>>>>>>>>>>>> Would you mind to point out lines that is hard to > >>>>>>>>>>>>>> understand? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> moreover, what is the length of the prefix being > >>>>>>>>>>>>>>> injected? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can see several possibilities here: > >>>>>>>>>>>>>>> - a /48 for each multihomed site (of course if you have > >>>>>>>>>>>>>>> two > >>>>>>>>>>>>>>> multihomed > >>>>>>>>>>>>>>> customers that use the same two ISPs and they both have > >>>>>>>>>>>>>>> obtained > >>>>>>>>>>>>>>> its > >>>>>>>>>>>>>>> prefix from the same ISP and they have obtained > >>>>>>>>>>>>>>> aggregatable > >>>>>>>>>>>>>>> prefixes, > >>>>>>>>>>>>>>> you can aggregate those two prefixes into one, but i am > >>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>> sure > >>>>>>>>>>>>>>> how > >>>>>>>>>>>>>>> likely this situation would be). Now if you inject a /48 > >>>>>>>>>>>>>>> (or > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>> /47), > >>>>>>>>>>>>>>> you are basically doing current IPv4 multihoming solution > >>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>> its > >>>>>>>>>>>>>>> scalability limitations > >>>>>>>>>>>>>>> - a /32. At this case i can think of a couple of > >>>>>>>>>>>>>>> possibilities: > >>>>>>>>>>>>>>> The /32 belong to one of the ISPs. This case doesn't > >>>>>>>>>>>>>>> makes > >>>>>>>>>>>>>>> much > >>>>>>>>>>>>>>> business sense imho, since this would mean that the ISP > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>> announcing the prefix but does not owns the prefix will > >>>>>>>>>>>>>>> receive > >>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> traffic for that prefix even the traffic addressed to no > >>>>>>>>>>>>>>> multihomed > >>>>>>>>>>>>>>> customers. > >>>>>>>>>>>>>>> The other option i can think of is that there is a > >>>>>>>>>>>>>>> special > >>>>>>>>>>>>>>> /32 > >>>>>>>>>>>>>>> assigned to the clients multihomed with these two ISPs. > >>>>>>>>>>>>>>> Now > >>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> CIDR > >>>>>>>>>>>>>>> RFCs > >>>>>>>>>>>>>>> (if i remember correctly). The problem with this is that > >>>>>>>>>>>>>>> you > >>>>>>>>>>>>>>> need > >>>>>>>>>>>>>>> an > >>>>>>>>>>>>>>> important amount of /32 (more exactly the number of > >>>>>>>>>>>>>>> combinations > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>> 2 > >>>>>>>>>>>>>>> of all providers available, and then all the combinations > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>> three > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> so on). The other question that i have in this context, i > >>>>>>>>>>>>>>> fail > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>> understand what do you need nemo or mip6 for doing this > >>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>> any > >>>>>>>>>>>>>>> case... > >>>>>>>>>>>>>>> (so i guess i still don't understand you proposal : -( > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> regards, marcelo > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Regards, marcelo > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi$B"u(B: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Dear all, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> We have submitted an updated draft. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami- > >>>>>>>>>>>>>>>>>>>>>> mip6- > >>>>>>>>>>>>>>>>>>>>>> nemo- > >>>>>>>>>>>>>>>>>>>>>> multihome- > >>>>>>>>>>>>>>>>>>>>>> fixed-network-01.txt > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Abstract > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Multi-homing technology improves the > >>>>>>>>>>>>>>>>>>>>>> availability of > >>>>>>>>>>>>>>>>>>>>>> host > >>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> network connectivity. Since the node and > >>>>>>>>>>>>>>>>>>>>>> network > >>>>>>>>>>>>>>>>>>>>>> behavior > >>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>> mobile networking and fixed networking are > >>>>>>>>>>>>>>>>>>>>>> different, > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> different architecture has been discussed and > >>>>>>>>>>>>>>>>>>>>>> proposed. > >>>>>>>>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>>>>>>> document proposes the common architecture > >>>>>>>>>>>>>>>>>>>>>> both > >>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> fixed networking environment, using the > >>>>>>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>>>>>> IP > >>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> NEMO. > >>>>>>>>>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>>>>>>>>> proposed architecture only requires a > >>>>>>>>>>>>>>>>>>>>>> modification > >>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> mobile > >>>>>>>>>>>>>>>>>>>>>> IP and NEMO so that multiple-CoA can be used. > >>>>>>>>>>>>>>>>>>>>>> In > >>>>>>>>>>>>>>>>>>>>>> addition, > >>>>>>>>>>>>>>>>>>>>>> multiple HAs which are located in different > >>>>>>>>>>>>>>>>>>>>>> place, > >>>>>>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>>>> required > >>>>>>>>>>>>>>>>>>>>>> for redundancy. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> draft. > >>>>>>>>>>>>>>>>>>>>>> We have sent a request to WG chairs. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> We appreciate any comments, questions or > >>>>>>>>>>>>>>>>>>>>>> suggestions. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> At Mon, 12 Jul 2004 18:47:38 +0900, > >>>>>>>>>>>>>>>>>>>>>> Thierry Ernst wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>>>> - 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 > >>>>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>>>>>> responsability > >>>>>>>>>>>>>>>>>>>>>>> of the author to send a note to the NEMO ML. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>>>> NEMO Chairs. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > > > From nemo-bounces@ietf.org Thu Jul 29 09:20: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 JAA09822 for ; Thu, 29 Jul 2004 09:20: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 1BqAH7-0003W9-Sv; Thu, 29 Jul 2004 08:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqA2O-0000yR-RJ for nemo@megatron.ietf.org; Thu, 29 Jul 2004 08:29: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 IAA06841 for ; Thu, 29 Jul 2004 08:29: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 1BqA4K-0003UW-1G for nemo@ietf.org; Thu, 29 Jul 2004 08:31:33 -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 956A65D0B0; Thu, 29 Jul 2004 21:28:53 +0900 (JST) Date: Thu, 29 Jul 2004 21:27:02 +0900 (JST) Message-Id: <20040729.212702.09684558.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Subject: Re: [nemo] Comments on RO Taxonomy draft From: Masafumi Watari In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0304B6@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0304B6@xmb-ams-337.emea.cisco.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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit 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 Thu Jul 29 11:07: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 LAA17358 for ; Thu, 29 Jul 2004 11:07: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 1BqBfc-00022E-NX; Thu, 29 Jul 2004 10:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB4I-0007lL-Ek for nemo@megatron.ietf.org; Thu, 29 Jul 2004 09:35: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 FAA28832 for ; Thu, 29 Jul 2004 05:34: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 1Bq7Kj-00012d-GL for nemo@ietf.org; Thu, 29 Jul 2004 05:36:18 -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 8E24A5D0C9 for ; Thu, 29 Jul 2004 18:33:41 +0900 (JST) Date: Thu, 29 Jul 2004 18:33:31 +0900 From: Thierry Ernst To: nemo Message-Id: <20040729183331.4a1d5809.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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [nemo] Please send slides for SD 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 Dear all, So far, we have only received the slides from a couple of presenters. Please all of you send TJ and myself the slides ahead of time (by Saturday would be best), or we might not give you the requested slot. For easy processing, I recommend the following file naming: nemo-ietf60-MeaningfulKeyWord-PresenterName.type For instance, see slides names for IETF 59 on http://www.mobilenetworks.org/nemo/ietf59/slides/ I do personaly prefer .pdf over any other format. I will send the slides to the IETF proceedings after the meeting, so please be sure you send us the latest version in case you make any late change prior to the meeting. Thanks in advance, Thierry. From nemo-bounces@ietf.org Thu Jul 29 11:12: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 LAA17618 for ; Thu, 29 Jul 2004 11:12: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 1BqBfq-0002F2-1o; Thu, 29 Jul 2004 10:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB4e-0000Ds-Tp for nemo@megatron.ietf.org; Thu, 29 Jul 2004 09:35: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 EAA27493 for ; Thu, 29 Jul 2004 04:58:53 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq6mX-0000eN-0i for nemo@ietf.org; Thu, 29 Jul 2004 05:00:59 -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 76BC95D175 for ; Thu, 29 Jul 2004 17:58:16 +0900 (JST) Date: Thu, 29 Jul 2004 17:58:06 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] comments on draft-ietf-nemo-terminology Message-Id: <20040729175806.77b9459c.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0304AE@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC0304AE@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: ea4ac80f790299f943f0a53be7e1a21a 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, > 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 nemo-bounces@ietf.org Thu Jul 29 11:14: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 LAA17726 for ; Thu, 29 Jul 2004 11:14: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 1BqBfr-0002Fj-8f; Thu, 29 Jul 2004 10:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB4o-0008Cu-LS for nemo@megatron.ietf.org; Thu, 29 Jul 2004 09:36: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 EAA26853 for ; Thu, 29 Jul 2004 04:41:51 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq6W2-0000Sj-NM for nemo@ietf.org; Thu, 29 Jul 2004 04:43:58 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2004 10:49:09 +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 i6T8f7UH022979; Thu, 29 Jul 2004 10:41:17 +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); Thu, 29 Jul 2004 10:36:14 +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 Subject: RE: [nemo] Comments on RO Taxonomy draft Date: Thu, 29 Jul 2004 10:41:10 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0304B6@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Comments on RO Taxonomy draft Thread-Index: AcR0u1wh5s6LpzouQ5Cw7/9uUwJ73AAi2p4g From: "Pascal Thubert \(pthubert\)" To: "Masafumi Watari" , X-OriginalArrivalTime: 29 Jul 2004 08:36:14.0750 (UTC) FILETIME=[1C1543E0:01C47547] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 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=20 > -----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 >=20 > Hi all, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Below are the cases that are in my mind for now. >=20 > Case 1: Same MR, same nested NEMO > Two communicating nodes are located behind the same mobile router, and > behind the same nested NEMO. >=20 > 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. >=20 > Case 3: Different nested NEMO. > Two communicating nodes are located behind a different nested NEMO. >=20 > 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. >=20 > Any comments? >=20 > Best regards, > watari From nemo-bounces@ietf.org Thu Jul 29 11:23:28 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 LAA18212 for ; Thu, 29 Jul 2004 11:23: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 1BqBgG-0002Ot-0U; Thu, 29 Jul 2004 10:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB73-0008Cu-Fi for nemo@megatron.ietf.org; Thu, 29 Jul 2004 09:38: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 EAA26224 for ; Thu, 29 Jul 2004 04:31:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq6Ls-0000Iu-Ov for nemo@ietf.org; Thu, 29 Jul 2004 04:33:26 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2004 10:38:38 +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 i6T8UXUF021319; Thu, 29 Jul 2004 10:30:44 +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, 29 Jul 2004 10:30: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] comments on draft-ietf-nemo-terminology Date: Thu, 29 Jul 2004 10:30:33 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0304AE@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on draft-ietf-nemo-terminology Thread-Index: AcRvRsnVNJ7vh+QKT/mbA4Bj3dCH8gF/vsoA From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Thierry Ernst" X-OriginalArrivalTime: 29 Jul 2004 08:30:37.0609 (UTC) FILETIME=[5321A190:01C47546] 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 > > > >>>3.7 NEMO-prefix (MNP) > >>> > >>> An acronym for Mobile Network Prefix (as defined in [2]) > >> > >>why introduce this term if we are not re-defining it? MNP has been > >>widely used on the mailing list and in the NEMO Basic Support spec. I > >>prefer MNP (Mobile Network Prefix) over NEMO-prefix. > > > > > > This is an abbreviation for Mobile Network Prefix, so the defintion is > > the one in "Mobile Network Prefix". May be I can state this in a > > different way. > > > > regarding NEMO-Prefix vs MNP, this is a long history of mails (I cannot > > point the month, nor the subject line without doing a search - I don't > > have time for it know, so if someone knows, please post this to us). > > Alexandru has constantly opposed NEMO-Prefix, as TJ, if I recall, but > > some have supported NEMO-Prefix if I'm not mistaken. In any case, I > > proposed this term at the IETF meeting and there was no opposition. > > > > So, what's the purpose of the meetings if people don't oppose to the > > propositions made there ? >=20 > not everyone attends all meetings (I didnt attend the meeting in > Seoul). I think decisions taken during a WG meeting do not hold > until they are confirmed on the mailing list. 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. Pascal =20 From nemo-bounces@ietf.org Thu Jul 29 19:20: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 TAA17213 for ; Thu, 29 Jul 2004 19:20: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 1BqJeq-000051-Qq; Thu, 29 Jul 2004 18:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqJK8-00054F-U9 for nemo@megatron.ietf.org; Thu, 29 Jul 2004 18:24: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 SAA13996 for ; Thu, 29 Jul 2004 18:24:20 -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 1BqJM9-0004YP-HZ for nemo@ietf.org; Thu, 29 Jul 2004 18:26:34 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id C17B4621B for ; Thu, 29 Jul 2004 15:23:43 -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 06568-02 for ; Thu, 29 Jul 2004 15:23:42 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id C23DB622D; Thu, 29 Jul 2004 15:23:42 -0700 (PDT) Received: from [192.168.4.10] (wideload.tehama.multihop.net [192.168.4.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 179BA6109 for ; Thu, 29 Jul 2004 15:23:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) To: IETF NEMO WG Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--983994328; protocol="application/pkcs7-signature" From: "T.J.Kniveton" Date: Thu, 29 Jul 2004 15:23:58 -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: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [nemo] Note takers / 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 --Apple-Mail-9--983994328 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, If you are interested in taking notes, and/or joining a jabber session, at the NEMO meeting, please e-mail me. We MUST have note takers before the meeting can commence. Thanks, TJ --Apple-Mail-9--983994328 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyOTIyMjM1 OVowIwYJKoZIhvcNAQkEMRYEFOCAX0Os1ATcx+PXdht4duoJeDNYMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgFGJYova+naIBbc3R3bQAbFcnSaeDsM/q45VzvjiFhoZ +nmpRYMUX1IkU37VJMr4/1WL+TYHXtW4alSW6/ARebOEr1X9JfJ29mVdl4RjqLmylWLkA2ERYKCs nHXvi9IFLevPgcnlERX8K7W3cpVzdBRv+ZYwZuhX5s/4rh+wecVUAAAAAAAA --Apple-Mail-9--983994328-- From nemo-bounces@ietf.org Thu Jul 29 21:16: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 VAA23086 for ; Thu, 29 Jul 2004 21:16: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 1BqLcO-00052e-IQ; Thu, 29 Jul 2004 20:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqL2r-0007Zm-Mu for nemo@megatron.ietf.org; Thu, 29 Jul 2004 20:14: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 UAA19898 for ; Thu, 29 Jul 2004 20:14:38 -0400 (EDT) Received: from [203.253.31.197] (helo=ssu.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BqL4q-0006Dg-5h for nemo@ietf.org; Thu, 29 Jul 2004 20:16:52 -0400 Received: from ssu.ac.kr by ietf.org with ESMTP (BeeHive 1.4.1) for nemo@ietf.org; Fri, 30 Jul 2004 09:14:31 +0900 Message-ID: <002d01c475ca$2ceb2cb0$8601a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" References: <41017D52.7090504@iprg.nokia.com><007801c4717e$abd35bb0$4f01a8c0@SOUHWANSENSQ> <410597A5.2000109@iprg.nokia.com> Subject: Re: [nemo] Re: comments on draft-jung-nemo-threat-analysis Date: Fri, 30 Jul 2004 09:14:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: base64 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: base64 PiBvbmNlIE1SMSBiZWNvbWVzIGEgbmVzdGVkIE1SIG9mIE1SMiwgTVIxJ3MgZWdyZXNzIGludGVy ZmFjZSBpcw0KPiBjb25uZWN0ZWQgdG8gTVIyJ3MgaW5ncmVzcyBpbnRlcmZhY2UuDQo+IA0KPiAt IE1SMiByZXNwb25kcyB0byByb3V0ZXIgc29saWNpdGF0aW9ucyBvbiB0aGUgaW5ncmVzcyBpbnRl cmZhY2UNCj4gLSBNUjIgaWdub3JlcyByb3V0ZXIgc29saWNpdGF0aW9ucyBvbiB0aGUgZWdyZXNz IGludGVyZmFjZQ0KPiAtIE1SMSBwcm9jZXNzZXMgcm91dGVyIGFkdmVydGlzZW1lbnRzIHJlY2Vp dmVkIG9uIGl0cyBlZ3Jlc3MgaW50ZXJmYWNlDQo+IC0gTVIxIGlnbm9yZXMgcm91dGVyIHNvbGlj aXRhdGlvbnMgb24gdGhlIGVncmVzcyBpbnRlcmZhY2UNCj4gDQo+IHNvIHdoYXQgaXMgdGhlIHBy b2JsZW0/DQo+IA0KPiBWaWpheQ0KPiANCj4NCg0KQXMgeW91IHN0YXRlZCBhYm92ZSwgdGhlcmUg aXMgbm8gcHJvYmxlbSwgb25jZSBNUjEgZmluZHMgTVIyIGFuZCBuZXRzZWQgdG8gaXQuDQpUaGUg YXR0YWNrIEkgZGVzY3JpYmVkIGlzIHRoZSBzaXR1YXRpb24gYmVmb3JlIE1SMSBpcyBuZXN0ZWQg dG8gTVIyLiANCkluIHRoZSBwcm9jZXNzIG9mIGZpbmRpbmcgTVIyLCBNUjEgbWlnaHQgYmUgZGVj ZWl2ZWQgYnkgYSBtYWxpY2lvdXMgTVIuDQpJIHBvaW50ZWQgb3V0IHRoZSBhdHRhY2sgZm9yIGNs YWltaW5nIHRoYXQgYSBraW5kIG9mIG1lc3NhZ2UgYXV0aGV0aWNhdGlvbiBpcyBuZWNlc3NyeSBh bW9uZyBtdWx0aXBsZSBNUnMuDQoNCg0KU291aHdhbg0K From nemo-bounces@ietf.org Thu Jul 29 21: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 VAA23485 for ; Thu, 29 Jul 2004 21: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 1BqLqr-0001fU-SE; Thu, 29 Jul 2004 21:06:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqLKg-0001z7-AE for nemo@megatron.ietf.org; Thu, 29 Jul 2004 20:33: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 UAA20793 for ; Thu, 29 Jul 2004 20:33:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqLMf-0006TO-6p for nemo@ietf.org; Thu, 29 Jul 2004 20:35:17 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6U0WOk00722; Thu, 29 Jul 2004 17:32:24 -0700 X-mProtect: <200407300032> 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 smtpd9W26ij; Thu, 29 Jul 2004 17:32:22 PDT Message-ID: <410998C0.3010500@iprg.nokia.com> Date: Thu, 29 Jul 2004 17:39:28 -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: Souhwan Jung Subject: Re: [nemo] Re: comments on draft-jung-nemo-threat-analysis References: <41017D52.7090504@iprg.nokia.com><007801c4717e$abd35bb0$4f01a8c0@SOUHWANSENSQ> <410597A5.2000109@iprg.nokia.com> <002d01c475ca$2ceb2cb0$8601a8c0@SOUHWANSENSQ> In-Reply-To: <002d01c475ca$2ceb2cb0$8601a8c0@SOUHWANSENSQ> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Souhwan Jung wrote: >>once MR1 becomes a nested MR of MR2, MR1's egress interface is >>connected to MR2's ingress interface. >> >>- MR2 responds to router solicitations on the ingress interface >>- MR2 ignores router solicitations on the egress interface >>- MR1 processes router advertisements received on its egress interface >>- MR1 ignores router solicitations on the egress interface >> >>so what is the problem? > > As you stated above, there is no problem, once MR1 finds MR2 and netsed to it. > The attack I described is the situation before MR1 is nested to MR2. > In the process of finding MR2, MR1 might be deceived by a malicious MR. > I pointed out the attack for claiming that a kind of message authetication is necessry among multiple MRs. okay. but this doesnt still explain the following sentence in your draft. NEMO basic draft[3] describes that MR SHOULD not respond to the unsolicited RA messages to its egress interface, but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD listen the RA from alternative MR2 on its ingress interface. NEMO basic support has no such restriction. Vijay From nemo-bounces@ietf.org Fri Jul 30 02:01: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 CAA06370 for ; Fri, 30 Jul 2004 02:01: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 1BqQ7U-0006KL-0H; Fri, 30 Jul 2004 01:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqPpg-00044M-IH for nemo@megatron.ietf.org; Fri, 30 Jul 2004 01:21: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 BAA03977 for ; Fri, 30 Jul 2004 01:21:22 -0400 (EDT) Received: from jules.nautilus6.org ([203.178.138.2] helo=bender) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqPrl-0001x0-3s for nemo@ietf.org; Fri, 30 Jul 2004 01:23:38 -0400 Received: from bender (bender [127.0.0.1]) by bender (Postfix) with SMTP id E6CFDA1BF1; Fri, 30 Jul 2004 14:22:08 +0900 (JST) Date: Fri, 30 Jul 2004 14:22:08 +0900 From: Romain KUNTZ To: "T.J.Kniveton" Subject: Re: [nemo] Note takers / Jabber Message-Id: <20040730142208.219ce0fd.kuntz@sfc.wide.ad.jp> In-Reply-To: References: 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: 79899194edc4f33a41f49410777972f8 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, > If you are interested in taking notes, and/or joining a jabber > session, at the NEMO meeting, please e-mail me. We MUST have note > takers before the meeting can commence. I am interested in joining a jabber session in order to follow the discussion, but I did not find the information to join jabber server this year. Last year it was: nemo@conference.ietf.jabber.com Is it the same each year ? Best regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Fri Jul 30 09:40: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 JAA05332 for ; Fri, 30 Jul 2004 09:40: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 1BqXZj-0003kw-DR; Fri, 30 Jul 2004 09:37:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqXQj-0000HW-LL for nemo@megatron.ietf.org; Fri, 30 Jul 2004 09:28: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 HAA00492 for ; Fri, 30 Jul 2004 07:33:14 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqVfc-0005p3-SP for nemo@ietf.org; Fri, 30 Jul 2004 07:35:33 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 30 Jul 2004 21:39:31 +1000 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6UBVTs3006326; Fri, 30 Jul 2004 21:32:28 +1000 (EST) 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, 30 Jul 2004 13:31:54 +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 Subject: RE: [nemo] Comments on RO Taxonomy draft Date: Fri, 30 Jul 2004 13:31:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05663C@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Comments on RO Taxonomy draft Thread-Index: AcR1cawOKcWf4HviR4mTLopPcNoBIgAtvU+g From: "Pascal Thubert \(pthubert\)" To: "Masafumi Watari" X-OriginalArrivalTime: 30 Jul 2004 11:31:54.0573 (UTC) FILETIME=[D0B85FD0:01C47628] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 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 >=20 > Hello Pascal-san, >=20 > Well, for case 1 & 2, I understand that such integration may be a > possible solution, and that alternate routes can avoid the tunnels. >=20 > 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. >=20 > 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. >=20 > Even if we don't consider VMNs for now, we do need to consider case 3, > I think. >=20 > watari >=20 > On Thu, 29 Jul 2004 10:41:10 +0200, > "Pascal Thubert (pthubert)" wrote: >=20 > > 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 > > > > >=20 From nemo-bounces@ietf.org Fri Jul 30 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 KAA07557 for ; Fri, 30 Jul 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 1BqXu3-0003N1-Ly; Fri, 30 Jul 2004 09:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqXkd-0007ac-B6 for nemo@megatron.ietf.org; Fri, 30 Jul 2004 09:48: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 HAA29306 for ; Fri, 30 Jul 2004 07:00:46 -0400 (EDT) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqVAH-0005WC-KJ for nemo@ietf.org; Fri, 30 Jul 2004 07:03:07 -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 9D8835D0C2 for ; Fri, 30 Jul 2004 20:00:10 +0900 (JST) Date: Fri, 30 Jul 2004 19:59:56 +0900 From: Thierry Ernst To: nemo Message-Id: <20040730195956.11e95dde.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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [nemo] RO Taxonomy X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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've beeen thinking for a while about a RO taxonomy. I think an exhaustiv taxonomy would consider all potential solutions, included MIP6-based solutions, but not limited to it. Since we don't have much experience in NEMO topologies, it might be useful that the study covers all host mobility approaches. As far as host mobility support is concerned, at least the following classes would exist: 1. two-tier addressing category: using 2 addresses, one as a locator, one as a identifier 2. routing-based category (using routing protocols) 3. renumbering (changing the address/prefix) 4. combined (a combination of the above) 5. separation of locator and identifier 6. overlay network 7 others Depending on how detailed the taxonomy is, these may be further be divided into sub classes. For instance, the two-tier addressing category could be divided into: -- home-agent based framework (e.g. MIP6) -- hierarchical framework (e.g. HMIP6) -- multicast framework -- others Some solutions like HMIP would of course be ranged both into home-agent based and hierarchical. Each category has of course its limitations and benefits. Some may not applied to NEMO, but it would be better to find out before we investigate one specific category. I've made such a taxonomy for host mobility support a couple of years ago. I guess it could be applied to network mobility support, but would need to be refined, because of the complexity of the configurations like nested mobile networks, and the number of cases where RO is needed (e.g between 2 nodes in distinct nested-NEMO). I don't even dare to mention multihoming, but for this latter case, I'm pretty sure we would be well inspired to follow the work done in the multi6 WG. Might be useful to speak about this at SD. Thierry. From nemo-bounces@ietf.org Fri Jul 30 11:01: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 LAA12546 for ; Fri, 30 Jul 2004 11:01: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 1BqYW0-00032D-I4; Fri, 30 Jul 2004 10:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqYS9-0008Q0-3G for nemo@megatron.ietf.org; Fri, 30 Jul 2004 10:33: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 KAA10284 for ; Fri, 30 Jul 2004 10:33:42 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqYUD-0000AD-FA for nemo@ietf.org; Fri, 30 Jul 2004 10:36:05 -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 i6UEXWWR020347 for ; Fri, 30 Jul 2004 16:33:32 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 16:33:31 +0200 Received: from ericsson.com (sealwa02m075.sw.ericsson.se [130.100.249.75]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR2FN640; Fri, 30 Jul 2004 16:33:31 +0200 Message-ID: <410A5C38.1050504@ericsson.com> Date: Fri, 30 Jul 2004 16:33:28 +0200 X-Sybari-Trust: f86250f5 74470f8f 6ee4b189 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: Thierry Ernst Subject: Re: [nemo] RO Taxonomy References: <20040730195956.11e95dde.ernst@sfc.wide.ad.jp> In-Reply-To: <20040730195956.11e95dde.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2004 14:33:31.0914 (UTC) FILETIME=[300AA6A0:01C47642] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Hi Thierry, Thierry Ernst wrote: > Dear all, > > I've beeen thinking for a while about a RO taxonomy. I think an > exhaustiv taxonomy would consider all potential solutions, included > MIP6-based solutions, but not limited to it. Since we don't have much > experience in NEMO topologies, it might be useful that the study covers > all host mobility approaches. > > As far as host mobility support is concerned, at least the following > classes would exist: > > 1. two-tier addressing category: using 2 addresses, one as a locator, one > as a identifier > > 2. routing-based category (using routing protocols) > > 3. renumbering (changing the address/prefix) > > 4. combined (a combination of the above) > > 5. separation of locator and identifier > > 6. overlay network > > 7 others I agree that this is useful, but I get the feeling some of them belong to other than the IP layer in the stack. Class 3, 5 and 6 would need support from upper layers to handle changing IP addresses without breaking applications' sessions. Do we want to talk about classes of solutions belonging to any layer? /Mattias From nemo-bounces@ietf.org Fri Jul 30 12:40: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 MAA18060 for ; Fri, 30 Jul 2004 12:40: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 1BqaI6-0006fw-SM; Fri, 30 Jul 2004 12:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqaCQ-0004Dj-6a for nemo@megatron.ietf.org; Fri, 30 Jul 2004 12:25: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 MAA17261 for ; Fri, 30 Jul 2004 12:25: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 1BqaEg-0002CY-6u for nemo@ietf.org; Fri, 30 Jul 2004 12:27:59 -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 9664A5D122; Sat, 31 Jul 2004 01:25:04 +0900 (JST) Date: Sat, 31 Jul 2004 01:23:10 +0900 (JST) Message-Id: <20040731.012310.41697222.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Subject: Re: [nemo] Comments on RO Taxonomy draft From: Masafumi Watari In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05663C@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC05663C@xmb-ams-337.emea.cisco.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: 0ff9c467ad7f19c2a6d058acd7faaec8 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, No, you're correct. But if one of the node is a LFN, then home address of VMN is used which causes a routing to the infrastructure. Such approach can solve some cases, but not all. So, maybe something like a proxy HA inside the nest in needed. Also, I think that if solutions assume the correspondent nodes to be an extended CN, or a CR, then its okay since optimization is possible with those nodes, and are useful in some situations. But if a bi-directional tunnel with the home agent is used, then its a problem becuase CN can be hiding under another nested NEMO, which is the case 3, I mentioned. You might have an optimized path to the HA from the outgoing nest, but after that, its all tunneling among the HAs to the CN. This is also true for RRH, if I am correct. Masafumi Watari On Fri, 30 Jul 2004 13:31:51 +0200, "Pascal Thubert (pthubert)" 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 Fri Jul 30 12:51: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 MAA18795 for ; Fri, 30 Jul 2004 12:51: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 1BqaVP-0003DA-9H; Fri, 30 Jul 2004 12:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqaKG-0007Kl-Ro for nemo@megatron.ietf.org; Fri, 30 Jul 2004 12:33: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 MAA17731 for ; Fri, 30 Jul 2004 12:33:41 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqaMW-0002Kj-Et for nemo@ietf.org; Fri, 30 Jul 2004 12:36:05 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i6UGTNQO006219; Fri, 30 Jul 2004 09:29:23 -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 i6UEXSoa020158; Fri, 30 Jul 2004 09:33:29 -0500 Message-ID: <410A7857.6020406@motorola.com> Date: Fri, 30 Jul 2004 18:33:27 +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 Subject: Re: [nemo] RO Taxonomy References: <20040730195956.11e95dde.ernst@sfc.wide.ad.jp> In-Reply-To: <20040730195956.11e95dde.ernst@sfc.wide.ad.jp> 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="------------ms060304070504070408010003" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 a cryptographically signed message in MIME format. --------------ms060304070504070408010003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I've beeen thinking for a while about a RO taxonomy. I think an > exhaustiv taxonomy would consider all potential solutions, included > MIP6-based solutions, but not limited to it. Since we don't have much > experience in NEMO topologies, it might be useful that the study > covers all host mobility approaches. > > As far as host mobility support is concerned, at least the following > classes would exist: > > 1. two-tier addressing category: using 2 addresses, one as a locator, > one as a identifier [...] > Depending on how detailed the taxonomy is, these may be further be > divided into sub classes. For instance, the two-tier addressing > category could be divided into: > > -- home-agent based framework (e.g. MIP6) > -- hierarchical framework (e.g. HMIP6) > -- multicast framework > -- others 1.5. using 2 addresses: one as an IP address, one as a FQDN name; also known as DNS updates. > Each category has of course its limitations and benefits. Some may not > applied to NEMO, but it would be better to find out before we > investigate one specific category. But I think this is all about host mobility in general. What is specific about RO in this taxonomy? What is "multicast framework" and how does it provide RO for mobiles? What is a "path length" anyways. Is the "path length" the number of IP hops w/o encapsulation? Or with encapsulation? Is "path length" weighted by intermediary link bandwidth or not? What is an "optimal path" anyways. Is it the "shortest" of all the possible "path lengths" between two mobiles? Or maybe there's a degree of tolerance? How much need is there for how much optimality and how much gain is expected. Is there a quantifying experiment proving an overwhelming need for shorter-than-through-HA paths? Alex --------------ms060304070504070408010003 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3 MzAxNjMzMjdaMCMGCSqGSIb3DQEJBDEWBBQrW82WaC6I4HaYT1MZOnI8t0pU9TBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCKXXugxaL0oScxN32ltbMm6TqQQo4VFNav5UnV qXD9UTBkBeKFsQKzKh4rbWX/k6LNusuRro+Rdy1wVZoNGOF+cu4QQX7Y2aas5qOra6/sFLWi 6736euDjX/eRyOPRnCcqgjf4zbklbnYu3ljIR1BnSZB3f6S+W1V6SUAY0ZQp8QAAAAAAAA== --------------ms060304070504070408010003-- From nemo-bounces@ietf.org Fri Jul 30 13: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 NAA21158 for ; Fri, 30 Jul 2004 13:43: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 1BqbML-00065q-Km; Fri, 30 Jul 2004 13:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqbI0-0004ci-ON for nemo@megatron.ietf.org; Fri, 30 Jul 2004 13:35: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 NAA20919 for ; Fri, 30 Jul 2004 13:35:27 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqbKH-0003ET-VX for nemo@ietf.org; Fri, 30 Jul 2004 13:37:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2004 19:38:33 +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 i6UHYaUF020230; Fri, 30 Jul 2004 19:34:53 +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); Fri, 30 Jul 2004 19:29:40 +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: Fri, 30 Jul 2004 19:34:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0566A9@xmb-ams-337.emea.cisco.com> Thread-Topic: RRH security draft Thread-Index: AcRriZXB2Ypv56SOTPiOeRliDM8ItwKzl2/Q From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , X-OriginalArrivalTime: 30 Jul 2004 17:29:40.0125 (UTC) FILETIME=[CB2FACD0:01C4765A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Subject: [nemo] 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 this work. I believe that there's a lot to say and a lot that can be done for RRH security. I must say that in our initial spec, we did have a subentry in the RRH for MRs to sign the RRH till himself, as I understand that you propose. We dropped it because we thought that the hop by hop checking of topological correctness did provide a same level of protection. You must think deeper about the handling of RH 2, as we already discussed that on this list about draft-na-nemo-nested-path-info-00.txt: a MR will only forward a RRH DOWN the tree. So loops are impossible. Also, an attacker within the tree must send topologically correct packets (and source packet from himself), so the attack always backfires on itself since the MR above adds that address to the RRH. As a result, some of the attacks you mention can actually NOT take place, though heave drooping is quite feasible. I hope we can meet and discuss that.=20 The other reason not to add the signature inside the RRH was that we wanted a clean standard RH, easy to reverse. So we thought that the signature -if one is wanted- should be outside the RRH. As you have realized already: - Entries in the RRH do not have to be addresses. The MR that writes an entry is the only user for it. - A MR is allowed to fully modify a RRH as long as it is able to restore the right RH2 on the way back (but for entry 0). In particular, a MR may transform the source address that he adds to the RRH using some reversible crypto and a private key.=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. So you see there's quite a lot of cool stuff we can do :) Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Fan Zhao > Sent: samedi 17 juillet 2004 00:56 > To: nemo@ietf.org > Subject: [nemo] new draft submitted >=20 >=20 > Hello, >=20 > We have submitted a new draft on the security analysis and mechanisms > of RRH, a proposed route optimization solution. Your comments are > appreciated. >=20 > http://www.ietf.org/internet-drafts/draft-zhao-nemo-rrh-security-00.txt >=20 > Abstract: In this draft, we begin with an extensive security analysis > on a NEMO RO proposal, RRH, and then propose effective security > mechanisms to resist those new threats introduced by the RRH header in > the nested mobile network. >=20 > Thanks. >=20 > fan From nemo-bounces@ietf.org Fri Jul 30 14:04: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 OAA21994 for ; Fri, 30 Jul 2004 14:04: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 1BqbhD-0006P9-Ih; Fri, 30 Jul 2004 14:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqbc1-0003vg-Fh for nemo@megatron.ietf.org; Fri, 30 Jul 2004 13:56: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 NAA21601 for ; Fri, 30 Jul 2004 13: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 1BqbeH-0003S8-MU for nemo@ietf.org; Fri, 30 Jul 2004 13:58:31 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2004 19:59:13 +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 i6UHtXU7022325; Fri, 30 Jul 2004 19:55:33 +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, 30 Jul 2004 19:55:32 +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 Subject: RE: [nemo] Route Optimization by CR Date: Fri, 30 Jul 2004 19:55:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0566AA@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Route Optimization by CR Thread-Index: AcRu5uTkxJfNgrygTOusvTjVStaUkAHdUhhg From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 30 Jul 2004 17:55:32.0970 (UTC) FILETIME=[68C104A0:01C4765E] 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 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.=20 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 :) - 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. - 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. - 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. 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.=20 There are lower level details that I could discuss. Like adding text for topological correctness over the tunnels, things like that. What do you think? Pascal From nemo-bounces@ietf.org Fri Jul 30 14:15: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 OAA22480 for ; Fri, 30 Jul 2004 14:15: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 1Bqbq4-0007wG-5G; Fri, 30 Jul 2004 14:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqbkl-0007JK-Au for nemo@megatron.ietf.org; Fri, 30 Jul 2004 14:05: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 OAA22054 for ; Fri, 30 Jul 2004 14:05:09 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqbn2-0003a4-Kb for nemo@ietf.org; Fri, 30 Jul 2004 14:07:33 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2004 20:08:15 +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 i6UI4XU9023184; Fri, 30 Jul 2004 20:04:36 +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, 30 Jul 2004 20:04:35 +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 Subject: RE: [nemo] comments on draft-ietf-nemo-terminology Date: Fri, 30 Jul 2004 20:04:31 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0566AB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on draft-ietf-nemo-terminology Thread-Index: AcR1gyojVZCwp7J2SFK3CE5gIp5JEwA3AITQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 30 Jul 2004 18:04:35.0117 (UTC) FILETIME=[ABE615D0:01C4765F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 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.=20 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 >=20 >=20 > Hi Pascal, >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > We will make a decision on these at SD, definitely. >=20 > Thierry. >=20 From nemo-bounces@ietf.org Fri Jul 30 19:19: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 TAA07980 for ; Fri, 30 Jul 2004 19:19: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 1BqgbT-0004zh-Nz; Fri, 30 Jul 2004 19:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqgYl-0004RQ-Dq for nemo@megatron.ietf.org; Fri, 30 Jul 2004 19:13: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 TAA07782 for ; Fri, 30 Jul 2004 19:13:04 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqgb3-0007UK-KZ for nemo@ietf.org; Fri, 30 Jul 2004 19:15:31 -0400 Received: from cucujus.ucdavis.edu (cucujus.ucdavis.edu [169.237.104.179]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i6UNCcMr004544; Fri, 30 Jul 2004 16:12:38 -0700 (PDT) Received: from cucujus.ucdavis.edu (localhost [127.0.0.1]) by cucujus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i6UNCcPK007477; Fri, 30 Jul 2004 16:12:38 -0700 (PDT) Received: (from www@localhost) by cucujus.ucdavis.edu (8.12.10/8.12.9/Submit) id i6UNCbqh007476; Fri, 30 Jul 2004 16:12:37 -0700 (PDT) Date: Fri, 30 Jul 2004 16:12:37 -0700 (PDT) Message-Id: <200407302312.i6UNCbqh007476@cucujus.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: [169.237.7.45] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Gecko------------1091229157----_" X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 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 This is a multi-part message in MIME format. --Gecko------------1091229157----_ Content-Type: text/plain Dear Pascal, Thank you very much for your insightful comments. I have to admit that my original draft is very preliminary and immature. RRH is a very interesitng solution. Recently I rethink about some RRH security issues and general questions about RO, some of which you have already pointed out. The document is quite long so I send it as an attachment. Please correct me if there are some errors. Look forward to meet you in SD. Sincerely, fan > Hi Fan: > > Thanks a lot for this work. I believe that there's a lot to say and a > lot that can be done for RRH security. > > I must say that in our initial spec, we did have a subentry in the RRH > for MRs to sign the RRH till himself, as I understand that you propose. > We dropped it because we thought that the hop by hop checking of > topological correctness did provide a same level of protection. You must > think deeper about the handling of RH 2, as we already discussed that on > this list about draft-na-nemo-nested-path-info-00.txt: a MR will only > forward a RRH DOWN the tree. So loops are impossible. Also, an attacker > within the tree must send topologically correct packets (and source > packet from himself), so the attack always backfires on itself since the > MR above adds that address to the RRH. As a result, some of the attacks > you mention can actually NOT take place, though heave drooping is quite > feasible. I hope we can meet and discuss that. > > The other reason not to add the signature inside the RRH was that we > wanted a clean standard RH, easy to reverse. So we thought that the > signature -if one is wanted- should be outside the RRH. As you have > realized already: > > - Entries in the RRH do not have to be addresses. The MR that writes an > entry is the only user for it. > - A MR is allowed to fully modify a RRH as long as it is able to restore > the right RH2 on the way back (but for entry 0). In particular, a MR may > transform the source address that he adds to the RRH using some > reversible crypto and a private key. > - 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. > > So you see there's quite a lot of cool stuff we can do :) > > Pascal > > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > Of Fan Zhao > > Sent: samedi 17 juillet 2004 00:56 > > To: nemo@ietf.org > > Subject: [nemo] new draft submitted > > > > > > Hello, > > > > We have submitted a new draft on the security analysis and mechanisms > > of RRH, a proposed route optimization solution. Your comments are > > appreciated. > > > > > http://www.ietf.org/internet-drafts/draft-zhao-nemo-rrh-security-00.txt > > > > Abstract: In this draft, we begin with an extensive security analysis > > on a NEMO RO proposal, RRH, and then propose effective security > > mechanisms to resist those new threats introduced by the RRH header in > > the nested mobile network. > > > > Thanks. > > > > fan > > --Gecko------------1091229157----_ Content-Type: text/plain Content-Description: changes-v1.txt Content-Disposition: attachment; filename=changes-v1.txt Content-Transfer-Encoding: base64 MS4gQWNjZXNzIENvbnRyb2wgSXNzdWUNCjEuMSBOZXh0IEhvcCBJUCBhZGRy ZXNzIGNoZWNrDQpOZXh0IEhvcCBJUCBhZGRyZXNzOiB0aGUgSVAgYWRkcmVz cyBpbiB0aGUgc2xvdCB0aGF0IHdpbGwgYmUgdXNlZCANCmFzIHRoZSBhZGRy ZXNzIG9mIHRoZSBuZXh0IGhvcCB0byBmb3J3YXJkIHRvLg0KIA0KTVIgZG9l cyBub3Qgb25seSB0aGUgaW5ncmVzcyBmaWx0ZXJpbmcgY2hlY2sgb24gdGhl IHNvdXJjZSBJUCANCmFkZHJlc3MgaW4gdGhlIG91dGdvaW5nIHBhY2tldCBi dXQgYWxzbyB0aGUgbmV4dCBob3AgSVAgYWRkcmVzcyANCmNoZWNrIGluIHRo ZSBSUkggaGVhZGVyIGluIHRoZSBpbmNvbWluZyBwYWNrZXQuIElmIHRoZSBu ZXh0IGhvcCANCklQIGFkZHJlc3MgZG9lcyBub3QgYmVsb25nIHRvIG9uZSBv ZiBpdHMgTU5QKHMpLCB0aGlzIHBhY2tldCB3aWxsIA0KYmUgZHJvcHBlZCBz aWxlbnRseTsgb3RoZXJ3aXNlIGl0IGlzIGZvcndhcmRlZC4NCg0KUHJvb2Y6 IEJ5IHVzaW5nIHRoZSBuZXh0IGhvcCBJUCBhZGRyZXNzIGNoZWNrIGluIHRo ZSBSUkggaGVhZGVyLCANCnRoZSBsb29wIHdpbGwgbm90IGJlIGZvcm1lZCBh cyBsb25nIGFzIHRoZSB0b3BvbG9neSBvZiBORU1PIG5lc3RlZCANCm5ldHdv cmsgaXMgbG9vcC1mcmVlLg0KDQpXZSBjYW4gdHJhbnNsYXRlIHRoZSBORU1P IG5lc3RlZCBuZXR3b3JrIGludG8gYSBkaXJlY3QgZ3JhcGggPFYsIEU+IA0K d2hlcmUgZWFjaCBub2RlIGluIFYgZGVub3RlcyBvbmUgb3IgbXVsdGlwbGUg TVJzIGFuZCB0aGUgZGlyZWN0ZWQgZWRnZSANCjxNUmkgLT4gTVJqPiBiZWxv bmdzIHRvIHRoZSBlZGdlIHNldCBFIGlmIGFuZCBvbmx5IGlmIE1SaiBnZXRz IGl0cyANCmNhcmUtb2YtYWRkcmVzcyBmcm9tIE1SaS4gDQoNCkluIGEgc2lu Z2xlIE5FTU8gbmVzdGVkIG5ldHdvcmssIGVhY2ggTVIgaXMgZGVub3RlZCBi eSBvbmUgbm9kZS4gDQpIb3dldmVyLCBpbiB0aGUgbXVsdGktaG9taW5nIE5F TU8gbmVzdGVkIG5ldHdvcmssIHRoZXJlIGNvdWxkIGJlIG11bHRpcGxlIA0K TVJzIGFuZC9vciBtdWx0aXBsZSBNTlBzIGluIG9uZSBtb2JpbGUgbmV0d29y aywgYW5kIGVhY2ggTVIgY291bGQgZ2V0IG9uZSANCm9yIG1vcmUgY2FyZS1v Zi1hZGRyZXNzZXMgZnJvbSBvbmUgb3IgbW9yZSBwYXJlbnQgTVJzLiANCg0K SWYgbXVsdGlwbGUgTVJzIGluIG9uZSBORU1PIG5ldHdvcmsgZ2V0IHRoZWly IGNhcmUtb2YtYWRkcmVzc2VzIGZyb20gdGhlIA0Kc2FtZSAocGFyZW50KSBN TlAsIG11bHRpcGxlIE1SUyBhcmUgZGVub3RlZCBieSBvbmUgbm9kZS4gSWYg dGhleSBnZXQgZnJvbQ0KZGlmZmVyZW50IE1OUHMsIGJhc2VkIG9uIHRoZSBz b3VyY2Ugb2YgY2FyZS1vZi1hZGRyZXNzLCB0aGV5IHdpbGwgYmUgZGVub3Rl ZA0KYnkgZGlmZmVyZW50IG5vZGVzLiBJZiBNUmogZ2V0cyBtdWx0aXBsZSBj YXJlLW9mLWFkZHJlc3NlcyBmcm9tIG11bHRpcGxlIHBhcmVudA0KTU5QcyBh bmQgaWYgYWxsIE1OUHMgYXJlIG93bmVkIGJ5IE1SaSwgdGhlcmUgaXMgb25s eSBvbmUgZGlyZWN0ZWQgbGluayBmcm9tDQpNUmkgdG8gTVJqLiBJZiBNTlBz IGFyZSBvd25lZCBieSBhIHNldCBvZiBNUnMsIHRoZXJlIGlzIGRpcmVjdGVk IGxpbmtzIGZyb20gZWFjaA0KcGFyZW50IE1SIHRvIE1Sai4NCg0KU28gdGhp cyBkaXJlY3QgZ3JhcGggaXMgZ2VuZXJhdGVkIGJhc2VkIG9uIHdoaWNoIHBh cmVudCBNTlAgdGhlIGNhcmUtb2YtYWRkcmVzcyBvZiANCk1SIGlzIGdvdCBm cm9tLiAgDQoNCldoZW4gZWFjaCBNUiBkb2VzIHRoZSBuZXh0IGhvcCBJUCBh ZGRyZXNzIGNoZWNrLCBhIGxvb3AgY2FuIGJlIGZvcm1lZCBpbiB0aGUgUlJo DQpoZWFkZXIgd2l0aG91dCBiZWluZyBkZXRlY3RlZCBpZiBhbmQgb25seSBp ZiB0aGUgdG9wb2xvZ3kgb2YgTkVNTyBuZXN0ZWQgd29yayBjb250YWlucyAN CmEgbG9vcCB3aGVyZSBvbmUgcGFyZW50IE1SIHdpbGwgYWNoaWV2ZSBpdHMg Y2FyZS1vZi1hZGRyZXNzIGZyb20gYSBjaGlsZCBvciBncmFuZGNoaWxkIE1S LiANCg0KVGhlIGFuYWx5c2lzIGFib3ZlIG9ubHkgYW5hbHl6ZXMgdGhlIGZv cndhcmRpbmcgcGF0aCBiZXdlZW4gcGFyZW50IE1SIGFuZCBjaGlsZCBNUiwN CmJ1dCBpdCBtaXNzZXMgb25lIHNpdHVhdGlvbiwgdGhlIGxvb3AgYmV0d2Vl biBNUnMgYmVsb25naW5nIHRvIG9uZSBORU1vIG5ldHdvcmsuDQoNCiAgICAg ICAgICAgICBldGgwIHwgQ29BMSAgICAgICAgIGV0aDAgfCBDb0EyDQogICAg ICAgICAgICB8LS0tLS18LS0tLS18ICAgICAgIHwtLS0tLXwtLS0tLXwNCiAg ICAgICAgICAgIHwgICAgTVIxICAgIHwgICAgICAgfCAgICBNUjIgICAgfA0K ICAgICAgICAgICAgfC0tLS0tfC0tLS0tfCAgICAgICB8LS0tLS18LS0tLS18 DQogICAgICAgICAgICAgZXRoMSB8IEhvQTEgICAgICAgICBldGgxIHwgSG9B Mg0KICAgICAgICAgfC0tLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0tLS18LS0t LS0tLXwNCiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICB8ICAgICAgICAgICAgICAgIE1OUCAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS18DQoNCkhvQTEgYW5kIEhvQTIgYmVsb25n IHRvIHRoZSBzYW1lIE1OUC4gVGhlIFJSSCBoZWFkZXIgcmVjZWl2ZWQgYnkg TVIxIGxvb2tzIGxpa2UNCnRoaXMsIFsuLi4sIEhvQTIsIEhvQTEsIEhvQTIs Li4uXS4gVGhlIG5leHQgaG9wIGFkZHJlc3MgY2hlY2sgcGVyZm9ybWVkIA0K YnkgYm90aCBNUjEgYW5kIE1SMiB3aWxsIG5vdCBkZXRlY3QgdGhlIGxvb3Au IEJ1dCB0aGUgcGFja2V0IG1heSBiZSBkcm9wcGVkIGJ5IA0KdGhlIGluZ3Jl c3MgZmlsdGVyaW5nIGluIE1SMiBzaW5jZSBpdCBpcyBhbiBpbmJvdW5kIHBh Y2tldCAoZnJvbSBvdXRzaWRlIGdvaW5nIHRvIA0KaW5zaWRlIE5FTU8gbmV0 d29yaykgYW5kIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBkb2VzIG5vdCBiZWxv bmcgdG8gTU5QLg0KDQpJZiBhbiBhdHRhY2tlciBpbnNpZGUgdGhlIE1OUCBs YXVuY2hlcyB0aGlzIGtpbmQgb2YgYXR0YWNrLCBNUjEgd2lsbCBmb3J3YXJk DQp0aGUgcGFja2V0IHRocm91Z2ggdGhlIGVncmVzcyBpbnRlcmZhY2UuIA0K DQpXaGF0IGlmIHRoZSBlZ3Jlc3MgYW5kIGluZ3Jlc3MgaW50ZXJmYWNlcyBh cmUgd2lyZWxlc3MgbGluayB3aGVyZSB0aGUgYXR0YWNrIHBhY2tldCANCmNh biByZWFjaCB0aGUgYm90aCBsaW5rcz8gU28gd2UgaGF2ZSB0byBmb3JjZSBN UiBub3QgdG8gZnVuY3Rpb24gYXMgYSBmdWxsLWZsZWRnZWQgDQpyb3V0ZXIg d2hlbiBpdCBpcyBhd2F5IGZyb20gaXRzIGhvbWUuIEJlbG93IGFyZSBzb21l IHZlcnkgcHJlbGltaW5hcnkgdGhvdWdodHMgYWJvdXQNCnRoZSBzZWN1cml0 eSBydWxlcyBvZiBNUi4NCg0KV2hlbiBNUiByZWNlaXZlcyB0aGUgcGFja2V0 IG9uIHRoZSBJTkdSRVNTIGludGVyZmFjZSwgdGhlIGZvbGxvd2luZyBydWxl cyBhcmUgYXBwbGllZC4NCjEuIFRoZSBzb3VyY2UgSVAgYWRkcmVzcyBtdXN0 IGJlIGNoZWNrZWQgYnkgaW5ncmVzcyBmaWx0ZXJpbmcuIA0KMi4gSWYgdGhl IGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaXMgbm90IE1SIGl0c2VsZiwgaXQg d2lsbCBiZSBmb3J3YXJkZWQgYmFzZWQgb24gUlJIIA0KcHJvdG9jb2wuIA0K My4gSWYgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaXMgTVIgaXRzZWxm IChIb0Egb3IgQ29BKSBhbmQgdGhlcmUgaXMgYSBSUkggaGVhZGVyLCANCnRo ZSBwYWNrZXQgaXMgZHJvcHBlZC4NCg0KV2hlbiBNUiByZWNlaXZlcyB0aGUg cGFja2V0IG9uIHRoZSBFR1JFU1MgaW50ZXJmYWNlLCB0aGUgZm9sbG93aW5n IHJ1bGVzIGFyZSBhcHBsaWVkLg0KMS4gVGhlIHNvdXJjZSBJUCBhZGRyZXNz IGRvZXMgbm90IGJlbG9uZyB0byBpdHMgTU5QLg0KMi4gSWYgdGhlIGRlc3Rp bmF0aW9uIElQIGFkZHJlc3MgaXMgQ29BIGFuZCB0aGVyZSBpcyBubyBSUkgg aGVhZGVyLCBpdCBpcyBwcm9jZXNzZWQgYnkgDQpORU1PIGJhc2ljIHN1cHBv cnQuDQozLiBJZiB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBpcyBDb0Eg YW5kIHRoZXJlIGlzIFJSSCBoZWFkZXIsIG5leHQgaG9wIGFkZHJlc3MgY2hl Y2sNCmlzIHBlcmZvcm1lZCBhbmQgaXQgaXMgcHJvY2Vzc2VkIGJ5IFJSSCBw cm90b2NvbC4NCjQuIElmIHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGlz IEhvQSwgaXQgd2lsbCBiZSBkcm9wcGVkIGluIG9yZGVyIHRvIHByZXZlbnQg dGhlIA0KYXR0YWNrIGFib3ZlIHdoZW4gYnJvYWRjYXN0aW5nIHRvIHRoZSBl Z3Jlc3MgaW50ZXJmYWNlIGluIHRoZSB3aXJlbGVzcyBsaW5rLiANCg0KMS4y IEhvcC1ieS1Ib3AgQXV0aGVudGljYXRpb24gYW5kIEVuY3J5cHRpb24NCkhv cC1ieS1Ib3AgYXV0aGVudGljYXRpb24gYW5kIGVuY3J5cHRpb24gaXMgc2lt aWxhciB3aXRoIElQU2VjIEVTUCB0dW5uZWwgYXBwbGllZCANCnRvIHRoZSBN Ui1IQSBjaGFubmVsLCBidXQgaXQgcHJvdmlkZXMgYSBiZXR0ZXIgYWNjZXNz IGNvbnRyb2wgdGhhbiBpbiBORU1PIGJhc2ljIHN1cHBvcnQNCndoZXJlIEhB IG1heSBpbiBtb3N0IGNhc2VzIChpZiBIQSBkb2VzIG5vdCBkbyBhbnkgaW50 cnVzaW9uIGRldGVjdGlvbiB0aGluZ3MpIGp1c3QgDQpibGluZGx5IGVuY3J5 cHQsIHNpZ24gdGhlIHJlY2VpdmVkIHBhY2tldCBhbmQgZm9yd2FyZCB0byBN Ui4NCkJ5IHVzaW5nIEhvcC1ieS1ob3Agb3Igcm9vdC1NUiBvbmx5IGF1dGhl bnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uLCBNUiBjYW4gZWZmZWN0aXZlbHkN CnByb3RlY3QgdGhlIE5FTU8gbmVzdGVkIG5ldHdvcmsgZnJvbSB1bmF1dGhv cml6ZWQgYWNjZXNzLCBmb3IgZXhhbXBsZSwgRERvcyBhdHRhY2sgaWYgDQph bnRpLXJlcGxheSBpcyBlbmFibGVkLg0KDQoyLiBDb21wYXJpc29uIGJldHdl ZW4gcm91dGluZyBoZWFkZXIgaW4gdGhlIGRhdGEgcGFja2V0IGFuZCByb3V0 aW5nIHN0YXRlIGluIHRoZSBNUg0KMi4xIFJvdXRpbmcgaGVhZGVyIGluIHRo ZSBkYXRhIHBhY2tldA0KUHJvczoJUXVpY2tseSBhZGFwdCB0byB0aGUgdG9w b2xvZ3kgY2hhbmdlcy4NCglObyBtYW55IHN0YXRlcyBhcmUgcmVxdWlyZWQg dG8gYmUgbWFpbnRhaW5lZC4NCgkNCkNvbnM6IAlQYXlsb2FkIG92ZXJoZWFk IGluIHRoZSBkYXRhIHBhY2tldC4gDQoJTVIgaGFzIHRvIHByb2Nlc3MgZWFj aCBmb3J3YXJkZWQgcGFja2V0LiAocHJvY2Vzc2luZyBvdmVyaGVhZCkNCglH aXZlbiBhIG5vbi1hY2tub3dsZWRnZW1lbnQgY29tbXVuaWNhdGlvbiBmcm9t IENOIHRvIExGTi9NTk4sIGFuIGF0dGFja2VyIGNvdWxkIGNvbXByb21pc2Ug DQogICAgICAgIHRoZSBSUkggaGVhZGVyIGluIGp1c3Qgb25lIGRhdGEgcGFj a2V0IHRvIHJlZGlyZWN0IHRoZSB3aG9sZSBzdHJlYW0gdG8gdmljdGltcy4g DQoNCjIuMiBNaW5pbWFsIGJ1dCBub24temVybyByb3V0aW5nIHN0YXRlIGlu IHRoZSBNUg0KUHJvczoJTGVzcyBvdmVyaGVhZCBpbiB0aGUgZGF0YSBwYWNr ZXQuDQoJSW5kZXBlbmRlbnQgZnJvbSBhbnkgdHlwZXMgb2YgdHJhZmZpYy4N CglPbmx5IGxvb2t1cCBhbmQgbWFpbnRlbmFuY2Ugb3ZlcmhlYWQgYWZ0ZXIg c2V0IHVwLg0KIA0KQ29uczoJU2NhbGFiaWxpdHkgaXNzdWUgc3RpbGwgZXhp c3RzLg0KCVRoZSBhc3N1bXB0aW9uIG9uIHRoZSBtb2JpbGl0eSBncmFudWxh cml0eSBtYXkgbm90IGJlIGhlbGQgYWx3YXlzIChUaGUgcm91dGluZyBzdGF0 ZSANCiAgICAgICAgZG9lcyBub3QgZXhwaXJlIGV2ZW4gdGhvdWdoIHRoZSBy b3V0aW5nIHBhdGggaXMgY2hhbmdlZC4pLg0KCUF0dGFjayBvbiB0aGUgcm91 dGluZyBzdGF0ZS4NCglUaGUgb3ZlcmhlYWQgb2Ygc2V0IHVwIGFuZCByZW5l d2FsLg0KDQpDYW4gd2UgY29tYmluZSB0aGVzZSB0d28gdG9nZXRoZXIgdG8g YWNoaWV2ZSB0aGUgYmVzdCByZXN1bHQgaW4gdGhlIGRpZmZlcmVudCBzaXR1 YXRpb25zPw0KDQozLiBNdWx0aS1ob21pbmcgcmVsYXRlZCBhdHRhY2sgaW4g TkVNTyBuZXN0ZWQgbmV0d29yaw0KDQogfC0tLS0tfCAgICAgfC0tLS0tLS0t LXwNCiB8IE1SMCB8ICAgICB8ICAgTVIxICAgfC0tLS0tLS0tLS0tLXwNCiB8 LS0tLS18ICAgICB8LS0tLS0tLS0tfCAgICAgICAgICAgIHwNCiAgICB8ICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICB8 LS0tLS0tLS0tfCAgICAgICAgfC0tLS0tLS18DQogICAgfC0tLS0tLS0tfCAg IE1SMiAgIHwgICAgICAgIHwgIE1SMyAgfA0KICAgICAgICAgICAgIHwtLS0t LS0tLS18ICAgICAgICB8LS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgfC0tLS0tLS18DQogICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgIHwgIE1SNCAgfA0KICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8LS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICB8LS0tLS0tLS0tfCAgICAgICAgICAgIHwN CiAgICAgICAgICAgICB8ICAgTVI1ICAgfC0tLS0tLS0tLS0tLXwgDQogICAg ICAgICAgICAgfC0tLS0tLS0tLXwNCg0KSW4gdGhpcyBjYXNlLCB0aGUgYXR0 YWNrZXIgTVIyIHdpbGwgaW50ZXJjZXB0IHRoZSBkYXRhIHBhY2tldCBmcm9t IHZpY3RpbSwgTVI1IGFuZCBhbHNvDQpNUjIga25vd3MgdGhlcmUgZXhpc3Rz IGEgbG9uZ2VyIHBhdGggTVI1LCBNUjQsIE1SMywgTVIxLiBTbyBNUjIgd2ls bCBmb3JnZSB0aGUgUlJIIGhlYWRlcg0KdXNpbmcgTVIzIGFuZCBNUjQgcmF0 aGVyIHRoYW4gaXRzZWxmLiBJZiB0aGUgdHJhZmZpYyBzb2xpY2l0ZWQgYnkg TVI1IGlzIGF1ZGlvIG9yIHZpZGVvDQpzdHJlYW0gd2l0aG91dCBhY2sgbmVl ZGVkLCB0aGUgYXR0YWNrIHdpbGwgcmVtYWluIHVudGlsIEJDRSBpbiBIQTUg ZXhwaXJlcy4gTVIyIGNhbiBhdm9pZA0KdGhlIGJhY2tmaXJlIGJ5IHVzaW5n IGFub3RoZXIgY2hhbm5lbCB0aHJvdWdoIE1SMC4NCg0KNC4gUlIgdGVzdA0K V2UgYWN0dWFsbHkgdGhpbmsgYWJvdXQgYSBzaW1pbGFyIFJSIHRlc3QgdG8g ZW5oYW5jZSB0aGUgc2VjdXJpdHkuDQoNCjQuMSBSUiB0ZXN0IGluc2lkZSB0 aGUgTkVNTyBuZXN0ZWQgbmV0d29yaw0KVXNpbmcgdGhpcyB0ZXN0IHRvIHJl c2lzdCB0aGUgbWFsaWNpb3VzIGludGVybWVkaWF0ZSBNUiBhbmQgY3JlYXRl IHRoZSBzZWN1cml0eSBhc3NvY2lhdGlvbiANCmJldHdlZW4gcm9vdC1NUiBh bmQgTVIuICANCg0KNC4yIFJSIHRlc3QgaW4gdGhlIEludGVybmV0DQpVc2lu ZyB0aGlzIHRlc3QgdG8gcmVzaXN0IGFueSBtYWxpY2lvdXMgbm9kZSBhbmQg Y3JlYXRlIHRoZSBzZWN1cml0eSBhc3NvY2lhdGlvbiANCmJldHdlZW4gcm9v dC1NUiBhbmQgYW5vdGhlciBIQS4gIA0KDQo0LjMgQXV0aG9yaXphdGlvbiBp c3N1ZXMNCg0KNS4gU29tZSBvcGVuIHF1ZXN0aW9ucw0KNS4xIFdoYXQgaXMg dGhlIGRlZmluaXRpb24gb2Ygb3B0aW1hbCByb3V0ZT8NClRoZSByb3V0aW5n IHBhdGggaW4gTkVNTyBoYXMgdHdvIHBhcnRzLCBpbiB0aGUgSW50ZXJuZXQg YW5kIGluc2lkZSB0aGUgTkVNTyBuZXN0ZWQgbmV0d29yay4NCkRvZXMgdGhl IHJvdXRpbmcgcGF0aCBpbnNpZGUgdGhlIE5FTU8gbmVzdGVkIG5ldHdvcmsg YWxzbyBiZWxvbmcgdG8gUk8gY2F0ZWdvcnk/DQpUaGUgcm91dGluZyBwYXRo IGNob3NlbiBieSB0aGUgcm91dGluZyBpbmZyYXN0cnVjdHVyZSBpcyBub3Qg bmVjZXNzYXJpbHkgdGhlIGJlc3Qgcm91dGUgaW4gdGVybXMgb2YNCmRlbGF5 Lg0KDQo1LjIgVHJhZGVvZmYNCkluIFJSSCBwcm90b2NvbCwgYSByb3V0aW5n IHBhdGggYmV0d2VlbiByb290LU1SIGFuZCBIQWkgaXMgdGFrZW4gZmlyc3Rs eSBkdWUgdG8gdGhlIHNjYWxhYmlsaXR5DQppc3N1ZXMuIFNvIHRoZXJlIGlz IHRyYWRlb2ZmIGJldHdlZW4gb3ZlaGVhZCBhbmQgb3B0aW1pemFlZCByb3V0 ZS4gVG8gd2hhdCBleHRlbnQgb2Ygb3B0aW1pemVkIHJvdXRlDQppcyB0aGUg YmVzdCBiYWxhbmNlIGJldHdlZW4gb3ZlcmhlYWQgYW5kIHBlcmZvcm1hbmNl Pw0K --Gecko------------1091229157----_--