From mailman-bounces@ietf.org Sat Jan 1 05:48:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07952 for ; Sat, 1 Jan 2005 05:48:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgBx-0005YA-87 for nemo-archive@lists.ietf.org; Sat, 01 Jan 2005 05:09:01 -0500 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: Sat, 01 Jan 2005 05:02:31 -0500 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 Tue Jan 4 04:57:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28085 for ; Tue, 4 Jan 2005 04:57:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllI0-00081O-CA; Tue, 04 Jan 2005 04:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjYLF-0004Hg-Fg for nemo@megatron.ietf.org; Wed, 29 Dec 2004 02:33:57 -0500 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 CAA13084 for ; Wed, 29 Dec 2004 02:33:55 -0500 (EST) Received: from wira1.cs.usm.my ([161.142.8.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjYWI-0006S4-76 for nemo@ietf.org; Wed, 29 Dec 2004 02:45:23 -0500 Received: from wira1.cs.usm.my (wira1.cs.usm.my [161.142.8.21]) by wira1.cs.usm.my (8.12.10/8.12.10) with ESMTP id iBT7LUWb004047; Wed, 29 Dec 2004 15:21:31 +0800 (SGT) Date: Wed, 29 Dec 2004 15:21:30 +0800 (SGT) From: Tan Tat Kin To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Tue, 04 Jan 2005 04:47:42 -0500 Cc: nemo@ietf.org Subject: [nemo] comments on draft-clausen-nemo-ro-problem-statement-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 Clausen, have a general question after reading your draft. Basically on page9 when you briefly mentioned the potential solution of implementing OLSR that could potentially letting MRouters to provide direct routing of MNNs (instead of, like you outlined, to have gone thru HAs). So my question is, bypassing the many levels of encapsulation would this solution open to other security attacks such as DoS? I was thiking if a MR allows direct routing between NEMOs which is under this MR's tree, malicious MR or even MNN could learn the routes quite easily. Part of the reason encapsulations with and via HAs was by far using the BUs that would provide some security protections and verifications. thanks. rgds, tatkin From nemo-bounces@ietf.org Tue Jan 4 05:03:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28435 for ; Tue, 4 Jan 2005 05:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllSU-0003v1-4r; Tue, 04 Jan 2005 04:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllLX-0000XE-DT for nemo@megatron.ietf.org; Tue, 04 Jan 2005 04:51:25 -0500 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 EAA27632 for ; Tue, 4 Jan 2005 04:51:20 -0500 (EST) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CllXr-00017H-UL for nemo@ietf.org; Tue, 04 Jan 2005 05:04:08 -0500 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j049pJF5023883 for ; Tue, 4 Jan 2005 01:51:20 -0800 (PST) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j049pJcR009839 for ; Tue, 4 Jan 2005 01:51:19 -0800 (PST) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j049pJ4Y009838; Tue, 4 Jan 2005 01:51:19 -0800 (PST) Date: Tue, 4 Jan 2005 01:51:19 -0800 (PST) Message-Id: <200501040951.j049pJ4Y009838@tremex.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [nemo] Call for Papers: IEEE JSAC MRNM X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From nemo-bounces@ietf.org Tue Jan 4 22:59:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21006 for ; Tue, 4 Jan 2005 22:59:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm2CY-00085u-KT; Tue, 04 Jan 2005 22:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm28v-0006vE-Pd for nemo@megatron.ietf.org; Tue, 04 Jan 2005 22:47:30 -0500 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 WAA20051 for ; Tue, 4 Jan 2005 22:47:27 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm2LN-0008Mn-8z for nemo@ietf.org; Tue, 04 Jan 2005 23:00:24 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5E0114D84C; Wed, 5 Jan 2005 12:46:36 +0900 (JST) Date: Wed, 5 Jan 2005 12:50:07 +0900 From: Thierry Ernst To: nemo Message-Id: <20050105125007.3993b823.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Vijay Devarapalli , tj , Ryuji Wakikawa , "Pascal Thubert \(pthubert\)" Subject: [nemo] NEMO WG Last Call on 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 all, First of all, I wish you all a happy nemo and IPv6 new year. As aggreed in ... Washington, we would like to issue a WG Last Call on NEMO WG draft "NEMO Home Network models" (http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt) We will close this Last Call in 2 weeks time, i.e. Jan.19th. This is your last chance to express agreement or disagreement with this draft being forwarded to the IESG as Informational. Network Mobility P. Thubert Internet-Draft Cisco Expires: April 5, 2005 R. Wakikawa Keio University V. Devarapalli Nokia October 5, 2004 NEMO Home Network models draft-ietf-nemo-home-network-models-01 Thanks to Pascal (more than once ;-) and Vijay (at least once) for reminding me ... The NEMO WG chairs. From nemo-bounces@ietf.org Wed Jan 5 02:17:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19694 for ; Wed, 5 Jan 2005 02:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm5M0-0004bV-Ls; Wed, 05 Jan 2005 02:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm5GI-0002AO-IX for nemo@megatron.ietf.org; Wed, 05 Jan 2005 02:07:18 -0500 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 CAA10661 for ; Wed, 5 Jan 2005 02:07:16 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm5Sn-00046U-KI for nemo@ietf.org; Wed, 05 Jan 2005 02:20:14 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Jan 2005 08:21:16 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xfb-ams-331.cisco.com (xfb-ams-331.cisco.com [144.254.231.70]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0576gW6015635; Wed, 5 Jan 2005 08:06:42 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xfb-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jan 2005 08:06:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2005 08:06:35 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC68921D@xmb-ams-337.emea.cisco.com> Thread-Topic: about the Home Network Models WG item Thread-Index: AcTOWGzaNQDPkqV2THiuAv8PQeKs0AknGNsg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Jan 2005 07:06:42.0404 (UTC) FILETIME=[1C025240:01C4F2F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: about the Home Network Models WG item X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Alex: =20 | Then, in the current description of the "Aggregated Home Network" | section 5, there are very many things unclear to me: |=20 | section 5: | > A node on the Home Link computes that the Aggregated Home Network is | > actually a subnet on the Home Link and may use it for | > autoconfiguration purposes. |=20 | It would be more readable to say: "use the prefix on the Home Link to | autoconfigure a Home Address". |=20 I agree with you here. I made the change as issue 1. Pascal From nemo-bounces@ietf.org Wed Jan 5 03:28:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11940 for ; Wed, 5 Jan 2005 03:28:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6Rj-0003oa-DU; Wed, 05 Jan 2005 03:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm6MG-0002HW-8D for nemo@megatron.ietf.org; Wed, 05 Jan 2005 03:17:32 -0500 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 DAA10946 for ; Wed, 5 Jan 2005 03:17:28 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm6Jc-0005VS-6T for nemo@ietf.org; Wed, 05 Jan 2005 03:14:51 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Jan 2005 09:15:51 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xfb-ams-331.cisco.com (xfb-ams-331.cisco.com [144.254.231.70]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0581AWC025278 for ; Wed, 5 Jan 2005 09:01:16 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xfb-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jan 2005 09:01:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Wed, 5 Jan 2005 09:01:12 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689275@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTOWGzaNQDPkqV2THiuAv8PQeKs0AknGNsgAADOsdA= From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 05 Jan 2005 08:01:13.0284 (UTC) FILETIME=[B99B0040:01C4F2FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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:=20 Please note that the issue list for this draft is hosted at: http://mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models- issues.html Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Pascal Thubert (pthubert) | Sent: Wednesday, January 05, 2005 8:07 AM | To: Alexandru Petrescu | Cc: nemo@ietf.org | Subject: [nemo] RE: about the Home Network Models WG item |=20 | Hi Alex: |=20 | | Then, in the current description of the "Aggregated Home Network" | | section 5, there are very many things unclear to me: | | | | section 5: | | > A node on the Home Link computes that the Aggregated Home Network is | | > actually a subnet on the Home Link and may use it for | | > autoconfiguration purposes. | | | | It would be more readable to say: "use the prefix on the Home Link to | | autoconfigure a Home Address". | | |=20 | I agree with you here. I made the change as issue 1. |=20 | Pascal From nemo-bounces@ietf.org Wed Jan 5 11:03:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16513 for ; Wed, 5 Jan 2005 11:03:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDVV-0003ly-9i; Wed, 05 Jan 2005 10:55:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDRT-0002OL-SE for nemo@megatron.ietf.org; Wed, 05 Jan 2005 10:51:23 -0500 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 KAA15349 for ; Wed, 5 Jan 2005 10:51:21 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDe0-00085C-2J for nemo@ietf.org; Wed, 05 Jan 2005 11:04:25 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j05Fr6fL022510; Wed, 5 Jan 2005 08:53:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j05FnwNv032270; Wed, 5 Jan 2005 09:49:58 -0600 Received: from [10.161.201.138] (zfr01-2138.crm.mot.com [10.161.201.138]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9A66D8A3A7C; Wed, 5 Jan 2005 16:51:14 +0100 (CET) Message-ID: <41DC0CF2.4080909@motorola.com> Date: Wed, 05 Jan 2005 16:51:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC68921D@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC68921D@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Alex: > > | Then, in the current description of the "Aggregated Home Network" > | section 5, there are very many things unclear to me: > | > | section 5: > | > A node on the Home Link computes that the Aggregated Home Network is > | > actually a subnet on the Home Link and may use it for > | > autoconfiguration purposes. > | > | It would be more readable to say: "use the prefix on the Home Link to > | autoconfigure a Home Address". > | > > I agree with you here. I made the change as issue 1. Ok. I hope having an issues list helps advancing this draft WG item. What about the other issues I raised by email to you and authors of draft? They don't appear in the issues list. Alex From nemo-bounces@ietf.org Wed Jan 5 11:30:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18730 for ; Wed, 5 Jan 2005 11:30:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDjk-0000KC-FM; Wed, 05 Jan 2005 11:10:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDhx-0007zM-Mh for nemo@megatron.ietf.org; Wed, 05 Jan 2005 11:08:26 -0500 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 LAA16797 for ; Wed, 5 Jan 2005 11:08:22 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDuV-00006s-M2 for nemo@ietf.org; Wed, 05 Jan 2005 11:21:26 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j05GA9fL015987; Wed, 5 Jan 2005 09:10:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id j05G8I61020854; Wed, 5 Jan 2005 10:08:18 -0600 Received: from [10.161.201.138] (zfr01-2138.crm.mot.com [10.161.201.138]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C07A38A3A7C; Wed, 5 Jan 2005 17:08:17 +0100 (CET) Message-ID: <41DC10F1.5020903@motorola.com> Date: Wed, 05 Jan 2005 17:08:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] NEMO WG Last Call on Home Network Models References: <20050105125007.3993b823.ernst@sfc.wide.ad.jp> In-Reply-To: <20050105125007.3993b823.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: nemo , tj , Vijay Devarapalli , "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > As aggreed in ... Washington, we would like to issue a WG Last Call on > NEMO WG draft "NEMO Home Network models" > (http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt) > > We will close this Last Call in 2 weeks time, i.e. Jan.19th. This is > your last chance to express agreement or disagreement with this draft > being forwarded to the IESG as Informational. Thierry, I've raised some issues in private to authors of the draft. I wonder if anybody else has issues with this draft. Alex From nemo-bounces@ietf.org Wed Jan 5 12:04:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21999 for ; Wed, 5 Jan 2005 12:04:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmEVO-000223-7H; Wed, 05 Jan 2005 11:59:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmESM-0001AM-Pz for nemo@megatron.ietf.org; Wed, 05 Jan 2005 11:56:22 -0500 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 LAA21012 for ; Wed, 5 Jan 2005 11:56:19 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmEex-000247-IH for nemo@ietf.org; Wed, 05 Jan 2005 12:09:24 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 05 Jan 2005 18:10:26 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j05GtiW6027044; Wed, 5 Jan 2005 17:55:45 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Jan 2005 17:55:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Wed, 5 Jan 2005 17:55:38 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzPnENF/PTNOc8S4mjbLtRb8ACrAACAASw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Jan 2005 16:55:44.0280 (UTC) FILETIME=[6568A180:01C4F347] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] | Sent: Wednesday, January 05, 2005 4:51 PM | To: Pascal Thubert (pthubert) | Cc: nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | > Hi Alex: | > | > | Then, in the current description of the "Aggregated Home Network" | > | section 5, there are very many things unclear to me: | > | | > | section 5: | > | > A node on the Home Link computes that the Aggregated Home Network is | > | > actually a subnet on the Home Link and may use it for | > | > autoconfiguration purposes. | > | | > | It would be more readable to say: "use the prefix on the Home Link to | > | autoconfigure a Home Address". | > | | > | > I agree with you here. I made the change as issue 1. |=20 | Ok. I hope having an issues list helps advancing this draft WG item. |=20 | What about the other issues I raised by email to you and authors of | draft? They don't appear in the issues list. |=20 My understanding is that we had already discussed the other items (name for extended, order in the doc between aggregated and extended, /64 in the examples) in the ML itself and done the changes we agreed upon at the time (in particular, say that 64 as a prefix length is an example, and use a different value in the aggregated case).=20 But if you wish to change something more, please present on this list at this time, and if you get enough support, I'll do the changes as required. You might want to consult the WIP for 02 at: http://mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models- xx.html Pascal From nemo-bounces@ietf.org Wed Jan 5 13:14:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27293 for ; Wed, 5 Jan 2005 13:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFbA-0003Kl-CR; Wed, 05 Jan 2005 13:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFQR-0000eh-7p for nemo@megatron.ietf.org; Wed, 05 Jan 2005 12:58:27 -0500 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 MAA25956 for ; Wed, 5 Jan 2005 12:58:23 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFd2-000632-HJ for nemo@ietf.org; Wed, 05 Jan 2005 13:11:29 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j05I0CfL001038; Wed, 5 Jan 2005 11:00:12 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j05Hv19v011223; Wed, 5 Jan 2005 11:57:01 -0600 Received: from [10.161.201.138] (zfr01-2138.crm.mot.com [10.161.201.138]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 955368A3A7C; Wed, 5 Jan 2005 18:58:20 +0100 (CET) Message-ID: <41DC2ABC.1080504@motorola.com> Date: Wed, 05 Jan 2005 18:58:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: [...] > please present on this list at this time, and if you get enough > support, I'll do the changes as required. I do not think in the simplest Home Network configuration the MR may use a Home Address derived from the prefix assigned on its moving network link, the MNP. In the simplest cases, the MR Home Address is derived from the prefix valid on the Home Link. Or, section 4.1 Extended Home Network configuration has a last item saying: > Alternatively, a Mobile Router could also form a Home Address from > one of its prefixes and use it to register[...] I think this kind of item should belong to other more complex Home Network configurations. Besides, I think that a useful informational document on the types of home networks should describe several such networks - in the order of simplicity - starting first from the most simple and basic and obvious and only later to the most exotic. Or, while the current document does describe three such networks, there does not seem to be an order from basic to complex. The first described is already "Extended" and the other two are "Aggregated" and "Virtual". The "Aggregated" is a little more complex than the "Extended" in that the MR looks up its MNNs via ND on the Home Link, which is a little exotic feature. The "Virtual" model is the most exotic in that there is no returning home procedure for example. So, I understand there is a form of scale on differentiation, from the most basic up to the most complex, but the most basic is still called "Extended" and allows MR HoA from MNP. Hence my proposal to call the basic model just "Basic Home Network" and this model not to use MR Home Address from the MNP. Alternatively, I propose to introduce a 4th model, called "Basic Home Network Model", that would come before the other three models, and in which MR would only construct its Home Address from the prefix on the home link, that would perform ND for that address, that would implement the NEMO Returning Home procedure and for which address the HA performs proxy ND when MR not at home, according to Mobile IPv6. What do you think Pascal? What do the others think? Alex From nemo-bounces@ietf.org Wed Jan 5 13:32:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28421 for ; Wed, 5 Jan 2005 13:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFtt-0007uy-A6; Wed, 05 Jan 2005 13:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFpa-0006Bg-1d for nemo@megatron.ietf.org; Wed, 05 Jan 2005 13:24:26 -0500 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 NAA27914 for ; Wed, 5 Jan 2005 13:24:22 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmG28-00088r-7w for nemo@ietf.org; Wed, 05 Jan 2005 13:37:28 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2005 10:31:59 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j05INjjw019672; Wed, 5 Jan 2005 10:23:46 -0800 (PST) Received: from dshell-w2k02.cisco.com (rtp-vpn2-386.cisco.com [10.82.241.130]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA14133; Wed, 5 Jan 2005 10:23:44 -0800 (PST) Message-Id: <4.3.2.7.2.20050105132136.00c60ae8@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jan 2005 13:23:44 -0500 To: Alexandru Petrescu From: Daniel Shell Subject: Re: [nemo] RE: about the Home Network Models WG item In-Reply-To: <41DC2ABC.1080504@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Sounds good to have the sections labelled Basic Extended Aggregated Virtual Would like to see what Pascal says though. At 06:58 PM 1/5/2005 +0100, Alexandru Petrescu wrote: >Pascal Thubert (pthubert) wrote: >[...] >>please present on this list at this time, and if you get enough support, >>I'll do the changes as required. > >I do not think in the simplest Home Network configuration the MR may use >a Home Address derived from the prefix assigned on its moving network >link, the MNP. In the simplest cases, the MR Home Address is derived >from the prefix valid on the Home Link. > >Or, section 4.1 Extended Home Network configuration has a last item saying: >>Alternatively, a Mobile Router could also form a Home Address from >>one of its prefixes and use it to register[...] > >I think this kind of item should belong to other more complex Home Network >configurations. > >Besides, I think that a useful informational document on the types of home >networks should describe several such networks - in the order of >simplicity - starting first from the most simple and basic and obvious and >only later to the most exotic. > >Or, while the current document does describe three such networks, there >does not seem to be an order from basic to complex. The first described >is already "Extended" and the other two are "Aggregated" and >"Virtual". The "Aggregated" is a little more complex than the "Extended" >in that the MR looks up its MNNs via ND on the Home Link, which is a >little exotic feature. The "Virtual" model is the most exotic in that >there is no returning home procedure for example. > >So, I understand there is a form of scale on differentiation, from the >most basic up to the most complex, but the most basic is still called >"Extended" and allows MR HoA from MNP. > >Hence my proposal to call the basic model just "Basic Home Network" and >this model not to use MR Home Address from the MNP. Alternatively, I >propose to introduce a 4th model, called "Basic Home Network Model", that >would come before the other three models, and in which MR would only >construct its Home Address from the prefix on the home link, that would >perform ND for that address, that would implement the NEMO Returning Home >procedure and for which address the HA performs proxy ND when MR not at >home, according to Mobile IPv6. > >What do you think Pascal? What do the others think? > >Alex Dan Shell Government Service Unit CISCO Systems IP mobility/Wireless/Satellite 440 331 5663 From nemo-bounces@ietf.org Wed Jan 5 14:08:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01602 for ; Wed, 5 Jan 2005 14:08:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmGRy-0005s5-68; Wed, 05 Jan 2005 14:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmGQr-0005b2-0n for nemo@megatron.ietf.org; Wed, 05 Jan 2005 14:02:57 -0500 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 OAA01132 for ; Wed, 5 Jan 2005 14:02:55 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmGdS-0003K4-Mg for nemo@ietf.org; Wed, 05 Jan 2005 14:16:00 -0500 Received: from wifi-139-142.sfc.wide.ad.jp.sfc.wide.ad.jp (wifi-139-142.sfc.wide.ad.jp [203.178.139.142]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j05J2bFj006334; Thu, 6 Jan 2005 04:02:38 +0900 Date: Thu, 06 Jan 2005 04:02:36 +0900 Message-ID: From: Ryuji Wakikawa To: alexandru.petrescu@motorola.com Subject: Re: [nemo] RE: about the Home Network Models WG item In-Reply-To: <41DC2ABC.1080504@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <41DC2ABC.1080504@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Hello Alex. Happy New Year! I agree. Since the draft title is "home network models", it is fare to have the basic configuration. regards, ryuji At Wed, 05 Jan 2005 18:58:20 +0100, Alexandru Petrescu wrote: > > Pascal Thubert (pthubert) wrote: > [...] > > please present on this list at this time, and if you get enough > > support, I'll do the changes as required. > > I do not think in the simplest Home Network configuration the MR may use > a Home Address derived from the prefix assigned on its moving network > link, the MNP. In the simplest cases, the MR Home Address is derived > from the prefix valid on the Home Link. > > Or, section 4.1 Extended Home Network configuration has a last item saying: > > Alternatively, a Mobile Router could also form a Home Address from > > one of its prefixes and use it to register[...] > > I think this kind of item should belong to other more complex Home > Network configurations. > > Besides, I think that a useful informational document on the types of > home networks should describe several such networks - in the order of > simplicity - starting first from the most simple and basic and obvious > and only later to the most exotic. > > Or, while the current document does describe three such networks, there > does not seem to be an order from basic to complex. The first described > is already "Extended" and the other two are "Aggregated" and "Virtual". > The "Aggregated" is a little more complex than the "Extended" in that > the MR looks up its MNNs via ND on the Home Link, which is a little > exotic feature. The "Virtual" model is the most exotic in that there is > no returning home procedure for example. > > So, I understand there is a form of scale on differentiation, from the > most basic up to the most complex, but the most basic is still called > "Extended" and allows MR HoA from MNP. > > Hence my proposal to call the basic model just "Basic Home Network" and > this model not to use MR Home Address from the MNP. Alternatively, I > propose to introduce a 4th model, called "Basic Home Network Model", > that would come before the other three models, and in which MR would > only construct its Home Address from the prefix on the home link, that > would perform ND for that address, that would implement the NEMO > Returning Home procedure and for which address the HA performs proxy ND > when MR not at home, according to Mobile IPv6. > > What do you think Pascal? What do the others think? > > Alex From nemo-bounces@ietf.org Wed Jan 5 21:19:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15112 for ; Wed, 5 Jan 2005 21:19:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmNBo-00037B-5W; Wed, 05 Jan 2005 21:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmN9S-0002F4-Nf for nemo@megatron.ietf.org; Wed, 05 Jan 2005 21:13:27 -0500 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 VAA14804 for ; Wed, 5 Jan 2005 21:13:24 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmNM8-0005Yd-VS for nemo@ietf.org; Wed, 05 Jan 2005 21:26:33 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 269DF4C5CE; Thu, 6 Jan 2005 11:12:36 +0900 (JST) Date: Thu, 6 Jan 2005 11:16:07 +0900 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: [nemo] NEMO WG Last Call on Home Network Models Message-Id: <20050106111607.528439ff.ernst@sfc.wide.ad.jp> In-Reply-To: <41DC10F1.5020903@motorola.com> References: <20050105125007.3993b823.ernst@sfc.wide.ad.jp> <41DC10F1.5020903@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) 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: nemo@ietf.org, tj@kniveton.com, vijayd@iprg.nokia.com, pthubert@cisco.com, ryuji@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Alexandru, Please raise your issues again, on the public ML this time, as this is a WG document. Thanks in advance, Thierry On Wed, 05 Jan 2005 17:08:17 +0100 Alexandru Petrescu wrote: > Thierry Ernst wrote: > > As aggreed in ... Washington, we would like to issue a WG Last Call on > > NEMO WG draft "NEMO Home Network models" > > (http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt) > > > > We will close this Last Call in 2 weeks time, i.e. Jan.19th. This is > > your last chance to express agreement or disagreement with this draft > > being forwarded to the IESG as Informational. > > Thierry, I've raised some issues in private to authors of the draft. > > I wonder if anybody else has issues with this draft. > > Alex From nemo-bounces@ietf.org Thu Jan 6 12:04:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24547 for ; Thu, 6 Jan 2005 12:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmavI-000257-GK; Thu, 06 Jan 2005 11:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmatV-000133-Q2 for nemo@megatron.ietf.org; Thu, 06 Jan 2005 11:53:53 -0500 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 LAA23234 for ; Thu, 6 Jan 2005 11:53:51 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmb6I-0005Ez-BV for nemo@ietf.org; Thu, 06 Jan 2005 12:07:08 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Jan 2005 18:08:17 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06Gr9WC021509; Thu, 6 Jan 2005 17:53:16 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Jan 2005 17:53:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Thu, 6 Jan 2005 17:53:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC68997E@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzUDbLxI4ZOwDbSLqO1MdZ/y1NsgAg/eOw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 06 Jan 2005 16:53:15.0140 (UTC) FILETIME=[36ED6C40:01C4F410] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: I open this as issue 2, and I'll give my view on a separate message. Pascal | -----Original Message----- | From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] | Sent: Wednesday, January 05, 2005 6:58 PM | To: Pascal Thubert (pthubert) | Cc: nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | [...] | > please present on this list at this time, and if you get enough | > support, I'll do the changes as required. |=20 | I do not think in the simplest Home Network configuration the MR may use | a Home Address derived from the prefix assigned on its moving network | link, the MNP. In the simplest cases, the MR Home Address is derived | from the prefix valid on the Home Link. |=20 | Or, section 4.1 Extended Home Network configuration has a last item | saying: | > Alternatively, a Mobile Router could also form a Home Address from | > one of its prefixes and use it to register[...] |=20 | I think this kind of item should belong to other more complex Home | Network configurations. |=20 | Besides, I think that a useful informational document on the types of | home networks should describe several such networks - in the order of | simplicity - starting first from the most simple and basic and obvious | and only later to the most exotic. |=20 | Or, while the current document does describe three such networks, there | does not seem to be an order from basic to complex. The first described | is already "Extended" and the other two are "Aggregated" and "Virtual". | The "Aggregated" is a little more complex than the "Extended" in that | the MR looks up its MNNs via ND on the Home Link, which is a little | exotic feature. The "Virtual" model is the most exotic in that there is | no returning home procedure for example. |=20 | So, I understand there is a form of scale on differentiation, from the | most basic up to the most complex, but the most basic is still called | "Extended" and allows MR HoA from MNP. |=20 | Hence my proposal to call the basic model just "Basic Home Network" and | this model not to use MR Home Address from the MNP. Alternatively, I | propose to introduce a 4th model, called "Basic Home Network Model", | that would come before the other three models, and in which MR would | only construct its Home Address from the prefix on the home link, that | would perform ND for that address, that would implement the NEMO | Returning Home procedure and for which address the HA performs proxy ND | when MR not at home, according to Mobile IPv6. |=20 | What do you think Pascal? What do the others think? |=20 | Alex From nemo-bounces@ietf.org Thu Jan 6 12:32:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26291 for ; Thu, 6 Jan 2005 12:32:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbLi-0004QM-Q2; Thu, 06 Jan 2005 12:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbFV-0001V0-RJ for nemo@megatron.ietf.org; Thu, 06 Jan 2005 12:16:37 -0500 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 MAA25156 for ; Thu, 6 Jan 2005 12:16:35 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmbS8-0004YB-6P for nemo@ietf.org; Thu, 06 Jan 2005 12:29:53 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Jan 2005 18:30:50 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06HFnW6028752; Thu, 6 Jan 2005 18:15:49 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jan 2005 18:15:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Thu, 6 Jan 2005 18:15:43 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689998@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8A From: "Pascal Thubert \(pthubert\)" To: "Daniel Shell \(dshell\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 06 Jan 2005 17:15:49.0421 (UTC) FILETIME=[5E244DD0:01C4F413] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In fact, extended means versus the MIP Home Agent which is the 'basic'. In all modes, we can take the Home Address from a Mobile Network. But I agree with Alex it's a bit complex (actually almost against nature :) to do it with extended mode. OTOH, it seems to me that it's the preferred mode in the aggregated case. Comments anybody? My suggestion to fix this issue is: 1) to explain better that extended is versus MIP Home at the beginning of that section 2) to describe better the case where the Home Address is taken from the Home Link in extended and say it's the preferred mode, and explain why 3) in aggregated, say that the address is taken from the MNP and explain why (DAD related). Once we agree no the approach we can start proposing text :) Pascal | -----Original Message----- | From: Daniel Shell (dshell) | Sent: Wednesday, January 05, 2005 7:24 PM | To: Alexandru Petrescu | Cc: Pascal Thubert (pthubert); nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Sounds good to have the sections labelled |=20 | Basic | Extended | Aggregated | Virtual |=20 | Would like to see what Pascal says though. |=20 |=20 |=20 |=20 | At 06:58 PM 1/5/2005 +0100, Alexandru Petrescu wrote: | >Pascal Thubert (pthubert) wrote: | >[...] | >>please present on this list at this time, and if you get enough support, | >>I'll do the changes as required. | > | >I do not think in the simplest Home Network configuration the MR may use | >a Home Address derived from the prefix assigned on its moving network | >link, the MNP. In the simplest cases, the MR Home Address is derived | >from the prefix valid on the Home Link. | > | >Or, section 4.1 Extended Home Network configuration has a last item | saying: | >>Alternatively, a Mobile Router could also form a Home Address from | >>one of its prefixes and use it to register[...] | > | >I think this kind of item should belong to other more complex Home | Network | >configurations. | > | >Besides, I think that a useful informational document on the types of | home | >networks should describe several such networks - in the order of | >simplicity - starting first from the most simple and basic and obvious | and | >only later to the most exotic. | > | >Or, while the current document does describe three such networks, there | >does not seem to be an order from basic to complex. The first described | >is already "Extended" and the other two are "Aggregated" and | >"Virtual". The "Aggregated" is a little more complex than the "Extended" | >in that the MR looks up its MNNs via ND on the Home Link, which is a | >little exotic feature. The "Virtual" model is the most exotic in that | >there is no returning home procedure for example. | > | >So, I understand there is a form of scale on differentiation, from the | >most basic up to the most complex, but the most basic is still called | >"Extended" and allows MR HoA from MNP. | > | >Hence my proposal to call the basic model just "Basic Home Network" and | >this model not to use MR Home Address from the MNP. Alternatively, I | >propose to introduce a 4th model, called "Basic Home Network Model", that | >would come before the other three models, and in which MR would only | >construct its Home Address from the prefix on the home link, that would | >perform ND for that address, that would implement the NEMO Returning Home | >procedure and for which address the HA performs proxy ND when MR not at | >home, according to Mobile IPv6. | > | >What do you think Pascal? What do the others think? | > | >Alex |=20 | Dan Shell | Government Service Unit | CISCO Systems | IP mobility/Wireless/Satellite | 440 331 5663 From nemo-bounces@ietf.org Thu Jan 6 13:43:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00525 for ; Thu, 6 Jan 2005 13:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcXL-0002JG-Mw; Thu, 06 Jan 2005 13:39:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcS2-0000c0-M1 for nemo@megatron.ietf.org; Thu, 06 Jan 2005 13:33:38 -0500 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 NAA29766 for ; Thu, 6 Jan 2005 13:33:37 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmcer-0007HI-3Q for nemo@ietf.org; Thu, 06 Jan 2005 13:46:54 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j06IZOJD011252; Thu, 6 Jan 2005 11:35:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id j06IXENs018111; Thu, 6 Jan 2005 12:33:14 -0600 Received: from [10.161.201.138] (zfr01-2138.crm.mot.com [10.161.201.138]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 427A68A3A71; Thu, 6 Jan 2005 19:33:32 +0100 (CET) Message-ID: <41DD847C.9000705@motorola.com> Date: Thu, 06 Jan 2005 19:33:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689998@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689998@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Ah, I understand that for you "extended" means MRs at home instead of simply MIP6 MHs at home. Just that in this simple extension there is no HoA from MNP. Pascal Thubert (pthubert) wrote: > My suggestion to fix this issue is: > > 1) to explain better that extended is versus MIP Home at the > beginning of that section At which point one would need to explain what a "MIP Home model" is, a sub-section on its own. > 2) to describe better the case where the Home Address is taken from > the Home Link in extended and say it's the preferred mode, and > explain why > > 3) in aggregated, say that the address is taken from the MNP and > explain why (DAD related). > > Once we agree no the approach we can start proposing text :) Once we get a common understanding the text should flow seamlessly IMHO. Alex From nemo-bounces@ietf.org Fri Jan 7 04:16:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28010 for ; Fri, 7 Jan 2005 04:16:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmqBw-0005bc-0C; Fri, 07 Jan 2005 04:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmq9l-0004hn-5y for nemo@megatron.ietf.org; Fri, 07 Jan 2005 04:11:41 -0500 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 EAA27577 for ; Fri, 7 Jan 2005 04:11:39 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmqMh-0003qU-G5 for nemo@ietf.org; Fri, 07 Jan 2005 04:25:04 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 10:26:17 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xfb-ams-331.cisco.com (xfb-ams-331.cisco.com [144.254.231.70]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j079B1WA028667; Fri, 7 Jan 2005 10:11:05 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xfb-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 10:11:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 10:10:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689AF5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0HkdJlKEexglVR4WNVzGtGSEVzwAdDKpQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 09:11:02.0857 (UTC) FILETIME=[CF9C9B90:01C4F498] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 | -----Original Message----- | From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] | Sent: Thursday, January 06, 2005 7:34 PM | To: Pascal Thubert (pthubert) | Cc: nemo | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Ah, I understand that for you "extended" means MRs at home instead of | simply MIP6 MHs at home. Just that in this simple extension there is no | HoA from MNP. Exactly :) The HoA from MNP is orthogonal, could be done in all modes, but natural in aggregated and not in extended. Extended extends MIP because Home is MIP's Home + MNPs, so it is no more a subnet on a link but the aggregation of that subnet and all the NEMOs |=20 | Pascal Thubert (pthubert) wrote: | > My suggestion to fix this issue is: | > | > 1) to explain better that extended is versus MIP Home at the | > beginning of that section |=20 | At which point one would need to explain what a "MIP Home model" is, a | sub-section on its own. Why not, long as it stays short and does not open to endless debates ;) That can be the 'basic' you are mentioning... |=20 | > 2) to describe better the case where the Home Address is taken from | > the Home Link in extended and say it's the preferred mode, and | > explain why | > | > 3) in aggregated, say that the address is taken from the MNP and | > explain why (DAD related). | > | > Once we agree no the approach we can start proposing text :) |=20 | Once we get a common understanding the text should flow seamlessly IMHO. |=20 OK. Advice anybody? I'll propose some text next week based on the reactions to this mail. Pascal From nemo-bounces@ietf.org Fri Jan 7 04:35:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29023 for ; Fri, 7 Jan 2005 04:35:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmqOT-0001fa-FR; Fri, 07 Jan 2005 04:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmqNA-000129-St for nemo@megatron.ietf.org; Fri, 07 Jan 2005 04:25:33 -0500 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 EAA28448 for ; Fri, 7 Jan 2005 04:25:31 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmqa6-00055v-W1 for nemo@ietf.org; Fri, 07 Jan 2005 04:38:56 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 10:40:09 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j079OWW8001859; Fri, 7 Jan 2005 10:24:56 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 10:25:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 10:24:44 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689B07@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAAAKyl8A== From: "Pascal Thubert \(pthubert\)" To: "BINET David RD-CORE-CAE" , "Daniel Shell \(dshell\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 09:25:37.0681 (UTC) FILETIME=[D90C2810:01C4F49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I agree with you on the virtual case. On the aggregated case, we could by construction reserve some address = space in the aggregation that we would not dedicate to any MNP, and, = again by construction, we could enforce that the MR HoA be taken from = that reserved space. This would allow a real DAD process by the Home = Agent, but it seems a bit unnatural to my taste. Can/should we word that = something looks more natural then something else? That requires a = consensus in the WG. To my personal taste, it is natural to take the Home Address from the = Home Link in extended mode and from the MNP in aggregated mode. But in = both cases, the alternate is possible. Specific support by the HA might = be needed to enforce the related policies, and that is not in the scope = of basic. Should we leave that to the products or is there something we = should standardize?=20 Pascal | -----Original Message----- | From: BINET David RD-CORE-CAE [mailto:david.binet@francetelecom.com] | Sent: Friday, January 07, 2005 10:00 AM | To: Pascal Thubert (pthubert); Daniel Shell (dshell); Alexandru = Petrescu | Cc: nemo@ietf.org | Subject: RE: [nemo] RE: about the Home Network Models WG item |=20 | From the draft, I understand that the question about the configuration = of | Home Address is only valid in extended mode. In aggregated mode and | virtual mode, there is no specific Home subnet and Home Address will = be | configured on any MNP. | I think it could be useful to distinguish both modes in current = "extended | mode", one if the Home Address is taken from Home Net (basic one) and = one | if the home address is taken from Mobile Net (extended one). |=20 | David |=20 | -----Message d'origine----- | De : nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] De la part = de | Pascal Thubert (pthubert) | Envoy=E9 : jeudi 6 janvier 2005 18:16 | =C0 : Daniel Shell (dshell); Alexandru Petrescu | Cc : nemo@ietf.org | Objet : RE: [nemo] RE: about the Home Network Models WG item |=20 | In fact, extended means versus the MIP Home Agent which is the = 'basic'. | In all modes, we can take the Home Address from a Mobile Network. But = I | agree with Alex it's a bit complex (actually almost against nature :) = to | do it with extended mode. OTOH, it seems to me that it's the preferred | mode in the aggregated case. Comments anybody? |=20 | My suggestion to fix this issue is: |=20 | 1) to explain better that extended is versus MIP Home at the beginning = of | that section |=20 | 2) to describe better the case where the Home Address is taken from = the | Home Link in extended and say it's the preferred mode, and explain why |=20 | 3) in aggregated, say that the address is taken from the MNP and = explain | why (DAD related). |=20 | Once we agree no the approach we can start proposing text :) |=20 | Pascal |=20 | | -----Original Message----- | | From: Daniel Shell (dshell) | | Sent: Wednesday, January 05, 2005 7:24 PM | | To: Alexandru Petrescu | | Cc: Pascal Thubert (pthubert); nemo@ietf.org | | Subject: Re: [nemo] RE: about the Home Network Models WG item | | | | Sounds good to have the sections labelled | | | | Basic | | Extended | | Aggregated | | Virtual | | | | Would like to see what Pascal says though. | | | | | | | | | | At 06:58 PM 1/5/2005 +0100, Alexandru Petrescu wrote: | | >Pascal Thubert (pthubert) wrote: | | >[...] | | >>please present on this list at this time, and if you get enough | support, | | >>I'll do the changes as required. | | > | | >I do not think in the simplest Home Network configuration the MR = may | use | | >a Home Address derived from the prefix assigned on its moving = network | | >link, the MNP. In the simplest cases, the MR Home Address is = derived | | >from the prefix valid on the Home Link. | | > | | >Or, section 4.1 Extended Home Network configuration has a last item | | saying: | | >>Alternatively, a Mobile Router could also form a Home Address from | | >>one of its prefixes and use it to register[...] | | > | | >I think this kind of item should belong to other more complex Home | | Network | | >configurations. | | > | | >Besides, I think that a useful informational document on the types = of | | home | | >networks should describe several such networks - in the order of | | >simplicity - starting first from the most simple and basic and | obvious | | and | | >only later to the most exotic. | | > | | >Or, while the current document does describe three such networks, | there | | >does not seem to be an order from basic to complex. The first | described | | >is already "Extended" and the other two are "Aggregated" and | | >"Virtual". The "Aggregated" is a little more complex than the | "Extended" | | >in that the MR looks up its MNNs via ND on the Home Link, which is = a | | >little exotic feature. The "Virtual" model is the most exotic in | that | | >there is no returning home procedure for example. | | > | | >So, I understand there is a form of scale on differentiation, from | the | | >most basic up to the most complex, but the most basic is still = called | | >"Extended" and allows MR HoA from MNP. | | > | | >Hence my proposal to call the basic model just "Basic Home Network" | and | | >this model not to use MR Home Address from the MNP. Alternatively, = I | | >propose to introduce a 4th model, called "Basic Home Network = Model", | that | | >would come before the other three models, and in which MR would = only | | >construct its Home Address from the prefix on the home link, that | would | | >perform ND for that address, that would implement the NEMO = Returning | Home | | >procedure and for which address the HA performs proxy ND when MR = not | at | | >home, according to Mobile IPv6. | | > | | >What do you think Pascal? What do the others think? | | > | | >Alex | | | | Dan Shell | | Government Service Unit | | CISCO Systems | | IP mobility/Wireless/Satellite | | 440 331 5663 From nemo-bounces@ietf.org Fri Jan 7 07:52:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10417 for ; Fri, 7 Jan 2005 07:52:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmtTu-0001HN-Nz; Fri, 07 Jan 2005 07:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmtTm-000108-P3 for nemo@megatron.ietf.org; Fri, 07 Jan 2005 07:44:34 -0500 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 HAA10021 for ; Fri, 7 Jan 2005 07:44:33 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmtgi-0001No-Ux for nemo@ietf.org; Fri, 07 Jan 2005 07:58:00 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j07CkHJD003199; Fri, 7 Jan 2005 05:46:17 -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 j07CiPNx013322; Fri, 7 Jan 2005 06:44:26 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D56988A3C61; Fri, 7 Jan 2005 13:44:24 +0100 (CET) Message-ID: <41DE8420.50400@motorola.com> Date: Fri, 07 Jan 2005 13:44:16 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: BINET David RD-CORE-CAE Subject: Re: [nemo] RE: about the Home Network Models WG item References: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F55F@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F55F@ftrdmel3.rd.francetelecom.fr> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD0209E4319E85B81CE9C6D6" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD0209E4319E85B81CE9C6D6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit BINET David RD-CORE-CAE wrote: > From the draft, I understand that the question about the > configuration of Home Address is only valid in extended mode. In > aggregated mode and virtual mode, there is no specific Home subnet > and Home Address will be configured on any MNP. I think it could be > useful to distinguish both modes in current "extended mode", one if > the Home Address is taken from Home Net (basic one) and one if the > home address is taken from Mobile Net (extended one). I kind of agree. Which would boil down to two "extended" modes. I'd like the extended mode that uses HoA from Home Link to be the most basic simplest one describe. Alex --------------enigBD0209E4319E85B81CE9C6D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3oQoMmC0w56zj54RAkGHAJ9jlgb97e3pHZHOEH98rRAsOvvKNgCfbkip nnKQyy3Ks7xpMdCe9oTha/k= =bNGP -----END PGP SIGNATURE----- --------------enigBD0209E4319E85B81CE9C6D6-- From nemo-bounces@ietf.org Fri Jan 7 07:56:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10607 for ; Fri, 7 Jan 2005 07:56:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmtd7-0003az-TA; Fri, 07 Jan 2005 07:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmtXZ-0001w6-Ff for nemo@megatron.ietf.org; Fri, 07 Jan 2005 07:48:29 -0500 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 HAA10239 for ; Fri, 7 Jan 2005 07:48:28 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmtkV-0001wF-Cn for nemo@ietf.org; Fri, 07 Jan 2005 08:01:54 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j07CrjO9001924; Fri, 7 Jan 2005 05:53:45 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j07CktR9027012; Fri, 7 Jan 2005 06:46:56 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 27FFD8A3C61; Fri, 7 Jan 2005 13:48:21 +0100 (CET) Message-ID: <41DE850F.2020103@motorola.com> Date: Fri, 07 Jan 2005 13:48:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689AF5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689AF5@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig707507E152ED86EFC504334D" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig707507E152ED86EFC504334D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The HoA from MNP is orthogonal, could be done in all modes HoA from MNP may be "orthogonal" to all modes, but can not be done in all modes. An LFN on the Home Link can not talk to a neighbour MR that is away from home if that MR has HoA from MNP, because HA can not do proxy ND for a HoA that is not on the Home Link. So, to me, there exist a simple basic mode in which HoA is not from MNP. Alex --------------enig707507E152ED86EFC504334D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3oUVMmC0w56zj54RAketAKC8j1DQHIFiT6w/gbWYD2+dHmzB7gCgrLPn gqSz1iGLxU5TYgLLA2LIE+c= =bui6 -----END PGP SIGNATURE----- --------------enig707507E152ED86EFC504334D-- From nemo-bounces@ietf.org Fri Jan 7 08:22:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12390 for ; Fri, 7 Jan 2005 08:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmu3Y-0004aQ-IZ; Fri, 07 Jan 2005 08:21:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmtza-0003RC-Ok for nemo@megatron.ietf.org; Fri, 07 Jan 2005 08:17:26 -0500 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 IAA12103 for ; Fri, 7 Jan 2005 08:17:25 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmuCX-00040H-6V for nemo@ietf.org; Fri, 07 Jan 2005 08:30:52 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j07DMfnm027276; Fri, 7 Jan 2005 06:22:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j07DFpR9019485; Fri, 7 Jan 2005 07:15:51 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4DD1088DFAB; Fri, 7 Jan 2005 14:17:17 +0100 (CET) Message-ID: <41DE8BD4.6020708@motorola.com> Date: Fri, 07 Jan 2005 14:17:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689B07@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689B07@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0947B8546672B33592C387A2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0947B8546672B33592C387A2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > To my personal taste, it is natural to take the Home Address from the > Home Link in extended mode I'm ok with this; but just don't call it "extended" IMHO, call it "normal basic". Or maybe "NEMO-extended MIP Home mode", but that's a bit clumsy. IMHO. > and from the MNP in aggregated mode. Pascal, the idea of having the HoA from MNP has an initial motivation different than building aggregated Home Networks. In my understanding from verbal explanations, the idea of having HoA from MNP comes from ease of implementing a certain RO feature. That is not mentioned in the draft. > But in both cases, the alternate is possible. Let's get a feeling of why it is good to have a HoA from MNP, and not try to put HoA from MNP in all modes (simple, extended, aggregated, virtual) just because it is possible to have it. > Specific support by the HA might be needed to enforce the related > policies, and that is not in the scope of basic. Do we have an idea whether the NEMO Basic Support supports all modes described in the NEMO Home Network Models? > Should we leave that to the products or is there something we should > standardize? I think that if you know about a product that specifically supports (or plans to support) a certain Home Network Model then please mention it, it is very important. When you're asking on whether there is something to be standardized. I think standard is better to have because inter-operability it facilitates. At the same time this draft being targeted as INFORMATIONAL, its scope is supposedly (1) to advice network deployers about how to do a Home Network that works with the NEMO Basic Support. Or probably it aims to (2) describe existing deployments, positive experiences. Or probably it (3) gives just "seed" ideas about directions of thinking of what a potential Home Network _could_ look like with no engagement of actual implementation support, just providing new ideas for future protocol development. These are three different goals IMHO. But even so numerous be they, I do not think this draft proposes anything about inter-operability, standardization. This is my understanding of the draft currently, but you may know better about the intent. Alex --------------enig0947B8546672B33592C387A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3ovdMmC0w56zj54RAgaWAKD3IHtRLyESZvzjW0pYFYlwkB5KIACfR002 +u9e8EpOCQ9BtAz5Zzrx5uY= =FEIq -----END PGP SIGNATURE----- --------------enig0947B8546672B33592C387A2-- From nemo-bounces@ietf.org Fri Jan 7 08:25:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12568 for ; Fri, 7 Jan 2005 08:25:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmu3s-0004uo-Cz; Fri, 07 Jan 2005 08:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmu0v-0003x7-LR for nemo@megatron.ietf.org; Fri, 07 Jan 2005 08:18:49 -0500 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 IAA12200 for ; Fri, 7 Jan 2005 08:18:48 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmuDv-0004DA-70 for nemo@ietf.org; Fri, 07 Jan 2005 08:32:15 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 14:33:30 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xfb-ams-331.cisco.com (xfb-ams-331.cisco.com [144.254.231.70]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07DI5WA023457; Fri, 7 Jan 2005 14:18:09 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xfb-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 14:17:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 14:17:43 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689C59@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0tzVqiEASjvbuTuyCkJnp7w6AmwAA7qvA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 13:17:49.0215 (UTC) FILETIME=[48E38AF0:01C4F4BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Friday, January 07, 2005 1:48 PM | To: Pascal Thubert (pthubert) | Cc: nemo | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | > The HoA from MNP is orthogonal, could be done in all modes |=20 | HoA from MNP may be "orthogonal" to all modes, but can not be done in | all modes. An LFN on the Home Link can not talk to a neighbour MR that | is away from home if that MR has HoA from MNP, because HA can not do | proxy ND for a HoA that is not on the Home Link. So, to me, there exist | a simple basic mode in which HoA is not from MNP. |=20 The HA would need to proxy ND the whole prefix. Not only to ping the MR, but also any MNN. In the draft:=20 " Thus, the Home Agent MUST intercept all the packets to the MNNs on the registered prefixes. In order to do so, the Home Agent might perform ND proxying for all addresses in all registered Mobile Network Prefixes, and protect the MNP space from autoconfiguration by uncontrolled visitors on the Home Link. " Pascal From nemo-bounces@ietf.org Fri Jan 7 08:49:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14283 for ; Fri, 7 Jan 2005 08:49:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuQK-0004As-VX; Fri, 07 Jan 2005 08:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuLE-00026Z-Tj for nemo@megatron.ietf.org; Fri, 07 Jan 2005 08:39:48 -0500 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 IAA13413 for ; Fri, 7 Jan 2005 08:39:47 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmuYE-00068L-MH for nemo@ietf.org; Fri, 07 Jan 2005 08:53:14 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j07DaaJD024252; Fri, 7 Jan 2005 06:36:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id j07DYj61028315; Fri, 7 Jan 2005 07:34:45 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1970D8A3C61; Fri, 7 Jan 2005 14:34:45 +0100 (CET) Message-ID: <41DE8FEF.8080606@motorola.com> Date: Fri, 07 Jan 2005 14:34:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689C59@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689C59@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig955193DB8AD70F7AB09E5614" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig955193DB8AD70F7AB09E5614 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > | Pascal Thubert (pthubert) wrote: > | > The HoA from MNP is orthogonal, could be done in all modes > | > | HoA from MNP may be "orthogonal" to all modes, but can not be done in > | all modes. An LFN on the Home Link can not talk to a neighbour MR > | that > | is away from home if that MR has HoA from MNP, because HA can not do > | proxy ND for a HoA that is not on the Home Link. So, to me, there > | exist > | a simple basic mode in which HoA is not from MNP. > | > > The HA would need to proxy ND the whole prefix. Not only to ping the > MR, but also any MNN. In the draft: " Thus, the Home Agent MUST > intercept all the packets to the MNNs on the registered prefixes. In > order to do so, the Home Agent might perform ND proxying for all > addresses in all registered Mobile Network Prefixes, and protect the > MNP space from autoconfiguration by uncontrolled visitors on the Home > Link. " A-ha! So without the HA proxying all addresses in all MNPs in its BC the "HoA from MNP" can not work. HA proxying for all addresses in all MNPs in its BC is something that can not be implemented. Why? At least because proxy NA is sent periodically, becoming an overload. Am I missing something? What does "HA protects the MNP space from autoconfiguration by uncontrolled visitors on the Home Link" mean? Is it that HA defends a certain HoA from a certain BC-registered MNP, by sending proxy Neighbour Advertisements? ("defends" in that when a visitor tries to autoconfigure an address based on MNP, its DAD fails because of the NA sent by the HA on behalf of MR). But how would a visitor on the home link autoconfigure an address based on MNP if that MNP is not present in an RA? Or is anybody sending RAs on the home link with the MNP? Alex --------------enig955193DB8AD70F7AB09E5614 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3o/0MmC0w56zj54RAp7eAKDDx7kfmBtr+ajQiYQ4znpVjX7qDwCgqrh4 BmtwYt/PP2gjdiCTnsBLr/Y= =FHGi -----END PGP SIGNATURE----- --------------enig955193DB8AD70F7AB09E5614-- From nemo-bounces@ietf.org Fri Jan 7 08:59:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14863 for ; Fri, 7 Jan 2005 08:59:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuXD-0006mG-OY; Fri, 07 Jan 2005 08:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuSM-0004bx-HR for nemo@megatron.ietf.org; Fri, 07 Jan 2005 08:47:11 -0500 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 IAA14055 for ; Fri, 7 Jan 2005 08:47:09 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmufI-0006jm-PB for nemo@ietf.org; Fri, 07 Jan 2005 09:00:36 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 14:47:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 14:47:01 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F82C@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAAAKyl8AAJLzXw From: "BINET David RD-CORE-CAE" To: "Pascal Thubert \(pthubert\)" , "Daniel Shell \(dshell\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 13:47:02.0954 (UTC) FILETIME=[5E32E0A0:01C4F4BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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 Comments in the text=20 > -----Message d'origine----- > De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Envoy=E9 : vendredi 7 janvier 2005 10:25 > =C0 : BINET David RD-CORE-CAE; Daniel Shell (dshell); Alexandru = Petrescu > Cc : nemo@ietf.org > Objet : RE: [nemo] RE: about the Home Network Models WG item >=20 > I agree with you on the virtual case. >=20 > On the aggregated case, we could by construction reserve some=20 > address space in the aggregation that we would not dedicate=20 > to any MNP, and, again by construction, we could enforce that=20 > the MR HoA be taken from that reserved space. This would=20 > allow a real DAD process by the Home Agent, but it seems a=20 > bit unnatural to my taste. Can/should we word that something=20 > looks more natural then something else? That requires a=20 > consensus in the WG. If you have a reserved address space in the aggregated home network, it = looks like a specific prefix for home network and this solution is quite = equivalent to extended mode. In the aggregated mode, MR HoA can be = configured from any MNP and there is no mean, a priori, to enforce some = HoA configuration.=20 >=20 > To my personal taste, it is natural to take the Home Address=20 > from the Home Link in extended mode and from the MNP in=20 > aggregated mode. But in both cases, the alternate is=20 > possible. Specific support by the HA might be needed to=20 > enforce the related policies, and that is not in the scope of=20 > basic. Should we leave that to the products or is there=20 > something we should standardize?=20 If there can be some interoperability issues, I think it has to be = specified. If two different modes (basic and extended) are described, = implementations will support one or both modes and there will not be any = problem with different extended implementations, with regard to HoA = configuration. >=20 >=20 > Pascal David >=20 > | -----Original Message----- > | From: BINET David RD-CORE-CAE [mailto:david.binet@francetelecom.com] > | Sent: Friday, January 07, 2005 10:00 AM > | To: Pascal Thubert (pthubert); Daniel Shell (dshell); Alexandru=20 > | Petrescu > | Cc: nemo@ietf.org > | Subject: RE: [nemo] RE: about the Home Network Models WG item > |=20 > | From the draft, I understand that the question about the=20 > configuration=20 > | of Home Address is only valid in extended mode. In=20 > aggregated mode and=20 > | virtual mode, there is no specific Home subnet and Home=20 > Address will=20 > | be configured on any MNP. > | I think it could be useful to distinguish both modes in current=20 > | "extended mode", one if the Home Address is taken from Home=20 > Net (basic=20 > | one) and one if the home address is taken from Mobile Net=20 > (extended one). > |=20 > | David > |=20 > | -----Message d'origine----- > | De : nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]=20 > De la part=20 > | de Pascal Thubert (pthubert) Envoy=E9 : jeudi 6 janvier 2005=20 > 18:16 =C0 :=20 > | Daniel Shell (dshell); Alexandru Petrescu Cc :=20 > nemo@ietf.org Objet :=20 > | RE: [nemo] RE: about the Home Network Models WG item > |=20 > | In fact, extended means versus the MIP Home Agent which is=20 > the 'basic'. > | In all modes, we can take the Home Address from a Mobile=20 > Network. But=20 > | I agree with Alex it's a bit complex (actually almost=20 > against nature=20 > | :) to do it with extended mode. OTOH, it seems to me that it's the=20 > | preferred mode in the aggregated case. Comments anybody? > |=20 > | My suggestion to fix this issue is: > |=20 > | 1) to explain better that extended is versus MIP Home at=20 > the beginning=20 > | of that section > |=20 > | 2) to describe better the case where the Home Address is taken from=20 > | the Home Link in extended and say it's the preferred mode,=20 > and explain=20 > | why > |=20 > | 3) in aggregated, say that the address is taken from the MNP and=20 > | explain why (DAD related). > |=20 > | Once we agree no the approach we can start proposing text :) > |=20 > | Pascal > |=20 > | | -----Original Message----- > | | From: Daniel Shell (dshell) > | | Sent: Wednesday, January 05, 2005 7:24 PM > | | To: Alexandru Petrescu > | | Cc: Pascal Thubert (pthubert); nemo@ietf.org > | | Subject: Re: [nemo] RE: about the Home Network Models WG item > | | > | | Sounds good to have the sections labelled > | | > | | Basic > | | Extended > | | Aggregated > | | Virtual > | | > | | Would like to see what Pascal says though. > | | > | | > | | > | | > | | At 06:58 PM 1/5/2005 +0100, Alexandru Petrescu wrote: > | | >Pascal Thubert (pthubert) wrote: > | | >[...] > | | >>please present on this list at this time, and if you get enough > | support, > | | >>I'll do the changes as required. > | | > > | | >I do not think in the simplest Home Network configuration the MR=20 > | | >may > | use > | | >a Home Address derived from the prefix assigned on its moving=20 > | | >network link, the MNP. In the simplest cases, the MR=20 > Home Address=20 > | | >is derived from the prefix valid on the Home Link. > | | > > | | >Or, section 4.1 Extended Home Network configuration has=20 > a last item > | | saying: > | | >>Alternatively, a Mobile Router could also form a Home=20 > Address from=20 > | | >>one of its prefixes and use it to register[...] > | | > > | | >I think this kind of item should belong to other more=20 > complex Home > | | Network > | | >configurations. > | | > > | | >Besides, I think that a useful informational document on=20 > the types=20 > | | >of > | | home > | | >networks should describe several such networks - in the order of=20 > | | >simplicity - starting first from the most simple and basic and > | obvious > | | and > | | >only later to the most exotic. > | | > > | | >Or, while the current document does describe three such networks, > | there > | | >does not seem to be an order from basic to complex. The first > | described > | | >is already "Extended" and the other two are "Aggregated" and=20 > | | >"Virtual". The "Aggregated" is a little more complex than the > | "Extended" > | | >in that the MR looks up its MNNs via ND on the Home=20 > Link, which is=20 > | | >a little exotic feature. The "Virtual" model is the=20 > most exotic in > | that > | | >there is no returning home procedure for example. > | | > > | | >So, I understand there is a form of scale on=20 > differentiation, from > | the > | | >most basic up to the most complex, but the most basic is still=20 > | | >called "Extended" and allows MR HoA from MNP. > | | > > | | >Hence my proposal to call the basic model just "Basic=20 > Home Network" > | and > | | >this model not to use MR Home Address from the MNP. =20 > Alternatively,=20 > | | >I propose to introduce a 4th model, called "Basic Home Network=20 > | | >Model", > | that > | | >would come before the other three models, and in which MR would=20 > | | >only construct its Home Address from the prefix on the=20 > home link,=20 > | | >that > | would > | | >perform ND for that address, that would implement the NEMO=20 > | | >Returning > | Home > | | >procedure and for which address the HA performs proxy ND when MR=20 > | | >not > | at > | | >home, according to Mobile IPv6. > | | > > | | >What do you think Pascal? What do the others think? > | | > > | | >Alex > | | > | | Dan Shell > | | Government Service Unit > | | CISCO Systems > | | IP mobility/Wireless/Satellite > | | 440 331 5663 >=20 From nemo-bounces@ietf.org Fri Jan 7 09:15:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16165 for ; Fri, 7 Jan 2005 09:15:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmurG-0005ny-BA; Fri, 07 Jan 2005 09:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmuoB-0004lw-9F for nemo@megatron.ietf.org; Fri, 07 Jan 2005 09:09:43 -0500 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 JAA15767 for ; Fri, 7 Jan 2005 09:09:41 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmv1B-0000Fr-53 for nemo@ietf.org; Fri, 07 Jan 2005 09:23:09 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 15:09:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 15:09:36 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F874@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0uzlD62KaIUeIRUWqNCrZlY1WewABb9ow From: "BINET David RD-CORE-CAE" To: "Alexandru Petrescu" , "Pascal Thubert \(pthubert\)" X-OriginalArrivalTime: 07 Jan 2005 14:09:37.0659 (UTC) FILETIME=[85AA74B0:01C4F4C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Comments in the text > -----Message d'origine----- > De : Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 > Envoy=E9 : vendredi 7 janvier 2005 14:17 > =C0 : Pascal Thubert (pthubert) > Cc : BINET David RD-CORE-CAE; Daniel Shell (dshell); nemo@ietf.org > Objet : Re: [nemo] RE: about the Home Network Models WG item >=20 > Pascal Thubert (pthubert) wrote: > > To my personal taste, it is natural to take the Home=20 > Address from the =20 > > Home Link in extended mode >=20 > I'm ok with this; but just don't call it "extended" IMHO,=20 > call it "normal basic". Or maybe "NEMO-extended MIP Home=20 > mode", but that's a bit clumsy. IMHO. >=20 > > and from the MNP in aggregated mode. >=20 > Pascal, the idea of having the HoA from MNP has an initial=20 > motivation different than building aggregated Home Networks. >=20 > In my understanding from verbal explanations, the idea of=20 > having HoA from MNP comes from ease of implementing a certain=20 > RO feature. That is not mentioned in the draft. >=20 > > But in both cases, the alternate is possible. >=20 > Let's get a feeling of why it is good to have a HoA from MNP,=20 > and not try to put HoA from MNP in all modes (simple,=20 > extended, aggregated, > virtual) just because it is possible to have it. I think I agree with this. I do not think that we have to describe all = the solutions in the document because it is tecchnically feasible. Even = if the configuration of HoA from MNP is possible in all modes, it can be = convenient to distinguish the different modes with some configuration = support. If several solutions are possible and useful, maybe it could be = good to give some reasons to implement one specific solution, according = to RO deployment or traffic load or whatever.=20 >=20 > > Specific support by the HA might be needed to enforce the related=20 > > policies, and that is not in the scope of basic. >=20 > Do we have an idea whether the NEMO Basic Support supports=20 > all modes described in the NEMO Home Network Models? >=20 > > Should we leave that to the products or is there something=20 > we should =20 > > standardize? >=20 > I think that if you know about a product that specifically=20 > supports (or plans to support) a certain Home Network Model=20 > then please mention it, it is very important. >=20 > When you're asking on whether there is something to be=20 > standardized. I think standard is better to have because=20 > inter-operability it facilitates. At the same time this=20 > draft being targeted as INFORMATIONAL, its scope is=20 > supposedly (1) to advice network deployers about how to do a=20 > Home Network that works with the NEMO Basic Support. > Or probably it aims to (2) describe existing deployments,=20 > positive experiences. Or probably it (3) gives just "seed"=20 > ideas about directions of thinking of what a potential Home=20 > Network _could_ look like with no engagement of actual=20 > implementation support, just providing new ideas for future=20 > protocol development. These are three different goals IMHO. =20 > But even so numerous be they, I do not think this draft=20 > proposes anything about inter-operability, standardization. >=20 > This is my understanding of the draft currently, but you may=20 > know better about the intent. >=20 > Alex David >=20 From nemo-bounces@ietf.org Fri Jan 7 09:26:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16656 for ; Fri, 7 Jan 2005 09:26:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmuxz-0008Vq-D8; Fri, 07 Jan 2005 09:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmusX-0006R0-Ma for nemo@megatron.ietf.org; Fri, 07 Jan 2005 09:14:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16145 for ; Fri, 7 Jan 2005 09:14:12 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmv5V-0000jr-Mi for nemo@ietf.org; Fri, 07 Jan 2005 09:27:40 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j07E3w9x029555; Fri, 7 Jan 2005 07:03:59 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id j07E3cNs030186; Fri, 7 Jan 2005 08:03:38 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3D2E988DFAB; Fri, 7 Jan 2005 15:03:56 +0100 (CET) Message-ID: <41DE96C6.6090401@motorola.com> Date: Fri, 07 Jan 2005 15:03:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: BINET David RD-CORE-CAE Subject: Re: [nemo] RE: about the Home Network Models WG item References: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F82C@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F82C@ftrdmel3.rd.francetelecom.fr> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF9B0D7EEB625AD08D3CDFA97" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9B0D7EEB625AD08D3CDFA97 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit BINET David RD-CORE-CAE wrote: > If there can be some interoperability issues, I think it has to be > specified. If two different modes (basic and extended) are described, > implementations will support one or both modes and there will not be > any problem with different extended implementations, with regard to > HoA configuration. Yes, that is true. If there is any interoperability issue between various Home Network models then it has to be specified. Specifically, one needs to have different vendors' HAs and MRs that interoperate. Otherwise, I just wanted to point out my summarizing thoughts: -there is no relation between NEMO "explicit/implicit" modes and the NEMO Home Network Models "basic/extended". -there is no relation between NEMO Basic Support and the NEMO "extended" support of Route Optimization. -NEMO Basic Support does support a _very_ wide range of home network deployments, not all described in the NEMO Home Network Models draft. Just take _any_ deployment of fixed networks, graph, tree, whatever, with prefixes already assigned, upgrade the router that you want to move, put a HA box next to it and it all works. This includes deployments in which the prefixes are deployed in a hierarchical manner, aggregated or non-hierarchical, or non-aggregated. In all these networks no need of HoA from MNP in order to be supported. With respect to the NEMO Home Network models, I'm ok if there is an initial 0th section that is "basic", ressembles to the current "extended" description but does not use HoA from MNP. If this model gets enough support then should be done. Alex --------------enigF9B0D7EEB625AD08D3CDFA97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3pbMMmC0w56zj54RAiFLAKCc3UQWmIeZQVUPbhNgSKckPSk0gwCfTWsr SjoQoZN95mp5mfxVnss74As= =D180 -----END PGP SIGNATURE----- --------------enigF9B0D7EEB625AD08D3CDFA97-- From nemo-bounces@ietf.org Fri Jan 7 10:59:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22761 for ; Fri, 7 Jan 2005 10:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwQv-00081Z-Mh; Fri, 07 Jan 2005 10:53:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwPs-0007d4-A6 for nemo@megatron.ietf.org; Fri, 07 Jan 2005 10:52:44 -0500 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 KAA22337 for ; Fri, 7 Jan 2005 10:52:42 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmwcq-0000hd-3z for nemo@ietf.org; Fri, 07 Jan 2005 11:06:11 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 17:07:24 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07Fq1WA006884; Fri, 7 Jan 2005 16:52:06 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Jan 2005 16:52:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 16:52:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689D48@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0u0DA2jLXhqt7ShWcfKAe9jswygAAHk6A From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 15:52:06.0742 (UTC) FILETIME=[D6CE0F60:01C4F4D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Friday, January 07, 2005 2:17 PM | To: Pascal Thubert (pthubert) | Cc: BINET David RD-CORE-CAE; Daniel Shell (dshell); nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | > To my personal taste, it is natural to take the Home Address from the | > Home Link in extended mode |=20 | I'm ok with this; but just don't call it "extended" IMHO, call it | "normal basic". Or maybe "NEMO-extended MIP Home mode", but that's a | bit clumsy. IMHO. The problem is that your proposal would duplicate all the extended Home text, but the part that describe taking HoA from MNP. From a editorial standpoint, it's a bit clumsy. |=20 | > and from the MNP in aggregated mode. |=20 | Pascal, the idea of having the HoA from MNP has an initial motivation | different than building aggregated Home Networks. |=20 | In my understanding from verbal explanations, the idea of having HoA | from MNP comes from ease of implementing a certain RO feature. That is | not mentioned in the draft. |=20 | > But in both cases, the alternate is possible. |=20 | Let's get a feeling of why it is good to have a HoA from MNP, and not | try to put HoA from MNP in all modes (simple, extended, aggregated, | virtual) just because it is possible to have it. |=20 | > Specific support by the HA might be needed to enforce the related | > policies, and that is not in the scope of basic. |=20 | Do we have an idea whether the NEMO Basic Support supports all modes | described in the NEMO Home Network Models? This is a good question. Applies to MR as well. The capability for MR to switch to bridge mode in aggregated might not be there. The capability for a MR to start/stop the IGP when at home might also be missing. Enforcing policies is nice to have and things might appear to be working without that feature. You definitely need a specific support on HA to define Home in extended mode if you want the HoA from the MNP. By default, HoA os from the prefixes on the Home Link. =20 | > Should we leave that to the products or is there something we should | > standardize? |=20 | I think that if you know about a product that specifically supports (or | plans to support) a certain Home Network Model then please mention it, | it is very important. |=20 | When you're asking on whether there is something to be standardized. I | think standard is better to have because inter-operability it | facilitates. At the same time this draft being targeted as | INFORMATIONAL, its scope is supposedly (1) to advice network deployers | about how to do a Home Network that works with the NEMO Basic Support. | Or probably it aims to (2) describe existing deployments, positive | experiences. Or probably it (3) gives just "seed" ideas about | directions of thinking of what a potential Home Network _could_ look | like with no engagement of actual implementation support, just providing | new ideas for future protocol development. These are three different | goals IMHO. But even so numerous be they, I do not think this draft | proposes anything about inter-operability, standardization. |=20 | This is my understanding of the draft currently, but you may know better | about the intent. Looks fine to me :) Pascal From nemo-bounces@ietf.org Fri Jan 7 11:00:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22842 for ; Fri, 7 Jan 2005 11:00:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwQw-00081f-3F; Fri, 07 Jan 2005 10:53:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwPs-0007d7-S8 for nemo@megatron.ietf.org; Fri, 07 Jan 2005 10:52:44 -0500 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 KAA22340 for ; Fri, 7 Jan 2005 10:52:42 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmwcs-0000hf-Om for nemo@ietf.org; Fri, 07 Jan 2005 11:06:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 17:07:27 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07Fq3WC006895; Fri, 7 Jan 2005 16:52:09 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 16:52:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 16:52:04 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689D4A@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0vm/R2aJz0l7NSl+EPn71gIL6xQAC2AaA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 15:52:03.0763 (UTC) FILETIME=[D5078030:01C4F4D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Friday, January 07, 2005 2:35 PM | To: Pascal Thubert (pthubert) | Cc: nemo | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | > | Pascal Thubert (pthubert) wrote: | > | > The HoA from MNP is orthogonal, could be done in all modes | > | | > | HoA from MNP may be "orthogonal" to all modes, but can not be done in | > | all modes. An LFN on the Home Link can not talk to a neighbour MR | > | that | > | is away from home if that MR has HoA from MNP, because HA can not do | > | proxy ND for a HoA that is not on the Home Link. So, to me, there | > | exist | > | a simple basic mode in which HoA is not from MNP. | > | | > | > The HA would need to proxy ND the whole prefix. Not only to ping the | > MR, but also any MNN. In the draft: " Thus, the Home Agent MUST | > intercept all the packets to the MNNs on the registered prefixes. In | > order to do so, the Home Agent might perform ND proxying for all | > addresses in all registered Mobile Network Prefixes, and protect the | > MNP space from autoconfiguration by uncontrolled visitors on the Home | > Link. " |=20 | A-ha! So without the HA proxying all addresses in all MNPs in its BC | the "HoA from MNP" can not work. =20 Think again: It's not the HoA from MNP that does not work without the proxying. It is the support of coming Home in the Aggregated Home Network Model. Think of the communication between a node at Home and a MNN. Pascal=20 From nemo-bounces@ietf.org Fri Jan 7 11:32:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24983 for ; Fri, 7 Jan 2005 11:32:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmwo9-0000nC-LZ; Fri, 07 Jan 2005 11:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmwmq-0000Ic-Hh for nemo@megatron.ietf.org; Fri, 07 Jan 2005 11:16:28 -0500 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 LAA23639 for ; Fri, 7 Jan 2005 11:16:26 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmwzp-0002cI-Tr for nemo@ietf.org; Fri, 07 Jan 2005 11:29:56 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j07GGZvM020478; Fri, 7 Jan 2005 09:16:35 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id j07GAqNs013225; Fri, 7 Jan 2005 10:10:53 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DC69188DFAB; Fri, 7 Jan 2005 17:11:10 +0100 (CET) Message-ID: <41DEB499.1050502@motorola.com> Date: Fri, 07 Jan 2005 17:11:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689D4A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689D4A@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0F1BC43A68CE042B0987A73" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0F1BC43A68CE042B0987A73 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > | A-ha! So without the HA proxying all addresses in all MNPs in its > BC | the "HoA from MNP" can not work. > > Think again: > > It's not the HoA from MNP that does not work without the proxying. Right, it's not the HoA from the MNP that does not work without the proxying, it is the entire "HoA from the MNP" scenario that does not work. > It is the support of coming Home in the Aggregated Home Network > Model. Not only the coming home in the Aggregated Home Network Model. Many other things don't work when using HoA from MNP. So I was looking to find out what are the advantages of using the HoA from MNP. Alex --------------enigD0F1BC43A68CE042B0987A73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3rSeMmC0w56zj54RAjTFAJ92Cwb6Wp9Ac6X+C/N30WOUXfs5pgCfXdw0 WTY/1B62OZggOyAWBlrw3aM= =bNJ1 -----END PGP SIGNATURE----- --------------enigD0F1BC43A68CE042B0987A73-- From nemo-bounces@ietf.org Fri Jan 7 11:46:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26315 for ; Fri, 7 Jan 2005 11:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmx3n-0006D3-4k; Fri, 07 Jan 2005 11:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwuI-0002uN-Mr for nemo@megatron.ietf.org; Fri, 07 Jan 2005 11:24:10 -0500 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 LAA24262 for ; Fri, 7 Jan 2005 11:24:08 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmx7G-0003KQ-P8 for nemo@ietf.org; Fri, 07 Jan 2005 11:37:38 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 17:38:51 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xfb-ams-331.cisco.com (xfb-ams-331.cisco.com [144.254.231.70]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07GNIWK015614; Fri, 7 Jan 2005 17:23:33 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xfb-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 17:23:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 17:23:08 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689D7A@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT01D1+E0YPVYTxTS2lmqDhAtcNPQAACQQQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 16:23:15.0953 (UTC) FILETIME=[30F10610:01C4F4D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Friday, January 07, 2005 5:11 PM | To: Pascal Thubert (pthubert) | Cc: nemo | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: |=20 | > | A-ha! So without the HA proxying all addresses in all MNPs in its | > BC | the "HoA from MNP" can not work. | > | > Think again: | > | > It's not the HoA from MNP that does not work without the proxying. |=20 | Right, it's not the HoA from the MNP that does not work without the | proxying, it is the entire "HoA from the MNP" scenario that does not work. |=20 | > It is the support of coming Home in the Aggregated Home Network | > Model. |=20 | Not only the coming home in the Aggregated Home Network Model. Many | other things don't work when using HoA from MNP. So I was looking to | find out what are the advantages of using the HoA from MNP. |=20 Alex: I have a feeling that you do not like taking the HoA from MNP; but please do not confuse people on this list with wrong assertions. The problem we are discussing here is in the case of aggregated, a node on the home link that pings an address on a NEMO that is not at Home. So the HA has to proxy as mentioned in the draft for the ping to work.=20 This is not due to whether the MR HoA is taken from the MNP or the rest of aggregation. The problem comes from the fact that everyone on the link thinks that the aggregation is on the link. That's the definition of the model. Pascal=20 From nemo-bounces@ietf.org Fri Jan 7 12:04:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28318 for ; Fri, 7 Jan 2005 12:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxO6-0004Vh-TP; Fri, 07 Jan 2005 11:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxJK-0002xK-QC for nemo@megatron.ietf.org; Fri, 07 Jan 2005 11:50:02 -0500 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 LAA26783 for ; Fri, 7 Jan 2005 11:50:00 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmxWM-0005ZL-3s for nemo@ietf.org; Fri, 07 Jan 2005 12:03:30 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2005 18:04:46 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j07GmhWa022939; Fri, 7 Jan 2005 17:49:27 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 17:49:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 17:49:25 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC689D8B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAAAKyl8AAJLzXwAAXqPMA= From: "Pascal Thubert \(pthubert\)" To: "BINET David RD-CORE-CAE" , "Daniel Shell \(dshell\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 16:49:16.0410 (UTC) FILETIME=[D30BDDA0:01C4F4D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 | > De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] | > Envoy=E9 : vendredi 7 janvier 2005 10:25 | > =C0 : BINET David RD-CORE-CAE; Daniel Shell (dshell); Alexandru = Petrescu | > Cc : nemo@ietf.org | > Objet : RE: [nemo] RE: about the Home Network Models WG item | > | > I agree with you on the virtual case. | > | > On the aggregated case, we could by construction reserve some | > address space in the aggregation that we would not dedicate | > to any MNP, and, again by construction, we could enforce that | > the MR HoA be taken from that reserved space. This would | > allow a real DAD process by the Home Agent, but it seems a | > bit unnatural to my taste. Can/should we word that something | > looks more natural then something else? That requires a | > consensus in the WG. | If you have a reserved address space in the aggregated home network, = it | looks like a specific prefix for home network and this solution is = quite | equivalent to extended mode.=20 I would agree with that.=20 | In the aggregated mode, MR HoA can be | configured from any MNP and there is no mean, a priori, to enforce = some | HoA configuration. I'm not sure I get what you mean here?=20 NEMO basic says " =20 A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. =20 " But NEMO does not enforce any checking for this. I guess it's up to = implementations. The NEMO words are open enough to allow both extended = and aggregated modes. | > | > To my personal taste, it is natural to take the Home Address | > from the Home Link in extended mode and from the MNP in | > aggregated mode. But in both cases, the alternate is | > possible. Specific support by the HA might be needed to | > enforce the related policies, and that is not in the scope of | > basic. Should we leave that to the products or is there | > something we should standardize? | If there can be some interoperability issues, I think it has to be | specified. If two different modes (basic and extended) are described, | implementations will support one or both modes and there will not be = any | problem with different extended implementations, with regard to HoA | configuration. | > Agreed. I think it's more like some variations of the modes might not = operate equivalently with all implementations. Like a HA might do = checkings and another one might not. Or a MR might support bridging for = aggregated mode or not. But I do not see any identified MR-HA = interoperation problem. If someone did please raise your hand. Pascal From nemo-bounces@ietf.org Fri Jan 7 12:21:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29175 for ; Fri, 7 Jan 2005 12:21:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxZe-00014o-0x; Fri, 07 Jan 2005 12:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmxSu-0006kr-12 for nemo@megatron.ietf.org; Fri, 07 Jan 2005 11:59:56 -0500 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 LAA28013 for ; Fri, 7 Jan 2005 11:59:53 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmxfq-0006LR-Ja for nemo@ietf.org; Fri, 07 Jan 2005 12:13:23 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j07H1cJD011185; Fri, 7 Jan 2005 10:01:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j07GwQ9v009432; Fri, 7 Jan 2005 10:58:27 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 92F4888DFAB; Fri, 7 Jan 2005 17:59:46 +0100 (CET) Message-ID: <41DEBFFD.8060704@motorola.com> Date: Fri, 07 Jan 2005 17:59:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689D7A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689D7A@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E16257F8B0DC64A660967EE" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E16257F8B0DC64A660967EE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I have a feeling that you do not like taking the HoA from MNP; but > please do not confuse people on this list with wrong assertions. Sorry I don't mean to confuse anyone. I think I'll refrain posting on this subject because it seems I'm confusing people. > The problem we are discussing here is in the case of aggregated, a node > on the home link that pings an address on a NEMO that is not at Home. So > the HA has to proxy as mentioned in the draft for the ping to work. Right, I was not discussing the case of aggregated. I was discussing the simple basic mode, the one before "extended", the one that does not use the HoA from MNP. > This is not due to whether the MR HoA is taken from the MNP or the rest > of aggregation. The problem comes from the fact that everyone on the > link thinks that the aggregation is on the link. This is another topic. I wanted to discuss about it later. For the moment my only proposal is to have a simple basic mode that does not use the HoA from MNP. For the topic where everyone on the link thinks that the entire aggregation is on the link: is the MR still a router, or just a sort of bridge? Alex --------------enig1E16257F8B0DC64A660967EE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFB3sACMmC0w56zj54RAtasAJ9e9J9AmjSMwq1ASXq0ai3mYo6ICACYpBFE LOKv9jNbYQv2Hp6ywQin+w== =Bdmu -----END PGP SIGNATURE----- --------------enig1E16257F8B0DC64A660967EE-- From nemo-bounces@ietf.org Fri Jan 7 12:52:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01670 for ; Fri, 7 Jan 2005 12:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmyFg-00018E-NR; Fri, 07 Jan 2005 12:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmyBG-0008DA-5n for nemo@megatron.ietf.org; Fri, 07 Jan 2005 12:45:46 -0500 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 MAA01214 for ; Fri, 7 Jan 2005 12:45:43 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmyOE-0001Yp-Mb for nemo@ietf.org; Fri, 07 Jan 2005 12:59:13 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j07HlTJD029630; Fri, 7 Jan 2005 10:47:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id j07Hjc61008112; Fri, 7 Jan 2005 11:45:38 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CC67D88DFAB; Fri, 7 Jan 2005 18:45:37 +0100 (CET) Message-ID: <41DECABC.5000906@motorola.com> Date: Fri, 07 Jan 2005 18:45:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC689D48@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC689D48@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3C8794ADDFB49D874BCC08E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3C8794ADDFB49D874BCC08E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The problem is that your proposal would duplicate all the extended > Home text, but the part that describe taking HoA from MNP. From a > editorial standpoint, it's a bit clumsy. I don't see anything clumsy in removing the last item "HoA from MNP" and substituting the word "basic" for the word "extended". It's quick. > | Do we have an idea whether the NEMO Basic Support supports all > modes | described in the NEMO Home Network Models? This is a good > question. Applies to MR as well. The capability for MR to switch to > bridge mode in aggregated might not be there. A router switching to bridge mode? Can you be more specific on how could a router become a bridge and why would it do it? > The capability for a MR to start/stop the IGP when at home might also > be missing. Yes, it is missing, which is yet another topic. Alex --------------enigF3C8794ADDFB49D874BCC08E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB3srBMmC0w56zj54RAkRTAJ0d3SwrA5xM8PORG7hhz7vuwplQlACdHXRs sONvjs4nVohx5WcJqwN617A= =sNOZ -----END PGP SIGNATURE----- --------------enigF3C8794ADDFB49D874BCC08E-- From nemo-bounces@ietf.org Sun Jan 9 23:50:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02939 for ; Sun, 9 Jan 2005 23:50:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnrT7-00046o-Da; Sun, 09 Jan 2005 23:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnrQa-0003v2-IU for nemo@megatron.ietf.org; Sun, 09 Jan 2005 23:45:16 -0500 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 XAA02760 for ; Sun, 9 Jan 2005 23:45:14 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnre3-0007GJ-Mz for nemo@ietf.org; Sun, 09 Jan 2005 23:59:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0A5GE725997; Sun, 9 Jan 2005 21:16:14 -0800 X-mProtect: <200501100516> Nokia Silicon Valley Messaging Protection Received: from danira-pool05416.americas.nokia.com (10.241.54.16, claiming to be "[10.241.54.16]") by darkstar.iprg.nokia.com smtpdMZQ8Sb; Sun, 09 Jan 2005 21:16:13 PST Message-ID: <41E20823.7090507@iprg.nokia.com> Date: Sun, 09 Jan 2005 20:44:19 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <41DC2ABC.1080504@motorola.com> In-Reply-To: <41DC2ABC.1080504@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I have to disagree. this draft is primariy about Home Network Configuration. in every model (extended, aggregated and virtual), the Mobile Router is free to configure a HoA from the MNP at any time and use that for Home Registration. there is no way a Home Agent can force the Mobile Router to only use a HoA from the home link. lets assume a particular home link as configured as a "Basic Home Link" (as described by Alex below). if the MR chooses to configure a HoA from the MNP, the HA can't prevent it. and I dont think we need to provide a way for the HA to prevent it. I dont see the need for a "Basic Home Link" model. Vijay Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > [...] > >> please present on this list at this time, and if you get enough >> support, I'll do the changes as required. > > > I do not think in the simplest Home Network configuration the MR may use > a Home Address derived from the prefix assigned on its moving network > link, the MNP. In the simplest cases, the MR Home Address is derived > from the prefix valid on the Home Link. > > Or, section 4.1 Extended Home Network configuration has a last item saying: > >> Alternatively, a Mobile Router could also form a Home Address from >> one of its prefixes and use it to register[...] > > > I think this kind of item should belong to other more complex Home > Network configurations. > > Besides, I think that a useful informational document on the types of > home networks should describe several such networks - in the order of > simplicity - starting first from the most simple and basic and obvious > and only later to the most exotic. > > Or, while the current document does describe three such networks, there > does not seem to be an order from basic to complex. The first described > is already "Extended" and the other two are "Aggregated" and "Virtual". > The "Aggregated" is a little more complex than the "Extended" in that > the MR looks up its MNNs via ND on the Home Link, which is a little > exotic feature. The "Virtual" model is the most exotic in that there is > no returning home procedure for example. > > So, I understand there is a form of scale on differentiation, from the > most basic up to the most complex, but the most basic is still called > "Extended" and allows MR HoA from MNP. > > Hence my proposal to call the basic model just "Basic Home Network" and > this model not to use MR Home Address from the MNP. Alternatively, I > propose to introduce a 4th model, called "Basic Home Network Model", > that would come before the other three models, and in which MR would > only construct its Home Address from the prefix on the home link, that > would perform ND for that address, that would implement the NEMO > Returning Home procedure and for which address the HA performs proxy ND > when MR not at home, according to Mobile IPv6. > > What do you think Pascal? What do the others think? > > Alex > From nemo-bounces@ietf.org Mon Jan 10 06:28:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10136 for ; Mon, 10 Jan 2005 06:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnxdH-0002pb-Jr; Mon, 10 Jan 2005 06:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnxXR-0000vo-5s for nemo@megatron.ietf.org; Mon, 10 Jan 2005 06:16:45 -0500 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 GAA09181 for ; Mon, 10 Jan 2005 06:16:42 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cnxkz-0004Ai-0y for nemo@ietf.org; Mon, 10 Jan 2005 06:30:48 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j0ABJnGZ029609; Mon, 10 Jan 2005 04:19:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id j0ABDeea027986; Mon, 10 Jan 2005 05:13:40 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7173A8659B4; Mon, 10 Jan 2005 12:16:35 +0100 (CET) Message-ID: <41E2640E.20804@motorola.com> Date: Mon, 10 Jan 2005 12:16:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <41DC2ABC.1080504@motorola.com> <41E20823.7090507@iprg.nokia.com> In-Reply-To: <41E20823.7090507@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF9FDC65D7876BC95BE1AAF5F" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9FDC65D7876BC95BE1AAF5F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > if the MR chooses to configure a HoA from the MNP, the HA can't > prevent it. and I dont think we need to provide a way for the HA to > prevent it. Vijay, true HA can't prevent MR do whatever it wants with its addresses. But in order for HA to do proxy-ND for Home Address that Home Address must be valid on the Home Link. If it's from MNP then it's not valid on the Home Link. Alex --------------enigF9FDC65D7876BC95BE1AAF5F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB4mQTMmC0w56zj54RAtMjAKCmYqfRg261InefiAo+vhzC4JhFEgCgn/4N Bu4astteVIvYmIs3GjwA9RQ= =bfxu -----END PGP SIGNATURE----- --------------enigF9FDC65D7876BC95BE1AAF5F-- From nemo-bounces@ietf.org Mon Jan 10 07:52:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15086 for ; Mon, 10 Jan 2005 07:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnz0k-0006pl-FC; Mon, 10 Jan 2005 07:51:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnyyq-0006Qh-VR for nemo@megatron.ietf.org; Mon, 10 Jan 2005 07:49:09 -0500 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 HAA14881 for ; Mon, 10 Jan 2005 07:49:07 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnzCP-0007b2-B6 for nemo@ietf.org; Mon, 10 Jan 2005 08:03:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 14:04:39 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0ACmDWK024380; Mon, 10 Jan 2005 13:48:28 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 13:48:25 +0100 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 Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Mon, 10 Jan 2005 13:47:28 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF261@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT04LwdPhtRdDi9TNizSeR9HsbMcwCMXTbw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Jan 2005 12:48:25.0741 (UTC) FILETIME=[AD0403D0:01C4F712] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | > | Do we have an idea whether the NEMO Basic Support supports all | > modes | described in the NEMO Home Network Models? This is a good | > question. Applies to MR as well. The capability for MR to switch to | > bridge mode in aggregated might not be there. |=20 | A router switching to bridge mode? Can you be more specific on how | could a router become a bridge and why would it do it? Alex, sometimes I wonder how deeply you read the draft. This is all written down, and I would agree that it is not obvious to understand anyway, but I'm surprised that you do not know about it at all. Please let us know if it is unclear. Pascal From nemo-bounces@ietf.org Mon Jan 10 08:00:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15483 for ; Mon, 10 Jan 2005 08:00:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnz0k-0006ps-R1; Mon, 10 Jan 2005 07:51:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnyyr-0006Qi-1g for nemo@megatron.ietf.org; Mon, 10 Jan 2005 07:49:09 -0500 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 HAA14884 for ; Mon, 10 Jan 2005 07:49:07 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnzCP-0007b3-I7 for nemo@ietf.org; Mon, 10 Jan 2005 08:03:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 14:04:42 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0ACmDWM024380; Mon, 10 Jan 2005 13:48:30 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 13:48:25 +0100 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 Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Mon, 10 Jan 2005 13:48:21 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF262@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT2zxN9RbU76ur4RhGHv8zwyaao9gAQ3l1Q From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Alexandru Petrescu" X-OriginalArrivalTime: 10 Jan 2005 12:48:25.0897 (UTC) FILETIME=[AD1BD190:01C4F712] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'm writing some text that I'll propose on the ML based on all these suggestions. Thank you all :) Pascal | -----Original Message----- | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] | Sent: Monday, January 10, 2005 5:44 AM | To: Alexandru Petrescu | Cc: Pascal Thubert (pthubert); nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | I have to disagree. this draft is primariy about Home Network | Configuration. in every model (extended, aggregated and virtual), | the Mobile Router is free to configure a HoA from the MNP at | any time and use that for Home Registration. there is no way a | Home Agent can force the Mobile Router to only use a HoA from | the home link. lets assume a particular home link as configured | as a "Basic Home Link" (as described by Alex below). if the MR | chooses to configure a HoA from the MNP, the HA can't prevent | it. and I dont think we need to provide a way for the HA to | prevent it. |=20 | I dont see the need for a "Basic Home Link" model. |=20 | Vijay |=20 | Alexandru Petrescu wrote: | > Pascal Thubert (pthubert) wrote: | > [...] | > | >> please present on this list at this time, and if you get enough | >> support, I'll do the changes as required. | > | > | > I do not think in the simplest Home Network configuration the MR may use | > a Home Address derived from the prefix assigned on its moving network | > link, the MNP. In the simplest cases, the MR Home Address is derived | > from the prefix valid on the Home Link. | > | > Or, section 4.1 Extended Home Network configuration has a last item | saying: | > | >> Alternatively, a Mobile Router could also form a Home Address from | >> one of its prefixes and use it to register[...] | > | > | > I think this kind of item should belong to other more complex Home | > Network configurations. | > | > Besides, I think that a useful informational document on the types of | > home networks should describe several such networks - in the order of | > simplicity - starting first from the most simple and basic and obvious | > and only later to the most exotic. | > | > Or, while the current document does describe three such networks, there | > does not seem to be an order from basic to complex. The first described | > is already "Extended" and the other two are "Aggregated" and "Virtual". | > The "Aggregated" is a little more complex than the "Extended" in that | > the MR looks up its MNNs via ND on the Home Link, which is a little | > exotic feature. The "Virtual" model is the most exotic in that there is | > no returning home procedure for example. | > | > So, I understand there is a form of scale on differentiation, from the | > most basic up to the most complex, but the most basic is still called | > "Extended" and allows MR HoA from MNP. | > | > Hence my proposal to call the basic model just "Basic Home Network" and | > this model not to use MR Home Address from the MNP. Alternatively, I | > propose to introduce a 4th model, called "Basic Home Network Model", | > that would come before the other three models, and in which MR would | > only construct its Home Address from the prefix on the home link, that | > would perform ND for that address, that would implement the NEMO | > Returning Home procedure and for which address the HA performs proxy ND | > when MR not at home, according to Mobile IPv6. | > | > What do you think Pascal? What do the others think? | > | > Alex | > From nemo-bounces@ietf.org Mon Jan 10 10:17:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24935 for ; Mon, 10 Jan 2005 10:17:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1Bu-0006Sm-6C; Mon, 10 Jan 2005 10:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1BW-0006Ix-E6 for nemo@megatron.ietf.org; Mon, 10 Jan 2005 10:10:22 -0500 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 KAA24105 for ; Mon, 10 Jan 2005 10:10:20 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1P4-0004Jo-5U for nemo@ietf.org; Mon, 10 Jan 2005 10:24:27 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 16:25:52 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0AF9IWO005247 for ; Mon, 10 Jan 2005 16:09:39 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 Jan 2005 16:09:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2005 16:09:26 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> Thread-Topic: issue 2 diffs Thread-Index: AcT3JmAgOzU8BVoBTR+VsMcb43rDbA== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 10 Jan 2005 15:09:33.0004 (UTC) FILETIME=[63E5D0C0:01C4F726] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 Content-Transfer-Encoding: quoted-printable Subject: [nemo] issue 2 diffs X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: Here are the proposed diff for issue 2.=20 I created a new section prior to extended with MIP reminders to help explain the difference later. Then I added a new section in extended and aggregated to place the deployment caveats as suggested by David. I followed Alex recommendation and presented that the most natural way in extended in a Home Address from the Home Link Prefix and in aggregated, from the MNP.=20 Maybe it's easier for you to check the WIP for 02 at: http://mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models- xx.html Please let me know your comments on the proposed changes :) Issue 2 diffs: -------------- --- draft-ietf-nemo-home-network-models-xx.xml0 2005-01-10 10:09:39.554767700 +0100 +++ draft-ietf-nemo-home-network-models-xx.xml 2005-01-10 15:56:55.912533300 +0100 @@ -68,17 +68,23 @@ Home Network. How the two concepts relate in a given deployment depend on the organization of the Home Network, as described below. =20 - Four different organizations of the Home Network including + + + Five different organizations of the Home Network including a hierarchical construction are documented: - + + A short reminder of what the Home Network is with Mobile IP, in order + to help the reader figure out the evolution towards NEMO. + + In this disposition, the Home Network is only 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. More in . - + In this disposition, the Home Network actually overlaps with the Mobile Networks. When at Home, a Mobile Router acts as=20 a bridge between the Home Link and the Mobile Networks. More @@ -89,7 +95,7 @@ Mobile Routers to come back Home to. More in . - + In this disposition, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a=20 @@ -244,15 +250,42 @@ -
+
+ + + With Mobile IPv6 (MIP6) = specification +Mobile Nodes are at Home when they are connected to their Home Link, where they +recognize their Home Prefix in Router Advertisement messages. +Also, a binding is checked using of Duplicate Address Detection on the Home Link, +and Home Agents discover each other by means of Neighbor Discovery extensions over +that link. + +The Home Prefix, that is advertized on the Home Link, is a final prefix, as opposed to +an aggregation, and it may be used by hosts on the Home Link for autoconfiguration +purposes. + + +As we see, the concept of a Home Network for Mobile IPv6 is really a prefix on a link, +served by one or more Home Agents as opposed to a routed mesh. +We will see in the next sections that NEMO needs additional prefixes for use +by the Mobile Networks. For that reason, NEMO extends the concept of +Home Network into a more complex, aggregated structure. + + +
+ + + + + +
=20 - One simple approach is to reserve one or several subnets from an - aggregation - for the Home Link, and to use the other subnets as MNPs. - In that case, the Home Network and the Mobile Networks do not overlap. - The aggregation is called an Extended Home Network - and depicted in . +One simple way of extending the MIP Home Network is to use additional prefixes, +contiguous to the Home Link Prefix inherited from MIPv6, as Mobile Network Prefixes. +As this model trivially extends the MIP Home Network, the resulting +aggregation is called a NEMO Extended Home Network. +It is depicted in . =20
- The Mobile Routers are assigned individually a Home Address from the=20 - Home Network and use is to register their MNP(es).=20 - In that case, the Home Agent performs - DAD in the Home Network as prescribed by=20 - Mobile IPv6 for the Home Addresses. - - Alternatively, a Mobile Router could also form a Home Address from one - of its prefixes and use it to register, performing its own DAD on its - ingress network. + Since the Extended Home Network operations inherit trivially from MIPv6, + it can be seen as natural that the Mobile Routers be assigned their Home Addresses + from the prefix on the Home Link, as opposed to their own MNP, which is allowed + by the NEMO specification. + In that case, a Home Agent can perform DAD on the Home Link + as prescribed by Mobile IPv6 for the Mobile Router Home Addresses. =20 @@ -312,54 +342,87 @@ A Mobile Router returns Home by connecting directly to the Home Link, and dropping the MRHA tunnel. =20 - If the Home Address of the Mobile Router is derived from one of its Mobile - Network Prefixes, 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, so there is an need to configure - the range for the extended Home Network in order to validate the Home Address - It might seem more natural to take the Home Address from the prefix on the Home Link, - and operate as MIP does on that link, including DAD operations. - - When at home, the Mobile Router ensures the connectivity of the=20 + When at home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations. =20 In implicit mode, the HA has the necessary information to continue routing to the MNPs in the absence of registration, and the participation of the MR to the Home IGP is not required. =20 - But explicit mode, or if the MR uses an IGP over the MRHA tunnel, - then it must resume its IGP operations on - the Home Link in order to advertise its Mobile Networks. + But in explicit mode, or if the MR uses an IGP over the MRHA tunnel, + then it must resume its IGP operations on the Home Link in order to advertise + its Mobile Networks. =20 Alternate procedures for ensuring the connectivity of the Mobile Networks when at home are described in .
=20 + +
+
+ + We saw that a natural extension of the MIP procedure is to derive the Home + Address of a Mobile Router from the prefix on the Home Link. Alternatively, NEMO + basic supports allows that a Mobile Router forms its Home Address from one of its + Mobile Network Prefixes. + + + In that case, 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 at Home, as opposed to matching + the prefix on the Home Link with that of its Home Address. + + Also, the MR is responsible for performing its own DAD on its + ingress network, and this has a few consequences on the behavior of the Home Agent + + + So, if the Home Address does not match the Home Prefix, then there is a need to + configure the support for the extended Home Network and the range of the + aggregation on the HA. + Based on that new configuration, the HA can accept a Home Address that is not from + the Home Link, and it knows that it should not perform any DAD. But + if an implementation is simply derived from that of MIP, then this capability + might not exist, and the HA will not be able to accept a Home Address based on + the MNP. + +
+ +
+ In explicit mode, a specific support on the MR is required to control + the IGP operation depending on whether a MR is at Home or not. This support + might not be present in all implementations. + +
+
+
The extended Home Network keeps the MIP6 concept of a Home Network for both Mobile Nodes and Mobile Routers to take their Home Address from. Since there is no overlap between the prefixes that are affected to MNPs and prefix(es) that are dedicated to the Home Link, it is possible for MNs and MRs to coexist with that -model.=20 - =20 -=09 -
+model. + + Also, when the Home Address is derived from the prefix on the Home Link, the +HA behavior on the link trivially extends that of MIP and the support should for that +configuration should be available with all implementations. + =20 =20
+
-
+
=20 One other approach is to consider that the Aggregation of all the - MNPs is used plainly as the Home Network, referred to as - the Aggregated Home Network. This means that the Mobile Aggregated + MNPs is used plainly as the Home Link Prefix. In this model, the + Home Network is referred to as a NEMO + 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, as depicted in . =20 @@ -383,23 +446,17 @@ =20 ]]> + In that model, it seems natural to subnet the whole range of addresses into + Mobile Network prefixes, as opposed to reserving one prefix for the Home Link, + which would boil down to the Extended Home Network model. If the prefix on the Home + Link is really an aggregation and not a final prefix, it should not be allowed for + autoconfiguration or Home Address allocation. =20 - A node on the Home Link computes that the Aggregated Home Network - is actually a subnet on the Home Link and may use the prefix on the Home Link to - autoconfigure a Home Address. - 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 - MNP, it will lookup all MNNs using Neighbor Discovery - over the Home Link. - - Thus, the Home Agent MUST intercept all the packets to the MNNs - on the registered prefixes. In order to do so, the Home Agent might - perform ND proxying for all addresses in all registered Mobile Network - Prefixes, and protect the MNP space from autoconfiguration - by uncontrolled visitors on the Home Link. - Alternatives based on a routing protocol or ICMP redirect may apply - in some cases. + Note that in that case, it makes sense + for a Mobile Router to register using a Home Address from + one of its own MNPs. Taking the Home Address from its own range guarantees + the unicity of the suffix. That unicity can be checked by the MR on its + ingress network using DAD. =20 =20
@@ -411,27 +468,14 @@ Home Network over the Home Link. =20 A Mobile Router returns Home - by connecting directly to the Home Link, and dropping the MRHA - tunnel. + 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. =20 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 MNPs, - but that the Home Address matches the Home Network Prefix. + its MNPs, but that the Home Address still matches the Home Network Prefix. =20 - Also, Note that in that case, it makes sense - for a Mobile Router to register using a Home Address from - one of its own MNPs. Taking the Home Address from its own range guarantees - the unicity of the suffix. That unicity can be checked by the MR on its - ingress network using DAD. - - Finally, note that NEMO basic support does not check for the unicity of a - registered prefix the way MIPv6 checks for the unicity of a Home Address. - It is thus possible for 2 different MRs to register the same prefix with - different Home Addresses, and this will cause an undetected problem if the - corresponding ingress links are not connected. =20
A Mobile Router coming Home via its egress interface @@ -493,6 +537,7 @@
=20
+
With this model, there is no specific space for independent nodes as any address in the aggregation belongs to a MNP, and thus to a Mobile Router. @@ -506,9 +551,63 @@ if returning Home is required.
+ +
+ +
+ A node on the Home Link discovers that the Aggregated Home Network + is actually a subnet on the Home Link and may use the prefix on the Home Link to + autoconfigure a Home Address. + 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 + Mobile Network Prefix, it will lookup all MNNs on that MNP using Neighbor Discovery + over the Home Link. + + Thus, on the Home Link, the Home Agent MUST intercept all the packets + to ALL the Mobile Network Nodes on the registered prefixes. + In order to do so, the Home Agent might perform some form of ND proxying + for all addresses in all registered Mobile Network + Prefixes. The HA must also protect the MNP space from autoconfiguration + by uncontrolled visitors at DAD level. + + Alternatives based on a routing protocol or ICMP redirect may apply + in some cases. + + In any case, if an HA implementation is simply derived from that of MIP, + then the capability to perform the required proxying might not exist, + and there is a need to provide a specific configuration on the HA to specify + that it operates in Aggregated Mode. + +
+
+ + If the MR returns Home by egress, a specific support is required to control + the bridging operation depending on whether a MR is at Home or not. This support + might not be present in all implementations. + + Also, note that NEMO authorizes multiple registrations for a same MNP by different + Mobile Routers. This is a case of multihoming, and it normally means that the MRs + are interconnected by the ingress network that bears the common MNP. But there is no + provision in NEMO basic support to test that this condition is met at binding time + and maintained overtime. + + It is thus possible for 2 different MRs to register a same prefix with + different Home Addresses, and this will cause an undetected problem if the + corresponding ingress links are not connected. + + When the Home Address of a Mobile Router is derived from its MNP, + there is thus an additional risk of an undetected misconfiguration if + the Home Address is autoconfigured from the ingress link as opposed to statically + assigned with the MNP itself. + + +
=20 =20 +
=20 @@ -772,6 +871,19 @@ + +
+ + + Editorial + + Added a caveat part in extended and aggregated sections. + Also added a MIP Home Network section prior to those. + + + +
Pascal From nemo-bounces@ietf.org Mon Jan 10 10:29:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26108 for ; Mon, 10 Jan 2005 10:29:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1Kw-0000qk-SB; Mon, 10 Jan 2005 10:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1Ep-0007J5-IS for nemo@megatron.ietf.org; Mon, 10 Jan 2005 10:13:47 -0500 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 KAA24487 for ; Mon, 10 Jan 2005 10:13:45 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1SR-0004S5-7W for nemo@ietf.org; Mon, 10 Jan 2005 10:27:52 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 16:29:23 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0AFCqWK006606; Mon, 10 Jan 2005 16:13:10 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 16:13:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Mon, 10 Jan 2005 16:13:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF358@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT0vm/R2aJz0l7NSl+EPn71gIL6xQADDxIg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Jan 2005 15:13:10.0168 (UTC) FILETIME=[E5566980:01C4F726] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 | HA proxying for all addresses in all | MNPs in its BC is something that can not be implemented. Why? At least | because proxy NA is sent periodically, becoming an overload. Am I | missing something? Note that I'm not a promoter of that model from the start :) I agree that the HA can not send the async NA for all the range of suffixes at Home. It should just respond to NS. We can compare this with Dave Thaler's work on spit networks. Alternatively, you can bar coming Home in Aggregated. Anyway, the process is nit mandated by NEMO or any other standard, so it would be a product specific support to get there. | What does "HA protects the MNP space from autoconfiguration by | uncontrolled visitors on the Home Link" mean? MR binds MNP. Then, a node on the Home Link autoconfs an address from MNP. HA should defend the address at DAD time. The trouble with aggregated is that the whole aggregation is supposedly on link. Do you have a rewording in mind? =20 | Is it that HA defends a certain HoA from a certain BC-registered MNP, by | sending proxy Neighbour Advertisements? ("defends" in that when a | visitor tries to autoconfigure an address based on MNP, its DAD fails | because of the NA sent by the HA on behalf of MR). But how would a | visitor on the home link autoconfigure an address based on MNP if that | MNP is not present in an RA? Or is anybody sending RAs on the home link | with the MNP? |=20 | Alex From nemo-bounces@ietf.org Mon Jan 10 11:07:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28710 for ; Mon, 10 Jan 2005 11:07:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1yF-0000Cj-Fp; Mon, 10 Jan 2005 11:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co1wa-0008Ey-4I for nemo@megatron.ietf.org; Mon, 10 Jan 2005 10:59:00 -0500 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 KAA28060 for ; Mon, 10 Jan 2005 10:58:57 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2AA-0006Jn-B2 for nemo@ietf.org; Mon, 10 Jan 2005 11:13:05 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j0AFnhSe009560; Mon, 10 Jan 2005 08:49:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id j0AFvIxd023230; Mon, 10 Jan 2005 09:57:19 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1B52D855021; Mon, 10 Jan 2005 16:58:41 +0100 (CET) Message-ID: <41E2A62A.1090206@motorola.com> Date: Mon, 10 Jan 2005 16:58:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3A72848D6107E35D758A6201" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A72848D6107E35D758A6201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I created a new section prior to extended with MIP reminders to help > explain the difference later. Thanks for this action. I've read the section. It does reflect what we have discussed. It is just I still do not feel comfortable with calling it "extended model" I explain below why. Overall it is because we seem to have different views on deployment. You seem to see it as one would start from scratch to deploy a Home Network that supports mobility (first deploy a MIP Home Link, then extend it for MRs). I see it as a Home Network already exists and mobility of hosts and routers is added simultaneously (thus the prefixes are already allocated by some prior to mobility). > With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. > Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at > Home when they are connected to their Home Link, where they recognize > their Home Prefix in Router Advertisement messages. Also, a binding > is checked using of Duplicate Address Detection on the Home Link, and > Home Agents discover each other by means of Neighbor Discovery > extensions over that link. > > The Home Prefix, that is advertized on the Home Link, is a final > prefix, as opposed to an aggregation, and it may be used by hosts on > the Home Link for autoconfiguration purposes. > > As we see, the concept of a Home Network for Mobile IPv6 is really a > prefix on a link, served by one or more Home Agents as opposed to a > routed mesh. We will see in the next sections that NEMO needs > additional prefixes for use by the Mobile Networks. For that reason, > NEMO extends the concept of Home Network into a more complex, > aggregated structure. Pascal, I do not see _NEMO_ needing additional prefixes for use of Mobile Networks. It's subnetting that needs additional prefixes. If I have a MIP home link with MNs attached to it and I want to add MRs to this home then what I have to do first is to allocate /64 prefixes (out of the /48 pictured) as MNPs. Then all I have to do is to add routes in HA towards these MNPs through the respective HoAs. This is exactly the same operation I have to do if I have a Link (non-MIP) and want to further "subnet it" for non-mobile purposes with fixed routers. That is why I'm not comfortable calling it "extended model". It could as well be called "subnetted mode" or simply a "network model". When reading the draft, I get the feeling that NEMO Home Network extends the MIP Home Network. To me, this is a network further subnetted, NEMO extends nothing in this. IMHO. > As this model trivially extends the MIP Home Network Exactly, this "extension" is so trivial it does not even deserve a name IMHO. It's plain simple networking. If there is agreement around getting rid of "extended" then I'm fine. Otherwise the current text I read better than the previous (because it explains what "extended" means). Alex --------------enig3A72848D6107E35D758A6201 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB4qYwMmC0w56zj54RAlAvAJ9ihEBjGT5ufnuZuoiCOUjB0EQtUgCfS0VO wKdVkGR62IAzpCkUag60DnI= =yeQn -----END PGP SIGNATURE----- --------------enig3A72848D6107E35D758A6201-- From nemo-bounces@ietf.org Mon Jan 10 11:22:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29494 for ; Mon, 10 Jan 2005 11:22:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2DV-0002zf-R6; Mon, 10 Jan 2005 11:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2BC-0002JH-3j for nemo@megatron.ietf.org; Mon, 10 Jan 2005 11:14:06 -0500 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 LAA29103 for ; Mon, 10 Jan 2005 11:14:03 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2On-0006um-M5 for nemo@ietf.org; Mon, 10 Jan 2005 11:28:12 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0AGFrJD002419; Mon, 10 Jan 2005 09:15:53 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id j0AGB3ea015187; Mon, 10 Jan 2005 10:11:04 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F10DA86602A; Mon, 10 Jan 2005 17:13:58 +0100 (CET) Message-ID: <41E2A9C1.3030105@motorola.com> Date: Mon, 10 Jan 2005 17:13:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6BF358@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BF358@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig42EF4E6FFE6A0BE5D191F451" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42EF4E6FFE6A0BE5D191F451 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > | HA proxying for all addresses in all > | MNPs in its BC is something that can not be implemented. Why? At > least > | because proxy NA is sent periodically, becoming an overload. Am I > | missing something? > > Note that I'm not a promoter of that model from the start :) I agree > that the HA can not send the async NA for all the range of suffixes at > Home. It should just respond to NS. We can compare this with Dave > Thaler's work on spit networks. Alternatively, you can bar coming Home > in Aggregated. Anyway, the process is nit mandated by NEMO or any other > standard, so it would be a product specific support to get there. If compared to other works (split networks) then it should be referenced and made work with that model. One thousand more lines make sure it's exactly the other work, is it worth the effort? For hosts to autoconfigure addresses based on each MNP - who would send RAs for each MNP on the home link? > | What does "HA protects the MNP space from autoconfiguration by > | uncontrolled visitors on the Home Link" mean? > > MR binds MNP. Then, a node on the Home Link autoconfs an address from > MNP. HA should defend the address at DAD time. The trouble with > aggregated is that the whole aggregation is supposedly on link. Do you > have a rewording in mind? I don't have a rewording in mind, sorry. My only wording is that it can't scale. You seem to say the same thing, so why re-wording it when we could simply remove it. Alex --------------enig42EF4E6FFE6A0BE5D191F451 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB4qnGMmC0w56zj54RAhp/AKCFPzw+62bO4L6sZBcNXuTawk5f4wCgsM3Y JORRqTajTspAeKoMxs5mMCw= =PfDM -----END PGP SIGNATURE----- --------------enig42EF4E6FFE6A0BE5D191F451-- From nemo-bounces@ietf.org Mon Jan 10 11:44:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03984 for ; Mon, 10 Jan 2005 11:44:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2TK-00068G-0g; Mon, 10 Jan 2005 11:32:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2OT-0004uC-GL for nemo@megatron.ietf.org; Mon, 10 Jan 2005 11:27:49 -0500 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 LAA01644 for ; Mon, 10 Jan 2005 11:27:47 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2c6-0007XE-1n for nemo@ietf.org; Mon, 10 Jan 2005 11:41:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2005 09:39:08 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0AGR6l2024239; Mon, 10 Jan 2005 08:27:07 -0800 (PST) Received: from dshell-w2k02.cisco.com (rtp-vpn1-74.cisco.com [10.82.224.74]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA19005; Mon, 10 Jan 2005 08:27:13 -0800 (PST) Message-Id: <4.3.2.7.2.20050110112249.00c6a4b0@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jan 2005 11:27:12 -0500 To: Alexandru Petrescu From: Daniel Shell Subject: Re: [nemo] issue 2 diffs In-Reply-To: <41E2A62A.1090206@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Alex So you seem to be saying the NEMO extended is just subnetting as you would with any network. You seem to object to the notion that somehow NEMO is extending the ipv6 network when all NEMO is doing is subnetted the ipv6 network and this is not really a mobility issue but a network design. How about NEMO with subnetted prefix. At 04:58 PM 1/10/2005 +0100, Alexandru Petrescu wrote: >Pascal Thubert (pthubert) wrote: >>I created a new section prior to extended with MIP reminders to help >> explain the difference later. > >Thanks for this action. I've read the section. It does reflect what we >have discussed. > >It is just I still do not feel comfortable with calling it "extended >model" I explain below why. Overall it is because we seem to have >different views on deployment. You seem to see it as one would start >from scratch to deploy a Home Network that supports mobility (first >deploy a MIP Home Link, then extend it for MRs). I see it as a Home >Network already exists and mobility of hosts and routers is added >simultaneously (thus the prefixes are already allocated by some >prior to mobility). > >>With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. >>Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at Home >>when they are connected to their Home Link, where they recognize >> their Home Prefix in Router Advertisement messages. Also, a binding is >> checked using of Duplicate Address Detection on the Home Link, and >> Home Agents discover each other by means of Neighbor Discovery >> extensions over that link. >>The Home Prefix, that is advertized on the Home Link, is a final prefix, >>as opposed to an aggregation, and it may be used by hosts on the Home >>Link for autoconfiguration purposes. >>As we see, the concept of a Home Network for Mobile IPv6 is really a >>prefix on a link, served by one or more Home Agents as opposed to a >>routed mesh. We will see in the next sections that NEMO needs additional >>prefixes for use by the Mobile Networks. For that reason, NEMO extends >>the concept of Home Network into a more complex, aggregated structure. > >Pascal, I do not see _NEMO_ needing additional prefixes for use >of Mobile Networks. It's subnetting that needs additional prefixes. If >I have a MIP home link with MNs attached to it and I want to add MRs to >this home then what I have to do first is to allocate /64 prefixes (out >of the /48 pictured) as MNPs. Then all I have to do is to add routes in >HA towards these MNPs through the respective HoAs. > >This is exactly the same operation I have to do if I have a Link >(non-MIP) and want to further "subnet it" for non-mobile purposes with >fixed routers. > >That is why I'm not comfortable calling it "extended model". It >could as well be called "subnetted mode" or simply a "network model". > >When reading the draft, I get the feeling that NEMO Home Network extends >the MIP Home Network. To me, this is a network further subnetted, NEMO >extends nothing in this. IMHO. > >>As this model trivially extends the MIP Home Network > >Exactly, this "extension" is so trivial it does not even deserve a name >IMHO. It's plain simple networking. > >If there is agreement around getting rid of "extended" then I'm fine. >Otherwise the current text I read better than the previous (because it >explains what "extended" means). > >Alex > > Dan Shell Government Service Unit CISCO Systems IP mobility/Wireless/Satellite 440 331 5663 From nemo-bounces@ietf.org Mon Jan 10 11:46:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04196 for ; Mon, 10 Jan 2005 11:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2eA-000849-Nq; Mon, 10 Jan 2005 11:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2Zx-00078Z-8x for nemo@megatron.ietf.org; Mon, 10 Jan 2005 11:39:41 -0500 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 LAA03489 for ; Mon, 10 Jan 2005 11:39:36 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2nY-0008BA-4L for nemo@ietf.org; Mon, 10 Jan 2005 11:53:45 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0AGaRJD027712; Mon, 10 Jan 2005 09:36:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j0AGX6R9021106; Mon, 10 Jan 2005 10:33:06 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1EFAC86602A; Mon, 10 Jan 2005 17:34:33 +0100 (CET) Message-ID: <41E2AE92.1040004@motorola.com> Date: Mon, 10 Jan 2005 17:34:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Shell Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> <4.3.2.7.2.20050110112249.00c6a4b0@lint.cisco.com> In-Reply-To: <4.3.2.7.2.20050110112249.00c6a4b0@lint.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB63786961C5A627569F8381F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB63786961C5A627569F8381F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Daniel Shell wrote: > So you seem to be saying the NEMO extended is just subnetting as you > would with any network. Exactly. > You seem to object to the notion that somehow NEMO is extending the > ipv6 network when all NEMO is doing is subnetted the ipv6 network and > this is not really a mobility issue but a network design. Exactly. > How about NEMO with subnetted prefix. Sounds good. Alex --------------enigB63786961C5A627569F8381F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB4q6YMmC0w56zj54RAhiaAKDo0wOPkRgtUSpeT0uemBO6h2ohqgCcDZJ9 lc72e6i8MEVN2h+pSHYdVHA= =7qjG -----END PGP SIGNATURE----- --------------enigB63786961C5A627569F8381F-- From nemo-bounces@ietf.org Mon Jan 10 13:03:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09758 for ; Mon, 10 Jan 2005 13:03:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3lX-0005s0-7r; Mon, 10 Jan 2005 12:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3cw-0004cL-55 for nemo@megatron.ietf.org; Mon, 10 Jan 2005 12:46:51 -0500 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 MAA08415 for ; Mon, 10 Jan 2005 12:46:47 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3qZ-0002FW-7w for nemo@ietf.org; Mon, 10 Jan 2005 13:00:56 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 19:02:28 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0AHkDW6025213; Mon, 10 Jan 2005 18:46:13 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 18:46:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Mon, 10 Jan 2005 18:45:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF43D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcT3L4LjWPRrY76GQL2qRZBkpgm2iAADApGA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Jan 2005 17:46:08.0623 (UTC) FILETIME=[441F7FF0:01C4F73C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Monday, January 10, 2005 5:14 PM | To: Pascal Thubert (pthubert) | Cc: nemo | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Pascal Thubert (pthubert) wrote: | > | HA proxying for all addresses in all | > | MNPs in its BC is something that can not be implemented. Why? At | > least | > | because proxy NA is sent periodically, becoming an overload. Am I | > | missing something? | > | > Note that I'm not a promoter of that model from the start :) I agree | > that the HA can not send the async NA for all the range of suffixes at | > Home. It should just respond to NS. We can compare this with Dave | > Thaler's work on spit networks. Alternatively, you can bar coming Home | > in Aggregated. Anyway, the process is nit mandated by NEMO or any other | > standard, so it would be a product specific support to get there. |=20 | If compared to other works (split networks) then it should be referenced | and made work with that model. One thousand more lines make sure it's | exactly the other work, is it worth the effort? |=20 | For hosts to autoconfigure addresses based on each MNP - who would send | RAs for each MNP on the home link? |=20 | > | What does "HA protects the MNP space from autoconfiguration by | > | uncontrolled visitors on the Home Link" mean? | > | > MR binds MNP. Then, a node on the Home Link autoconfs an address from | > MNP. HA should defend the address at DAD time. The trouble with | > aggregated is that the whole aggregation is supposedly on link. Do you | > have a rewording in mind? |=20 | I don't have a rewording in mind, sorry. My only wording is that it | can't scale. You seem to say the same thing, so why re-wording it when | we could simply remove it. Well, remove what? The whole aggregated model? The support of coming Home in aggregated? I agree I can not specify MNP level proxying and this is an informational draft anyway. All I can say is that if you wish to do this (nodes at home connect to nodes on MNPs), than you need your implementation to do that (HA ND proxies for nodes on MNP). I agree I cannot say how this can be done.=20 Personally, I believe it could be done, by passively answering NS. But I'm not 100% sure there's no caveat in the process :( I favor the extended home network vs. the aggregated. Pascal From nemo-bounces@ietf.org Mon Jan 10 13:04:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09831 for ; Mon, 10 Jan 2005 13:04:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3lX-0005sj-P0; Mon, 10 Jan 2005 12:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3cy-0004cN-VY for nemo@megatron.ietf.org; Mon, 10 Jan 2005 12:46:53 -0500 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 MAA08419 for ; Mon, 10 Jan 2005 12:46:49 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3qb-0002FW-Ok for nemo@ietf.org; Mon, 10 Jan 2005 13:00:59 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2005 19:02:34 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0AHjYWi024990; Mon, 10 Jan 2005 18:46:19 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 Jan 2005 18:46:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Mon, 10 Jan 2005 18:46:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BF43C@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT3LWMwAgzPwn8qSc+Qy2hABdtx/QADXFsQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Jan 2005 17:46:08.0132 (UTC) FILETIME=[43D49440:01C4F73C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | Sent: Monday, January 10, 2005 4:59 PM | To: Pascal Thubert (pthubert) | Cc: nemo@ietf.org | Subject: Re: [nemo] issue 2 diffs |=20 | Pascal Thubert (pthubert) wrote: | > I created a new section prior to extended with MIP reminders to help | > explain the difference later. |=20 | Thanks for this action. I've read the section. It does reflect what we | have discussed. |=20 | It is just I still do not feel comfortable with calling it "extended | model" I explain below why. Overall it is because we seem to have | different views on deployment. You seem to see it as one would start | from scratch to deploy a Home Network that supports mobility (first | deploy a MIP Home Link, then extend it for MRs). I see it as a Home | Network already exists and mobility of hosts and routers is added | simultaneously (thus the prefixes are already allocated by some | prior to mobility). |=20 OK | > With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. | > Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at | > Home when they are connected to their Home Link, where they recognize | > their Home Prefix in Router Advertisement messages. Also, a binding | > is checked using of Duplicate Address Detection on the Home Link, and | > Home Agents discover each other by means of Neighbor Discovery | > extensions over that link. | > | > The Home Prefix, that is advertized on the Home Link, is a final | > prefix, as opposed to an aggregation, and it may be used by hosts on | > the Home Link for autoconfiguration purposes. | > | > As we see, the concept of a Home Network for Mobile IPv6 is really a | > prefix on a link, served by one or more Home Agents as opposed to a | > routed mesh. We will see in the next sections that NEMO needs | > additional prefixes for use by the Mobile Networks. For that reason, | > NEMO extends the concept of Home Network into a more complex, | > aggregated structure. |=20 | Pascal, I do not see _NEMO_ needing additional prefixes for use | of Mobile Networks. It's subnetting that needs additional prefixes. If | I have a MIP home link with MNs attached to it and I want to add MRs to | this home then what I have to do first is to allocate /64 prefixes (out | of the /48 pictured) as MNPs. Then all I have to do is to add routes in | HA towards these MNPs through the respective HoAs. |=20 | This is exactly the same operation I have to do if I have a Link | (non-MIP) and want to further "subnet it" for non-mobile purposes with | fixed routers. |=20 | That is why I'm not comfortable calling it "extended model". It | could as well be called "subnetted mode" or simply a "network model". |=20 | When reading the draft, I get the feeling that NEMO Home Network extends | the MIP Home Network. To me, this is a network further subnetted, NEMO | extends nothing in this. IMHO. |=20 OK, I guess it's a way of picturing things and there's no absolute truth. I have your vision and Vijay's. I'm waiting for others to see if there's a trend. | > As this model trivially extends the MIP Home Network |=20 | Exactly, this "extension" is so trivial it does not even deserve a name | IMHO. It's plain simple networking. |=20 | If there is agreement around getting rid of "extended" then I'm fine. | Otherwise the current text I read better than the previous (because it | explains what "extended" means). |=20 Cool :) pascal From nemo-bounces@ietf.org Tue Jan 11 07:17:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16715 for ; Tue, 11 Jan 2005 07:17:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoKw7-0003rS-1D; Tue, 11 Jan 2005 07:15:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoKqq-0003Bh-QY for nemo@megatron.ietf.org; Tue, 11 Jan 2005 07:10:21 -0500 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 HAA16385 for ; Tue, 11 Jan 2005 07:10:16 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoL4Z-0003Hb-WB for nemo@ietf.org; Tue, 11 Jan 2005 07:24:35 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 13:08:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Tue, 11 Jan 2005 13:08:13 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201A571F2@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT3LWMwAgzPwn8qSc+Qy2hABdtx/QADXFsQACPyqDA= From: "BINET David RD-CORE-CAE" To: "Pascal Thubert \(pthubert\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 11 Jan 2005 12:08:14.0335 (UTC) FILETIME=[3A1E68F0:01C4F7D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Thanks for this proposition, Pascal. Some comments in the text.=20 > -----Message d'origine----- > De : nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] De=20 > la part de Pascal Thubert (pthubert) > Envoy=E9 : lundi 10 janvier 2005 18:46 > =C0 : Alexandru Petrescu > Cc : nemo@ietf.org > Objet : RE: [nemo] issue 2 diffs >=20 >=20 >=20 > | -----Original Message----- > | From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > | Sent: Monday, January 10, 2005 4:59 PM > | To: Pascal Thubert (pthubert) > | Cc: nemo@ietf.org > | Subject: Re: [nemo] issue 2 diffs > |=20 > | Pascal Thubert (pthubert) wrote: > | > I created a new section prior to extended with MIP=20 > reminders to help =20 > | > explain the difference later. > |=20 > | Thanks for this action. I've read the section. It does=20 > reflect what > we > | have discussed. > |=20 > | It is just I still do not feel comfortable with calling it=20 > "extended=20 > | model" I explain below why. Overall it is because we seem to have=20 > | different views on deployment. You seem to see it as one=20 > would start=20 > | from scratch to deploy a Home Network that supports mobility (first=20 > | deploy a MIP Home Link, then extend it for MRs). I see it=20 > as a Home=20 > | Network already exists and mobility of hosts and routers is added=20 > | simultaneously (thus the prefixes are already allocated by=20 > some prior=20 > | to mobility). > |=20 >=20 > OK >=20 > | > With Mobile IPv6 (MIP6) specificationJohnson, D.,=20 > Perkins, C. and J. > | > Arkko, Mobility Support in IPv6, June 2004.[7] Mobile=20 > Nodes are at=20 > | > Home when they are connected to their Home Link, where they > recognize > | > their Home Prefix in Router Advertisement messages.=20 > Also, a binding=20 > | > is checked using of Duplicate Address Detection on the Home Link, > and > | > Home Agents discover each other by means of Neighbor Discovery=20 > | > extensions over that link. > | > > | > The Home Prefix, that is advertized on the Home Link, is a final=20 > | > prefix, as opposed to an aggregation, and it may be used=20 > by hosts on=20 > | > the Home Link for autoconfiguration purposes. > | > > | > As we see, the concept of a Home Network for Mobile IPv6=20 > is really a=20 > | > prefix on a link, served by one or more Home Agents as=20 > opposed to a=20 > | > routed mesh. We will see in the next sections that NEMO needs=20 > | > additional prefixes for use by the Mobile Networks. For=20 > that reason,=20 > | > NEMO extends the concept of Home Network into a more complex,=20 > | > aggregated structure. > |=20 > | Pascal, I do not see _NEMO_ needing additional prefixes for use of=20 > | Mobile Networks. It's subnetting that needs additional prefixes. > If > | I have a MIP home link with MNs attached to it and I want to add MRs > to > | this home then what I have to do first is to allocate /64 prefixes > (out > | of the /48 pictured) as MNPs. Then all I have to do is to=20 > add routes > in > | HA towards these MNPs through the respective HoAs. > |=20 > | This is exactly the same operation I have to do if I have a Link > | (non-MIP) and want to further "subnet it" for non-mobile=20 > purposes with=20 > | fixed routers. > |=20 > | That is why I'm not comfortable calling it "extended=20 > model". It could=20 > | as well be called "subnetted mode" or simply a "network model". > |=20 > | When reading the draft, I get the feeling that NEMO Home Network > extends > | the MIP Home Network. To me, this is a network further subnetted, > NEMO > | extends nothing in this. IMHO. > |=20 >=20 > OK, I guess it's a way of picturing things and there's no=20 > absolute truth. I have your vision and Vijay's. I'm waiting=20 > for others to see if there's a trend. Thanks for the explanation. I have understood where the term "Extended" = come from. I do not think that Extended is really the right term. I agree with = Alex. I do not know if the references to MIP architecture has to be described = so much. The first reference (general expectations) is something useful = but afterwards I do not think that Nemo home networks descriptions have = to have so many links with MIP architecture. Nemo and MIP are two = different protocols and services and I do not see some "progression" = from one type of service or network to another one. So, I think that the = references from one "model" (MIP) to another one (Nemo) should be = reduced and Nemo home networks models should be as independant as = possible from MIP architecture. >=20 >=20 > | > As this model trivially extends the MIP Home Network > |=20 > | Exactly, this "extension" is so trivial it does not even deserve a > name > | IMHO. It's plain simple networking. > |=20 > | If there is agreement around getting rid of "extended" then=20 > I'm fine. > | Otherwise the current text I read better than the previous=20 > (because it=20 > | explains what "extended" means). > |=20 > Cool :) "5.4 Applicability The extended Home Network keeps the MIP6 concept of a Home Network for both Mobile Nodes and Mobile Routers to take their Home Address from." I think the end of sentence is missing. David >=20 > pascal >=20 >=20 From nemo-bounces@ietf.org Tue Jan 11 18:59:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17849 for ; Tue, 11 Jan 2005 18:59:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVgL-00030V-AJ; Tue, 11 Jan 2005 18:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVbH-000241-Lb for nemo@megatron.ietf.org; Tue, 11 Jan 2005 18:38:59 -0500 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 SAA16918 for ; Tue, 11 Jan 2005 18:38:56 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVpB-0004Xq-Gb for nemo@ietf.org; Tue, 11 Jan 2005 18:53:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0C0A0u00632; Tue, 11 Jan 2005 16:10:00 -0800 X-mProtect: <200501120010> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdDIxdrc; Tue, 11 Jan 2005 16:09:59 PST Message-ID: <41E464B8.2080201@iprg.nokia.com> Date: Tue, 11 Jan 2005 15:43:52 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <41DC2ABC.1080504@motorola.com> <41E20823.7090507@iprg.nokia.com> <41E2640E.20804@motorola.com> In-Reply-To: <41E2640E.20804@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >> if the MR chooses to configure a HoA from the MNP, the HA can't >> prevent it. and I dont think we need to provide a way for the HA to >> prevent it. > > > Vijay, true HA can't prevent MR do whatever it wants with its addresses. > But in order for HA to do proxy-ND for Home Address that Home Address > must be valid on the Home Link. If it's from MNP then it's not valid on > the Home Link. if the HoA does not belong to the home link and belongs to the MNP, the Home Agent treats the address as any other address in the MNP. it does not treat it as an address on the home link. if the HA is using a route for the MNP (pointing to the MR's current location/tunnel interface) to do routing for addresses in the MNP, it does the same for the HoA.if the HA using proxy ND to do routing for addresses in the MNP, it does the same for the HoA. Vijay From nemo-bounces@ietf.org Tue Jan 11 19:17:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19382 for ; Tue, 11 Jan 2005 19:17:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVzp-0006MT-Tj; Tue, 11 Jan 2005 19:04:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVpG-0004LU-9b for nemo@megatron.ietf.org; Tue, 11 Jan 2005 18:53:26 -0500 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 SAA17606 for ; Tue, 11 Jan 2005 18:53:23 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoW3A-0004nh-Mz for nemo@ietf.org; Tue, 11 Jan 2005 19:07:49 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0C0OTJ19273; Tue, 11 Jan 2005 16:24:29 -0800 X-mProtect: <200501120024> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdzjNlrL; Tue, 11 Jan 2005 16:24:27 PST Message-ID: <41E4681C.1050605@iprg.nokia.com> Date: Tue, 11 Jan 2005 15:58:20 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> <41E2A62A.1090206@motorola.com> In-Reply-To: <41E2A62A.1090206@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Alex, it is true that regular IPv6 subnetting is used to allocate prefixes for the home link and the mobile networks. no issues. but the MR creating a route for its subnet at the HA which actually has a subnet of its own, is what we are calling the NEMO "Extended Home Network Model". so I dont see whats wrong with the term. having said that, it really only a term. I dont care if it is changed to something else. Pascal, do you think it might make sense to re-draw the figure for the Extended Home Network model as follows. | route v /48 A:B:C::/48 --+-----+-----+--+- . -+- . -+-- | | | | | HA MR1 MR2 MRi MRN HA link - A:B:C:0::/64 /64 /64 /64 /64 /64 A:B:C:i::/64 1 < i <= N Extended Home Network <-----------------------------------------------------------> Home Net Mobile Net Mobile Net ... Mobile Net <------------><------------><------------> ... <------------> Vijay Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > >> I created a new section prior to extended with MIP reminders to help >> explain the difference later. > > > Thanks for this action. I've read the section. It does reflect what we > have discussed. > > It is just I still do not feel comfortable with calling it "extended > model" I explain below why. Overall it is because we seem to have > different views on deployment. You seem to see it as one would start > from scratch to deploy a Home Network that supports mobility (first > deploy a MIP Home Link, then extend it for MRs). I see it as a Home > Network already exists and mobility of hosts and routers is added > simultaneously (thus the prefixes are already allocated by some > prior to mobility). > >> With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. >> Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at >> Home when they are connected to their Home Link, where they recognize >> their Home Prefix in Router Advertisement messages. Also, a binding >> is checked using of Duplicate Address Detection on the Home Link, and >> Home Agents discover each other by means of Neighbor Discovery >> extensions over that link. >> >> The Home Prefix, that is advertized on the Home Link, is a final >> prefix, as opposed to an aggregation, and it may be used by hosts on >> the Home Link for autoconfiguration purposes. >> >> As we see, the concept of a Home Network for Mobile IPv6 is really a >> prefix on a link, served by one or more Home Agents as opposed to a >> routed mesh. We will see in the next sections that NEMO needs >> additional prefixes for use by the Mobile Networks. For that reason, >> NEMO extends the concept of Home Network into a more complex, >> aggregated structure. > > > Pascal, I do not see _NEMO_ needing additional prefixes for use > of Mobile Networks. It's subnetting that needs additional prefixes. If > I have a MIP home link with MNs attached to it and I want to add MRs to > this home then what I have to do first is to allocate /64 prefixes (out > of the /48 pictured) as MNPs. Then all I have to do is to add routes in > HA towards these MNPs through the respective HoAs. > > This is exactly the same operation I have to do if I have a Link > (non-MIP) and want to further "subnet it" for non-mobile purposes with > fixed routers. > > That is why I'm not comfortable calling it "extended model". It > could as well be called "subnetted mode" or simply a "network model". > > When reading the draft, I get the feeling that NEMO Home Network extends > the MIP Home Network. To me, this is a network further subnetted, NEMO > extends nothing in this. IMHO. > >> As this model trivially extends the MIP Home Network > > > Exactly, this "extension" is so trivial it does not even deserve a name > IMHO. It's plain simple networking. > > If there is agreement around getting rid of "extended" then I'm fine. > Otherwise the current text I read better than the previous (because it > explains what "extended" means). > > Alex From nemo-bounces@ietf.org Tue Jan 11 19:30:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20379 for ; Tue, 11 Jan 2005 19:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWCI-0000lC-UF; Tue, 11 Jan 2005 19:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVzH-0006H0-MP for nemo@megatron.ietf.org; Tue, 11 Jan 2005 19:03:47 -0500 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 TAA18247 for ; Tue, 11 Jan 2005 19:03:44 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWDB-0004y8-8J for nemo@ietf.org; Tue, 11 Jan 2005 19:18:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0C0Yqi01130; Tue, 11 Jan 2005 16:34:52 -0800 X-mProtect: <200501120034> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdxMggg5; Tue, 11 Jan 2005 16:34:50 PST Message-ID: <41E46A8C.3080603@iprg.nokia.com> Date: Tue, 11 Jan 2005 16:08:44 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal, the following is already covered in the Basic Support spec. > In that case, the Home Address does not match the Home Link > Prefix, and there is a need to configure the HA in a specific > mode with the support for the extended Home Network and the > range of the Mobile Network Prefixes. section 6.2 - Mobile IPv6 specification [1] requires that the Home Address in the Binding Update should be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specification relaxes this requirement so that the Home Agent rejects the Binding Update only if Home Address does not belong to the prefix that the Home Agent is configured to serve. so the following limitation does not exist. > But if an implementation is simply derived from that of MIP, > then this capability might not exist, and the HA will not be > able to accept a Home Address based on the MNP. another issue with the text. > Thus, on the Home Link, the Home Agent MUST intercept all the > packets to ALL the Mobile Network Nodes on the registered > prefixes. In order to do so, the Home Agent might perform some > form of ND proxying for all addresses in all registered Mobile > Network Prefixes. this is better done through a route at the HA for the MNP. but ofcourse, the above can also be done. you might want to mention that the HA SHOULD NOT send gratuitous proxy NAs for the addresses in the MNP. Vijay Pascal Thubert (pthubert) wrote: > Hi: > > Here are the proposed diff for issue 2. > > I created a new section prior to extended with MIP reminders to help > explain the difference later. Then I added a new section in extended and > aggregated to place the deployment caveats as suggested by David. I > followed Alex recommendation and presented that the most natural way in > extended in a Home Address from the Home Link Prefix and in aggregated, > from the MNP. > > Maybe it's easier for you to check the WIP for 02 at: > http://mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models- > xx.html > > Please let me know your comments on the proposed changes :) > From nemo-bounces@ietf.org Tue Jan 11 22:24:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00580 for ; Tue, 11 Jan 2005 22:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYys-0002Bw-PW; Tue, 11 Jan 2005 22:15:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYu3-0001BJ-5Q for nemo@megatron.ietf.org; Tue, 11 Jan 2005 22:10:35 -0500 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 WAA00074 for ; Tue, 11 Jan 2005 22:10:32 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoZ7w-0000Rz-AF for nemo@ietf.org; Tue, 11 Jan 2005 22:24:59 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0C3CLJD027775; Tue, 11 Jan 2005 20:12:21 -0700 (MST) Received: from [10.181.32.101] (mvp-10-181-32-101.ea.mot.com [10.181.32.101]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j0C3969v015152; Tue, 11 Jan 2005 21:09:07 -0600 Message-ID: <41E4951C.3080309@motorola.com> Date: Wed, 12 Jan 2005 04:10:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: about the Home Network Models WG item References: <7892795E1A87F04CADFCCF41FADD00FC6895BC@xmb-ams-337.emea.cisco.com> <41DC2ABC.1080504@motorola.com> <41E20823.7090507@iprg.nokia.com> <41E2640E.20804@motorola.com> <41E464B8.2080201@iprg.nokia.com> In-Reply-To: <41E464B8.2080201@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090308030706050109030604" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms090308030706050109030604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm trying to follow you... Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >> Vijay Devarapalli wrote: >> >>> if the MR chooses to configure a HoA from the MNP, the HA can't >>> prevent it. and I dont think we need to provide a way for the HA >>> to prevent it. >> >> Vijay, true HA can't prevent MR do whatever it wants with its >> addresses. But in order for HA to do proxy-ND for Home Address that >> Home Address must be valid on the Home Link. If it's from MNP >> then it's not valid on the Home Link. > > if the HoA does not belong to the home link and belongs to the MNP, > the Home Agent treats the address as any other address in the MNP. it > does not treat it as an address on the home link. if the HA is using > a route for the MNP (pointing to the MR's current location/tunnel > interface) to do routing for addresses in the MNP, it does the same > for the HoA. Kind of agree, but I don't understand exactly what you mean. Do you mean that wherever the HoA is coming from (MNP or home link) packets to it will actually get routed to the MR? I agree with it. I do have the picture of a R1 (MR) and R2 (HA) holding a route towards R1's ingress interface (and not R1's egress). Is it this you mean? Also I'm confused you saying "if HA uses a route towards MNP" because HA must always have a route to MNP, be MR at home or away, right? > if the HA using proxy ND to do routing for addresses in the MNP, it > does the same for the HoA. First, HA can't do proxy-ND for an address that is not valid on its link, and all addresses derived from MNP aren't valid on the home link. If HA can't do proxy-ND for the HoA from MNP then HA can't receive packets addressed to HoA when MR not at home, do you agree? Alex --------------ms090308030706050109030604 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAx MTIwMzEwMjBaMCMGCSqGSIb3DQEJBDEWBBTTHxWG/ZwrNxwnbPfbYdepGHQqcjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYApYF60S9nNl9OIfpdxXkRFMsio6WzHZUBPxHMl s3M5kBo+63PYXGFtiebPpsvoY6PEjHEO9xiHBk+BNDIq8nI5z1TRX9djvFSWD3v1y2wtBscJ VFkDn/Uzym2/Yhrs3kZ5QKNqFxYnaYGx30hpxY2NzabTcc0r818RdvgXNHizIAAAAAAAAA== --------------ms090308030706050109030604-- From nemo-bounces@ietf.org Tue Jan 11 22:45:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02292 for ; Tue, 11 Jan 2005 22:45:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoZKf-0006qe-5y; Tue, 11 Jan 2005 22:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoZDZ-0005Aw-MH for nemo@megatron.ietf.org; Tue, 11 Jan 2005 22:30:45 -0500 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 WAA01257 for ; Tue, 11 Jan 2005 22:30:43 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoZRW-0000op-1a for nemo@ietf.org; Tue, 11 Jan 2005 22:45:10 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0C3WZJD016465; Tue, 11 Jan 2005 20:32:35 -0700 (MST) Received: from [10.181.32.101] (mvp-10-181-32-101.ea.mot.com [10.181.32.101]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id j0C3ULNs012187; Tue, 11 Jan 2005 21:30:22 -0600 Message-ID: <41E499D9.5050002@motorola.com> Date: Wed, 12 Jan 2005 04:30:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BF34C@xmb-ams-337.emea.cisco.com> <41E2A62A.1090206@motorola.com> <41E4681C.1050605@iprg.nokia.com> In-Reply-To: <41E4681C.1050605@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8D8B13AD02CB47498B1C4A7" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8D8B13AD02CB47498B1C4A7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > but the MR creating a route for its subnet at the HA which > actually has a subnet of its own, HA has a subnet of its own? Isn't the HA the Home Link's default route to the Internet? Is the Internet a subnet of HA? I don't get it. > is what we are calling the NEMO "Extended Home Network Model". so I > dont see whats wrong with the term. Vijay, it's not the NEMO MR that creates a route for its subnet at the HA. This route must exist on the HA because otherwise the MNP is not reachable when MR is at home. This route at the HA can be created in several ways[*], not related to NEMO. This must exist prior to NEMO running, otherwise MNP is not reachable when MR at home. [*] ways to create a route at HA prior to NEMO running: static, dynamic, at reboot, on the rt protocol config file, inserted by ospf, by ICMP Redirect, etc. > having said that, it really only a term. I dont care if it > is changed to something else. Indeed it's just a term. I feel the same as you about it. > Pascal, do you think it might make sense to re-draw the figure > for the Extended Home Network model as follows. > > | > route v /48 A:B:C::/48 > > --+-----+-----+--+- . -+- . -+-- > | | | | | > HA MR1 MR2 MRi MRN HA link - A:B:C:0::/64 > /64 /64 /64 /64 /64 A:B:C:i::/64 1 < i <= N > > > Extended Home Network > <-----------------------------------------------------------> > > Home Net Mobile Net Mobile Net ... Mobile Net > <------------><------------><------------> ... <------------> Vijay, let me ask here. It seems in this picture the HA no longer has two interfaces? I'm fine with that. But where is the Home Link? Is it the common link between MRs? If yes, for this to work you need a Gateway that is MRs' and HA's default route and that sends ICMP Redirect to HA for the MNPs (such that HA obtains routes towards the MNPs). It's a bit confusing to me, why don't you picture more detail, with the Internet, the Gateway, the ingress/egress interfaces of MR and HA. Alex --------------enigC8D8B13AD02CB47498B1C4A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB5JnfMmC0w56zj54RAlayAKCoqhdP8CcPtflfm0RQAv1+eIHgywCbBOBX MzbqTAnNLdz4Jv0CgO/mR34= =NMto -----END PGP SIGNATURE----- --------------enigC8D8B13AD02CB47498B1C4A7-- From imeaqlkjgekqs@yahoo.com Wed Jan 12 02:08:11 2005 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 CAA22510; Wed, 12 Jan 2005 02:08:10 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cocpr-000593-Lr; Wed, 12 Jan 2005 02:22:35 -0500 Received: from [211.190.129.10] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CocbY-0002qR-J9; Wed, 12 Jan 2005 02:07:47 -0500 Received: from .anu..au ([218.88.128.240] helo=anu..au) by smtp7..co with esmtp id 1A5Ys6-994167-29 Message-ID: Sender: freeradius-devel-imeaqlkjgekqs@yahoo.com X-Mailman-Version: 2.0.1 Date: Wed, 12 Jan 2005 08:06:16 +0100 From: "Luther Washington" To: nemo-admin@ietf.org, nemo-archive@ietf.org, nemo-request@ietf.org, nemo-web-archive@ietf.org, net@ietf.org, new-work@ietf.org, nfsv4@ietf.org Subject: You Need This Nemo-admin X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Huge offer for Viicodin, Viagraa, Vallium and lots moreee... savee up to 7o% meds on our stores. Visit uss today http://coolhealth.info/in.php?aid=56 Happy New Year AmU4bJ6Cy80s75eJs2BCphsOpThj5lfZzU3eN9S3pBljFpW2ly8Wa9Nv5MxCH From nemo-bounces@ietf.org Wed Jan 12 04:36:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25875 for ; Wed, 12 Jan 2005 04:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoerM-0006UG-0l; Wed, 12 Jan 2005 04:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoekV-0005Ku-HR for nemo@megatron.ietf.org; Wed, 12 Jan 2005 04:25:07 -0500 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 EAA25283 for ; Wed, 12 Jan 2005 04:25:05 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoeyU-0008Dr-Qk for nemo@ietf.org; Wed, 12 Jan 2005 04:39:35 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2005 10:41:18 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0C9OEWK021919; Wed, 12 Jan 2005 10:24:32 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 10:24:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Wed, 12 Jan 2005 10:23:15 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BFA51@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT4OLw25Wxbp/AcQTW6iqTt/C73xQATy7Dg From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Alexandru Petrescu" X-OriginalArrivalTime: 12 Jan 2005 09:24:21.0738 (UTC) FILETIME=[7FD8ECA0:01C4F888] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] | Sent: Wednesday, January 12, 2005 12:58 AM | To: Alexandru Petrescu | Cc: Pascal Thubert (pthubert); nemo@ietf.org | Subject: Re: [nemo] issue 2 diffs |=20 | Alex, |=20 | it is true that regular IPv6 subnetting is used to allocate | prefixes for the home link and the mobile networks. no issues. |=20 | but the MR creating a route for its subnet at the HA which | actually has a subnet of its own, is what we are calling the | NEMO "Extended Home Network Model". so I dont see whats | wrong with the term. |=20 | having said that, it really only a term. I dont care if it | is changed to something else. |=20 The thing is that we already debated this long ago, and the term has now been used for a while. Good or not, it's always the same debate of changing the terminology after it has been used for a long time. In particular, just look at the mobilenetworks site for the last 4 IETF presentations and you'll see the term. I'd need a very good new name and very powerful reasons to change that now... | Pascal, do you think it might make sense to re-draw the figure | for the Extended Home Network model as follows. |=20 | | | route v /48 A:B:C::/48 |=20 | --+-----+-----+--+- . -+- . -+-- | | | | | | | HA MR1 MR2 MRi MRN HA link - A:B:C:0::/64 | /64 /64 /64 /64 /64 A:B:C:i::/64 1 < i <=3D = N |=20 |=20 | Extended Home Network | <-----------------------------------------------------------> |=20 | Home Net Mobile Net Mobile Net ... Mobile Net | <------------><------------><------------> ... <------------> |=20 | Vijay |=20 Done as issue 3 :) Pascal | Alexandru Petrescu wrote: | > Pascal Thubert (pthubert) wrote: | > | >> I created a new section prior to extended with MIP reminders to help | >> explain the difference later. | > | > | > Thanks for this action. I've read the section. It does reflect what we | > have discussed. | > | > It is just I still do not feel comfortable with calling it "extended | > model" I explain below why. Overall it is because we seem to have | > different views on deployment. You seem to see it as one would start | > from scratch to deploy a Home Network that supports mobility (first | > deploy a MIP Home Link, then extend it for MRs). I see it as a Home | > Network already exists and mobility of hosts and routers is added | > simultaneously (thus the prefixes are already allocated by some | > prior to mobility). | > | >> With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. | >> Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at | >> Home when they are connected to their Home Link, where they recognize | >> their Home Prefix in Router Advertisement messages. Also, a binding | >> is checked using of Duplicate Address Detection on the Home Link, and | >> Home Agents discover each other by means of Neighbor Discovery | >> extensions over that link. | >> | >> The Home Prefix, that is advertized on the Home Link, is a final | >> prefix, as opposed to an aggregation, and it may be used by hosts on | >> the Home Link for autoconfiguration purposes. | >> | >> As we see, the concept of a Home Network for Mobile IPv6 is really a | >> prefix on a link, served by one or more Home Agents as opposed to a | >> routed mesh. We will see in the next sections that NEMO needs | >> additional prefixes for use by the Mobile Networks. For that reason, | >> NEMO extends the concept of Home Network into a more complex, | >> aggregated structure. | > | > | > Pascal, I do not see _NEMO_ needing additional prefixes for use | > of Mobile Networks. It's subnetting that needs additional prefixes. If | > I have a MIP home link with MNs attached to it and I want to add MRs to | > this home then what I have to do first is to allocate /64 prefixes (out | > of the /48 pictured) as MNPs. Then all I have to do is to add routes in | > HA towards these MNPs through the respective HoAs. | > | > This is exactly the same operation I have to do if I have a Link | > (non-MIP) and want to further "subnet it" for non-mobile purposes with | > fixed routers. | > | > That is why I'm not comfortable calling it "extended model". It | > could as well be called "subnetted mode" or simply a "network model". | > | > When reading the draft, I get the feeling that NEMO Home Network extends | > the MIP Home Network. To me, this is a network further subnetted, NEMO | > extends nothing in this. IMHO. | > | >> As this model trivially extends the MIP Home Network | > | > | > Exactly, this "extension" is so trivial it does not even deserve a name | > IMHO. It's plain simple networking. | > | > If there is agreement around getting rid of "extended" then I'm fine. | > Otherwise the current text I read better than the previous (because it | > explains what "extended" means). | > | > Alex From nemo-bounces@ietf.org Wed Jan 12 04:58:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27264 for ; Wed, 12 Jan 2005 04:58:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CofAj-00021t-4e; Wed, 12 Jan 2005 04:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cof3h-0000x3-DE for nemo@megatron.ietf.org; Wed, 12 Jan 2005 04:44:57 -0500 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 EAA26394 for ; Wed, 12 Jan 2005 04:44:55 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CofHh-0000AC-3A for nemo@ietf.org; Wed, 12 Jan 2005 04:59:25 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2005 11:01:09 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0C9i4WK027355; Wed, 12 Jan 2005 10:44:23 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 10:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Wed, 12 Jan 2005 10:44:15 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BFA70@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT4OidLqedzF3XlQaWS3zX3iaFWEQAUQ85Q From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 12 Jan 2005 09:44:20.0840 (UTC) FILETIME=[4A915E80:01C4F88B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable |=20 | another issue with the text. |=20 | > Thus, on the Home Link, the Home Agent MUST intercept all the | > packets to ALL the Mobile Network Nodes on the registered | > prefixes. In order to do so, the Home Agent might perform some | > form of ND proxying for all addresses in all registered Mobile | > Network Prefixes. |=20 | this is better done through a route at the HA for the MNP. | but ofcourse, the above can also be done. you might want to | mention that the HA SHOULD NOT send gratuitous proxy NAs for | the addresses in the MNP. |=20 Vijay, this is the aggregated mode, so the HA advertises the aggregation is the onlink prefix. A host there will not participate to an IGP and will NS any MNN from the aggregation. Obviously the HA will have a route to the MNP, but the Host will not.=20 Do I miss something? Pascal From nemo-bounces@ietf.org Wed Jan 12 04:59:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27356 for ; Wed, 12 Jan 2005 04:59:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CofAn-00022R-5w; Wed, 12 Jan 2005 04:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cof3g-0000wz-N7 for nemo@megatron.ietf.org; Wed, 12 Jan 2005 04:44:56 -0500 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 EAA26390 for ; Wed, 12 Jan 2005 04:44:55 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CofHf-0000AC-E1 for nemo@ietf.org; Wed, 12 Jan 2005 04:59:24 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2005 11:01:07 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0C9i4WI027355; Wed, 12 Jan 2005 10:44:21 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 10:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Wed, 12 Jan 2005 10:43:35 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BFA6F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT4OidLqedzF3XlQaWS3zX3iaFWEQAQ012Q From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 12 Jan 2005 09:44:20.0512 (UTC) FILETIME=[4A5F5200:01C4F88B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] | Sent: Wednesday, January 12, 2005 1:09 AM | To: Pascal Thubert (pthubert) | Cc: nemo@ietf.org | Subject: Re: [nemo] issue 2 diffs |=20 | Pascal, |=20 | the following is already covered in the Basic Support spec. |=20 | > In that case, the Home Address does not match the Home Link | > Prefix, and there is a need to configure the HA in a specific | > mode with the support for the extended Home Network and the | > range of the Mobile Network Prefixes. |=20 | section 6.2 |=20 | - Mobile IPv6 specification [1] requires that the Home Address in | the Binding Update should be configured from a prefix advertised | on the home link. Otherwise the Binding Update is rejected | with status value 132 [1]. This specification relaxes this | requirement so that the Home Agent rejects the Binding Update | only if Home Address does not belong to the prefix that the Home | Agent is configured to serve. |=20 | so the following limitation does not exist. |=20 | > But if an implementation is simply derived from that of MIP, | > then this capability might not exist, and the HA will not be | > able to accept a Home Address based on the MNP. Interesting... so you are saying that any NEMO HA SHOULD have a specific configuration to express the extended Home Network Prefix?=20 I did not interpret that text that way. Like a could or something, for an advanced feature It's good for the HA to know specifically the aggregation in order to automatically inject the route into the IGP. But it can be done indirectly as a static route for instance. So I was saying make sure your implementation has it if you want to derive the Home Address from MNP. I agree it's moot iff it's a MUST or a SHOULD by NEMO terms but I do not understand that it is. Maybe it's a problem against 3963, then, but I do not even think so, because the current text leaves the possibility for some simple implementations with limited features and other, richer. I do not see that this creates an interoperability issue, does it? What do you think? Pascal From nemo-bounces@ietf.org Wed Jan 12 13:18:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03108 for ; Wed, 12 Jan 2005 13:18:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Con1P-0003dh-5h; Wed, 12 Jan 2005 13:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ComoJ-00018x-Bv for nemo@megatron.ietf.org; Wed, 12 Jan 2005 13:01:35 -0500 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 NAA02311 for ; Wed, 12 Jan 2005 13:01:32 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Con2K-0003Sn-8n for nemo@ietf.org; Wed, 12 Jan 2005 13:16:07 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2005 19:17:47 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0CI0iWG016247; Wed, 12 Jan 2005 19:00:55 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 19:00:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Wed, 12 Jan 2005 19:00:37 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6BFD0A@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT4OLw25Wxbp/AcQTW6iqTt/C73xQAl6opQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 12 Jan 2005 18:00:43.0794 (UTC) FILETIME=[A2977F20:01C4F8D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 Oups:) I missed the fact that you had moved the HA. In fact, the picture is supposed to show the Home Link, and the MRs at (virtually) Home. I realized that your change actually gave it a very different meaning, close to the second part of the drawing. So I rolled back, but changed the drawing slightly to write down Home Link. Does it look better now? Pascal | -----Original Message----- | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] | Sent: Wednesday, January 12, 2005 12:58 AM | To: Alexandru Petrescu | Cc: Pascal Thubert (pthubert); nemo@ietf.org | Subject: Re: [nemo] issue 2 diffs |=20 | Alex, |=20 | it is true that regular IPv6 subnetting is used to allocate | prefixes for the home link and the mobile networks. no issues. |=20 | but the MR creating a route for its subnet at the HA which | actually has a subnet of its own, is what we are calling the | NEMO "Extended Home Network Model". so I dont see whats | wrong with the term. |=20 | having said that, it really only a term. I dont care if it | is changed to something else. |=20 | Pascal, do you think it might make sense to re-draw the figure | for the Extended Home Network model as follows. |=20 | | | route v /48 A:B:C::/48 |=20 | --+-----+-----+--+- . -+- . -+-- | | | | | | | HA MR1 MR2 MRi MRN HA link - A:B:C:0::/64 | /64 /64 /64 /64 /64 A:B:C:i::/64 1 < i <=3D = N |=20 |=20 | Extended Home Network | <-----------------------------------------------------------> |=20 | Home Net Mobile Net Mobile Net ... Mobile Net | <------------><------------><------------> ... <------------> |=20 | Vijay |=20 | Alexandru Petrescu wrote: | > Pascal Thubert (pthubert) wrote: | > | >> I created a new section prior to extended with MIP reminders to help | >> explain the difference later. | > | > | > Thanks for this action. I've read the section. It does reflect what we | > have discussed. | > | > It is just I still do not feel comfortable with calling it "extended | > model" I explain below why. Overall it is because we seem to have | > different views on deployment. You seem to see it as one would start | > from scratch to deploy a Home Network that supports mobility (first | > deploy a MIP Home Link, then extend it for MRs). I see it as a Home | > Network already exists and mobility of hosts and routers is added | > simultaneously (thus the prefixes are already allocated by some | > prior to mobility). | > | >> With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and J. | >> Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at | >> Home when they are connected to their Home Link, where they recognize | >> their Home Prefix in Router Advertisement messages. Also, a binding | >> is checked using of Duplicate Address Detection on the Home Link, and | >> Home Agents discover each other by means of Neighbor Discovery | >> extensions over that link. | >> | >> The Home Prefix, that is advertized on the Home Link, is a final | >> prefix, as opposed to an aggregation, and it may be used by hosts on | >> the Home Link for autoconfiguration purposes. | >> | >> As we see, the concept of a Home Network for Mobile IPv6 is really a | >> prefix on a link, served by one or more Home Agents as opposed to a | >> routed mesh. We will see in the next sections that NEMO needs | >> additional prefixes for use by the Mobile Networks. For that reason, | >> NEMO extends the concept of Home Network into a more complex, | >> aggregated structure. | > | > | > Pascal, I do not see _NEMO_ needing additional prefixes for use | > of Mobile Networks. It's subnetting that needs additional prefixes. If | > I have a MIP home link with MNs attached to it and I want to add MRs to | > this home then what I have to do first is to allocate /64 prefixes (out | > of the /48 pictured) as MNPs. Then all I have to do is to add routes in | > HA towards these MNPs through the respective HoAs. | > | > This is exactly the same operation I have to do if I have a Link | > (non-MIP) and want to further "subnet it" for non-mobile purposes with | > fixed routers. | > | > That is why I'm not comfortable calling it "extended model". It | > could as well be called "subnetted mode" or simply a "network model". | > | > When reading the draft, I get the feeling that NEMO Home Network extends | > the MIP Home Network. To me, this is a network further subnetted, NEMO | > extends nothing in this. IMHO. | > | >> As this model trivially extends the MIP Home Network | > | > | > Exactly, this "extension" is so trivial it does not even deserve a name | > IMHO. It's plain simple networking. | > | > If there is agreement around getting rid of "extended" then I'm fine. | > Otherwise the current text I read better than the previous (because it | > explains what "extended" means). | > | > Alex From nemo-bounces@ietf.org Wed Jan 12 16:51:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20744 for ; Wed, 12 Jan 2005 16:51:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coq3U-0005EW-BC; Wed, 12 Jan 2005 16:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copyn-0002fi-Qa for nemo@megatron.ietf.org; Wed, 12 Jan 2005 16:24:37 -0500 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 QAA18309 for ; Wed, 12 Jan 2005 16:24:36 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqCo-0000Ia-Ll for nemo@ietf.org; Wed, 12 Jan 2005 16:39:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0CLtV303595; Wed, 12 Jan 2005 13:55:31 -0800 X-mProtect: <200501122155> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpd5x1VWa; Wed, 12 Jan 2005 13:55:30 PST Message-ID: <41E596B9.8050103@iprg.nokia.com> Date: Wed, 12 Jan 2005 13:29:29 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BFA70@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BFA70@xmb-ams-337.emea.cisco.com> 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: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > | > | another issue with the text. > | > | > Thus, on the Home Link, the Home Agent MUST intercept all the > | > packets to ALL the Mobile Network Nodes on the registered > | > prefixes. In order to do so, the Home Agent might perform some > | > form of ND proxying for all addresses in all registered Mobile > | > Network Prefixes. > | > | this is better done through a route at the HA for the MNP. > | but ofcourse, the above can also be done. you might want to > | mention that the HA SHOULD NOT send gratuitous proxy NAs for > | the addresses in the MNP. > | > > Vijay, this is the aggregated mode, so the HA advertises the aggregation > is the onlink prefix. A host there will not participate to an IGP and > will NS any MNN from the aggregation. Obviously the HA will have a route > to the MNP, but the Host will not. > > Do I miss something? you are right. please ignore this. I thought I read this text in the extended home network model. :( Vijay From nemo-bounces@ietf.org Wed Jan 12 16:53:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21238 for ; Wed, 12 Jan 2005 16:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqGN-0002Tf-Gi; Wed, 12 Jan 2005 16:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coq0w-0003Yt-Gb for nemo@megatron.ietf.org; Wed, 12 Jan 2005 16:26:50 -0500 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 QAA18768 for ; Wed, 12 Jan 2005 16:26:48 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqF2-0000S0-AF for nemo@ietf.org; Wed, 12 Jan 2005 16:41:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0CLvmn06990; Wed, 12 Jan 2005 13:57:48 -0800 X-mProtect: <200501122157> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdP9EIoT; Wed, 12 Jan 2005 13:57:46 PST Message-ID: <41E59742.5030203@iprg.nokia.com> Date: Wed, 12 Jan 2005 13:31:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BFD0A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BFD0A@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 okay. I guess moving the HA down will be confusing. the new figure looks good. Vijay Pascal Thubert (pthubert) wrote: > Oups:) > > I missed the fact that you had moved the HA. In fact, the picture is > supposed to show the Home Link, and the MRs at (virtually) Home. I > realized that your change actually gave it a very different meaning, > close to the second part of the drawing. > > So I rolled back, but changed the drawing slightly to write down Home > Link. > > Does it look better now? > > > Pascal > > | -----Original Message----- > | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > | Sent: Wednesday, January 12, 2005 12:58 AM > | To: Alexandru Petrescu > | Cc: Pascal Thubert (pthubert); nemo@ietf.org > | Subject: Re: [nemo] issue 2 diffs > | > | Alex, > | > | it is true that regular IPv6 subnetting is used to allocate > | prefixes for the home link and the mobile networks. no issues. > | > | but the MR creating a route for its subnet at the HA which > | actually has a subnet of its own, is what we are calling the > | NEMO "Extended Home Network Model". so I dont see whats > | wrong with the term. > | > | having said that, it really only a term. I dont care if it > | is changed to something else. > | > | Pascal, do you think it might make sense to re-draw the figure > | for the Extended Home Network model as follows. > | > | | > | route v /48 A:B:C::/48 > | > | --+-----+-----+--+- . -+- . -+-- > | | | | | | > | HA MR1 MR2 MRi MRN HA link - A:B:C:0::/64 > | /64 /64 /64 /64 /64 A:B:C:i::/64 1 < i <= N > | > | > | Extended Home Network > | <-----------------------------------------------------------> > | > | Home Net Mobile Net Mobile Net ... Mobile Net > | <------------><------------><------------> ... <------------> > | > | Vijay > | > | Alexandru Petrescu wrote: > | > Pascal Thubert (pthubert) wrote: > | > > | >> I created a new section prior to extended with MIP reminders to > help > | >> explain the difference later. > | > > | > > | > Thanks for this action. I've read the section. It does reflect > what we > | > have discussed. > | > > | > It is just I still do not feel comfortable with calling it "extended > | > model" I explain below why. Overall it is because we seem to have > | > different views on deployment. You seem to see it as one would > start > | > from scratch to deploy a Home Network that supports mobility (first > | > deploy a MIP Home Link, then extend it for MRs). I see it as a Home > | > Network already exists and mobility of hosts and routers is added > | > simultaneously (thus the prefixes are already allocated by some > | > prior to mobility). > | > > | >> With Mobile IPv6 (MIP6) specificationJohnson, D., Perkins, C. and > J. > | >> Arkko, Mobility Support in IPv6, June 2004.[7] Mobile Nodes are at > | >> Home when they are connected to their Home Link, where they > recognize > | >> their Home Prefix in Router Advertisement messages. Also, a > binding > | >> is checked using of Duplicate Address Detection on the Home Link, > and > | >> Home Agents discover each other by means of Neighbor Discovery > | >> extensions over that link. > | >> > | >> The Home Prefix, that is advertized on the Home Link, is a final > | >> prefix, as opposed to an aggregation, and it may be used by hosts > on > | >> the Home Link for autoconfiguration purposes. > | >> > | >> As we see, the concept of a Home Network for Mobile IPv6 is really > a > | >> prefix on a link, served by one or more Home Agents as opposed to a > | >> routed mesh. We will see in the next sections that NEMO needs > | >> additional prefixes for use by the Mobile Networks. For that > reason, > | >> NEMO extends the concept of Home Network into a more complex, > | >> aggregated structure. > | > > | > > | > Pascal, I do not see _NEMO_ needing additional prefixes for use > | > of Mobile Networks. It's subnetting that needs additional prefixes. > If > | > I have a MIP home link with MNs attached to it and I want to add MRs > to > | > this home then what I have to do first is to allocate /64 prefixes > (out > | > of the /48 pictured) as MNPs. Then all I have to do is to add > routes in > | > HA towards these MNPs through the respective HoAs. > | > > | > This is exactly the same operation I have to do if I have a Link > | > (non-MIP) and want to further "subnet it" for non-mobile purposes > with > | > fixed routers. > | > > | > That is why I'm not comfortable calling it "extended model". It > | > could as well be called "subnetted mode" or simply a "network > model". > | > > | > When reading the draft, I get the feeling that NEMO Home Network > extends > | > the MIP Home Network. To me, this is a network further subnetted, > NEMO > | > extends nothing in this. IMHO. > | > > | >> As this model trivially extends the MIP Home Network > | > > | > > | > Exactly, this "extension" is so trivial it does not even deserve a > name > | > IMHO. It's plain simple networking. > | > > | > If there is agreement around getting rid of "extended" then I'm > fine. > | > Otherwise the current text I read better than the previous (because > it > | > explains what "extended" means). > | > > | > Alex > From nemo-bounces@ietf.org Wed Jan 12 16:55:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21411 for ; Wed, 12 Jan 2005 16:55:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqQ3-000884-1n; Wed, 12 Jan 2005 16:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqDq-0001Jt-6G for nemo@megatron.ietf.org; Wed, 12 Jan 2005 16:40:10 -0500 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 QAA19942 for ; Wed, 12 Jan 2005 16:40:08 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqRv-0000pn-78 for nemo@ietf.org; Wed, 12 Jan 2005 16:54:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0CMBCv25784; Wed, 12 Jan 2005 14:11:12 -0800 X-mProtect: <200501122211> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdILaRnQ; Wed, 12 Jan 2005 14:11:10 PST Message-ID: <41E59A66.4090209@iprg.nokia.com> Date: Wed, 12 Jan 2005 13:45:10 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] issue 2 diffs References: <7892795E1A87F04CADFCCF41FADD00FC6BFA6F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC6BFA6F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > > | -----Original Message----- > | From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > | Sent: Wednesday, January 12, 2005 1:09 AM > | To: Pascal Thubert (pthubert) > | Cc: nemo@ietf.org > | Subject: Re: [nemo] issue 2 diffs > | > | Pascal, > | > | the following is already covered in the Basic Support spec. > | > | > In that case, the Home Address does not match the Home Link > | > Prefix, and there is a need to configure the HA in a specific > | > mode with the support for the extended Home Network and the > | > range of the Mobile Network Prefixes. > | > | section 6.2 > | > | - Mobile IPv6 specification [1] requires that the Home Address > in > | the Binding Update should be configured from a prefix > advertised > | on the home link. Otherwise the Binding Update is rejected > | with status value 132 [1]. This specification relaxes this > | requirement so that the Home Agent rejects the Binding Update > | only if Home Address does not belong to the prefix that the > Home > | Agent is configured to serve. > | > | so the following limitation does not exist. > | > | > But if an implementation is simply derived from that of MIP, > | > then this capability might not exist, and the HA will not be > | > able to accept a Home Address based on the MNP. > > Interesting... so you are saying that any NEMO HA SHOULD have a specific > configuration to express the extended Home Network Prefix? any NEMO HA should be configured with the prefix of the home network that is configured to serve. one has to make sure the prefix includes all the prefixes given out to the Mobile Routers. this is what the basic support spec says. so the question of a MIP HA supporting a HoA from the MNP does not exist. I dont know what it means when you say "But if an implementation is simply derived from that of MIP....". a HA that suports Mobile Routers is not just a simple MIP HA. it is already configured to serve the MNPs given out to the Mobile Routers. > > I did not interpret that text that way. Like a could or something, for > an advanced feature It's good for the HA to know specifically the > aggregation in order to automatically inject the route into the IGP. But > it can be done indirectly as a static route for instance. > > So I was saying make sure your implementation has it if you want to > derive the Home Address from MNP. I agree it's moot iff it's a MUST or a > SHOULD by NEMO terms but I do not understand that it is. my understanding is that section 6.2 in the Basic Support spec already says this. > Maybe it's a > problem against 3963, then, but I do not even think so, because the > current text leaves the possibility for some simple implementations with > limited features and other, richer. I do not see that this creates an > interoperability issue, does it? nope it does not. just pointing that the limitation you describe does not exist, IMO. > What do you think? its fine to emphasize it again in the Home Networks model draft. Vijay From nemo-bounces@ietf.org Thu Jan 13 17:21:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29201 for ; Thu, 13 Jan 2005 17:21:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDI9-0004cP-V2; Thu, 13 Jan 2005 17:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDAD-0000L9-FT for nemo@megatron.ietf.org; Thu, 13 Jan 2005 17:09:57 -0500 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 RAA28218 for ; Thu, 13 Jan 2005 17:09:54 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDOV-0001y4-O8 for nemo@ietf.org; Thu, 13 Jan 2005 17:24:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0DMevR28207 for ; Thu, 13 Jan 2005 14:40:57 -0800 X-mProtect: <200501132240> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.88.113, claiming to be "[10.241.88.113]") by darkstar.iprg.nokia.com smtpdCW0o9c; Thu, 13 Jan 2005 14:40:55 PST Message-ID: <41E6F183.2070201@iprg.nokia.com> Date: Thu, 13 Jan 2005 14:09:07 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [nemo] Connectathon NEMO testing X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Connectathon 2005 does not currently have NEMO interop testing. http://www.connectathon.org/. when I sent them an email about this, they asked me for a list of other potential participants to see if NEMO should be included. anybody interested in testing at Connectathon? I am not sure if there would be any conformance tests, but we sure can do interop testing. Nokia can provide a HA with NEMO Basic Support protocool. please send an email to this list and/or cthon@sun.com if you are interested in testing the NEMO Basic Support protocol. Vijay From nemo-bounces@ietf.org Thu Jan 13 17:23:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29646 for ; Thu, 13 Jan 2005 17:23:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDKq-0005d9-Ph; Thu, 13 Jan 2005 17:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDGw-0003jf-7o for nemo@megatron.ietf.org; Thu, 13 Jan 2005 17:16:56 -0500 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 RAA28600 for ; Thu, 13 Jan 2005 17:16:51 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDVE-00027F-Hy for nemo@ietf.org; Thu, 13 Jan 2005 17:31:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0DMlS000930; Thu, 13 Jan 2005 14:47:28 -0800 X-mProtect: <200501132247> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.88.113, claiming to be "[10.241.88.113]") by darkstar.iprg.nokia.com smtpdAWDcxC; Thu, 13 Jan 2005 14:47:26 PST Message-ID: <41E6F309.4090906@iprg.nokia.com> Date: Thu, 13 Jan 2005 14:15:37 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tj@kniveton.com, Thierry Ernst , nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO implementations X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit it might also make sense to create a web page on all the available NEMO Basic Support implementations out there. Vijay From nemo-bounces@ietf.org Thu Jan 13 17:47:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01213 for ; Thu, 13 Jan 2005 17:47:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDa9-0003Hj-Pq; Thu, 13 Jan 2005 17:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDUu-0001uM-IG for nemo@megatron.ietf.org; Thu, 13 Jan 2005 17:31:20 -0500 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 RAA00066 for ; Thu, 13 Jan 2005 17:31:17 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDjC-0002VU-Ox for nemo@ietf.org; Thu, 13 Jan 2005 17:46:08 -0500 Received: from [192.168.0.6] (p3115-ipbf37marunouchi.tokyo.ocn.ne.jp [220.104.129.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j0DMV1Fk011027; Fri, 14 Jan 2005 07:31:01 +0900 Date: Fri, 14 Jan 2005 07:31:01 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] Connectathon NEMO testing Organization: Keio Univ. / WIDE In-Reply-To: <41E6F183.2070201@iprg.nokia.com> References: <41E6F183.2070201@iprg.nokia.com> Message-Id: <20050114072639.61A9.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.06.02 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay WIDE project will participate Connectathon and bring NEMO (MR and HA). TAHI project develops conformance tests tool for MR. see www.tahi.org I am not sure they will bring this to connectathon or not. regards, ryuji > Connectathon 2005 does not currently have NEMO interop testing. > http://www.connectathon.org/. when I sent them an email about > this, they asked me for a list of other potential participants > to see if NEMO should be included. > > anybody interested in testing at Connectathon? I am not sure > if there would be any conformance tests, but we sure can do > interop testing. > > Nokia can provide a HA with NEMO Basic Support protocool. > > please send an email to this list and/or cthon@sun.com if you > are interested in testing the NEMO Basic Support protocol. > > Vijay From nemo-bounces@ietf.org Thu Jan 13 17:58:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02131 for ; Thu, 13 Jan 2005 17:58:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDkN-0006wE-G8; Thu, 13 Jan 2005 17:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpDcR-0003ds-9w for nemo@megatron.ietf.org; Thu, 13 Jan 2005 17:39:07 -0500 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 RAA00555 for ; Thu, 13 Jan 2005 17:39:04 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDqh-0002fX-Fy for nemo@ietf.org; Thu, 13 Jan 2005 17:53:54 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id EA5A68001D2; Fri, 14 Jan 2005 00:38:28 +0200 (EET) Date: Fri, 14 Jan 2005 00:38:28 +0200 (EET) From: Ville Nuorvala To: Vijay Devarapalli Subject: Re: [nemo] Connectathon NEMO testing In-Reply-To: <41E6F183.2070201@iprg.nokia.com> Message-ID: References: <41E6F183.2070201@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nemo@ietf.org, cthon@sun.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 On Thu, 13 Jan 2005, Vijay Devarapalli wrote: > Nokia can provide a HA with NEMO Basic Support protocool. > > please send an email to this list and/or cthon@sun.com if you > are interested in testing the NEMO Basic Support protocol. Hi Vijay, Helsinki University of Technology has both a HA and MR supporting NEMO Basic. We are at least interested in doing some interop at Connectathon. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From nemo-bounces@ietf.org Thu Jan 13 18:46:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06439 for ; Thu, 13 Jan 2005 18:46:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEJx-0004eP-Db; Thu, 13 Jan 2005 18:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEDu-0006UT-5G for nemo@megatron.ietf.org; Thu, 13 Jan 2005 18:17:50 -0500 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 SAA04336 for ; Thu, 13 Jan 2005 18:17:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpES2-0003Wm-JG for nemo@ietf.org; Thu, 13 Jan 2005 18:32:38 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 13 Jan 2005 15:17:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0DNH4RP008595; Thu, 13 Jan 2005 15:17:04 -0800 (PST) Date: Thu, 13 Jan 2005 15:17:04 -0800 (PST) From: Sri Gundavelli To: Ville Nuorvala Subject: Re: [nemo] Connectathon NEMO testing In-Reply-To: Message-ID: References: <41E6F183.2070201@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nemo@ietf.org, cthon@sun.com, Vijay Devarapalli , Read Bell X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay, Cisco has the implementation for NEMO Basic Support Protocol and we would love to participate in these interoperability testing events. However, we will not be able to make it to this particular event. But, if some vendor is interested in testing interoperability with our implementation, we will certainly provide all the help including the software images. We will also make efforts to participate in future events. Regards ! Sri. On Fri, 14 Jan 2005, Ville Nuorvala wrote: > On Thu, 13 Jan 2005, Vijay Devarapalli wrote: > > > Nokia can provide a HA with NEMO Basic Support protocool. > > > > please send an email to this list and/or cthon@sun.com if you > > are interested in testing the NEMO Basic Support protocol. > > Hi Vijay, > > Helsinki University of Technology has both a HA and MR supporting NEMO > Basic. We are at least interested in doing some interop at Connectathon. > > Regards, > Ville > > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > From nemo-bounces@ietf.org Thu Jan 13 19:44:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10616 for ; Thu, 13 Jan 2005 19:44:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpFOA-0005BD-UP; Thu, 13 Jan 2005 19:32:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpF1n-0004dE-IH for nemo@megatron.ietf.org; Thu, 13 Jan 2005 19:09:23 -0500 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 TAA08360 for ; Thu, 13 Jan 2005 19:09:20 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpFG6-0004fb-R8 for nemo@ietf.org; Thu, 13 Jan 2005 19:24:12 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j0E09KsZ004698; Thu, 13 Jan 2005 17:09:21 -0700 (MST) Received: from [10.181.32.124] (mvp-10-181-32-124.ea.mot.com [10.181.32.124]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id j0E07txd025704; Thu, 13 Jan 2005 18:07:56 -0600 Message-ID: <41E70D9D.7040603@motorola.com> Date: Fri, 14 Jan 2005 01:09:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Connectathon NEMO testing References: <41E6F183.2070201@iprg.nokia.com> In-Reply-To: <41E6F183.2070201@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD7508B5342927E9278534F23" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD7508B5342927E9278534F23 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay, how about interop testing over the Internet? Alex Vijay Devarapalli wrote: > Connectathon 2005 does not currently have NEMO interop testing. > http://www.connectathon.org/. when I sent them an email about > this, they asked me for a list of other potential participants > to see if NEMO should be included. > > anybody interested in testing at Connectathon? I am not sure > if there would be any conformance tests, but we sure can do > interop testing. > > Nokia can provide a HA with NEMO Basic Support protocool. > > please send an email to this list and/or cthon@sun.com if you > are interested in testing the NEMO Basic Support protocol. > > Vijay > --------------enigD7508B5342927E9278534F23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB5w2tMmC0w56zj54RAnizAKCSIVIvuRWgi+zrBA5yJTsrwvc7PgCeKXaf j9YDHKuU9QsaLveLtppJV40= =Yy5Q -----END PGP SIGNATURE----- --------------enigD7508B5342927E9278534F23-- From nemo-bounces@ietf.org Thu Jan 13 20:07:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11952 for ; Thu, 13 Jan 2005 20:07:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpFrU-0008Bj-20; Thu, 13 Jan 2005 20:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpFSz-0007ml-43 for nemo@megatron.ietf.org; Thu, 13 Jan 2005 19:37:29 -0500 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 TAA10329 for ; Thu, 13 Jan 2005 19:37:25 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpFhJ-0005GC-7X for nemo@ietf.org; Thu, 13 Jan 2005 19:52:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0E18SZ14584; Thu, 13 Jan 2005 17:08:28 -0800 X-mProtect: <200501140108> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141110.americas.nokia.com (172.18.141.110, claiming to be "[172.18.141.110]") by darkstar.iprg.nokia.com smtpdmECvMg; Thu, 13 Jan 2005 17:08:26 PST Message-ID: <41E7141C.3070409@iprg.nokia.com> Date: Thu, 13 Jan 2005 16:36:44 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Connectathon NEMO testing References: <41E6F183.2070201@iprg.nokia.com> <41E70D9D.7040603@motorola.com> In-Reply-To: <41E70D9D.7040603@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 good idea. http://www.watersprings.org/pub/id/draft-kniveton-mipv6-remote-testing-00.txt was supposed to address this. it seems to have expired, TJ?. ETSI has a facility for remote MIPv6 testing http://mip6.plugtests.org/. maybe that can be extended to NEMO as well. Vijay Alexandru Petrescu wrote: > Vijay, how about interop testing over the Internet? > > Alex > > Vijay Devarapalli wrote: > >> Connectathon 2005 does not currently have NEMO interop testing. >> http://www.connectathon.org/. when I sent them an email about >> this, they asked me for a list of other potential participants >> to see if NEMO should be included. >> >> anybody interested in testing at Connectathon? I am not sure >> if there would be any conformance tests, but we sure can do >> interop testing. >> >> Nokia can provide a HA with NEMO Basic Support protocool. >> >> please send an email to this list and/or cthon@sun.com if you >> are interested in testing the NEMO Basic Support protocol. >> >> Vijay >> > From nemo-bounces@ietf.org Thu Jan 13 21:35:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18408 for ; Thu, 13 Jan 2005 21:35:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpH9A-0000FG-6H; Thu, 13 Jan 2005 21:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpH8Q-0007kz-UP for nemo@megatron.ietf.org; Thu, 13 Jan 2005 21:24:23 -0500 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 VAA17654 for ; Thu, 13 Jan 2005 21:24:20 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpHMl-0007Ip-Gb for nemo@ietf.org; Thu, 13 Jan 2005 21:39:12 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Jan 2005 19:28:01 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0E2LPl2006408; Thu, 13 Jan 2005 18:21:25 -0800 (PST) Received: from dshell-w2k02.cisco.com (rtp-vpn1-412.cisco.com [10.82.225.156]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA24802; Thu, 13 Jan 2005 18:21:25 -0800 (PST) Message-Id: <4.3.2.7.2.20050113212014.00c44718@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jan 2005 21:21:21 -0500 To: Vijay Devarapalli From: Daniel Shell Subject: Re: [nemo] Connectathon NEMO testing In-Reply-To: <41E7141C.3070409@iprg.nokia.com> References: <41E70D9D.7040603@motorola.com> <41E6F183.2070201@iprg.nokia.com> <41E70D9D.7040603@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Vijay I would be willing to use the internet as well from my lab in Cleveland OHIO USA. form NEMO Basic as well as extended. At 04:36 PM 1/13/2005 -0800, Vijay Devarapalli wrote: >good idea. > >http://www.watersprings.org/pub/id/draft-kniveton-mipv6-remote-testing-00.txt >was supposed to address this. it seems to have expired, TJ?. >ETSI has a facility for remote MIPv6 testing >http://mip6.plugtests.org/. > >maybe that can be extended to NEMO as well. > >Vijay > >Alexandru Petrescu wrote: >>Vijay, how about interop testing over the Internet? >>Alex >>Vijay Devarapalli wrote: >> >>>Connectathon 2005 does not currently have NEMO interop testing. >>>http://www.connectathon.org/. when I sent them an email about >>>this, they asked me for a list of other potential participants >>>to see if NEMO should be included. >>> >>>anybody interested in testing at Connectathon? I am not sure >>>if there would be any conformance tests, but we sure can do >>>interop testing. >>> >>>Nokia can provide a HA with NEMO Basic Support protocool. >>> >>>please send an email to this list and/or cthon@sun.com if you >>>are interested in testing the NEMO Basic Support protocol. >>> >>>Vijay Dan Shell Government Service Unit CISCO Systems IP mobility/Wireless/Satellite 440 331 5663 From nemo-bounces@ietf.org Thu Jan 13 21:55:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19739 for ; Thu, 13 Jan 2005 21:55:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpHTK-0001Bk-IT; Thu, 13 Jan 2005 21:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpHPO-0005v7-3v for nemo@megatron.ietf.org; Thu, 13 Jan 2005 21:41:54 -0500 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 VAA18857 for ; Thu, 13 Jan 2005 21:41:51 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpHdZ-0007fb-9h for nemo@ietf.org; Thu, 13 Jan 2005 21:56:43 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id j0E2euFa054495; Fri, 14 Jan 2005 11:40:56 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id j0E2euEn066905; Fri, 14 Jan 2005 11:40:56 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) In-Reply-To: <41E7141C.3070409@iprg.nokia.com> References: <41E6F183.2070201@iprg.nokia.com> <41E70D9D.7040603@motorola.com> <41E7141C.3070409@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hiroshi MIYATA Subject: Re: [nemo] Connectathon NEMO testing Date: Fri, 14 Jan 2005 11:40:57 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit As we announced in previous IETF, You will run MR conformance test in coming TAHI Event. Why you don't come? ;-) Anyway, if you are interested in Remote testing, how about testing with TAHI NEMO participants? Some implementers will be TAHI event. Of course we need to negotiate TAHI NEMO Participants. FYI. The TAHI test event is scheduled on Jan. 24 - 28. Thanks, ...miyata On 2005/01/14, at 9:36, Vijay Devarapalli wrote: > good idea. > > http://www.watersprings.org/pub/id/draft-kniveton-mipv6-remote- > testing-00.txt > was supposed to address this. it seems to have expired, TJ?. > ETSI has a facility for remote MIPv6 testing > http://mip6.plugtests.org/. > > maybe that can be extended to NEMO as well. > > Vijay > > Alexandru Petrescu wrote: >> Vijay, how about interop testing over the Internet? >> Alex >> Vijay Devarapalli wrote: >>> Connectathon 2005 does not currently have NEMO interop testing. >>> http://www.connectathon.org/. when I sent them an email about >>> this, they asked me for a list of other potential participants >>> to see if NEMO should be included. >>> >>> anybody interested in testing at Connectathon? I am not sure >>> if there would be any conformance tests, but we sure can do >>> interop testing. >>> >>> Nokia can provide a HA with NEMO Basic Support protocool. >>> >>> please send an email to this list and/or cthon@sun.com if you >>> are interested in testing the NEMO Basic Support protocol. >>> >>> Vijay >>> > > > From nemo-bounces@ietf.org Thu Jan 13 22:55:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22622 for ; Thu, 13 Jan 2005 22:55:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpIVD-0006P5-QW; Thu, 13 Jan 2005 22:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpISG-0004pK-HM for nemo@megatron.ietf.org; Thu, 13 Jan 2005 22:48:58 -0500 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 WAA22227 for ; Thu, 13 Jan 2005 22:48:53 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpIgZ-0000Po-PO for nemo@ietf.org; Thu, 13 Jan 2005 23:03:47 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 441004C0C6; Fri, 14 Jan 2005 12:48:07 +0900 (JST) Date: Fri, 14 Jan 2005 12:51:45 +0900 From: Thierry Ernst To: Vijay Devarapalli , tj@kniveton.com, nemo@ietf.org Subject: Re: [nemo] NEMO implementations Message-Id: <20050114125145.58be23b1.ernst@sfc.wide.ad.jp> In-Reply-To: <41E6F309.4090906@iprg.nokia.com> References: <41E6F309.4090906@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, > it might also make sense to create a web page on all the > available NEMO Basic Support implementations out there. It's a good idea. I think the best is to create such a list on the NEMO page http://www.mobilenetworks.org/nemo/, no ? If TJ agree, every one can send the information: - name of the project or company - url where to find more information - OS and version - name of the implementation Other information should be available on the developer's own web page. Thierrry From nemo-bounces@ietf.org Tue Jan 18 08:07:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20371 for ; Tue, 18 Jan 2005 08:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqt2y-0003Cp-Kv; Tue, 18 Jan 2005 08:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqt09-0002iU-8g for nemo@megatron.ietf.org; Tue, 18 Jan 2005 08:02:29 -0500 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 IAA19590 for ; Tue, 18 Jan 2005 08:02:27 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqtFO-0007Gg-3d for nemo@ietf.org; Tue, 18 Jan 2005 08:18:16 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2Osf006426 for ; Tue, 18 Jan 2005 22:02:24 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2NUn024139 for ; Tue, 18 Jan 2005 22:02:24 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2No0024136 for ; Tue, 18 Jan 2005 22:02:23 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2MIm011478 for ; Tue, 18 Jan 2005 22:02:23 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2MUq011475 for ; Tue, 18 Jan 2005 22:02:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2LJ9016622 for ; Tue, 18 Jan 2005 22:02:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2Lnk009489 for ; Tue, 18 Jan 2005 22:02:21 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (imd0.m.ecl.ntt.co.jp [129.60.5.142]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0ID2LEk009484 for ; Tue, 18 Jan 2005 22:02:21 +0900 (JST) Received: from [129.60.10.107] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA08814 for ; Tue, 18 Jan 2005 22:02:20 +0900 (JST) Date: Tue, 18 Jan 2005 22:07:06 +0900 From: Hiroyuki Ohnishi To: nemo@ietf.org Message-Id: <20050118213149.5FC5.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [nemo] questions about nemo basic support X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit hi all, I have some questions about NEMO basic support. -In the case that MR receives BA with Status=0 and Rbit=off in response for de-registarion, should the MR think the de-registration as failure one? -In section 8.5, it says "A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes as described in Section 8.5 of [1].". Do MRs support MPS/MPA? If so, in which situation do MRs use MPS/MPA? -The draft defines two mode explicit mode and implicit mode. Is there any case in which MRs use these two modes selectively? In which situation do MRs use this function? roaming situation? Best regard, -- Hiroyuki Ohnishi From nemo-bounces@ietf.org Tue Jan 18 14:03:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20321 for ; Tue, 18 Jan 2005 14:03:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqybY-0001IU-TB; Tue, 18 Jan 2005 14:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqyW3-0000Q8-9T for nemo@megatron.ietf.org; Tue, 18 Jan 2005 13:55:47 -0500 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 NAA19742 for ; Tue, 18 Jan 2005 13:55:45 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqylL-0008KR-KJ for nemo@ietf.org; Tue, 18 Jan 2005 14:11:37 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j0IItdsZ011892; Tue, 18 Jan 2005 11:55:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id j0IIs7Mn002197; Tue, 18 Jan 2005 12:54:08 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6D03486602A; Tue, 18 Jan 2005 19:55:36 +0100 (CET) Message-ID: <41ED5BA2.1070901@motorola.com> Date: Tue, 18 Jan 2005 19:55:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroyuki Ohnishi Subject: Re: [nemo] questions about nemo basic support References: <20050118213149.5FC5.OHNISHI.HIROYUKI@lab.ntt.co.jp> In-Reply-To: <20050118213149.5FC5.OHNISHI.HIROYUKI@lab.ntt.co.jp> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8AEC35FDEDB45095A73BD10E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8AEC35FDEDB45095A73BD10E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hiroyuki Ohnishi wrote: > hi all, > > I have some questions about NEMO basic support. > > -In the case that MR receives BA with Status=0 and Rbit=off in > response for de-registarion, should the MR think the de-registration > as failure one? I think it should only think that the MR's Home Address was correctly de-registered and assume nothing about the MNP being or not being de-registered. > -In section 8.5, it says "A Mobile Router MUST implement all > requirements for IPv6 Mobile Nodes as described in Section 8.5 of > [1].". Do MRs support MPS/MPA? If so, in which situation do MRs use > MPS/MPA? Yes, in theory MR MUST support MPS/MPA just like MH would do. The above phrase is more saying that a MR implementation is largely derived from an existing MH implementation that does RFC3775. MR may use MPS/MPA in situations where a home link get renumbered. Just like MH uses the same MPS/MPA to learn when things at home change and it does not have an opportunity to come home. In theory this may induce a change in the Home Address too (stateless autoconf), but I'm not sure it's mentioned in RFC3775. I think TJ may have a better explanation of why and when MPS/MPA are used. > -The draft defines two mode explicit mode and implicit mode. Is there > any case in which MRs use these two modes selectively? Using the two modes "selectively"? Yes, it should use only one of them. Implicit mode is more appropriate when a routing protocol is used too. That is needed if there are many MRs, the home network is large and the moving network is large too. Explicit mode is more appropriate when all routing is done with Mobile IP. > In which situation do MRs use this function? roaming situation? MR can use either implicit or explicit mode for any roaming situation. Am I addressing your questions ok? Alex --------------enig8AEC35FDEDB45095A73BD10E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB7VuoMmC0w56zj54RAi9bAKDNY2Cs8ITodztg14crLUq1IsiDFgCg7ULx yh7kvOzCyxolydIX/kjJBMc= =fiyU -----END PGP SIGNATURE----- --------------enig8AEC35FDEDB45095A73BD10E-- From nemo-bounces@ietf.org Tue Jan 18 14:33:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23052 for ; Tue, 18 Jan 2005 14:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqz4W-0007Lu-Ou; Tue, 18 Jan 2005 14:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqz1K-0006jc-6W for nemo@megatron.ietf.org; Tue, 18 Jan 2005 14:28:06 -0500 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 OAA22596 for ; Tue, 18 Jan 2005 14:28:04 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzGc-0000mX-Ui for nemo@ietf.org; Tue, 18 Jan 2005 14:43:56 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0IJwja16451; Tue, 18 Jan 2005 11:58:45 -0800 X-mProtect: <200501181958> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdSVW41c; Tue, 18 Jan 2005 11:58:43 PST Message-ID: <41ED6486.9030401@iprg.nokia.com> Date: Tue, 18 Jan 2005 11:33:26 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroyuki Ohnishi Subject: Re: [nemo] questions about nemo basic support References: <20050118213149.5FC5.OHNISHI.HIROYUKI@lab.ntt.co.jp> In-Reply-To: <20050118213149.5FC5.OHNISHI.HIROYUKI@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hiroyuki Ohnishi wrote: > hi all, > > I have some questions about NEMO basic support. > > -In the case that MR receives BA with Status=0 and Rbit=off in response > for de-registarion, should the MR think the de-registration as failure > one? its a weird case. did the earlier successful BAs have the R bit set? if the earlier successful BA had the R bit set, then it means the HA supports Mobile Routers. in this case, if the binding cache for MR's HoA is removed, all the associated routes for MNPs are also removed. so it is a successful registration. from section 6.7 In addition, the Home Agent removes the bi-directional tunnel and stops forwarding packets to the Mobile Network. The Home Agent should keep all necessary information to clean up whichever routes it installed, whether they come from an implicit or explicit source. In Explicit mode, the Home Agent MUST ignore any Mobile Network Prefix Options present in the de-registration Binding Update. its a bug in the HA implementation if the HA set the R bit in the earlier BAs and not in the de-registration BA. if the earlier BA did not have the R bit set, then the HA does not support Mobile Routes at all. so there is no issue. Vijay From nemo-bounces@ietf.org Fri Jan 21 01:34:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23568 for ; Fri, 21 Jan 2005 01:34:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrsIT-0006YK-85; Fri, 21 Jan 2005 01:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmpyw-0000h2-Mm for nemo@megatron.ietf.org; Fri, 07 Jan 2005 04:00:30 -0500 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 EAA27020 for ; Fri, 7 Jan 2005 04:00:28 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmqBq-0003N7-Dv for nemo@ietf.org; Fri, 07 Jan 2005 04:13:53 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 10:00:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 7 Jan 2005 10:00:21 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201A0F55F@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPA= From: "BINET David RD-CORE-CAE" To: "Pascal Thubert \(pthubert\)" , "Daniel Shell \(dshell\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Jan 2005 09:00:22.0292 (UTC) FILETIME=[51CE2540:01C4F497] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 21 Jan 2005 01:29:26 -0500 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 >From the draft, I understand that the question about the configuration = of Home Address is only valid in extended mode. In aggregated mode and = virtual mode, there is no specific Home subnet and Home Address will be = configured on any MNP.=20 I think it could be useful to distinguish both modes in current = "extended mode", one if the Home Address is taken from Home Net (basic = one) and one if the home address is taken from Mobile Net (extended = one). David=20 -----Message d'origine----- De : nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] De la part de = Pascal Thubert (pthubert) Envoy=E9 : jeudi 6 janvier 2005 18:16 =C0 : Daniel Shell (dshell); Alexandru Petrescu Cc : nemo@ietf.org Objet : RE: [nemo] RE: about the Home Network Models WG item In fact, extended means versus the MIP Home Agent which is the 'basic'. In all modes, we can take the Home Address from a Mobile Network. But I = agree with Alex it's a bit complex (actually almost against nature :) to = do it with extended mode. OTOH, it seems to me that it's the preferred = mode in the aggregated case. Comments anybody? My suggestion to fix this issue is: 1) to explain better that extended is versus MIP Home at the beginning = of that section 2) to describe better the case where the Home Address is taken from the = Home Link in extended and say it's the preferred mode, and explain why 3) in aggregated, say that the address is taken from the MNP and explain = why (DAD related). Once we agree no the approach we can start proposing text :) Pascal | -----Original Message----- | From: Daniel Shell (dshell) | Sent: Wednesday, January 05, 2005 7:24 PM | To: Alexandru Petrescu | Cc: Pascal Thubert (pthubert); nemo@ietf.org | Subject: Re: [nemo] RE: about the Home Network Models WG item |=20 | Sounds good to have the sections labelled |=20 | Basic | Extended | Aggregated | Virtual |=20 | Would like to see what Pascal says though. |=20 |=20 |=20 |=20 | At 06:58 PM 1/5/2005 +0100, Alexandru Petrescu wrote: | >Pascal Thubert (pthubert) wrote: | >[...] | >>please present on this list at this time, and if you get enough support, | >>I'll do the changes as required. | > | >I do not think in the simplest Home Network configuration the MR may use | >a Home Address derived from the prefix assigned on its moving network = | >link, the MNP. In the simplest cases, the MR Home Address is derived = | >from the prefix valid on the Home Link. | > | >Or, section 4.1 Extended Home Network configuration has a last item | saying: | >>Alternatively, a Mobile Router could also form a Home Address from=20 | >>one of its prefixes and use it to register[...] | > | >I think this kind of item should belong to other more complex Home | Network | >configurations. | > | >Besides, I think that a useful informational document on the types of | home | >networks should describe several such networks - in the order of=20 | >simplicity - starting first from the most simple and basic and obvious | and | >only later to the most exotic. | > | >Or, while the current document does describe three such networks, there | >does not seem to be an order from basic to complex. The first described | >is already "Extended" and the other two are "Aggregated" and=20 | >"Virtual". The "Aggregated" is a little more complex than the "Extended" | >in that the MR looks up its MNNs via ND on the Home Link, which is a=20 | >little exotic feature. The "Virtual" model is the most exotic in that | >there is no returning home procedure for example. | > | >So, I understand there is a form of scale on differentiation, from the | >most basic up to the most complex, but the most basic is still called = | >"Extended" and allows MR HoA from MNP. | > | >Hence my proposal to call the basic model just "Basic Home Network" and | >this model not to use MR Home Address from the MNP. Alternatively, I = | >propose to introduce a 4th model, called "Basic Home Network Model", that | >would come before the other three models, and in which MR would only=20 | >construct its Home Address from the prefix on the home link, that would | >perform ND for that address, that would implement the NEMO Returning Home | >procedure and for which address the HA performs proxy ND when MR not at | >home, according to Mobile IPv6. | > | >What do you think Pascal? What do the others think? | > | >Alex |=20 | Dan Shell | Government Service Unit | CISCO Systems | IP mobility/Wireless/Satellite | 440 331 5663 From nemo-bounces@ietf.org Mon Jan 24 21:16:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00891 for ; Mon, 24 Jan 2005 21:16:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtGAd-0002e5-P1; Mon, 24 Jan 2005 21:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtE4p-00007X-OQ; Mon, 24 Jan 2005 18:56:59 -0500 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 SAA19838; Mon, 24 Jan 2005 18:56:56 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtELQ-0006Cp-S4; Mon, 24 Jan 2005 19:14:09 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j0ONtmQ28357; Mon, 24 Jan 2005 15:55:48 -0800 (PST) Message-Id: <200501242355.j0ONtmQ28357@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 24 Jan 2005 15:55:48 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Mon, 24 Jan 2005 21:11:05 -0500 Cc: nemo@ietf.org, rfc-editor@rfc-editor.org Subject: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Request for Comments is now available in online RFC libraries. RFC 3963 Title: Network Mobility (NEMO) Basic Support Protocol Author(s): V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert Status: Standards Track Date: January 2005 Mailbox: vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com Pages: 33 Characters: 75955 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-nemo-basic-support-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3963.txt This document describes the Network Mobility (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 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 so that network mobility is transparent to the nodes inside the Mobile Network. This document is a product of the Network Mobility Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050124155415.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3963 --OtherAccess Content-Type: Message/External-body; name="rfc3963.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050124155415.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Jan 25 12:43:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23253 for ; Tue, 25 Jan 2005 12:43:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtUgQ-0007te-8f; Tue, 25 Jan 2005 12:40:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtUfN-0007cE-7R for nemo@megatron.ietf.org; Tue, 25 Jan 2005 12:39:49 -0500 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 MAA22824 for ; Tue, 25 Jan 2005 12:39:46 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtUw7-0001IB-Km for nemo@ietf.org; Tue, 25 Jan 2005 12:57:08 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA20321 for ; Tue, 25 Jan 2005 11:39:12 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0PHdAs06772 for ; Tue, 25 Jan 2005 11:39:11 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol - route optimization? Date: Tue, 25 Jan 2005 09:39:11 -0800 Message-ID: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> Thread-Topic: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol - route optimization? Thread-Index: AcUCg+tSqAOjlzXyQpmySGHfIJ2rzAAf+s4Q From: "Hsu, Julian P" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 folks, I'm wondering if someone could answer a newbie (first time mailing list poster) question. I notice that the RFC says that it does not describe route optimization of traffic between nodes in the mobile network and correspondent nodes, and later that it allows route optimization for traffic originating from the Mobile Router. Is there a discussion somewhere about the reasons for excluding mobile network nodes from the route optimization process? I couldn't tell from my readings of rfc 3775 on Mobility Support in IPv6 and this RFC 3963 why it would not be straightforward to have the NEMO home agent allow route optimization to mobile network nodes known to be attached to a mobile router.. Thanks! Julian=20 -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, January 24, 2005 3:56 PM To: ietf-announce@ietf.org Cc: nemo@ietf.org; rfc-editor@rfc-editor.org Subject: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol A new Request for Comments is now available in online RFC libraries. RFC 3963 Title: Network Mobility (NEMO) Basic Support Protocol Author(s): V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert Status: Standards Track Date: January 2005 Mailbox: vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com Pages: 33 Characters: 75955 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-nemo-basic-support-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3963.txt This document describes the Network Mobility (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 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 so that network mobility is transparent to the nodes inside the Mobile Network. This document is a product of the Network Mobility Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. From nemo-bounces@ietf.org Tue Jan 25 14:07:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28559 for ; Tue, 25 Jan 2005 14:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtW01-000310-Jb; Tue, 25 Jan 2005 14:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtVzb-0002tu-Lt for nemo@megatron.ietf.org; Tue, 25 Jan 2005 14:04:47 -0500 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 OAA28451 for ; Tue, 25 Jan 2005 14:04:46 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtWGN-0004E7-41 for nemo@ietf.org; Tue, 25 Jan 2005 14:22:07 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j0PJAxkI025407; Tue, 25 Jan 2005 12:10:59 -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 j0PJ4gSE009112; Tue, 25 Jan 2005 13:04:43 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4607A855024; Tue, 25 Jan 2005 20:04:42 +0100 (CET) Message-ID: <41F6983E.8070806@motorola.com> Date: Tue, 25 Jan 2005 20:04:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hsu, Julian P" Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol - route optimization? References: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> In-Reply-To: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFCECC2FE05EDB0A20C3EC781" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFCECC2FE05EDB0A20C3EC781 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hsu, Julian P wrote: > poster) question. I notice that the RFC says that it does not > describe route optimization of traffic between nodes in the mobile > network and correspondent nodes, and later that it allows route > optimization for traffic originating from the Mobile Router. Yes, exactly, MR can use RO just like any MH (Mobile Host, what people call MN). An application running on MR may easily enjoy the benefits of RO as per RFC3775. > Is there a discussion somewhere about the reasons for excluding > mobile network nodes from the route optimization process? RO discussion in the early archives in mobilenetworks.org/nemo/archives. An application on LFN initiates communication to CN. The MR is just in between and tunnels/detunnels. The LFN does not implement RO because it's not Mobile IPv6 node. How could MR send RR (Return Routability) tests to CN if that MR's Home Address is different than the LFN's address. These two addresses are obviously different. In order to make this "proxy" RR (MR does RR "on behalf" of LFN) work there is need of some insurance at MR that it trusts the LFN and vice-versa. > I couldn't tell from my readings of rfc 3775 on Mobility Support in > IPv6 and this RFC 3963 why it would not be straightforward to have > the NEMO home agent allow route optimization to mobile network nodes > known to be attached to a mobile router.. It's less a matter of HA, than a matter of MR and LFN. LEss, but no 0. I imagine HA uses its BC when participating in RR for rfc3775, and LFN does not have an entry in the BC (MR does). The NEMO prefix may be in the BC, ok, but HA could not participate in RR tests for all Home Addresses of the NEMO prefix. Why are you asking? Alex --------------enigFCECC2FE05EDB0A20C3EC781 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB9phJMmC0w56zj54RAiw1AJ9r1t9auEVYqmn1Ftf4rtFqXZuvFACeMe4E sxNxkJPurgCEidSPiCVHmGE= =zckF -----END PGP SIGNATURE----- --------------enigFCECC2FE05EDB0A20C3EC781-- From nemo-bounces@ietf.org Tue Jan 25 14:58:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02139 for ; Tue, 25 Jan 2005 14:58:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtWjK-0002hd-Oi; Tue, 25 Jan 2005 14:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtWhO-0001fE-UH for nemo@megatron.ietf.org; Tue, 25 Jan 2005 14:50:03 -0500 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 OAA01660 for ; Tue, 25 Jan 2005 14:50:00 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtWy9-0005dA-4u for nemo@ietf.org; Tue, 25 Jan 2005 15:07:22 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA08206; Tue, 25 Jan 2005 11:49:26 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0PJnOs18633; Tue, 25 Jan 2005 13:49:24 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol- route optimization? Date: Tue, 25 Jan 2005 11:49:21 -0800 Message-ID: <96A337F5C5D4AB4C88A54E752D2A66E315B6DF@XCH-SWBH-04.sw.nos.boeing.com> Thread-Topic: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol- route optimization? Thread-Index: AcUDEL0rpONJo/a9Sm+h9UxH9tS2dgAA/tmw From: "Hsu, Julian P" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Alexandru, Thanks for your reply! I was especially heartened to find a NEMO terminology internet draft on the site that you directed me to. I am interested in this topic because I am involved in system engineering for a network architecture that has mobile networks with changing points of connection to the infrastructure network. Pretty much exactly what NEMO seems to be addressing. The restriction that LFNs go through the tunnel, though, can be undesirable when the triangle routing from LFN to CN goes through say more high latency, low bandwidth, etc. links than the optimized path.. Are there any developments or efforts towards solidifying alternatives based on the MR trusting the LFN, or will running Mobile IPv6 within those LFNs that would like to initiate their own RR tests be sufficient? Thanks again, Julian -----Original Message----- From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 Sent: Tuesday, January 25, 2005 11:05 AM To: Hsu, Julian P Cc: nemo@ietf.org Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol- route optimization? Hsu, Julian P wrote: > poster) question. I notice that the RFC says that it does not=20 > describe route optimization of traffic between nodes in the mobile=20 > network and correspondent nodes, and later that it allows route=20 > optimization for traffic originating from the Mobile Router. Yes, exactly, MR can use RO just like any MH (Mobile Host, what people call MN). An application running on MR may easily enjoy the benefits of RO as per RFC3775. > Is there a discussion somewhere about the reasons for excluding mobile > network nodes from the route optimization process? RO discussion in the early archives in mobilenetworks.org/nemo/archives. An application on LFN initiates communication to CN. The MR is just in=20 between and tunnels/detunnels. The LFN does not implement RO because=20 it's not Mobile IPv6 node. How could MR send RR (Return Routability) tests to CN if that MR's Home=20 Address is different than the LFN's address. These two addresses are=20 obviously different. In order to make this "proxy" RR (MR does RR "on=20 behalf" of LFN) work there is need of some insurance at MR that it=20 trusts the LFN and vice-versa. > I couldn't tell from my readings of rfc 3775 on Mobility Support in=20 > IPv6 and this RFC 3963 why it would not be straightforward to have the > NEMO home agent allow route optimization to mobile network nodes known > to be attached to a mobile router.. It's less a matter of HA, than a matter of MR and LFN. LEss, but no 0. I imagine HA uses its BC when participating in RR for rfc3775, and LFN=20 does not have an entry in the BC (MR does). The NEMO prefix may be in=20 the BC, ok, but HA could not participate in RR tests for all Home=20 Addresses of the NEMO prefix. Why are you asking? Alex From nemo-bounces@ietf.org Tue Jan 25 15:33:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05151 for ; Tue, 25 Jan 2005 15:33:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtXDP-0001Nm-UL; Tue, 25 Jan 2005 15:23:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtX7c-0006Sm-5T for nemo@megatron.ietf.org; Tue, 25 Jan 2005 15:17:08 -0500 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 PAA04002 for ; Tue, 25 Jan 2005 15:17:06 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtXON-0006TT-3Z for nemo@ietf.org; Tue, 25 Jan 2005 15:34:28 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0PKIvJD019893; Tue, 25 Jan 2005 13:18:57 -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 j0PKGwSE012474; Tue, 25 Jan 2005 14:16:59 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4C949855024; Tue, 25 Jan 2005 21:16:58 +0100 (CET) Message-ID: <41F6A933.9090300@motorola.com> Date: Tue, 25 Jan 2005 21:16:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hsu, Julian P" Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol- route optimization? References: <96A337F5C5D4AB4C88A54E752D2A66E315B6DF@XCH-SWBH-04.sw.nos.boeing.com> In-Reply-To: <96A337F5C5D4AB4C88A54E752D2A66E315B6DF@XCH-SWBH-04.sw.nos.boeing.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66D4D79BD6C19DE17BAB9419" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66D4D79BD6C19DE17BAB9419 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hsu, Julian P wrote: > The restriction that LFNs go through the tunnel, though, can be > undesirable when the triangle routing from LFN to CN goes through say > more high latency, low bandwidth, etc. Right, if with systems engineering one could find out how undesirable is that triangle routing then it's same engineering that may propose a valuable idea. > Are there any developments or efforts towards solidifying alternatives > based on the MR trusting the LFN, or will running Mobile IPv6 within > those LFNs that would like to initiate their own RR tests be sufficient? I don't know. I think one does not exclude the other. Then, for each of the questions. MR trusting the LFN - no idea whether anything was propsed up to now (other than maybe SEND, but that won't cross subnets and the moving network may be subnetted with FRs Fixed Routers). Running Mobile IPv6 between LFN and CN then demands enhancements to LFN ("LFN" basically says "no Mobile IPv6") and to MR and to HA and presumably don't touch a 3775 RR CN. Somehow MR and HA must do RR for the address of LFN, and that's not specified anywhere. Remark, "LFN no Mobile IPv6" does not mean to me that LFN is forbidden to become a "MH", i.e. have a Mobile IPv6 stack. It could very well be a MH that is "at home" in the moving network, i.e. does not use the tunnel when in the moving network and its HA is _within_ the moving network, on the same link (this MH uses a tunnel to MR when it leaves the moving network, or when it goes down below some FR in the same moving network). This onboard HA could actually be the MR itself. And from this, just use your imagination; but within the limits of systems engineering :-) Alex --------------enig66D4D79BD6C19DE17BAB9419 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB9qk6MmC0w56zj54RAqwjAKCpdOVrMGQHsaSY1Kc/KfL9jZX8nQCfdQNo njkO38ONMnUEG0ESJpDAfNQ= =bG9R -----END PGP SIGNATURE----- --------------enig66D4D79BD6C19DE17BAB9419-- From nemo-bounces@ietf.org Tue Jan 25 21:00:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07791 for ; Tue, 25 Jan 2005 21:00:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtcIc-0007HF-La; Tue, 25 Jan 2005 20:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtcAm-0005Qv-7I for nemo@megatron.ietf.org; Tue, 25 Jan 2005 20:40:46 -0500 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 UAA05805 for ; Tue, 25 Jan 2005 20:40:37 -0500 (EST) 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 1CtcRU-0002bQ-Pu for nemo@ietf.org; Tue, 25 Jan 2005 20:58:02 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id D40B46219; Tue, 25 Jan 2005 17:39:48 -0800 (PST) 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 96675-10; Tue, 25 Jan 2005 17:39:48 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 7D2CB6218; Tue, 25 Jan 2005 17:39:48 -0800 (PST) Received: from [192.168.5.2] (apexpress.tehama.multihop.net [192.168.4.21]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 55E79620A; Tue, 25 Jan 2005 17:39:46 -0800 (PST) In-Reply-To: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> References: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3BFC9EFE-6F3B-11D9-BD9F-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol - route optimization? Date: Tue, 25 Jan 2005 17:40:18 -0800 To: "Hsu, Julian P" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 Julian, As Alexandru pointed out, for the mobile network node to employ route optimization, it would probably have to be mobility-aware, meaning that it's running Mobile IPv6 or something similar. If you are engineering the entire system, you could think about dynamically changing the routing of the mobile network so that it's routed directly to the Access Router on the visited link. So at the beginning, traffic would arrive at the HA_mr, and after the MR is at access router AR1 for a while, the routing infrastructure routes the MNP to AR1, and AR1 somehow knows that the MR is there (think Fully-Enabled case), so it stops receiving traffic on the HA_MR tunnel, and starts receiving it directly on the egress interface. Of course this is just 1 of many ways to do it. TJ On Jan 25, 2005, at 9:39 AM, Hsu, Julian P wrote: > Hi folks, > > I'm wondering if someone could answer a newbie (first time mailing list > poster) question. I notice that the RFC says that it does not describe > route optimization of traffic between nodes in the mobile network and > correspondent nodes, and later that it allows route optimization for > traffic originating from the Mobile Router. Is there a discussion > somewhere about the reasons for excluding mobile network nodes from the > route optimization process? > > I couldn't tell from my readings of rfc 3775 on Mobility Support in > IPv6 > and this RFC 3963 why it would not be straightforward to have the NEMO > home agent allow route optimization to mobile network nodes known to be > attached to a mobile router.. > > Thanks! > > > Julian > > -----Original Message----- > From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, January 24, 2005 3:56 PM > To: ietf-announce@ietf.org > Cc: nemo@ietf.org; rfc-editor@rfc-editor.org > Subject: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support > Protocol > > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3963 > > Title: Network Mobility (NEMO) Basic Support Protocol > Author(s): V. Devarapalli, R. Wakikawa, A. Petrescu, > P. Thubert > Status: Standards Track > Date: January 2005 > Mailbox: vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, > Alexandru.Petrescu@motorola.com, > pthubert@cisco.com > Pages: 33 > Characters: 75955 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-nemo-basic-support-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3963.txt > > > This document describes the Network Mobility (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 > 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 so that network mobility is transparent to the > nodes inside the Mobile Network. > > This document is a product of the Network Mobility Working Group of the > IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or > deleted from the RFC-DIST distribution list should be sent to > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an > EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to > RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > From nemo-bounces@ietf.org Tue Jan 25 21:00:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07872 for ; Tue, 25 Jan 2005 21:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtcIi-0007Ij-Cc; Tue, 25 Jan 2005 20:48:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtcCd-0005ok-9f for nemo@megatron.ietf.org; Tue, 25 Jan 2005 20:42:39 -0500 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 UAA06024 for ; Tue, 25 Jan 2005 20:42:37 -0500 (EST) 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 1CtcTR-0002gA-Dm for nemo@ietf.org; Tue, 25 Jan 2005 21:00:02 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 9690661DE for ; Tue, 25 Jan 2005 17:42:02 -0800 (PST) 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 96942-01 for ; Tue, 25 Jan 2005 17:42:02 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 57AA461D4; Tue, 25 Jan 2005 17:42:02 -0800 (PST) Received: from [192.168.5.2] (apexpress.tehama.multihop.net [192.168.4.21]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 8F24A6109 for ; Tue, 25 Jan 2005 17:42:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501242355.j0ONtmQ28357@boreas.isi.edu> References: <200501242355.j0ONtmQ28357@boreas.isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8CBB7209-6F3B-11D9-BD9F-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Date: Tue, 25 Jan 2005 17:42:33 -0800 To: IETF NEMO WG X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [nemo] RFC 3963 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Congratulations everyone, on your hard work. It paid off! Special thanks to Thierry, RFC 3963 authors, and the original MONET/NEMO draft authors, and of course our ADs. And of course everyone who has participated in the Basic Support discussions. Now, let's deploy! -TJ From nemo-bounces@ietf.org Tue Jan 25 22:58:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15363 for ; Tue, 25 Jan 2005 22:58:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CteIm-0003Ru-Ab; Tue, 25 Jan 2005 22:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CteHu-0003Bo-TC for nemo@megatron.ietf.org; Tue, 25 Jan 2005 22:56:14 -0500 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 WAA15232 for ; Tue, 25 Jan 2005 22:56:12 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CteYk-0006kF-HS for nemo@ietf.org; Tue, 25 Jan 2005 23:13:39 -0500 Received: from iseran.local (N014055.ppp.dion.ne.jp [61.202.14.55]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 667C24C5EF for ; Wed, 26 Jan 2005 12:55:23 +0900 (JST) Date: Wed, 26 Jan 2005 11:58:28 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol - route optimization? Message-Id: <20050126115828.7867c742.ernst@sfc.wide.ad.jp> In-Reply-To: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> References: <96A337F5C5D4AB4C88A54E752D2A66E315B6DD@XCH-SWBH-04.sw.nos.boeing.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 Dear Julian, > I'm wondering if someone could answer a newbie (first time mailing > list poster) question. I notice that the RFC says that it does not > describe route optimization of traffic between nodes in the mobile > network and correspondent nodes, and later that it allows route > optimization for traffic originating from the Mobile Router. Is there > a discussion somewhere about the reasons for excluding mobile network > nodes from the route optimization process? Please look into the archives of the NEMO ML which dates back from the early discussions and the set up of the WG. Requirements for the NEMO BS solution specified in RFC 3963 are explained in draft-ietf-nemo-requirements About RO, please read the NEMO charter, it explains the process of the WG. We are now due to release a RO problem statement, there was a lot of discussion last fall on the mailing list., and a couple of drat (draft-watarti, draft-thubert and draft-zhao). All of the documents are available on the "additional NEMO web page" which is linked from the NEMO WG chater web page. The NEMO WG will decide to pursue the work on RO or not once a proper IETF WG RO problem statement draft-ietf is issued (hopefully out of the 3 above cited drafts). Note that there are also a lot of reseach papers which address the RO issues. Thierry > > I couldn't tell from my readings of rfc 3775 on Mobility Support in > IPv6 and this RFC 3963 why it would not be straightforward to have the > NEMO home agent allow route optimization to mobile network nodes known > to be attached to a mobile router.. > > Thanks! > > > Julian > > -----Original Message----- > From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, January 24, 2005 3:56 PM > To: ietf-announce@ietf.org > Cc: nemo@ietf.org; rfc-editor@rfc-editor.org > Subject: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support > Protocol > > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3963 > > Title: Network Mobility (NEMO) Basic Support Protocol > Author(s): V. Devarapalli, R. Wakikawa, A. Petrescu, > P. Thubert > Status: Standards Track > Date: January 2005 > Mailbox: vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, > Alexandru.Petrescu@motorola.com, > pthubert@cisco.com > Pages: 33 > Characters: 75955 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-nemo-basic-support-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3963.txt > > > This document describes the Network Mobility (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 > 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 so that network mobility is > transparent to the nodes inside the Mobile Network. > > This document is a product of the Network Mobility Working Group of > the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or > deleted from the RFC-DIST distribution list should be sent to > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > Unless specifically noted otherwise on the RFC itself, all RFCs are > for unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to > RFC Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. -- Thierry Ernst, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Wed Jan 26 02:56:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28557 for ; Wed, 26 Jan 2005 02:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cti0N-00062K-Me; Wed, 26 Jan 2005 02:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CthwX-0005ZR-Lt for nemo@megatron.ietf.org; Wed, 26 Jan 2005 02:50:29 -0500 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 CAA27959 for ; Wed, 26 Jan 2005 02:50:23 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtiDM-0004ca-2E for nemo@ietf.org; Wed, 26 Jan 2005 03:07:51 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 57223456EE; Wed, 26 Jan 2005 08:49:49 +0100 (CET) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 389A3456D3; Wed, 26 Jan 2005 08:49:49 +0100 (CET) Subject: RE: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support Protocol- route optimization? From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Hsu, Julian P" In-Reply-To: <96A337F5C5D4AB4C88A54E752D2A66E315B6DF@XCH-SWBH-04.sw.nos.boeing.com> References: <96A337F5C5D4AB4C88A54E752D2A66E315B6DF@XCH-SWBH-04.sw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-74Fjtb/eXO0f/C+nnML0" Organization: Universidad Carlos III de Madrid Date: Wed, 26 Jan 2005 08:49:45 +0100 Message-Id: <1106725786.4505.5.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: nemo@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-74Fjtb/eXO0f/C+nnML0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Julian, El mar, 25-01-2005 a las 11:49 -0800, Hsu, Julian P escribi=F3: > Hi Alexandru, >=20 > Thanks for your reply! I was especially heartened to find a NEMO > terminology internet draft on the site that you directed me to. I am > interested in this topic because I am involved in system engineering for > a network architecture that has mobile networks with changing points of > connection to the infrastructure network. Pretty much exactly what NEMO > seems to be addressing. >=20 > The restriction that LFNs go through the tunnel, though, can be > undesirable when the triangle routing from LFN to CN goes through say > more high latency, low bandwidth, etc. links than the optimized path.. > Are there any developments or efforts towards solidifying alternatives > based on the MR trusting the LFN, or will running Mobile IPv6 within > those LFNs that would like to initiate their own RR tests be sufficient? We are working (within EU FP6 DAIDALOS project) on a solution exactly for that (sort-of "proxy MR"). Preliminar results are already published in a paper (MIRON: MIPv6 Route Optimization for NEMO) that can be found at http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf. Of course, comments are welcome. Kind Regards, Carlos J. =09 >=20 >=20 > Thanks again, >=20 > Julian >=20 >=20 >=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 > Sent: Tuesday, January 25, 2005 11:05 AM > To: Hsu, Julian P > Cc: nemo@ietf.org > Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic Support > Protocol- route optimization? >=20 >=20 > Hsu, Julian P wrote: > > poster) question. I notice that the RFC says that it does not=20 > > describe route optimization of traffic between nodes in the mobile=20 > > network and correspondent nodes, and later that it allows route=20 > > optimization for traffic originating from the Mobile Router. >=20 > Yes, exactly, MR can use RO just like any MH (Mobile Host, what people > call MN). An application running on MR may easily enjoy the benefits of > RO as per RFC3775. >=20 > > Is there a discussion somewhere about the reasons for excluding mobile >=20 > > network nodes from the route optimization process? >=20 > RO discussion in the early archives in mobilenetworks.org/nemo/archives. >=20 > An application on LFN initiates communication to CN. The MR is just in=20 > between and tunnels/detunnels. The LFN does not implement RO because=20 > it's not Mobile IPv6 node. >=20 > How could MR send RR (Return Routability) tests to CN if that MR's Home=20 > Address is different than the LFN's address. These two addresses are=20 > obviously different. In order to make this "proxy" RR (MR does RR "on=20 > behalf" of LFN) work there is need of some insurance at MR that it=20 > trusts the LFN and vice-versa. >=20 > > I couldn't tell from my readings of rfc 3775 on Mobility Support in=20 > > IPv6 and this RFC 3963 why it would not be straightforward to have the >=20 > > NEMO home agent allow route optimization to mobile network nodes known >=20 > > to be attached to a mobile router.. >=20 > It's less a matter of HA, than a matter of MR and LFN. LEss, but no 0. >=20 > I imagine HA uses its BC when participating in RR for rfc3775, and LFN=20 > does not have an entry in the BC (MR does). The NEMO prefix may be in=20 > the BC, ok, but HA could not participate in RR tests for all Home=20 > Addresses of the NEMO prefix. >=20 > Why are you asking? >=20 > Alex >=20 --=20 Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-74Fjtb/eXO0f/C+nnML0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB90uZ5vKyPtrWqkARAu/aAKDfZO89qaM6xxJn71iJENA2eBGO3ACg14RI t++ju3bF0TRo6iCB2qesodw= =1HKv -----END PGP SIGNATURE----- --=-74Fjtb/eXO0f/C+nnML0-- From nemo-bounces@ietf.org Wed Jan 26 03:25:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00653 for ; Wed, 26 Jan 2005 03:25:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiRI-0002Z3-VA; Wed, 26 Jan 2005 03:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiKP-00010t-R3 for nemo@megatron.ietf.org; Wed, 26 Jan 2005 03:15:05 -0500 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 DAA00226 for ; Wed, 26 Jan 2005 03:15:03 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtibH-0005GE-QO for nemo@ietf.org; Wed, 26 Jan 2005 03:32:32 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2005 09:25:08 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0Q8DpWc006086; Wed, 26 Jan 2005 09:14:30 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Jan 2005 09:14:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RFC 3963 on Network Mobility (NEMO) Basic SupportProtocol- route optimization? Date: Wed, 26 Jan 2005 09:14:20 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC773A53@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RFC 3963 on Network Mobility (NEMO) Basic SupportProtocol- route optimization? Thread-Index: AcUDfLqe25/hrXDBQDOrPJP8I4CQdAAAUfLg From: "Pascal Thubert \(pthubert\)" To: "Hsu, Julian P" X-OriginalArrivalTime: 26 Jan 2005 08:14:26.0508 (UTC) FILETIME=[0D1420C0:01C5037F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 You might find information in the various problem statements as well.=20 Maybe you want to visit http://www.mobilenetworks.org/nemo/=20 Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of | Carlos Jes=FAs Bernardos Cano | Sent: Wednesday, January 26, 2005 8:50 AM | To: Hsu, Julian P | Cc: nemo@ietf.org; Alexandru Petrescu | Subject: RE: [nemo] RFC 3963 on Network Mobility (NEMO) Basic | SupportProtocol- route optimization? |=20 | Hi Julian, |=20 | El mar, 25-01-2005 a las 11:49 -0800, Hsu, Julian P escribi=F3: | > Hi Alexandru, | > | > Thanks for your reply! I was especially heartened to find a NEMO | > terminology internet draft on the site that you directed me to. I = am | > interested in this topic because I am involved in system engineering = for | > a network architecture that has mobile networks with changing points = of | > connection to the infrastructure network. Pretty much exactly what = NEMO | > seems to be addressing. | > | > The restriction that LFNs go through the tunnel, though, can be | > undesirable when the triangle routing from LFN to CN goes through = say | > more high latency, low bandwidth, etc. links than the optimized = path.. | > Are there any developments or efforts towards solidifying = alternatives | > based on the MR trusting the LFN, or will running Mobile IPv6 within | > those LFNs that would like to initiate their own RR tests be = sufficient? |=20 | We are working (within EU FP6 DAIDALOS project) on a solution | exactly | for that (sort-of "proxy MR"). Preliminar results are already = published | in a paper (MIRON: MIPv6 Route Optimization for NEMO) that can be = found | at http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf. Of course, | comments are welcome. |=20 | Kind Regards, |=20 | Carlos J. |=20 |=20 |=20 | > | > | > Thanks again, | > | > Julian | > | > | > | > -----Original Message----- | > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] | > Sent: Tuesday, January 25, 2005 11:05 AM | > To: Hsu, Julian P | > Cc: nemo@ietf.org | > Subject: Re: [nemo] RFC 3963 on Network Mobility (NEMO) Basic = Support | > Protocol- route optimization? | > | > | > Hsu, Julian P wrote: | > > poster) question. I notice that the RFC says that it does not | > > describe route optimization of traffic between nodes in the mobile | > > network and correspondent nodes, and later that it allows route | > > optimization for traffic originating from the Mobile Router. | > | > Yes, exactly, MR can use RO just like any MH (Mobile Host, what = people | > call MN). An application running on MR may easily enjoy the = benefits of | > RO as per RFC3775. | > | > > Is there a discussion somewhere about the reasons for excluding = mobile | > | > > network nodes from the route optimization process? | > | > RO discussion in the early archives in = mobilenetworks.org/nemo/archives. | > | > An application on LFN initiates communication to CN. The MR is just = in | > between and tunnels/detunnels. The LFN does not implement RO = because | > it's not Mobile IPv6 node. | > | > How could MR send RR (Return Routability) tests to CN if that MR's = Home | > Address is different than the LFN's address. These two addresses = are | > obviously different. In order to make this "proxy" RR (MR does RR = "on | > behalf" of LFN) work there is need of some insurance at MR that it | > trusts the LFN and vice-versa. | > | > > I couldn't tell from my readings of rfc 3775 on Mobility Support = in | > > IPv6 and this RFC 3963 why it would not be straightforward to have = the | > | > > NEMO home agent allow route optimization to mobile network nodes = known | > | > > to be attached to a mobile router.. | > | > It's less a matter of HA, than a matter of MR and LFN. LEss, but no = 0. | > | > I imagine HA uses its BC when participating in RR for rfc3775, and = LFN | > does not have an entry in the BC (MR does). The NEMO prefix may be = in | > the BC, ok, but HA could not participate in RR tests for all Home | > Addresses of the NEMO prefix. | > | > Why are you asking? | > | > Alex | > | -- | Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net | GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Mon Jan 31 03:11:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00366 for ; Mon, 31 Jan 2005 03:11:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWXs-0001iM-D5; Mon, 31 Jan 2005 03:04:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWX5-0001by-4a for nemo@megatron.ietf.org; Mon, 31 Jan 2005 03:03:41 -0500 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 DAA29649 for ; Mon, 31 Jan 2005 03:03:36 -0500 (EST) Received: from ns.64translator.com ([202.214.123.16] helo=mail.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWow-0004VR-CS for nemo@ietf.org; Mon, 31 Jan 2005 03:22:07 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.11/8.12.6) with ESMTP id j0V82vJW054625; Mon, 31 Jan 2005 17:03:01 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id j0V82uEn055962; Mon, 31 Jan 2005 17:02:57 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) In-Reply-To: <20050114072639.61A9.RYUJI@sfc.wide.ad.jp> References: <41E6F183.2070201@iprg.nokia.com> <20050114072639.61A9.RYUJI@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <844DFF48-735E-11D9-A130-000A9599E546@jp.yokogawa.com> Content-Transfer-Encoding: 7bit From: Hiroshi MIYATA Subject: Re: [nemo] Connectathon NEMO testing Date: Mon, 31 Jan 2005 17:02:56 +0900 To: Ryuji Wakikawa X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi all, TAHI project is going to participate Connectathon 2005 with MR conformance test. And also we will support NEMO interoperability test. We hope to meet many NEMO implements at Connectathon. Best Regards, ....miyata@tahi On 2005/01/14, at 7:31, Ryuji Wakikawa wrote: > Vijay > > WIDE project will participate Connectathon and bring NEMO (MR and HA). > > TAHI project develops conformance tests tool for MR. > see www.tahi.org > I am not sure they will bring this to connectathon or not. > > regards, > ryuji > >> Connectathon 2005 does not currently have NEMO interop testing. >> http://www.connectathon.org/. when I sent them an email about >> this, they asked me for a list of other potential participants >> to see if NEMO should be included. >> >> anybody interested in testing at Connectathon? I am not sure >> if there would be any conformance tests, but we sure can do >> interop testing. >> >> Nokia can provide a HA with NEMO Basic Support protocool. >> >> please send an email to this list and/or cthon@sun.com if you >> are interested in testing the NEMO Basic Support protocol. >> >> Vijay > > > > From nemo-bounces@ietf.org Mon Jan 31 11:31:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20297 for ; Mon, 31 Jan 2005 11:31:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveM8-0001YI-Vm; Mon, 31 Jan 2005 11:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cve4q-0006Ff-FG for nemo@megatron.ietf.org; Mon, 31 Jan 2005 11:07:00 -0500 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 LAA16729 for ; Mon, 31 Jan 2005 11:06:58 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveMm-00070i-Qo for nemo@ietf.org; Mon, 31 Jan 2005 11:25:35 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2005 17:16:03 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VG5gQM014873; Mon, 31 Jan 2005 17:06:23 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 31 Jan 2005 17:06:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] issue 2 diffs Date: Mon, 31 Jan 2005 17:06:15 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC7B427B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 2 diffs Thread-Index: AcT3LWMwAgzPwn8qSc+Qy2hABdtx/QADXFsQACPyqDAD+PdsoA== From: "Pascal Thubert \(pthubert\)" To: "BINET David RD-CORE-CAE" , "Alexandru Petrescu" X-OriginalArrivalTime: 31 Jan 2005 16:06:28.0077 (UTC) FILETIME=[D21D59D0:01C507AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | I do not think that Extended is really the right term. I agree with Alex. | I do not know if the references to MIP architecture has to be described so | much. The first reference (general expectations) is something useful but | afterwards I do not think that Nemo home networks descriptions have to | have so many links with MIP architecture. Nemo and MIP are two different | protocols and services and I do not see some "progression" from one type | of service or network to another one. So, I think that the references from | one "model" (MIP) to another one (Nemo) should be reduced and Nemo home | networks models should be as independant as possible from MIP | architecture. |=20 Hi David: Sorry to respond so late, I've been quite busy. There is more then a progression between MIP and extended Home Networks. In fact, in extended more, they can share the same Home Link, and the same Home Prefix... Pascal