From exim@www1.ietf.org Tue Nov 4 04:15:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05015 for ; Tue, 4 Nov 2003 04:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxHE-0003Cz-DE for mip4-archive@odin.ietf.org; Tue, 04 Nov 2003 04:15:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49F4eF012329 for mip4-archive@odin.ietf.org; Tue, 4 Nov 2003 04:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxHD-0003Cm-Ft for mip4-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05011 for ; Tue, 4 Nov 2003 04:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxHA-0001QZ-00 for mip4-web-archive@ietf.org; Tue, 04 Nov 2003 04:15:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxHA-0001QV-00 for mip4-web-archive@ietf.org; Tue, 04 Nov 2003 04:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxHA-0003CM-TD; Tue, 04 Nov 2003 04:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxGZ-00037I-Ks for mip4@optimus.ietf.org; Tue, 04 Nov 2003 04:14:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05006 for ; Tue, 4 Nov 2003 04:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxGW-0001QQ-00 for mip4@ietf.org; Tue, 04 Nov 2003 04:14:20 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1AGxGW-0001QN-00 for mip4@ietf.org; Tue, 04 Nov 2003 04:14:20 -0500 Received: (qmail 17172 invoked from network); 4 Nov 2003 09:14:19 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 4 Nov 2003 09:14:19 -0000 Date: Tue, 4 Nov 2003 10:14:18 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031104101418.3081e3d6.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Tue__4_Nov_2003_10_14_18_+0100_=.)GbH/sIv_0885P" Subject: [Mip4] Draft agenda for Mip4 WG meeting in Minneapolis, Take Two Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Multipart_Tue__4_Nov_2003_10_14_18_+0100_=.)GbH/sIv_0885P Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit MIP4 (Mobility for IPv4 WG) Draft Agenda, Take Two -------------------------------------------------- MONDAY, November 10, 2003 1300-1500 Afternoon Sessions I CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page - WG issue tracker 2. Document Status 5 min Chairs draft-ietf-mip4-aaa-nai-00.txt draft-ietf-mip4-vpn-problem-statement-00.txt draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt draft-ietf-mip4-rfc2006bis-01.txt draft-ietf-mobileip-vpn-problem-solution-03.txt 3. AAA key distribution 10 min Pete McCann draft-ietf-mip4-aaa-key-01.txt * An update on the most recent changes which were made in response to IESG comments. This draft will go to IETF last call soon. 4. New confirmed charter item: 5 min Alpesh Patel * Experimental message types and extensions for MIPv4 (draft-patel-mobileip-experimental-messages-02.txt) 5. rfc 3344 bis Issues 15 min Charlie Perkins * Review of issues with the current RFC 3344 in preparation for the next revision. 6. Challenge extensions (revised) 10 min Jayshree Bharatia draft-ietf-mip4-rfc3012bis-00.txt * Update on the most recent edits, and evaluation of two outstanding issues: - Supposed deadlock behavior for slow Registration Replies. - Security considerations text. 7. New possible charter item: 10 min Chairs * Discovery and Description of current vendor-specific extensions, possibly leading to new proposals of new standardised extensions. 8. Dynamic ha assignment 10 min Alpesh Patel draft-kulkarni-mobileip-dynamic-assignment-02.txt * Evaluate WG interest in this proposed dynamic HA assignment mechanism. 9. IPv6 in MIPv4 tunnels 10 min Scott Corson draft-tsirtsis-v4v6-mipv4-00.txt * Evaluate WG interest in this v4-to-v6 transition mechanism. 10. Filters for Mobile IPv4 Bindings 10 min Koolana Kuladinithi draft-nomad-mobileip-filters-05.txt * Evaluate WG interest in this mechanism for providing QoS / selective routing. --------------------------------------------------------------------------- Total time: 100 min + 2 min * 10 items = 120 min --Multipart_Tue__4_Nov_2003_10_14_18_+0100_=.)GbH/sIv_0885P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/p23reVhrtTJkXCMRAgJaAKCvRAMTP6X2lttcIJjoo4PQF8PGVQCfSrI/ xbqM6rugdLtb8a6RtQ6YQIo= =7Rif -----END PGP SIGNATURE----- --Multipart_Tue__4_Nov_2003_10_14_18_+0100_=.)GbH/sIv_0885P-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 4 04:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05389 for ; Tue, 4 Nov 2003 04:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxSr-0003vt-6D for mip4-archive@odin.ietf.org; Tue, 04 Nov 2003 04:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49R4vA015112 for mip4-archive@odin.ietf.org; Tue, 4 Nov 2003 04:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxSp-0003uM-1r for mip4-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:27:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05362 for ; Tue, 4 Nov 2003 04:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxSm-0001cl-00 for mip4-web-archive@ietf.org; Tue, 04 Nov 2003 04:27:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxSl-0001cf-00 for mip4-web-archive@ietf.org; Tue, 04 Nov 2003 04:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxSn-0003t8-3C; Tue, 04 Nov 2003 04:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGv9Q-000710-Tp for mip4@optimus.ietf.org; Tue, 04 Nov 2003 01:58:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18147 for ; Tue, 4 Nov 2003 01:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGv9N-0007An-00 for mip4@ietf.org; Tue, 04 Nov 2003 01:58:49 -0500 Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx with esmtp (Exim 4.12) id 1AGv9M-0007Ak-00 for mip4@ietf.org; Tue, 04 Nov 2003 01:58:48 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id hA46wmEU018891 for ; Tue, 4 Nov 2003 08:58:48 +0200 (EET) Received: (qmail 11370 invoked from network); 4 Nov 2003 06:58:48 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 4 Nov 2003 06:58:48 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id hA46wmb14547; Tue, 4 Nov 2003 08:58:48 +0200 (EET) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f Message-ID: <16295.19927.833659.370404@ryijy.hel.fi.ssh.com> Date: Tue, 4 Nov 2003 08:57:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: mip4@ietf.org X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f X-Mailer: VM 7.07 under Emacs 20.7.1 X-Edit-Time: 0 min X-Total-Time: 0 min Content-Transfer-Encoding: 7bit Subject: [Mip4] IKEv2 Mobility and Multihoming BOF Tue, Nov 11, 1700-1800 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There has been some interest in the IPsec working group to add features to IKEv2 to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The features should then be used by the Mobile IP, HIP, etc working groups as building blocks to create their final protocols, but some of the features can immediately be used in the IPsec VPNs too (client roaming in VPN case, SCTP, multihoming support). The BOF is currently scheduled for Tuesday, November 11, 2003, at 1700-1800. The BOF have some kind of web pages at http://mobike.kivinen.iki.fi/index.html. The web pages have agenda for the meeting, proposed charter and basic introduction to the problem. The BOF mailing list: General Discussion: mobike@machshav.com To subscribe: mobike-request@machshav.com Archive and general information: https://www.machshav.com/mailman/listinfo/mobike The MOBIKE BOF's goal is to verify that we have enough interest to define mobility and multihoming extensions to the current IKEv2 protocol. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 6 06:43:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05013 for ; Thu, 6 Nov 2003 06:43:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHiXX-00017O-6E for mip4-archive@odin.ietf.org; Thu, 06 Nov 2003 06:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Bh3ie004294 for mip4-archive@odin.ietf.org; Thu, 6 Nov 2003 06:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHiXX-00017B-10 for mip4-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 06:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05005 for ; Thu, 6 Nov 2003 06:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHiXS-0007TT-00 for mip4-web-archive@ietf.org; Thu, 06 Nov 2003 06:42:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHiXS-0007TP-00 for mip4-web-archive@ietf.org; Thu, 06 Nov 2003 06:42:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHiXV-00016r-A9; Thu, 06 Nov 2003 06:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHiXH-00016g-Me for mip4@optimus.ietf.org; Thu, 06 Nov 2003 06:42:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04999 for ; Thu, 6 Nov 2003 06:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHiXD-0007TH-00 for mip4@ietf.org; Thu, 06 Nov 2003 06:42:43 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AHiXC-0007Sx-00 for mip4@ietf.org; Thu, 06 Nov 2003 06:42:42 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hA6Bg9EY028405; Thu, 6 Nov 2003 12:42:09 +0100 Date: Thu, 6 Nov 2003 12:42:12 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann , Henrik Levkowetz Message-Id: <20031106124212.39fd5983.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__6_Nov_2003_12_42_12_+0100_o7o9si1nUKw/u0sv" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] Volunteer minute-takers for the Mip4 session in Minneapolis Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Thu__6_Nov_2003_12_42_12_+0100_o7o9si1nUKw/u0sv Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, We're interested in two volunteers to take minutes for the Mip4 session at the upcoming meeting. If you're willing to take session minutes at Minneapolis, please send either Pete or me an email. Henrik --Signature=_Thu__6_Nov_2003_12_42_12_+0100_o7o9si1nUKw/u0sv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qjOUeVhrtTJkXCMRAuOTAKCd6DHUvi+BPQBElH09FzMc8ErSqgCg1eMe yHD0XxaKulFZEy3vmJGVh4E= =DFvg -----END PGP SIGNATURE----- --Signature=_Thu__6_Nov_2003_12_42_12_+0100_o7o9si1nUKw/u0sv-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 13:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28781 for ; Fri, 7 Nov 2003 13:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBcS-00079d-J2 for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 13:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Ik4L4027495 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 13:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBcS-00079O-E4 for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28761 for ; Fri, 7 Nov 2003 13:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBcQ-00018b-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 13:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBcP-00018U-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 13:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBcQ-00077l-Ui; Fri, 07 Nov 2003 13:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBbj-000740-MG for mip4@optimus.ietf.org; Fri, 07 Nov 2003 13:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28680; Fri, 7 Nov 2003 13:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBbh-00015t-00; Fri, 07 Nov 2003 13:45:17 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AIBbg-00015n-00; Fri, 07 Nov 2003 13:45:16 -0500 Received: from ella (ella [128.111.43.201]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hA7IjE221894; Fri, 7 Nov 2003 10:45:14 -0800 (PST) Date: Fri, 7 Nov 2003 10:45:14 -0800 (PST) From: "Krishna N. Ramachandran" X-Sender: krishna@ella To: mip4@ietf.org, mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] AODV @ IETF Project Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi there, Mobile ad hoc networks have typically been deployed on a small scale in restricted environments. The AODV@IETF project aims to make available the first ever publicly-usable ad hoc network at the 58th IETF conference to be held in Minneapolis, MN, USA from November 9-14. The AODV network, scheduled to go live at 12:01 AM on the 10th of November, a Monday, will support Internet capable AODV implementations for the Microsoft Windows XP and Linux operating systems. Our goals behind the project are to demonstrate the capabilities of ad hoc networks to the general public and also to evaluate the performance of ad hoc networks when used on a large-scale in the real world. We welcome and encourage your participation in the ad hoc network at the IETF. Please visit the AODV@IETF website: http://moment.cs.ucsb.edu/aodv-ietf for more details. On the same website, we will very soon make available the software packages needed to join the ad hoc network. Please email me if you have any questions at krishna@cs.ucsb.edu. Thank you and looking forward to your participation, Krishna Ramachandran, UC Santa Barbara. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 14:22:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02654 for ; Fri, 7 Nov 2003 14:22:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICBF-00019Z-HE for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 14:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JM11h004427 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICBF-00019J-Bm for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02647 for ; Fri, 7 Nov 2003 14:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICBC-0001fL-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 14:21:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICBC-0001fI-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 14:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICBE-00018s-7a; Fri, 07 Nov 2003 14:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICAU-00017Z-OF for mip4@optimus.ietf.org; Fri, 07 Nov 2003 14:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02606 for ; Fri, 7 Nov 2003 14:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICAS-0001eL-00 for mip4@ietf.org; Fri, 07 Nov 2003 14:21:12 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AICAR-0001eI-00 for mip4@ietf.org; Fri, 07 Nov 2003 14:21:11 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA7JL7Sr022335 for ; Fri, 7 Nov 2003 12:21:11 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA7JL5BJ000697 for ; Fri, 7 Nov 2003 13:21:06 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 84F5D2EC95 for ; Fri, 7 Nov 2003 20:21:05 +0100 (CET) To: mip4@ietf.org From: Alexandru Petrescu Date: Fri, 07 Nov 2003 20:21:05 +0100 In-Reply-To: <200310171934.PAA18267@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 17 Oct 2003 15:34:51 -0400") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) References: <200310171934.PAA18267@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , writes: > Title : Mobile IPv4 Dynamic Home Agent Assignment Framework > Author(s) : M. Kulkarni, A. Patel, K. Leung > Filename : draft-kulkarni-mobileip-dynamic-assignment-02.txt > Pages : 21 > Date : 2003-10-17 Hi to MIP4 members, I've read this draft because it relates to a similar draft for Mobile IPv6 with which I got familiar weeks ago. I was wondering if I can get IPv4-specific clarification for the motivation behind this idea. Once an MN is assigned a new HA (by the previous HA), is the new HA capable of receiving packets originated by CN and addressed to the same unique Home Address? Does the MN keep its old Home Address? > If the distance between the visited network and the home > network of the mobile node is large, the signaling delay for > these registrations may be long. Is the high delay of the _registration_ signalling (not the delay CN-MN useful comm) of enough high importance as to motivate choosing a new HA? > In such a case the MN will be anchored to its distant home > agent, resulting in tunneled traffic traveling a long > distance between home agent and the mobile node. This sounds to me like a typical route optimization problem. I think I remember about a RO draft existed some time (1 year?) ago but I don't know about its status. Is the RO work taken somewhere? > When a Mobile IP session initiates, if the mobile node can be > assigned an home agent which is close to the mobile node it > can drastically reduce the latency between the home agent and > mobile node. Yes, that looks reasonable. But remark that it is not the communication between MN and its HA that is of paramount importance. It is the useful app-level communication of MN that takes the most bandwidth and other network resources. In this case, it is very important to reduce MN-to-CN distances (instead of only the MN-to-HA distances), no? Thanks for any clarification, Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 14:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02812 for ; Fri, 7 Nov 2003 14:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEC-0001Gp-8C for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 14:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JP4nj004877 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 14:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEC-0001Ga-0w for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02789 for ; Fri, 7 Nov 2003 14:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICE9-0001hN-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 14:25:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICE9-0001hK-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 14:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEA-0001Ex-Vo; Fri, 07 Nov 2003 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICDl-0001DX-Bc for mip4@optimus.ietf.org; Fri, 07 Nov 2003 14:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02729 for ; Fri, 7 Nov 2003 14:24:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICDi-0001gQ-00 for mip4@ietf.org; Fri, 07 Nov 2003 14:24:34 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AICDi-0001gN-00 for mip4@ietf.org; Fri, 07 Nov 2003 14:24:34 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA7JOWJl005187; Fri, 7 Nov 2003 12:24:33 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id hA7JO6cv008871; Fri, 7 Nov 2003 13:24:21 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 45DA82EC98; Fri, 7 Nov 2003 20:24:05 +0100 (CET) To: Henrik Levkowetz Cc: Subject: Re: [Mip4] Draft agenda for Mip4 WG meeting in Minneapolis, Take Two From: Alexandru Petrescu Date: Fri, 07 Nov 2003 20:24:05 +0100 In-Reply-To: <20031104101418.3081e3d6.henrik@levkowetz.com> (Henrik Levkowetz's message of "Tue, 4 Nov 2003 10:14:18 +0100") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) References: <20031104101418.3081e3d6.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Henrik Levkowetz writes: > 8. Dynamic ha assignment 10 min Alpesh Patel > draft-kulkarni-mobileip-dynamic-assignment-02.txt > * Evaluate WG interest in this proposed dynamic HA > assignment mechanism. Hi, would it be possible to talk right now on the list about the WG interest in this particular item? I've sent comments on draft. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 16:04:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07498 for ; Fri, 7 Nov 2003 16:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDm0-00087J-3D for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 16:04:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7L44Sj031197 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 16:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDlz-000876-Uz for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07489 for ; Fri, 7 Nov 2003 16:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDly-0002tp-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:04:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDlx-0002tm-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDlx-00086g-AP; Fri, 07 Nov 2003 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDlr-00086O-Oh for mip4@optimus.ietf.org; Fri, 07 Nov 2003 16:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07482 for ; Fri, 7 Nov 2003 16:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDlq-0002tf-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:03:54 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AIDlp-0002tb-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:03:53 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hA7L3pm5025904 for ; Fri, 7 Nov 2003 14:03:51 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA7L3ZBJ009724; Fri, 7 Nov 2003 15:03:37 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3BFA02EC95; Fri, 7 Nov 2003 22:03:35 +0100 (CET) To: mip4@ietf.org Cc: lach@crm.mot.com, miguel.catalina@motorola.com From: Alexandru Petrescu Date: Fri, 07 Nov 2003 22:03:35 +0100 Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Mip4] new draft on network selection (NACP) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi again to the MIP4 group, We have recently submitted a draft on mechanisms for network selection by an MN. It's called NACP for Network Access Co-ordination Protocol and we're looking for feedback on it. http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt The draft describes a simple protocol happening between MN and a Network Access Agent (NAA) and allows a Mobile IPv4 MN to maintain ongoing connections while switching between three very different types of wireless links. MN sends to NAA a list of access networks that it can sense (GPRS, WLAN and DVB-T) and subsequently the NAA suggests back to MN which of those networks to use; NAA's suggestions rely on its high-level visibility of network, errrr, resources. (while MN has supposedly little visibility over how networks are overloaded, or how expensive). The relationship to Mobile IPv4: -working over heterogeneous systems is only possible if IP is used, being wireless implies mobility, and the wide-area characteristics of both GPRS and DVB-T imply Mobile IP. -MN uses its Home Address to inform the NAA about its identity (and not its temporary Care-of Address). Previously, the only WG that touched and delivered on these concepts was Seamoby. One resulted protocol was CARD. With CARD, the MN is assisted by first-hop Access Routers, while with NACP the MN is assisted by an entity deep in the network (that's why NACP is UDP while CARD is IP). More recently, a related draft is draft-njedjou-inter-an-handoffs-00.txt, which discusses the benefits of such a scheme but does not propose an actual solution. We're looking for guidance, and initially trying to learn how this work maybe already existed before, or how it can be done entirely differently, or maybe how some other RFC's already do it, or how wrong the reasoning above might be. Any feedback appreciated. Thank you for considering it, Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 16:43:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09239 for ; Fri, 7 Nov 2003 16:43:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIENl-0003nL-Ac for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 16:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Lh5Q4014581 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 16:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIENl-0003n6-5a for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09205 for ; Fri, 7 Nov 2003 16:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIENj-0003Sy-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:43:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIENi-0003Sv-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIENi-0003md-L7; Fri, 07 Nov 2003 16:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIENe-0003lJ-L4 for mip4@optimus.ietf.org; Fri, 07 Nov 2003 16:42:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09197 for ; Fri, 7 Nov 2003 16:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIENc-0003Sg-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:42:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIENc-0003Rm-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:42:56 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2003 13:47:42 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA7LgNmU008985; Fri, 7 Nov 2003 13:42:23 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALI14728; Fri, 7 Nov 2003 13:42:21 -0800 (PST) Message-ID: <3FAC11BE.1050605@cisco.com> Date: Fri, 07 Nov 2003 13:42:22 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: mip4@ietf.org, lach@crm.mot.com, miguel.catalina@motorola.com Subject: Re: [Mip4] new draft on network selection (NACP) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Hi again to the MIP4 group, > > We have recently submitted a draft on mechanisms for network selection > by an MN. It's called NACP for Network Access Co-ordination Protocol > and we're looking for feedback on it. > > http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt Hi Alex, You mean you submitted our Dynamic HA Assignment draft again? :) I am sure the draft name you specified above is a typo. If not, we need to talk ;) Milind > > The draft describes a simple protocol happening between MN and a > Network Access Agent (NAA) and allows a Mobile IPv4 MN to maintain > ongoing connections while switching between three very different types > of wireless links. MN sends to NAA a list of access networks that it > can sense (GPRS, WLAN and DVB-T) and subsequently the NAA suggests > back to MN which of those networks to use; NAA's suggestions rely on > its high-level visibility of network, errrr, resources. (while MN has > supposedly little visibility over how networks are overloaded, or how > expensive). > > The relationship to Mobile IPv4: > -working over heterogeneous systems is only possible if IP is used, > being wireless implies mobility, and the wide-area characteristics of > both GPRS and DVB-T imply Mobile IP. > -MN uses its Home Address to inform the NAA about its identity (and > not its temporary Care-of Address). > > Previously, the only WG that touched and delivered on these concepts > was Seamoby. One resulted protocol was CARD. With CARD, the MN is > assisted by first-hop Access Routers, while with NACP the MN is > assisted by an entity deep in the network (that's why NACP is UDP > while CARD is IP). > > More recently, a related draft is > draft-njedjou-inter-an-handoffs-00.txt, which discusses the benefits > of such a scheme but does not propose an actual solution. > > We're looking for guidance, and initially trying to learn how this > work maybe already existed before, or how it can be done entirely > differently, or maybe how some other RFC's already do it, or how wrong > the reasoning above might be. Any feedback appreciated. > > Thank you for considering it, > > Alex > GBU > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 16:50:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09517 for ; Fri, 7 Nov 2003 16:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEUX-0003xD-8K for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 16:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Lo4Tg015185 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 16:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEUW-0003wq-QP for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:50:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09505 for ; Fri, 7 Nov 2003 16:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEUU-0003Yj-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEUU-0003Yg-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 16:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEUT-0003vb-Ou; Fri, 07 Nov 2003 16:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEUK-0003v6-CF for mip4@optimus.ietf.org; Fri, 07 Nov 2003 16:49:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09492 for ; Fri, 7 Nov 2003 16:49:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEUI-0003YV-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:49:50 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIEUH-0003YP-00 for mip4@ietf.org; Fri, 07 Nov 2003 16:49:49 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA7LnkHc003733; Fri, 7 Nov 2003 14:49:46 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id hA7Lnecv018756; Fri, 7 Nov 2003 15:49:41 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id EBB7B2EC95; Fri, 7 Nov 2003 22:49:39 +0100 (CET) To: Milind Kulkarni Cc: , , "Miguel Catalina" Subject: Re: [Mip4] new draft on network selection (NACP) From: Alexandru Petrescu Date: Fri, 07 Nov 2003 22:49:39 +0100 In-Reply-To: <3FAC11BE.1050605@cisco.com> (Milind Kulkarni's message of "Fri, 07 Nov 2003 13:42:22 -0800") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) References: <3FAC11BE.1050605@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Milind Kulkarni writes: > You mean you submitted our Dynamic HA Assignment draft again? :) > I am sure the draft name you specified above is a typo. Oh yes, it was typo, my emacs buffers are filled with drafts so I switched to the wrong one, apologies. The NACP is at: http://www.ietf.org/internet-drafts/draft-lach-nac-01.txt > If not, we need to talk ;) We need to talk even if yes. For example, what do you think about our draft (I already said what I think about your draft and I'm tempted to believe it should not be presented). Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 17:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10167 for ; Fri, 7 Nov 2003 17:04:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEi3-00058n-3r for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 17:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7M43fL019755 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 17:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEi2-00057g-Us for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:04:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10147 for ; Fri, 7 Nov 2003 17:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEhz-0003rE-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 17:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEhy-0003r8-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 17:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEi0-00057A-5G; Fri, 07 Nov 2003 17:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEhk-00055u-1h for mip4@optimus.ietf.org; Fri, 07 Nov 2003 17:03:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10134 for ; Fri, 7 Nov 2003 17:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEhh-0003qn-00 for mip4@ietf.org; Fri, 07 Nov 2003 17:03:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AIEhh-0003qL-00 for mip4@ietf.org; Fri, 07 Nov 2003 17:03:41 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 14:05:37 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA7M38iN020639; Fri, 7 Nov 2003 14:03:08 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALI17229; Fri, 7 Nov 2003 14:03:07 -0800 (PST) Message-ID: <3FAC169B.1010208@cisco.com> Date: Fri, 07 Nov 2003 14:03:07 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Thanks for your feedback on the dynamic HA assignment draft. Please see inline... Alexandru Petrescu wrote: > writes: > >> Title : Mobile IPv4 Dynamic Home Agent Assignment Framework >> Author(s) : M. Kulkarni, A. Patel, K. Leung >> Filename : draft-kulkarni-mobileip-dynamic-assignment-02.txt >> Pages : 21 >> Date : 2003-10-17 > > > Hi to MIP4 members, I've read this draft because it relates to a > similar draft for Mobile IPv6 with which I got familiar weeks ago. > > I was wondering if I can get IPv4-specific clarification for the > motivation behind this idea. There are atleast 4 motivating reasons for dynamic HA assignment. They are listed in section 3 of the draft. > > Once an MN is assigned a new HA (by the previous HA), is the new HA > capable of receiving packets originated by CN and addressed to the > same unique Home Address? Since the draft suggests RRQ rejection as the mechanism for redirecting, the new HA has all the capabilities and that includes sending packets to MN. >Does the MN keep its old Home Address? I presume you are saying MN's home IP address. The MN may or may not keep its old IP address because it uses NAI. > > >> If the distance between the visited network and the home >> network of the mobile node is large, the signaling delay for >> these registrations may be long. > > > Is the high delay of the _registration_ signalling (not the delay > CN-MN useful comm) of enough high importance as to motivate choosing a > new HA? > > >> In such a case the MN will be anchored to its distant home >> agent, resulting in tunneled traffic traveling a long >> distance between home agent and the mobile node. > > > This sounds to me like a typical route optimization problem. I think > I remember about a RO draft existed some time (1 year?) ago but I > don't know about its status. Is the RO work taken somewhere? > > >> When a Mobile IP session initiates, if the mobile node can be >> assigned an home agent which is close to the mobile node it >> can drastically reduce the latency between the home agent and >> mobile node. > > > Yes, that looks reasonable. But remark that it is not the > communication between MN and its HA that is of paramount importance. > It is the useful app-level communication of MN that takes the most > bandwidth and other network resources. In this case, it is very > important to reduce MN-to-CN distances (instead of only the MN-to-HA > distances), no? True. But MN-CN proximity is automatically taken care of when the HA and MN are very close. If the MN and CN are close, but the HA is far away then the problem still remains. And we don't have intelligent CN like MIP v6 here. We sincerely believe, each reason above put together offers compelling argument. Regards, Milind > > Thanks for any clarification, > > Alex > GBU > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 17:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11753 for ; Fri, 7 Nov 2003 17:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFF0-0007vB-2f for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 17:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Mc52J030419 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 17:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFEx-0007td-Ec for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:38:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11702 for ; Fri, 7 Nov 2003 17:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFEu-0004Mo-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 17:38:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFEu-0004Ml-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 17:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFEw-0007t1-1R; Fri, 07 Nov 2003 17:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFEa-0007nB-NY for mip4@optimus.ietf.org; Fri, 07 Nov 2003 17:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11696 for ; Fri, 7 Nov 2003 17:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFEY-0004MX-00 for mip4@ietf.org; Fri, 07 Nov 2003 17:37:38 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIFEX-0004MQ-00 for mip4@ietf.org; Fri, 07 Nov 2003 17:37:37 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA7MbWHc015550; Fri, 7 Nov 2003 15:37:32 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id hA7MbPcv016280; Fri, 7 Nov 2003 16:37:28 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id DD5022EC95; Fri, 7 Nov 2003 23:37:24 +0100 (CET) To: Milind Kulkarni Cc: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt From: Alexandru Petrescu Date: Fri, 07 Nov 2003 23:37:24 +0100 In-Reply-To: <3FAC169B.1010208@cisco.com> (Milind Kulkarni's message of "Fri, 07 Nov 2003 14:03:07 -0800") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Milind Kulkarni writes: > There are atleast 4 motivating reasons for dynamic HA assignment. > They are listed in section 3 of the draft. Ok I read and not convinced. Do you think it would be a good if I address them one by one? > Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept > of identifying a MN by the NAI and enabling dynamic home > address assignment. Remark that when HA assigns a new Home Address to MN (based on NAI), this address is obviously topologically correct at HA. That HA can not assign an address to MN that is topologically correct at another HA far away, no? >> Once an MN is assigned a new HA (by the previous HA), is the new HA >> capable of receiving packets originated by CN and addressed to the >> same unique Home Address? > > Since the draft suggests RRQ rejection as the mechanism for > redirecting, the new HA has all the capabilities and that > includes sending packets to MN. I understand that, but what I was not asking about HA _sending_ packets to MN, but about the new HA _receiving_ packets from CN addressed towards the Home Address valid at the old HA. > >Does the MN keep its old Home Address? > > I presume you are saying MN's home IP address. The MN may or > may not keep its old IP address because it uses NAI. Yes, I'm assuming MN keeps its home IP address. I assume that CN sends to that MN by sending to the home IP address (and not to the NAI). So I was wondering whether when a new HA is assigned to MN, MN keeps the same home IP address and CN continues to send to that home IP address? >> Yes, that looks reasonable. But remark that it is not the >> communication between MN and its HA that is of paramount importance. >> It is the useful app-level communication of MN that takes the most >> bandwidth and other network resources. In this case, it is very >> important to reduce MN-to-CN distances (instead of only the MN-to-HA >> distances), no? > > True. But MN-CN proximity is automatically taken care of when the > HA and MN are very close. If the MN and CN are close, but the HA > is far away then the problem still remains. I understand the surface of this problem. The solution you propose has appeal in that a new HA is assigned that is closer to MN (in terms of no of IP hops). But I don't understand how this new HA can obtain the packets addressed by CN to the home IP address that is topologically valid only at the old HA. > And we don't have intelligent CN like MIP v6 here. I see, so that's why I can't find a draft on RO for MIPv4, maybe? > We sincerely believe, each reason above put together offers > compelling argument. I sincerely believe that it depends who you ask. If you ask me, I'd be ready to be compelled, but I need to figure out this new HA assignment. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 18:21:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13865 for ; Fri, 7 Nov 2003 18:21:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFua-0001Xs-1a for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 18:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7NL4sr005939 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 18:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFuZ-0001Xi-Sa for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 18:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13842 for ; Fri, 7 Nov 2003 18:20:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFuW-0004jv-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 18:21:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFuW-0004js-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 18:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFuY-0001XI-Gf; Fri, 07 Nov 2003 18:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFtd-0001W3-IK for mip4@optimus.ietf.org; Fri, 07 Nov 2003 18:20:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13826 for ; Fri, 7 Nov 2003 18:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFta-0004jT-00 for mip4@ietf.org; Fri, 07 Nov 2003 18:20:02 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIFtZ-0004jJ-00 for mip4@ietf.org; Fri, 07 Nov 2003 18:20:01 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA7NJTw5026598; Fri, 7 Nov 2003 15:19:29 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALI25947; Fri, 7 Nov 2003 15:19:28 -0800 (PST) Message-ID: <3FAC2880.9080408@cisco.com> Date: Fri, 07 Nov 2003 15:19:28 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Thanks for your responses. I glanced through NACP draft. Now I understand the view point you are coming from. The NACP draft is a different solution altogether. It is assisting in MN's handoff strategy. The dynamic HA assignment draft is solving different problem. It enhances the RFC-3344 behavior to get the optimal HA during session initiation only. Once selected, the MN is anchored to that HA for entire session. BTW, in which WG the NACP draft is tabled? Thanks, Milind Alexandru Petrescu wrote: > Milind Kulkarni writes: > >>There are atleast 4 motivating reasons for dynamic HA assignment. >>They are listed in section 3 of the draft. > > > Ok I read and not convinced. Do you think it would be a good if I > address them one by one? > > >> Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept >> of identifying a MN by the NAI and enabling dynamic home >> address assignment. > > > Remark that when HA assigns a new Home Address to MN (based on NAI), > this address is obviously topologically correct at HA. That HA can > not assign an address to MN that is topologically correct at another > HA far away, no? > > >>>Once an MN is assigned a new HA (by the previous HA), is the new HA >>>capable of receiving packets originated by CN and addressed to the >>>same unique Home Address? >> >>Since the draft suggests RRQ rejection as the mechanism for >>redirecting, the new HA has all the capabilities and that >>includes sending packets to MN. > > > I understand that, but what I was not asking about HA _sending_ > packets to MN, but about the new HA _receiving_ packets from CN > addressed towards the Home Address valid at the old HA. > > >> >Does the MN keep its old Home Address? >> >>I presume you are saying MN's home IP address. The MN may or >>may not keep its old IP address because it uses NAI. > > > Yes, I'm assuming MN keeps its home IP address. I assume that CN > sends to that MN by sending to the home IP address (and not to the > NAI). > > So I was wondering whether when a new HA is assigned to MN, MN keeps > the same home IP address and CN continues to send to that home IP > address? > > >>>Yes, that looks reasonable. But remark that it is not the >>>communication between MN and its HA that is of paramount importance. >>>It is the useful app-level communication of MN that takes the most >>>bandwidth and other network resources. In this case, it is very >>>important to reduce MN-to-CN distances (instead of only the MN-to-HA >>>distances), no? >> >>True. But MN-CN proximity is automatically taken care of when the >>HA and MN are very close. If the MN and CN are close, but the HA >>is far away then the problem still remains. > > > I understand the surface of this problem. The solution you propose > has appeal in that a new HA is assigned that is closer to MN (in terms > of no of IP hops). But I don't understand how this new HA can obtain > the packets addressed by CN to the home IP address that is > topologically valid only at the old HA. > > >>And we don't have intelligent CN like MIP v6 here. > > > I see, so that's why I can't find a draft on RO for MIPv4, maybe? > > >>We sincerely believe, each reason above put together offers >>compelling argument. > > > I sincerely believe that it depends who you ask. If you ask me, I'd > be ready to be compelled, but I need to figure out this new HA > assignment. > > Alex > GBU > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 19:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15808 for ; Fri, 7 Nov 2003 19:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGkq-0004HP-CX for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 19:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80F4t6016445 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 19:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGkq-0004HA-7n for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:15:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15782 for ; Fri, 7 Nov 2003 19:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGko-0005WS-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 19:15:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIGko-0005WP-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 19:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGko-0004Gi-F4; Fri, 07 Nov 2003 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGjz-0004D2-Tb for mip4@optimus.ietf.org; Fri, 07 Nov 2003 19:14:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15758 for ; Fri, 7 Nov 2003 19:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGjy-0005W5-00 for mip4@ietf.org; Fri, 07 Nov 2003 19:14:10 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AIGjx-0005W2-00 for mip4@ietf.org; Fri, 07 Nov 2003 19:14:09 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hA80DULK004691; Fri, 7 Nov 2003 17:14:02 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hA80CQDX026019; Fri, 7 Nov 2003 18:12:28 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 13DAC2EC95; Sat, 8 Nov 2003 01:13:26 +0100 (CET) Message-ID: <3FAC3525.8010909@nal.motlabs.com> Date: Sat, 08 Nov 2003 01:13:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Milind Kulkarni Cc: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> In-Reply-To: <3FAC2880.9080408@cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Milind Kulkarni wrote: > Alex, > > Thanks for your responses. I glanced through NACP draft. Now I > understand the view point you are coming from. The NACP draft is a > different solution altogether. It is assisting in MN's handoff > strategy. Absolutely, NACP is assisting in MN's handoff strategy. There is no relation between the two whatsoever. I was reviewing your draft at the same time as announcing NACP here, but no relations. But my interest in the HA selection/assignment scheme comes from the similarity between HAHA discussed in MIP6 and draft-kulkarni (nothing to do with NACP). > The dynamic HA assignment draft is solving different problem. Absolutely, sorry for the confusion. > It enhances the RFC-3344 behavior to get the optimal HA during > session initiation only. Once selected, the MN is anchored to that HA > for entire session. A-ha, so would it be reasonable to say that, with draft-kulkarni, upper-layer apps between MN-CN MUST be restarted each time a new HA is assigned? (thus loosing the classical advantage of Mobile IP that it preserves ongoing communications when address changes)? I assume that when a new HA is assigned, a new Home Address is assigned to MN too, even if NAI appears in the discussion. NAI is used by a normal HA to assign and re-assign the same Home Address to an MN, but it is always the same HA. If this session continuity advantage of Mobile IP is lost, is it reasonable to say that an MN could simply acquire a new address from the new DHCP server that it finds nearby, use that address for currrent sessions, then move, break communications, find another DHCP server, aquire a new address and so on? Otherwise, if the MN anchored to a new HA tries to continue using the same Home Address (valid at the old HA), then the new HA MUST absolutely have a means to get packets from CN towards that home address. I can not find something in draft-kulkarni that clarifies this. > BTW, in which WG the NACP draft is tabled? As you can see, we have announced NACP in this WG. It is an individual submission, just like yours. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 19:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16551 for ; Fri, 7 Nov 2003 19:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH78-0005ao-Hz for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 19:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80c6po021492 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 19:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH76-0005aZ-Rp for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16531 for ; Fri, 7 Nov 2003 19:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH75-0005si-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 19:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIH74-0005sf-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 19:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH73-0005ZE-Fu; Fri, 07 Nov 2003 19:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH6j-0005RM-8g for mip4@optimus.ietf.org; Fri, 07 Nov 2003 19:37:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16528 for ; Fri, 7 Nov 2003 19:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH6h-0005sc-00 for mip4@ietf.org; Fri, 07 Nov 2003 19:37:39 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIH6h-0005sB-00 for mip4@ietf.org; Fri, 07 Nov 2003 19:37:39 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA80b6w5026929; Fri, 7 Nov 2003 16:37:07 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALI33822; Fri, 7 Nov 2003 16:37:05 -0800 (PST) Message-ID: <3FAC3AB0.801@cisco.com> Date: Fri, 07 Nov 2003 16:37:04 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: >> The dynamic HA assignment draft is solving different problem. > > Absolutely, sorry for the confusion. > Ok. >> It enhances the RFC-3344 behavior to get the optimal HA during session >> initiation only. Once selected, the MN is anchored to that HA >> for entire session. > > > A-ha, so would it be reasonable to say that, with draft-kulkarni, > upper-layer apps between MN-CN MUST be restarted each time a new HA is > assigned? (thus loosing the classical advantage of Mobile IP that it > preserves ongoing communications when address changes)? No, no! The messaging specified in the draft-kulkarni-xxx is done only at the beginning of a new MIP v4 session. So this is a *new* MIP session, which gets an optimal HA. The MN stays anchored to the optimal HA for the rest of the MIP session. After that everything is RFC3344. The MN's IP address remains same and upper layer applications remain intact. Breaking upper layer sessions (and restarting applications) is definitely out of question :) The whole process repeats when the MIP session is restarted. I hope this is clear now. Milind -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 7 20:47:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18266 for ; Fri, 7 Nov 2003 20:47:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIIBq-0008Lc-25 for mip4-archive@odin.ietf.org; Fri, 07 Nov 2003 20:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA81l2g3032085 for mip4-archive@odin.ietf.org; Fri, 7 Nov 2003 20:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIIBp-0008LQ-RX for mip4-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 20:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18254 for ; Fri, 7 Nov 2003 20:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIIBn-0006ZK-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 20:46:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIIBn-0006ZH-00 for mip4-web-archive@ietf.org; Fri, 07 Nov 2003 20:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIIBo-0008L4-2u; Fri, 07 Nov 2003 20:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIIB8-0008JT-EC for mip4@optimus.ietf.org; Fri, 07 Nov 2003 20:46:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18244 for ; Fri, 7 Nov 2003 20:46:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIIB5-0006Yz-00 for mip4@ietf.org; Fri, 07 Nov 2003 20:46:16 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AIIB5-0006Yw-00 for mip4@ietf.org; Fri, 07 Nov 2003 20:46:15 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA81jG7q023582; Fri, 7 Nov 2003 18:45:16 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.36]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA81jsui032311; Fri, 7 Nov 2003 19:45:58 -0600 Message-ID: <12D2A932.3000009@nal.motlabs.com> Date: Fri, 04 Jan 1980 02:02:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Milind Kulkarni CC: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC3AB0.801@cisco.com> In-Reply-To: <3FAC3AB0.801@cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Milind Kulkarni wrote: > No, no! The messaging specified in the draft-kulkarni-xxx is done > only at the beginning of a new MIP v4 session. So this is a *new* MIP > session, which gets an optimal HA. The MN stays anchored to the > optimal HA for the rest of the MIP session. After that everything is > RFC3344. The MN's IP address remains same and upper layer > applications remain intact. Ah, I think I start to get it. So this would be a scenario like: MN arrives in a new area (all sessions down), contacts its original non-optimal HA, that non-optimal HA redirects towards this optimal HA and, starting from now, rfc3344 goes on and MN can visit various foreign networks close to this new HA. Packets from CN would be addressed to the Home Address valid at this new HA and forwarded to the current CoA, and all communications are not interupted. > Breaking upper layer sessions (and restarting applications) is > definitely out of question :) ...until MN moves into an area where another HA is optimal, right? Am I right to say that re-assigning a second new optimal HA implies however re-contacting the original HA, and a second new redirection, and thus restarting applications? I mean I agree that the first 0th re-direction from the original genuine HA towards the first optimal HA might work ok for applications started _after_ that redirection, but a second re-direction towards a second optimal HA might not work, right? This is something like: MN arrives somewhere, contacts its HA, its HA says 'no, use this optimal HA near you' and then MN uses the optimal HA nearby, that optimal HA assigns MN a Home Address and MN can wander around with this Home Address, but don't go too far otherwise another HA becomes optimal and applications need to be restarted. This sounds very much like being solvable with HA discovery, but the draft discards it as being a security leak (CERT advisory something). It is also clearly stated in section 3.1 on Scope that the entire HA assignment scheme can only work inside the same administrative domain. Or, this again goes against my comprehension of Mobile IP original applicability statements, being designed to work across administrative domain boundaries (rfc2005). If one considers that only the HA's are required to be _inside_ a certain admin domain and the CN's can be outside, then, in order for this draft to bring any benefits with respect to any CN (the claimed optimal closeness) implies that this HA administrative domain MUST be close to all CN's in the Internet and such a domain does not exist. Otherwise, this entire HA assignment solution reduces to placing a CN inside the HA mobility domain, and thus it is a closed system design, and, again, designing closed systems is probably not very inline with the original goals of Mobile IP to work across the entire Internet. Overall, I feel that this draft involves reducing and eliminating two key aspects of Mobile IP: work across Internet and maintain ongoing applications. At the cost of this, it brings in a minimal re-direction advantage that avoids a CERT issue raised in 1998. What do you think? Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 00:55:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23895 for ; Sat, 8 Nov 2003 00:55:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIM3t-0001GU-29 for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 00:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA85t5oe004856 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 00:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIM3s-0001GF-QY for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 00:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23879 for ; Sat, 8 Nov 2003 00:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIM3p-0001Vq-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 00:55:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIM3p-0001Vn-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 00:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIM3p-0001Fb-BO; Sat, 08 Nov 2003 00:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIM2q-0001Eq-80 for mip4@optimus.ietf.org; Sat, 08 Nov 2003 00:54:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23866 for ; Sat, 8 Nov 2003 00:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIM2n-0001VG-00 for mip4@ietf.org; Sat, 08 Nov 2003 00:53:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIM2m-0001VB-00 for mip4@ietf.org; Sat, 08 Nov 2003 00:53:56 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2003 21:54:35 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA85rOAt029617; Fri, 7 Nov 2003 21:53:24 -0800 (PST) Received: from cisco.com (sjc-vpn1-11.cisco.com [10.21.96.11]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANJ39194; Fri, 7 Nov 2003 21:53:23 -0800 (PST) Message-ID: <3FAC84D3.6010308@cisco.com> Date: Fri, 07 Nov 2003 21:53:23 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru - As Milind has mentioned, draft-kulkarni addresses the problem of optimal anchoring at the beginning of the mobile IP session. On subsequent moves, the MN is NOT anchored (or reanchored at a different HA) - this aspect is clearly outside the scope and is clearly mentioned. From one of your previous emails, RO was considered in the mobileip working group quite some time ago and from what I understand, that work has been abandoned (chairs can comment more about this). I will be at IETF in Minneapolis and if you are still not clear about the problem or scope of the draft, we can talk about this. -a Alexandru Petrescu wrote: > Milind Kulkarni wrote: > >> Alex, >> >> Thanks for your responses. I glanced through NACP draft. Now I >> understand the view point you are coming from. The NACP draft is a >> different solution altogether. It is assisting in MN's handoff strategy. > > > Absolutely, NACP is assisting in MN's handoff strategy. There is no > relation between the two whatsoever. I was reviewing your draft at the > same time as announcing NACP here, but no relations. > > But my interest in the HA selection/assignment scheme comes from the > similarity between HAHA discussed in MIP6 and draft-kulkarni (nothing to > do with NACP). > >> The dynamic HA assignment draft is solving different problem. > > > Absolutely, sorry for the confusion. > >> It enhances the RFC-3344 behavior to get the optimal HA during session >> initiation only. Once selected, the MN is anchored to that HA >> for entire session. > > > A-ha, so would it be reasonable to say that, with draft-kulkarni, > upper-layer apps between MN-CN MUST be restarted each time a new HA is > assigned? (thus loosing the classical advantage of Mobile IP that it > preserves ongoing communications when address changes)? I assume that > when a new HA is assigned, a new Home Address is assigned to MN too, > even if NAI appears in the discussion. NAI is used by a normal HA to > assign and re-assign the same Home Address to an MN, but it is always > the same HA. > > If this session continuity advantage of Mobile IP is lost, is it > reasonable to say that an MN could simply acquire a new address from the > new DHCP server that it finds nearby, use that address for currrent > sessions, then move, break communications, find another DHCP server, > aquire a new address and so on? > > Otherwise, if the MN anchored to a new HA tries to continue using the > same Home Address (valid at the old HA), then the new HA MUST absolutely > have a means to get packets from CN towards that home address. I can > not find something in draft-kulkarni that clarifies this. > >> BTW, in which WG the NACP draft is tabled? > > > As you can see, we have announced NACP in this WG. It is an individual > submission, just like yours. > > Alex > GBU > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 01:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24556 for ; Sat, 8 Nov 2003 01:14:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMMF-0002aw-5a for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 01:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86E3DJ009968 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 01:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMME-0002ah-Et for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 01:14:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24553 for ; Sat, 8 Nov 2003 01:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMMB-0001od-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 01:13:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMMB-0001oa-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 01:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMMD-0002aL-Dn; Sat, 08 Nov 2003 01:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMLh-0002Zu-I7 for mip4@optimus.ietf.org; Sat, 08 Nov 2003 01:13:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24513 for ; Sat, 8 Nov 2003 01:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMLe-0001oH-00 for mip4@ietf.org; Sat, 08 Nov 2003 01:13:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AIMLe-0001nd-00 for mip4@ietf.org; Sat, 08 Nov 2003 01:13:26 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA86Csw5002720; Fri, 7 Nov 2003 22:12:54 -0800 (PST) Received: from cisco.com (sjc-vpn2-346.cisco.com [10.21.113.90]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALI46440; Fri, 7 Nov 2003 22:12:53 -0800 (PST) Message-ID: <3FAC8963.3030901@cisco.com> Date: Fri, 07 Nov 2003 22:12:51 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: mip4@ietf.org, Alpesh Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC3AB0.801@cisco.com> <12D2A932.3000009@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please see inline... Alexandru Petrescu wrote: > Milind Kulkarni wrote: > >> No, no! The messaging specified in the draft-kulkarni-xxx is done only >> at the beginning of a new MIP v4 session. So this is a *new* MIP >> session, which gets an optimal HA. The MN stays anchored to the >> optimal HA for the rest of the MIP session. After that everything is >> RFC3344. The MN's IP address remains same and upper layer >> applications remain intact. > > > Ah, I think I start to get it. So this would be a scenario like: > MN arrives in a new area (all sessions down), contacts its original > non-optimal HA, that non-optimal HA redirects towards this optimal HA > and, starting from now, rfc3344 goes on and MN can visit various foreign > networks close to this new HA. Packets from CN would be addressed to > the Home Address valid at this new HA and forwarded to the current CoA, > and all communications are not interupted. Correct.. > >> Breaking upper layer sessions (and restarting applications) is >> definitely out of question :) > > > ...until MN moves into an area where another HA is optimal, right? If it is the ongoing mobile IP session, MN would continue using it's assigned HA. > > Am I right to say that re-assigning a second new optimal HA implies > however re-contacting the original HA, and a second new redirection, and > thus restarting applications? No. The reassignment will not take place until next new MIP session. Looks like we going in circles ;) If you are going to IETF meeting next week, Alpesh Patel will be there and he will explain the proposal. You may want to read the draft in detail. Thanks, Milind > > I mean I agree that the first 0th re-direction from the original genuine > HA towards the first optimal HA might work ok for applications started > _after_ that redirection, but a second re-direction towards a second > optimal HA might not work, right? > > This is something like: MN arrives somewhere, contacts its HA, its HA > says 'no, use this optimal HA near you' and then MN uses the optimal HA > nearby, that optimal HA assigns MN a Home Address and MN can wander > around with this Home Address, but don't go too far otherwise another HA > becomes optimal and applications need to be restarted. > > This sounds very much like being solvable with HA discovery, but the > draft discards it as being a security leak (CERT advisory something). > > It is also clearly stated in section 3.1 on Scope that the entire HA > assignment scheme can only work inside the same administrative domain. > Or, this again goes against my comprehension of Mobile IP original > applicability statements, being designed to work across administrative > domain boundaries (rfc2005). > > If one considers that only the HA's are required to be _inside_ a > certain admin domain and the CN's can be outside, then, in order for > this draft to bring any benefits with respect to any CN (the claimed > optimal closeness) implies that this HA administrative domain MUST be > close to all CN's in the Internet and such a domain does not exist. > > Otherwise, this entire HA assignment solution reduces to placing a CN > inside the HA mobility domain, and thus it is a closed system design, > and, again, designing closed systems is probably not very inline with > the original goals of Mobile IP to work across the entire Internet. > > Overall, I feel that this draft involves reducing and eliminating two > key aspects of Mobile IP: work across Internet and maintain ongoing > applications. At the cost of this, it brings in a minimal re-direction > advantage that avoids a CERT issue raised in 1998. > > What do you think? > > Alex > GBU > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 01:21:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24681 for ; Sat, 8 Nov 2003 01:21:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMT1-0002lO-6J for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 01:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86L3tC010616 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 01:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMT1-0002l9-1B for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 01:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24673 for ; Sat, 8 Nov 2003 01:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMSx-0001vL-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 01:20:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMSx-0001vI-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 01:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMSz-0002kj-RM; Sat, 08 Nov 2003 01:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMSX-0002kD-Ks for mip4@optimus.ietf.org; Sat, 08 Nov 2003 01:20:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24663 for ; Sat, 8 Nov 2003 01:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMSU-0001v8-00 for mip4@ietf.org; Sat, 08 Nov 2003 01:20:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AIMSU-0001ur-00 for mip4@ietf.org; Sat, 08 Nov 2003 01:20:30 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA86Jww5005041; Fri, 7 Nov 2003 22:19:58 -0800 (PST) Received: from cisco.com (sjc-vpn1-11.cisco.com [10.21.96.11]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANJ39966; Fri, 7 Nov 2003 22:19:57 -0800 (PST) Message-ID: <3FAC8B0C.80800@cisco.com> Date: Fri, 07 Nov 2003 22:19:56 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC3AB0.801@cisco.com> <12D2A932.3000009@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru - Please see inline under ALPS>> BTW, something is wrong with the timestamp on this email that you sent. Alexandru Petrescu wrote: > Milind Kulkarni wrote: > >> No, no! The messaging specified in the draft-kulkarni-xxx is done only >> at the beginning of a new MIP v4 session. So this is a *new* MIP >> session, which gets an optimal HA. The MN stays anchored to the >> optimal HA for the rest of the MIP session. After that everything is >> RFC3344. The MN's IP address remains same and upper layer >> applications remain intact. > > > Ah, I think I start to get it. So this would be a scenario like: > MN arrives in a new area (all sessions down), contacts its original > non-optimal HA, that non-optimal HA redirects towards this optimal HA > and, starting from now, rfc3344 goes on and MN can visit various foreign > networks close to this new HA. Packets from CN would be addressed to > the Home Address valid at this new HA and forwarded to the current CoA, > and all communications are not interupted. ALPS>> It is also possible that MN did not have a "cached" old-HA address (from a previous MIP session). Thus, it could start with All-zero-one-address (AZOA) as mentioned in the draft. > >> Breaking upper layer sessions (and restarting applications) is >> definitely out of question :) > > > ...until MN moves into an area where another HA is optimal, right? ALPS>> Once the MN is anchored, as long as the MIP session is in progress, we don't reanchor. This is clearly outside the scope of our draft (and mentioned in the draft). > > Am I right to say that re-assigning a second new optimal HA implies > however re-contacting the original HA, and a second new redirection, and > thus restarting applications? ALPS>> No - we don't re-assign MN to a new optimal HA. > > I mean I agree that the first 0th re-direction from the original genuine > HA towards the first optimal HA might work ok for applications started > _after_ that redirection, but a second re-direction towards a second > optimal HA might not work, right? ALPS>> No - as we have mentioned, the dynamic assignment occurs only when MIP session is established. > > This is something like: MN arrives somewhere, contacts its HA, its HA > says 'no, use this optimal HA near you' and then MN uses the optimal HA > nearby, that optimal HA assigns MN a Home Address and MN can wander > around with this Home Address, but don't go too far otherwise another HA > becomes optimal and applications need to be restarted. ALPS>> We are clearly not addressing the same issue. There is no reanchoring/redirection once MN is anchored. Once anchored, it is RFC3344, until MN re-initiates MIP session. Thus, our dynamic HA assignment mechanism kicks-in when the MIP session "starts". > > This sounds very much like being solvable with HA discovery, but the > draft discards it as being a security leak (CERT advisory something). ALPS>> HA discovery as per 3344 won't work. I would kindly refer you to the description in the draft and the CERT advisory. > > It is also clearly stated in section 3.1 on Scope that the entire HA > assignment scheme can only work inside the same administrative domain. > Or, this again goes against my comprehension of Mobile IP original > applicability statements, being designed to work across administrative > domain boundaries (rfc2005). ALPS>> "single administrative domain" means that MN and HA belong to the same domain. MN can roam to any domain and register to its HA from where it is currently roaming. MN and HA being in separate domains is outside the scope of the draft. > > If one considers that only the HA's are required to be _inside_ a > certain admin domain and the CN's can be outside, then, in order for > this draft to bring any benefits with respect to any CN (the claimed > optimal closeness) implies that this HA administrative domain MUST be > close to all CN's in the Internet and such a domain does not exist. ALPS>> Well one of the problem statements is the MN/HA proximity (among others as Milind pointed out). MN/CN or HA/CN proximity is not an issue that we address in this draft. That problem you mention was part of the RO draft, but I think it is not a WG item any longer. This draft does not suggest/mandate any specific network design WRT HA/CN location. > > Otherwise, this entire HA assignment solution reduces to placing a CN > inside the HA mobility domain, and thus it is a closed system design, > and, again, designing closed systems is probably not very inline with > the original goals of Mobile IP to work across the entire Internet. ALPS>> I think we are not in sync. with the problem we are describing. CN can reside anywhere in the Internet - no reference to this. > > Overall, I feel that this draft involves reducing and eliminating two > key aspects of Mobile IP: work across Internet and maintain ongoing > applications. At the cost of this, it brings in a minimal re-direction > advantage that avoids a CERT issue raised in 1998. ALPS>> I respectfully disagree. None of the basic assumptions/purposes of Mobile IP are broken/violated. The advantages/problem statement is addressed in section 3 of the draft. > > What do you think? ALPS>> I think a face to face meeting may help to solve this confusion. I would recommend that you read the draft in detail to appreciate the problem statement/applicability. ALPS>> I will be at Minneapolis and am more than willing to talk with you/anyone about this. (Will post the summary statement to this thread to close the loop). Alpesh > > Alex > GBU > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 09:33:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16845 for ; Sat, 8 Nov 2003 09:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIU99-0008GV-VF for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 09:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8EX354031767 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 09:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIU99-0008GI-Py for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 09:33:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16842 for ; Sat, 8 Nov 2003 09:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIU98-0007iZ-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 09:33:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIU97-0007iW-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 09:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIU97-0008G0-5E; Sat, 08 Nov 2003 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIU8U-0008Fi-Sj for mip4@optimus.ietf.org; Sat, 08 Nov 2003 09:32:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16804 for ; Sat, 8 Nov 2003 09:32:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIU8S-0007hv-00 for mip4@ietf.org; Sat, 08 Nov 2003 09:32:20 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AIU8S-0007hp-00 for mip4@ietf.org; Sat, 08 Nov 2003 09:32:20 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hA8EVweS026496; Sat, 8 Nov 2003 07:31:58 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.5]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hA8EVbcS014241; Sat, 8 Nov 2003 08:31:41 -0600 Message-ID: <12D35CA7.7070707@nal.motlabs.com> Date: Fri, 04 Jan 1980 14:48:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh CC: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC3AB0.801@cisco.com> <12D2A932.3000009@nal.motlabs.com> <3FAC8B0C.80800@cisco.com> In-Reply-To: <3FAC8B0C.80800@cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alpesh wrote: >> ...until MN moves into an area where another HA is optimal, right? > > > ALPS>> Once the MN is anchored, as long as the MIP session is in > progress, we don't reanchor. This is clearly outside the scope of our > draft (and mentioned in the draft). Exactly, so the redirection and assignment of HA happens only at the beginning of the MIP session and the goal of the draft is not to allow MN to hop between HA's. >> I mean I agree that the first 0th re-direction from the original >> genuine HA towards the first optimal HA might work ok for >> applications started _after_ that redirection, but a second >> re-direction towards a second optimal HA might not work, right? > > ALPS>> No - as we have mentioned, the dynamic assignment occurs only > when MIP session is established. Ok. >> This is something like: MN arrives somewhere, contacts its HA, its >> HA says 'no, use this optimal HA near you' and then MN uses the >> optimal HA nearby, that optimal HA assigns MN a Home Address and MN >> can wander around with this Home Address, but don't go too far >> otherwise another HA becomes optimal and applications need to be >> restarted. > > > ALPS>> We are clearly not addressing the same issue. There is no > reanchoring/redirection once MN is anchored. Once anchored, it is > RFC3344, until MN re-initiates MIP session. Thus, our dynamic HA > assignment mechanism kicks-in when the MIP session "starts". Ok, the reassignment is a one time operation. >> This sounds very much like being solvable with HA discovery, but >> the draft discards it as being a security leak (CERT advisory >> something). > > > ALPS>> HA discovery as per 3344 won't work. I would kindly refer you > to the description in the draft and the CERT advisory. Allright. I would kindly ask you to describe what is the particular scenario happening in the real world that needs this kind of HA redirection at MIP session startup. I've tried to interpolate one, based on private-public information. For example, a private secret set of slides posted to all the NEMO WG members only, discussed HA re-assignment when a plane travels to a new continent. With your solution, the plane arrives over a new continent, coming from his home continent, starts a MIP session, the HA from the home continent redirects to the new HA and communications start. The problem with this scenario is that when the plane does the return flight, it MUST start a new MIP session in order to get attached to the old HA of the old continent. The entire plane scenario has something missing with respect to HA placing and your solution does not seem to solve that problem. Your solution clearly works only for a first HA reassignment to an optimal HA; once anchored, the MN MUST stay anchored. If it wants to come back to its initial home, it MUST re-start applications. >> It is also clearly stated in section 3.1 on Scope that the entire >> HA assignment scheme can only work inside the same administrative >> domain. Or, this again goes against my comprehension of Mobile IP >> original applicability statements, being designed to work across >> administrative domain boundaries (rfc2005). > > > ALPS>> "single administrative domain" means that MN and HA belong to > the same domain. MN can roam to any domain and register to its HA > from where it is currently roaming. MN and HA being in separate > domains is outside the scope of the draft. Exactly. And with this above paragraph the draft goes further into believing that the domain holding the HA's can be close to any domain where MN may roam. Or, the MN may roam across the entire Internet, thus the draft seems to place HA's in a single admin domain that is present across the entire Internet. > ALPS>> Well one of the problem statements is the MN/HA proximity > (among others as Milind pointed out). MN/CN or HA/CN proximity is not > an issue that we address in this draft. That problem you mention was > part of the RO draft, but I think it is not a WG item any longer. > This draft does not suggest/mandate any specific network design WRT > HA/CN location. This draft mandates the placement of all HA's inside a single admin domain, right? This is the whole issue, it qualifies the problem of MN-HA distances inside this domain as more important than the problem of CN-MN distances across the entire Internet. >> Otherwise, this entire HA assignment solution reduces to placing a >> CN inside the HA mobility domain, and thus it is a closed system >> design, and, again, designing closed systems is probably not very >> inline with the original goals of Mobile IP to work across the >> entire Internet. > > > ALPS>> I think we are not in sync. with the problem we are > describing. CN can reside anywhere in the Internet - no reference to > this. Look, imagine that plane talks to a CN that is close to the original HA. Now plane arrives at new HA, gets anchored to this new HA and starts again talking to the CN that is close to the home HA. Using this draft clearly involves loosing benefits, because the CN is not placed near the new HA, but near the old HA. >> Overall, I feel that this draft involves reducing and eliminating >> two key aspects of Mobile IP: work across Internet and maintain >> ongoing applications. At the cost of this, it brings in a minimal >> re-direction advantage that avoids a CERT issue raised in 1998. > > ALPS>> I respectfully disagree. None of the basic > assumptions/purposes of Mobile IP are broken/violated. The > advantages/problem statement is addressed in section 3 of the draft. Sure, I wouldn't have expected you to agree :-) So I respectfully disagree too. > ALPS>> I think a face to face meeting may help to solve this > confusion. I would recommend that you read the draft in detail to > appreciate the problem statement/applicability. I would recommend that an external reviewer (not the authors) give their impression about the draft and thus help find out whether there is interest in this particular draft. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 09:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16886 for ; Sat, 8 Nov 2003 09:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUBA-0008Na-8H for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 09:35:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8EZ8nL032204 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 09:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUBA-0008NL-3O for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 09:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16881 for ; Sat, 8 Nov 2003 09:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIUB8-0007jD-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 09:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIUB7-0007j8-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 09:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUB4-0008LG-3J; Sat, 08 Nov 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUAn-0008KV-BB for mip4@optimus.ietf.org; Sat, 08 Nov 2003 09:34:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16873 for ; Sat, 8 Nov 2003 09:34:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIUAl-0007j2-00 for mip4@ietf.org; Sat, 08 Nov 2003 09:34:43 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AIUAk-0007iw-00 for mip4@ietf.org; Sat, 08 Nov 2003 09:34:43 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA8EYUJl025473; Sat, 8 Nov 2003 07:34:31 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.5]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hA8EYHcS015500; Sat, 8 Nov 2003 08:34:21 -0600 Message-ID: <12D35D47.5020209@nal.motlabs.com> Date: Fri, 04 Jan 1980 14:51:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh CC: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC84D3.6010308@cisco.com> In-Reply-To: <3FAC84D3.6010308@cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alpesh wrote: > Alexandru - > > As Milind has mentioned, draft-kulkarni addresses the > problem of optimal anchoring at the beginning of the > mobile IP session. > > > On subsequent moves, the MN is NOT anchored (or reanchored > at a different HA) - this aspect is clearly outside the > scope and is clearly mentioned. Ok, this is a good scope. Just to say that the benefits of this method are lost when the MN tries to move back closer to the initial HA. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 8 10:25:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18923 for ; Sat, 8 Nov 2003 10:25:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUxT-0001mr-EY for mip4-archive@odin.ietf.org; Sat, 08 Nov 2003 10:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8FP3gu006866 for mip4-archive@odin.ietf.org; Sat, 8 Nov 2003 10:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUxT-0001mf-82 for mip4-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 10:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18914 for ; Sat, 8 Nov 2003 10:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIUxQ-0000Sk-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 10:25:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIUxQ-0000Sh-00 for mip4-web-archive@ietf.org; Sat, 08 Nov 2003 10:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUxR-0001mJ-NP; Sat, 08 Nov 2003 10:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIUwd-0001j2-FL for mip4@optimus.ietf.org; Sat, 08 Nov 2003 10:24:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18899 for ; Sat, 8 Nov 2003 10:23:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIUwb-0000SE-00 for mip4@ietf.org; Sat, 08 Nov 2003 10:24:09 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AIUwa-0000SB-00 for mip4@ietf.org; Sat, 08 Nov 2003 10:24:08 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hA8FNnLK015879; Sat, 8 Nov 2003 08:23:52 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.17]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA8FMDLv010711; Sat, 8 Nov 2003 09:22:17 -0600 Message-ID: <12D368D5.7010502@nal.motlabs.com> Date: Fri, 04 Jan 1980 15:40:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Milind Kulkarni CC: mip4@ietf.org, Alpesh Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> <3FAC3525.8010909@nal.motlabs.com> <3FAC3AB0.801@cisco.com> <12D2A932.3000009@nal.motlabs.com> <3FAC8963.3030901@cisco.com> In-Reply-To: <3FAC8963.3030901@cisco.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Milind Kulkarni wrote: > Looks like we going in circles ;) If you are going to IETF meeting > next week, Alpesh Patel will be there and he will explain the > proposal. You may want to read the draft in detail. Thanks for the recommendation. I'm not going to next IETF meeting but if you go, Hong-Yon Lach (co-author of NACP) will be there so maybe he will assist at the explanation. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 10 09:20:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20406 for ; Mon, 10 Nov 2003 09:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCtm-0006oP-MR for mip4-archive@odin.ietf.org; Mon, 10 Nov 2003 09:20:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAEKAdC026179 for mip4-archive@odin.ietf.org; Mon, 10 Nov 2003 09:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCtm-0006oA-2G for mip4-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 09:20:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20397 for ; Mon, 10 Nov 2003 09:19:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCtk-000555-00 for mip4-web-archive@ietf.org; Mon, 10 Nov 2003 09:20:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJCtk-000551-00 for mip4-web-archive@ietf.org; Mon, 10 Nov 2003 09:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCtf-0006ne-84; Mon, 10 Nov 2003 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCtS-0006ms-Iz for mip4@optimus.ietf.org; Mon, 10 Nov 2003 09:19:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20384 for ; Mon, 10 Nov 2003 09:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCtQ-00054x-00 for mip4@ietf.org; Mon, 10 Nov 2003 09:19:48 -0500 Received: from dyn130-249.ietf58.ietf.org ([130.129.130.249] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1AJCtQ-00054r-00 for mip4@ietf.org; Mon, 10 Nov 2003 09:19:48 -0500 Received: (qmail 26940 invoked from network); 10 Nov 2003 14:19:39 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 10 Nov 2003 14:19:39 -0000 Date: Mon, 10 Nov 2003 15:19:37 +0100 From: Henrik Levkowetz To: Alexandru Petrescu Cc: mip4@ietf.org, lach@crm.mot.com, miguel.catalina@motorola.com Subject: Re: [Mip4] new draft on network selection (NACP) Message-Id: <20031110151937.2a9c3a80.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Mon__10_Nov_2003_15_19_37_+0100_=.5?mxw6qY/hclB7" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Multipart_Mon__10_Nov_2003_15_19_37_+0100_=.5?mxw6qY/hclB7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello Alexandru, One prior draft you may want to have a look at, which is very much related to your work here, is a record of the implementation of an experimental handover assistance protocol. You can find it at (it has timed out from the ietf repository): http://www.levkowetz.com/pub/id/draft-levkowetz-seamoby-sample-00.txt Regards, Henrik Friday 7 November 2003, Alexandru wrote: > The NACP is at: > http://www.ietf.org/internet-drafts/draft-lach-nac-01.txt (Correcting the URL in this earlier post from the same day:) > Hi again to the MIP4 group, > > We have recently submitted a draft on mechanisms for network selection > by an MN. It's called NACP for Network Access Co-ordination Protocol > and we're looking for feedback on it. > > http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt > > The draft describes a simple protocol happening between MN and a > Network Access Agent (NAA) and allows a Mobile IPv4 MN to maintain > ongoing connections while switching between three very different types > of wireless links. MN sends to NAA a list of access networks that it > can sense (GPRS, WLAN and DVB-T) and subsequently the NAA suggests > back to MN which of those networks to use; NAA's suggestions rely on > its high-level visibility of network, errrr, resources. (while MN has > supposedly little visibility over how networks are overloaded, or how > expensive). > > The relationship to Mobile IPv4: > -working over heterogeneous systems is only possible if IP is used, > being wireless implies mobility, and the wide-area characteristics of > both GPRS and DVB-T imply Mobile IP. > -MN uses its Home Address to inform the NAA about its identity (and > not its temporary Care-of Address). > > Previously, the only WG that touched and delivered on these concepts > was Seamoby. One resulted protocol was CARD. With CARD, the MN is > assisted by first-hop Access Routers, while with NACP the MN is > assisted by an entity deep in the network (that's why NACP is UDP > while CARD is IP). > > More recently, a related draft is > draft-njedjou-inter-an-handoffs-00.txt, which discusses the benefits > of such a scheme but does not propose an actual solution. > > We're looking for guidance, and initially trying to learn how this > work maybe already existed before, or how it can be done entirely > differently, or maybe how some other RFC's already do it, or how wrong > the reasoning above might be. Any feedback appreciated. --Multipart_Mon__10_Nov_2003_15_19_37_+0100_=.5?mxw6qY/hclB7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r556eVhrtTJkXCMRAvVkAKCwtBii7kKf4O40bDXnXg3B/mXPdwCfctyS EPz5p2d2VPLlJGTm6qjwbn4= =ytYN -----END PGP SIGNATURE----- --Multipart_Mon__10_Nov_2003_15_19_37_+0100_=.5?mxw6qY/hclB7-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 10 12:30:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02086 for ; Mon, 10 Nov 2003 12:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFrX-0003b3-F7 for mip4-archive@odin.ietf.org; Mon, 10 Nov 2003 12:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHU3tL013825 for mip4-archive@odin.ietf.org; Mon, 10 Nov 2003 12:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFrX-0003au-5L for mip4-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:30:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02060 for ; Mon, 10 Nov 2003 12:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFrV-0000rn-00 for mip4-web-archive@ietf.org; Mon, 10 Nov 2003 12:30:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFrV-0000rj-00 for mip4-web-archive@ietf.org; Mon, 10 Nov 2003 12:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFrV-0003aN-1u; Mon, 10 Nov 2003 12:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFrP-0003Zx-Ua for mip4@optimus.ietf.org; Mon, 10 Nov 2003 12:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02051 for ; Mon, 10 Nov 2003 12:29:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFrO-0000rZ-00 for mip4@ietf.org; Mon, 10 Nov 2003 12:29:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJFrN-0000qp-00 for mip4@ietf.org; Mon, 10 Nov 2003 12:29:54 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 09:32:37 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAHTKAt019167; Mon, 10 Nov 2003 09:29:20 -0800 (PST) Received: from KLEUNG-W2K.cisco.com (sjc-vpn2-55.cisco.com [10.21.112.55]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK39878; Mon, 10 Nov 2003 09:29:16 -0800 (PST) Message-Id: <4.3.2.7.2.20031110092144.0228e920@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 09:29:13 -0800 To: Alexandru Petrescu From: Kent Leung Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt Cc: Milind Kulkarni , mip4@ietf.org In-Reply-To: <3FAC3525.8010909@nal.motlabs.com> References: <3FAC2880.9080408@cisco.com> <200310171934.PAA18267@ietf.org> <3FAC169B.1010208@cisco.com> <3FAC2880.9080408@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Alex. Just couple of comments. >>The dynamic HA assignment draft is solving different problem. > >Absolutely, sorry for the confusion. 1) The 2 drafts address different problems and propose different solutions. There is no need to tie them together, IMHO. >If this session continuity advantage of Mobile IP is lost, is it >reasonable to say that an MN could simply acquire a new address from the >new DHCP server that it finds nearby, use that address for currrent >sessions, then move, break communications, find another DHCP server, >aquire a new address and so on? 2) The dynamic HA assignment draft provides the mechanism to anchor the session initially (based on optimal path or administrative policy). The HA maintains that session until MN decides to re-anchor (possibly after restart/dormant mode transition/MN policy). Kent -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 12 19:33:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19474 for ; Wed, 12 Nov 2003 19:33:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5Pz-0005zV-Cm for mip4-archive@odin.ietf.org; Wed, 12 Nov 2003 19:33:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD0X33o023025 for mip4-archive@odin.ietf.org; Wed, 12 Nov 2003 19:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5Pz-0005zI-6J for mip4-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 19:33:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19447 for ; Wed, 12 Nov 2003 19:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5Px-0001yb-00 for mip4-web-archive@ietf.org; Wed, 12 Nov 2003 19:33:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK5Pw-0001yX-00 for mip4-web-archive@ietf.org; Wed, 12 Nov 2003 19:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5Px-0005yC-Qc; Wed, 12 Nov 2003 19:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5P0-0005mz-0z for mip4@optimus.ietf.org; Wed, 12 Nov 2003 19:32:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19384; Wed, 12 Nov 2003 19:31:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ox-0001y3-00; Wed, 12 Nov 2003 19:31:59 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ow-0001xy-00; Wed, 12 Nov 2003 19:31:59 -0500 Message-ID: <00f601c3a97d$991aea70$85818182@dclkempt40> From: "James Kempf" To: , , , Date: Wed, 12 Nov 2003 16:32:17 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C3A93A.899CD560" Subject: [Mip4] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Attached are the minutes of the multiple link flows BAR BOF. jak ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; name="multilink-flows-bof-writeup.txt" Content-Disposition: attachment; filename="multilink-flows-bof-writeup.txt" Content-Transfer-Encoding: quoted-printable Introduction=0A= ------------=0A= =0A= This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless = last hop links were the primary focus, since market introduction of = consumer devices with multiple wireless interfaces is pending, and = people can get the same now with laptops that have multiple wireless = interface cards.=0A= =0A= Single Logical Flow over Separate Physical Links/IP Addresses=0A= -------------------------------------------------------------=0A= =0A= This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the = device. This technique had been proposed by SCTP orignally as a way of = load balancing, and in other contexts for transport striping to achieve = higher throughput. Randy Steward talked about why this was taken out of = SCTP. In summary, although the sending host may utilize multiple = addresses for the receiving host, and although the the receiving host = might have those multiple addresses configured on multiple separate = physical interfaces, the traffic between the two might run over the = exact same physical path, and consequently utilizing two addresses won't = really provide any load balancing as far as the intervening network is = concerned. Problems include out of order packets, false retransmissions, = problems with congestion control variables, and timeouts. Performing = retransmission on one address for congestion detected on the other might = have the perverse effect of causing worse congestion. As a result, SCTP = now supports multiple links only for purposes of fault tolerance, = failing over to a new link if the old one goes down, and not load = balancing.=0A= =0A= The University of Deleware has been doing research on this topic and has = published some papers. Below is a short bibliography:=0A= =0A= http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf=0A= =0A= Describes the problems with concurrent multilink transfer and proposes = some algorithms to fix the problems.=0A= =0A= http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf=0A= =0A= Shows that retransmit policies which try to utilize multiple paths often = result in worse performance.=0A= =0A= Moving Flows Between Mobile IP Care of Addresses=0A= ------------------------------------------------=0A= =0A= The idea behind this proposal is to allow movement of multiple flows = between different Mobile IP care of addresses depending on the = characteristics of the wireless links on which those addresses are = configured. The proposal seems most interesting near term for the MIP4 = WG in order to accommodate multiple interface devices in existing MIP4 = deployments, and longer term in the MIP6 WG as well as for mobile = networks in NEMO. This technique would not be performing link = aggregation since the paths for logical flows would be uniform, not = split. From the point of view of the SCTP experience, this seemed as if = it would not be a problem since end to end congestion control is being = performed on logical flows that traverse one path. It would, however, = hide the flow movement from the correspondent node, i.e. the = corresponding end point would not be involved in the decision about = which care of address to use. This idea has motivated a draft in the = MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends = installing "filters" at the home agent to perform the redirection. The = filters would allow traffic of various types to be redirected to care of = addresses whose corresponding physical interfaces had particular = bandwidth and latency characteristics, for example, running video over a = broadband WLAN interface. In addition, it would help preserve home = addresses in MIP4 since the MN would only have a single home address. = Clearly, there is a potential end to end issue in not notifying the = correspondent node about the flow switching, but since the home agent is = essentiall performing a routing function, the situation is not much = different than a QoS router that switches a flow to a different = interface due to flow state set up by RSVP signaling. There is, of = course, the same scaling issue in the home agent as for RSVP, since the = home agent must maintain per flow and per care of address state, but the = scaling issue is restricted to just the home agent.=0A= =0A= If this proposal is accepted, there is an issue about which signaling = protocol to use with the home agent to tell it how to move the flows. = Mobile IP itself was suggested, QoS signaling protocols such as RSVP and = NSIS, SNMP, and COPS. Lately, the trend has been to not add additional = functions into Mobile IP, to keep it simple and dedicated strictly to = mobility, thus, AAA was separated out of MIP6, so the MIP protocol = itself might not be the best choice for the signaling protocol.=0A= =0A= Simulations and prototypes in realistic networks would also be of = interest, to see if any unanticipated problems crop up.=0A= =0A= Two specific problems were discussed besides the general problem. One = was the usefulness of multiple care of addresses for mobile networks. = NEMO is still studying the issue, and hasn't as yet worked through the = problem. The other was using RFC 3401 address privacy for IPv6. In this = scenerio, the mobile node has multiple care of addresses assigned to a = single interface, and would like to use them for privacy between the = mobile node and home agent. =0A= =0A= Next Steps=0A= ----------=0A= =0A= There was no concensus in the group about whether the problem was = specifically an issue for the MIP groups or whether it required = participation from other WGs. Since there are some proposals before the = MIP4 & MIP6 WGs currently, the MIP groups are the logical place to = start. Thomas Narten suggested coming up with a clear problem statement, = and Carsten Borman volunteered to talk with the group at Universitaet = Bremen who authored draft-nomad-mobileip-filters-05.txt about authoring = a clear problem statement for the MIP care of address case.=0A= =0A= =0A= Terminology=0A= -----------=0A= =0A= After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that = doesn't capture the problem since it also implies logical flows over = multiple IP addresses, something that the SCTP experience has indicated = is problematic from a congestion control standpoint. The term "QoS = routing" came up during the meeting but that drags along a lot of = baggage. "Flow handoff" seems to capture the topic best, since the = intent is to hand off individual flows to care of addresses that have = the best characteristics for handling the flows. ------=_NextPart_000_00EE_01C3A93A.899CD560-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 12 21:49:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23516 for ; Wed, 12 Nov 2003 21:49:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Xa-0004fs-Nu for mip4-archive@odin.ietf.org; Wed, 12 Nov 2003 21:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD2n24H017962 for mip4-archive@odin.ietf.org; Wed, 12 Nov 2003 21:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Xa-0004fd-JY for mip4-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 21:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23496 for ; Wed, 12 Nov 2003 21:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XX-0003qR-00 for mip4-web-archive@ietf.org; Wed, 12 Nov 2003 21:48:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7XX-0003qO-00 for mip4-web-archive@ietf.org; Wed, 12 Nov 2003 21:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7XY-0004en-Pw; Wed, 12 Nov 2003 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7XT-0004eI-GI for mip4@optimus.ietf.org; Wed, 12 Nov 2003 21:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23490; Wed, 12 Nov 2003 21:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003q9-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003pd-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E062E6BA93; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hAD2mMgG007916; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hAD2mF7J021288; Wed, 12 Nov 2003 21:48:20 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031112213448.02839cc0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 12 Nov 2003 21:47:15 -0500 To: Alexandru Petrescu From: William D Ivancic Subject: Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-02.txt Cc: mip4@ietf.org, nemo@ietf.org In-Reply-To: References: <200310171934.PAA18267@ietf.org> <200310171934.PAA18267@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hello Alex, MIP4 and nemo: Regarding dynamic HA assignments in IPv4 (draft-kulkarni-mobileip-dynamic-assignment-02.txt) and nemo/IPv6 (draft-wakikawa-mip6-nemo-haha-00). I find some similarities and find these concepts very useful. I have had to opportunity to work with the dynamic HA in IPv4. Some of the potential architectures that can take advantage of the tools provided by these proposed protocols are documented in a paper entitled "Use of Mobile-IP Priority Home Agents for Aeronautics, Space Operations and Military Applications." The draft paper is available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/PID1317.pdf Will At 08:21 PM 11/7/2003 +0100, Alexandru Petrescu wrote: > writes: > > Title : Mobile IPv4 Dynamic Home Agent Assignment Framework > > Author(s) : M. Kulkarni, A. Patel, K. Leung > > Filename : draft-kulkarni-mobileip-dynamic-assignment-02.txt > > Pages : 21 > > Date : 2003-10-17 > >Hi to MIP4 members, I've read this draft because it relates to a >similar draft for Mobile IPv6 with which I got familiar weeks ago. > >I was wondering if I can get IPv4-specific clarification for the >motivation behind this idea. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 11:28:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05969 for ; Thu, 13 Nov 2003 11:28:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKKE-0000uk-Pa for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 11:28:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGS6n1003514 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 11:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKKE-0000uS-Ld for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05906 for ; Thu, 13 Nov 2003 11:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKKD-0000DC-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 11:28:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKKC-0000D7-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 11:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKK8-0000rf-OH; Thu, 13 Nov 2003 11:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKJm-0000qd-QT for mip4@optimus.ietf.org; Thu, 13 Nov 2003 11:27:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05884; Thu, 13 Nov 2003 11:27:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKJl-0000Co-00; Thu, 13 Nov 2003 11:27:37 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKKJl-0000CV-00; Thu, 13 Nov 2003 11:27:37 -0500 Message-ID: <02f701c3aa03$07d095c0$85818182@dclkempt40> From: "James Kempf" To: "Nicolas Montavont" Cc: , References: <00f601c3a97d$991aea70$85818182@dclkempt40> <3FB3A6E0.3050503@clarinet.u-strasbg.fr> Date: Thu, 13 Nov 2003 08:26:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Nicolas, > Thank you James for this good minutes of our meeting. It clearly > clarifies things and help to move forward. > > However, I have to raise a point. We (Ryuji, Thierry, Thomas and me) > began to write a problem statement draft in MIP6 WG > (draft-montavont-multihoming-pb-statement-00) and I think that it can be > the starting point of a pb statement document. Following the > presentation of this draft at the MIP6 meeting, and from some comments > in the mailing list, we receive valuable feedback for the evolution of > this draft. Also, the bar bof gives us other ideas to enhance this document. > > So I think that a new version of this draft can constitute the pb > statement currently required to move forward on the multihoming. It is > not necessary to duplicate the efforts. > Sorry I missed this in the minutes. An update of your draft based on list feedback and discussion at the BAR BOF would certainly be valuable. I think the U. Bremen folks are primarily interested in MIP4 as that is where their prototype was done, and I believe the primary near term deployment interest is there, due to the possiblity of multiinterface laptops and pending release of multi-interface phones. However, I think it might make some sense for you and they to combine efforts if you both agree there would be some common points in the problem statement between MIP4 and MIP6. Since MIP4 has some immediate deployment interest, it might be most approprate to work on a general problem statement there first, with review from the MIP6 group, then later work on the MIP6 specific issues in the MIP6 group. I'd suggest contacting the WG chairs of MIP4 and MIP6 about how to proceed, and definitely talking with Carsten and U. Bremen folks about the possibility of combining efforts. jak -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 11:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06030 for ; Thu, 13 Nov 2003 11:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKL9-00017q-3k for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 11:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGT2jM004318 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 11:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKL8-00017X-JM for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06008 for ; Thu, 13 Nov 2003 11:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKL7-0000EC-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 11:29:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKL7-0000E9-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 11:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKL7-00015K-3V; Thu, 13 Nov 2003 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJeG-0005e4-Gw for mip4@optimus.ietf.org; Thu, 13 Nov 2003 10:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03798 for ; Thu, 13 Nov 2003 10:44:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJeD-0007EM-00 for mip4@ietf.org; Thu, 13 Nov 2003 10:44:41 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKJeB-0007EA-00 for mip4@ietf.org; Thu, 13 Nov 2003 10:44:39 -0500 Received: (qmail 27636 invoked for bounce); 13 Nov 2003 15:44:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 15:44:48 -0000 Message-ID: <3FB3A6E0.3050503@clarinet.u-strasbg.fr> Date: Thu, 13 Nov 2003 16:44:32 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org References: <00f601c3a97d$991aea70$85818182@dclkempt40> In-Reply-To: <00f601c3a97d$991aea70$85818182@dclkempt40> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Thank you James for this good minutes of our meeting. It clearly=20 clarifies things and help to move forward. However, I have to raise a point. We (Ryuji, Thierry, Thomas and me)=20 began to write a problem statement draft in MIP6 WG=20 (draft-montavont-multihoming-pb-statement-00) and I think that it can be = the starting point of a pb statement document. Following the=20 presentation of this draft at the MIP6 meeting, and from some comments=20 in the mailing list, we receive valuable feedback for the evolution of=20 this draft. Also, the bar bof gives us other ideas to enhance this docume= nt. So I think that a new version of this draft can constitute the pb=20 statement currently required to move forward on the multihoming. It is=20 not necessary to duplicate the efforts. Nicolas James Kempf wrote: >Folks, > >Attached are the minutes of the multiple link flows BAR BOF. > > jak > >------------------------------------------------------------------------= > >Introduction >------------ > >This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless las= t hop links were the primary focus, since market introduction of consumer= devices with multiple wireless interfaces is pending, and people can get= the same now with laptops that have multiple wireless interface cards. > >Single Logical Flow over Separate Physical Links/IP Addresses >------------------------------------------------------------- > >This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the dev= ice. This technique had been proposed by SCTP orignally as a way of load = balancing, and in other contexts for transport striping to achieve higher= throughput. Randy Steward talked about why this was taken out of SCTP. I= n summary, although the sending host may utilize multiple addresses for t= he receiving host, and although the the receiving host might have those m= ultiple addresses configured on multiple separate physical interfaces, th= e traffic between the two might run over the exact same physical path, an= d consequently utilizing two addresses won't really provide any load bala= ncing as far as the intervening network is concerned. Problems include ou= t of order packets, false retransmissions, problems with congestion contr= ol variables, and timeouts. Performing retransmission on one address for = congestion detected on the other might have the perverse effect of causin= g worse congestion. As a result, SCTP now supports multiple links only fo= r purposes of fault tolerance, failing over to a new link if the old one = goes down, and not load balancing. > >The University of Deleware has been doing research on this topic and has= published some papers. Below is a short bibliography: > >http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf > >Describes the problems with concurrent multilink transfer and proposes s= ome algorithms to fix the problems. > >http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf > >Shows that retransmit policies which try to utilize multiple paths often= result in worse performance. > >Moving Flows Between Mobile IP Care of Addresses >------------------------------------------------ > >The idea behind this proposal is to allow movement of multiple flows bet= ween different Mobile IP care of addresses depending on the characteristi= cs of the wireless links on which those addresses are configured. The pro= posal seems most interesting near term for the MIP4 WG in order to accomm= odate multiple interface devices in existing MIP4 deployments, and longer= term in the MIP6 WG as well as for mobile networks in NEMO. This techniq= ue would not be performing link aggregation since the paths for logical f= lows would be uniform, not split. From the point of view of the SCTP expe= rience, this seemed as if it would not be a problem since end to end cong= estion control is being performed on logical flows that traverse one path= =2E It would, however, hide the flow movement from the correspondent node= , i.e. the corresponding end point would not be involved in the decision = about which care of address to use. This idea has motivated a draft in th= e MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends installi= ng "filters" at the home agent to perform the redirection. The filters wo= uld allow traffic of various types to be redirected to care of addresses = whose corresponding physical interfaces had particular bandwidth and late= ncy characteristics, for example, running video over a broadband WLAN int= erface. In addition, it would help preserve home addresses in MIP4 since = the MN would only have a single home address. Clearly, there is a potenti= al end to end issue in not notifying the correspondent node about the flo= w switching, but since the home agent is essentiall performing a routing = function, the situation is not much different than a QoS router that swit= ches a flow to a different interface due to flow state set up by RSVP sig= naling. There is, of course, the same scaling issue in the home agent as = for RSVP, since the home agent must maintain per flow and per care of add= ress state, but the scaling issue is restricted to just the home agent. > >If this proposal is accepted, there is an issue about which signaling pr= otocol to use with the home agent to tell it how to move the flows. Mobil= e IP itself was suggested, QoS signaling protocols such as RSVP and NSIS,= SNMP, and COPS. Lately, the trend has been to not add additional functio= ns into Mobile IP, to keep it simple and dedicated strictly to mobility, = thus, AAA was separated out of MIP6, so the MIP protocol itself might not= be the best choice for the signaling protocol. > >Simulations and prototypes in realistic networks would also be of intere= st, to see if any unanticipated problems crop up. > >Two specific problems were discussed besides the general problem. One wa= s the usefulness of multiple care of addresses for mobile networks. NEMO = is still studying the issue, and hasn't as yet worked through the problem= =2E The other was using RFC 3401 address privacy for IPv6. In this scener= io, the mobile node has multiple care of addresses assigned to a single i= nterface, and would like to use them for privacy between the mobile node = and home agent.=20 > >Next Steps >---------- > >There was no concensus in the group about whether the problem was specif= ically an issue for the MIP groups or whether it required participation f= rom other WGs. Since there are some proposals before the MIP4 & MIP6 WGs = currently, the MIP groups are the logical place to start. Thomas Narten s= uggested coming up with a clear problem statement, and Carsten Borman vol= unteered to talk with the group at Universitaet Bremen who authored draft= -nomad-mobileip-filters-05.txt about authoring a clear problem statement = for the MIP care of address case. > > >Terminology >----------- > >After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that does= n't capture the problem since it also implies logical flows over multiple= IP addresses, something that the SCTP experience has indicated is proble= matic from a congestion control standpoint. The term "QoS routing" came u= p during the meeting but that drags along a lot of baggage. "Flow handoff= " seems to capture the topic best, since the intent is to hand off indivi= dual flows to care of addresses that have the best characteristics for ha= ndling the flows. > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 17:36:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25175 for ; Thu, 13 Nov 2003 17:36:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ4K-0004bu-T1 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 17:36:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADMa4xq017558 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 17:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ4J-0004Wp-PB for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 17:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25137 for ; Thu, 13 Nov 2003 17:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ4H-0006tp-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 17:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQ4G-0006tm-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 17:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ4I-0004UT-72; Thu, 13 Nov 2003 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ3o-0004Nu-Jw for mip4@optimus.ietf.org; Thu, 13 Nov 2003 17:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25048; Thu, 13 Nov 2003 17:35:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tE-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tB-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hADMZO5u025263; Thu, 13 Nov 2003 15:35:25 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADMZKQ08048; Thu, 13 Nov 2003 23:35:20 +0100 (MET) Date: Thu, 13 Nov 2003 23:34:21 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: James Kempf Cc: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <00f601c3a97d$991aea70$85818182@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Mip4] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , I didn't make it to the bar on Monday due to jetlag. One observation I have on the desire to send different flows over different paths/CoAs. Looking at possible multihoming solutions (take draft-nordmark-multi6-noid as an example one what a solution might look like) the result is that the stack would have a mapping from an ID (used by transport protocols) to a set of locators for the peer. This type of example shows that it might be useful to express sending different flows over different paths/locators even if mobility isn't used. Thus I don't think such a scheme, if we are going to define one, should be tied to mobility specific signalling. Erik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 21:13:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05354 for ; Thu, 13 Nov 2003 21:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTSJ-0004Pi-N3 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2D3BZ016956 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTSI-0004Nw-Rg for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:13:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05290 for ; Thu, 13 Nov 2003 21:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTSG-0002mF-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:13:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTSF-0002mB-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTSH-0004N7-Ki; Thu, 13 Nov 2003 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTRZ-0004Fl-3P for mip4@optimus.ietf.org; Thu, 13 Nov 2003 21:12:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05148; Thu, 13 Nov 2003 21:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTRV-0002jO-00; Thu, 13 Nov 2003 21:12:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKTRU-0002jC-00; Thu, 13 Nov 2003 21:12:13 -0500 Message-ID: <05a801c3aa54$c15258c0$85818182@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , "Carsten Bormann" Cc: "Carsten Bormann" , , , , References: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Date: Thu, 13 Nov 2003 18:12:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Carsten, > > This type of example shows that it might be useful to express sending > > different flows over different paths/locators even if mobility isn't > > used. > > > > Thus I don't think such a scheme, if we are going to define one, > > should be tied to mobility specific signalling. > > This is certainly good thinking, but the question is "express to whom"? > > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. > NSIS is certanly more general, but seems like it is the right approach architecturally. The home agent is essentially a middlebox, and from the presentations I saw today in the NSIS group, NSIS is a solution primarily for signaling to middleboxes, not routers like RSVP is. > Generality is not always cheap. > (I'm willing to be convinced that it actually is, in this case.) > Not clear what the implementation and deployment cost of NSIS is at this point. In terms of dynamic performance, whether the MN sends a binding update or an NSIS message to the home agent, does it make such a differenc? > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. > One could make an argument that it still might be useful to mask multihoming from the CN. jak -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 21:20:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05819 for ; Thu, 13 Nov 2003 21:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTZ8-0004t9-E3 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2K6Nk018710 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTZ7-0004rW-BQ for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:20:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05747 for ; Thu, 13 Nov 2003 21:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTZ4-0002y4-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:20:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTZ3-0002xz-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTZ5-0004pZ-O2; Thu, 13 Nov 2003 21:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTYO-0004mf-II for mip4@optimus.ietf.org; Thu, 13 Nov 2003 21:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05724; Thu, 13 Nov 2003 21:19:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYL-0002xv-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYK-0002xs-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAE2JCPh015944; Thu, 13 Nov 2003 19:19:13 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2J9Q05946; Fri, 14 Nov 2003 03:19:09 +0100 (MET) Date: Fri, 14 Nov 2003 03:18:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Mip4] Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > This is certainly good thinking, but the question is "express to whom"? To the entity that has the ability to choose locators. In some multihoming proposals this is a shim layer above IP at the originating node. > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. Yes, bolting solutions on existing protocols even though the problem is more general is a common approach; sometimes we pay deerly for this because - we might end up solving the general case as well - the general + specific solutions means that we know have two solutions for the same problem - the specific solution makes the exising protocol (MIP signalling in this case) more complex, less likely to interoperate, etc > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. How can the peer know that I want the video part of the conference over the WLAN interface and the audio part over GPRS? One could declare this to be an application specific problem, but it would still require application specific signalling, right? Erik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 21:22:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05954 for ; Thu, 13 Nov 2003 21:22:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTb3-0005IF-Kq for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2M5A9020223 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 21:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTb2-0005D6-O1 for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05911 for ; Thu, 13 Nov 2003 21:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaz-00030t-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:22:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTaz-00030n-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 21:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTb0-00056a-HF; Thu, 13 Nov 2003 21:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTad-00055T-I4 for mip4@optimus.ietf.org; Thu, 13 Nov 2003 21:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05895; Thu, 13 Nov 2003 21:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-00030H-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-0002zs-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAE2L0UP010808; Thu, 13 Nov 2003 18:21:01 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2KgQ06073; Fri, 14 Nov 2003 03:20:42 +0100 (MET) Date: Fri, 14 Nov 2003 03:19:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Nicolas Montavont Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <3FB41243.7020502@clarinet.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Mip4] Re: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > Then you leave the hot spot zone and want to switch your flows on GPRS > interface. To do so, you send a BU to your HA. In this case, it can be > very useful to add some filters on what flows you want to be redirected > and what flows you don't want on your GPRS interface. It seems to me > that to use the BU in that case is a good solution, because you only > need to send one message. This does not forbidd the use of other > mechanisms to manage multihoming in different situations. Yes, but this is just as useful even if I don't use MIP. Developping multiple solutions to the same problem shouldn't be a goal I think. Erik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 22:45:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09698 for ; Thu, 13 Nov 2003 22:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtO-0002eB-2D for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3j5V7010153 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtN-0002dS-Ix for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09683 for ; Thu, 13 Nov 2003 22:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004bo-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004bf-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtL-0002c0-6n; Thu, 13 Nov 2003 22:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKU3o-00075S-JN for mip4@optimus.ietf.org; Thu, 13 Nov 2003 21:51:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07335; Thu, 13 Nov 2003 21:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3l-0003c3-00; Thu, 13 Nov 2003 21:51:45 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3k-0003c0-00; Thu, 13 Nov 2003 21:51:44 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hAE2paCA008696; Fri, 14 Nov 2003 03:51:37 +0100 (MET) Date: Fri, 14 Nov 2003 03:51:43 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > How can the peer know that I want the video part of the conference over > the WLAN interface and the audio part over GPRS? > One could declare this to be an application specific problem, but it > would > still require application specific signalling, right? Yes, and both SIP/SDP(ng) and H.323 allow specifying the IP address of the destination for a media stream. You can even move those during a session (if the peer system implements this). Even FTP had third-party transfers, before these went out of fashion. With HTTP, you just use the right interface to make the request. On the other hand, if you always wanted to involve the CN in these handoffs, we wouldn't need MobileIP. (The interesting deviant case is a non-cooperating CN -- here you actually need a friend in the network even if you are not mobile.) Gruesse, Carsten -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 23:36:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09697 for ; Thu, 13 Nov 2003 22:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtO-0002eA-1j for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3j5NP010167 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtN-0002dO-Dt for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09678 for ; Thu, 13 Nov 2003 22:44:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004bj-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004bd-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtK-0002ba-LK; Thu, 13 Nov 2003 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQUy-0006jQ-1Y for mip4@optimus.ietf.org; Thu, 13 Nov 2003 18:03:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26408; Thu, 13 Nov 2003 18:03:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUu-0007Ky-00; Thu, 13 Nov 2003 18:03:32 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUt-0007Kv-00; Thu, 13 Nov 2003 18:03:31 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hADN3OEf011370; Fri, 14 Nov 2003 00:03:24 +0100 (MET) Date: Fri, 14 Nov 2003 00:03:30 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This type of example shows that it might be useful to express sending > different flows over different paths/locators even if mobility isn't > used. > > Thus I don't think such a scheme, if we are going to define one, > should be tied to mobility specific signalling. This is certainly good thinking, but the question is "express to whom"? When you have a HA, this is a good place to perform this flow handoff -- existing trust relationship, same administrative domain, existing and stable communication relationship. The MobileIP protocol is a good way to talk to the HA (and much of the signalling actually can be piggybacked). A more general approach (e.g., the closest willing router shared between the paths to the two interfaces) will need an on-path signalling protocol like NSIS, which is much more complex to use. Generality is not always cheap. (I'm willing to be convinced that it actually is, in this case.) Oh, and if there is no mobility, it is much easier to involve the CN (transport peer) from the outset -- no protocol needed in this (obvious) case. Gruesse, Carsten -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 13 23:36:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09699 for ; Thu, 13 Nov 2003 22:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtO-0002e9-15 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3j5d1010139 for mip4-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtN-0002dP-Ha for mip4-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09681 for ; Thu, 13 Nov 2003 22:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004bl-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUtJ-0004be-00 for mip4-web-archive@ietf.org; Thu, 13 Nov 2003 22:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtK-0002bn-UX; Thu, 13 Nov 2003 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQnd-0008UO-6D for mip4@optimus.ietf.org; Thu, 13 Nov 2003 18:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28745 for ; Thu, 13 Nov 2003 18:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQnZ-0007ki-00 for mip4@ietf.org; Thu, 13 Nov 2003 18:22:49 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKQnY-0007kb-00 for mip4@ietf.org; Thu, 13 Nov 2003 18:22:48 -0500 Received: (qmail 30510 invoked for bounce); 13 Nov 2003 23:22:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 23:22:48 -0000 Message-ID: <3FB41243.7020502@clarinet.u-strasbg.fr> Date: Fri, 14 Nov 2003 00:22:43 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >I didn't make it to the bar on Monday due to jetlag. > >One observation I have on the desire to send different flows over >different paths/CoAs. > >Looking at possible multihoming solutions (take draft-nordmark-multi6-noid >as an example one what a solution might look like) the result >is that the stack would have a mapping from an ID (used by transport protocols) >to a set of locators for the peer. > >This type of example shows that it might be useful to express sending >different flows over different paths/locators even if mobility isn't used. > >Thus I don't think such a scheme, if we are going to define one, >should be tied to mobility specific signalling. > I totally agree with you that if we specify a MIPv6-tied solution for "general" multihoming, we may encounter difficulties with non-MNs. But I think that some points are to be clarified in MIPv6 when the MN is multihomed. That is what we are trying to show in draft-montavont-pb-statement. And I'd like to point out another aspect of multihoming, more linked to our draft on filtering (draft-montavont-mip6-ha-filtering). Assume that you have two interfaces, a WLAN interface and a GPRS interface and you currently use the WLAN interface through a reverse tunnel with your home agent. Assume that you receive several flows on your pda. One of them is a video streaming. Then you leave the hot spot zone and want to switch your flows on GPRS interface. To do so, you send a BU to your HA. In this case, it can be very useful to add some filters on what flows you want to be redirected and what flows you don't want on your GPRS interface. It seems to me that to use the BU in that case is a good solution, because you only need to send one message. This does not forbidd the use of other mechanisms to manage multihoming in different situations. Maybe the conclusion of that can be that different problems may lead to different solutions. A clear problem statement, from each WG may definitly help to clarify the situation. Nicolas > > Erik > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 14 09:07:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10770 for ; Fri, 14 Nov 2003 09:07:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKebK-00005n-8W for mip4-archive@odin.ietf.org; Fri, 14 Nov 2003 09:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEE75js000308 for mip4-archive@odin.ietf.org; Fri, 14 Nov 2003 09:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKebI-0008WG-Ur for mip4-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 09:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10713 for ; Fri, 14 Nov 2003 09:06:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKebH-0005Yb-00 for mip4-web-archive@ietf.org; Fri, 14 Nov 2003 09:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKebG-0005YV-00 for mip4-web-archive@ietf.org; Fri, 14 Nov 2003 09:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKebG-0008UN-GV; Fri, 14 Nov 2003 09:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeb6-0008TK-Gh for mip4@optimus.ietf.org; Fri, 14 Nov 2003 09:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10707; Fri, 14 Nov 2003 09:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005YR-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005XU-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAEE6CxA008351; Fri, 14 Nov 2003 06:06:13 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAEE67Q15529; Fri, 14 Nov 2003 15:06:07 +0100 (MET) Date: Fri, 14 Nov 2003 15:05:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Mip4] Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > On the other hand, if you always wanted to involve the CN in these > handoffs, we wouldn't need MobileIP. You'd still need one (or more) rendez-vous points aka home agents to handle initial contact and both ends of communication moving at the same time. Erik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 05:24:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07363 for ; Mon, 17 Nov 2003 05:24:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALgY7-0000s1-8C for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 05:24:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHAO3eu003345 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 05:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALgY7-0000rs-0h for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 05:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07355 for ; Mon, 17 Nov 2003 05:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALgY3-0004Qr-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 05:23:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALgY3-0004Ql-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 05:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALgY5-0000qZ-4e; Mon, 17 Nov 2003 05:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALgXf-0000pg-Ht for mip4@optimus.ietf.org; Mon, 17 Nov 2003 05:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07326; Mon, 17 Nov 2003 05:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALgXb-0004Pz-00; Mon, 17 Nov 2003 05:23:31 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ALgXb-0004P2-00; Mon, 17 Nov 2003 05:23:31 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 05:20:36 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F041FFA@ftmail.lab.flarion.com> From: Soliman Hesham To: mip4@ietf.org, mip6@ietf.org Date: Mon, 17 Nov 2003 05:20:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi, Just wanted to drop a note on adding flow movement capabilities to MIP. I completely agree that adding new functions to MIP just because "it's there" does not make any sense, and that where a problem applies to both fixed and mobile hosts we should avoid fixing it in a mobility protocol. However, when it comes to flow movement, it is not immediately obvious to me that it is outside the scope of MIP. I'll try to break the problem down in an attempt to realise where each component belongs. The basic problem is that a node needs to decide what src address should be used by a particular connection. Forgetting about MIP for a minute, this is obvious when a host is trying to initiate communication with another host. Src address selection can be augmented with various policies (user-based or otherwise) to allow the host to pick the right src address. However, this is a bit more complex when a host is not the initiator of communication. This leads to sub-problem (1) (1) Informing the initiator of communication of the right dst address for the host on the other end. This information can be communicated implicitly or explicitly. One possible example for implicitly informing the other end is through using different domain names (e.g. audio.example.com returns a different address from video.example.com). On the other hand, explicit notification of the address can be done by using a protocol to negotiate a connection setup (e.g. SIP does this today). Not withstanding the example solutions above, sub-problem (1) is independent of any mobility and applies to any multi-addressed host. Once a connection is established, the right addresses are chosen by both ends, end of story. Now, the other aspect of the problem is this: Once a connection is established, using a particular src and destination address pair, how can either host modify this information? In other words, if WLAN coverage suddenly appeared to my laptop, how do I inform the host on the other end to move one of our connections to WLAN, while leaving the other on the cellular interface? In a few words, I want to change the dst address for a particular connection without breaking that connection. This requires a protocol to signal that to the other end. To me, this problem seems to fall into the IP mobility category of problems, although it is addressing a finer granularity of mobility. Note that SIP also has signalling support for session transfer, but: A) it was not intended for this purpose and B) it is not widely implemented and C) it is slower than an "optimised" MIP (BTW neither A nor B discredits using SIP for this purpose). So sub-problem (2): (2) How to move a flow from one address to another. MIP efficiently solves this problem for a host, but it does not provide further granularity (i.e. connection or flow). Personally, I think sub-problem (2) is a mobility problem, by the definition of IP mobility. I believe that MIP solves two problems: maintaining current connections while moving, and reachability. "Moving" in the context of IP mobility effectively means changing IP address, independently of whether that change affects all flows or only one or two. My 2 cents! Hesham -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 07:59:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10374 for ; Mon, 17 Nov 2003 07:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALiyI-0005Ew-EV for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 07:59:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHCxESC020142 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 07:59:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALiyI-0005Ek-0n for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 07:59:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10343 for ; Mon, 17 Nov 2003 07:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALiyG-00068r-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 07:59:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALiyG-00068Z-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 07:59:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALiy5-000595-Nt; Mon, 17 Nov 2003 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALiy3-00058a-D4 for mip4@optimus.ietf.org; Mon, 17 Nov 2003 07:58:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10336; Mon, 17 Nov 2003 07:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALiy2-00068U-00; Mon, 17 Nov 2003 07:58:58 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ALiy1-00068N-00; Mon, 17 Nov 2003 07:58:58 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ALixy-0000Ak-00; Mon, 17 Nov 2003 13:58:54 +0100 Date: Mon, 17 Nov 2003 13:58:44 +0100 From: Henrik Levkowetz To: Soliman Hesham Cc: mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031117135844.3e7af1b2.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFA@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFA@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, That's a pretty good summary. My own thinking on this, after a bit of discussion in Minneapolis, is that the MIP solution which is the least MIP-specific would be to have separate individual MIP sessions for each flow (or group of flows) we wanted to move independently of other flows. This takes care of the ability to treat flows individually, and it does so by providing separate Home IP-addresses for those flows to pass through. I also note that the flow groups, and their IP-addresses, needs to be established before individual user applications start up and bind to the individual HoAs - we have no way to signal most application to re-bind to a new IP-address. The cost of this solution is in having to do re-registration of multiple sessions when you move, but such a cost is already implicit in the fact that with multiple connections through different connection media you have to be able to handle each media individually, whether it is by separate sessions or by filter adaptations. But I believe completely separate sessions will adapt better to any other non-movement-specific solution to multihoming that may appear. Henrik Monday 17 November 2003, Hesham wrote: > Hi, > > Just wanted to drop a note on adding flow movement > capabilities to MIP. > > I completely agree that adding new functions to > MIP just because "it's there" does not make any sense, > and that where a problem applies to both fixed and mobile > hosts we should avoid fixing it in a mobility protocol. > However, when it comes to flow movement, it is not immediately > obvious to me that it is outside the scope of MIP. > I'll try to break the problem down in an attempt to realise > where each component belongs. > > The basic problem is that a node needs to decide what > src address should be used by a particular connection. > Forgetting about MIP for a minute, this is obvious when > a host is trying to initiate communication with another host. > Src address selection can be augmented with various policies > (user-based or otherwise) to allow the host to pick the > right src address. However, this is a bit more complex when > a host is not the initiator of communication. This leads > to sub-problem (1) > (1) Informing the initiator of communication of the right > dst address for the host on the other end. > > This information can be communicated implicitly or explicitly. > One possible example for implicitly informing the other end > is through using different domain names (e.g. audio.example.com > returns a different address from video.example.com). On the > other hand, explicit notification of the address can be done > by using a protocol to negotiate a connection setup (e.g. SIP > does this today). > > Not withstanding the example solutions above, sub-problem > (1) is independent of any mobility and applies to any > multi-addressed host. > > Once a connection is established, the right addresses are > chosen by both ends, end of story. > > Now, the other aspect of the problem is this: Once a connection > is established, using a particular src and destination address > pair, how can either host modify this information? In other > words, if WLAN coverage suddenly appeared to my laptop, how > do I inform the host on the other end to move one of our > connections to WLAN, while leaving the other on the cellular > interface? In a few words, I want to change the dst address for > a particular connection without breaking that connection. > This requires a protocol to signal that to the other end. > To me, this problem seems to fall into the IP mobility category > of problems, although it is addressing a finer granularity > of mobility. > Note that SIP also has signalling support for session transfer, > but: A) it was not intended for this purpose and B) it is > not widely implemented and C) it is slower than an "optimised" MIP > (BTW neither A nor B discredits using SIP for this purpose). > > So sub-problem (2): > (2) How to move a flow from one address to another. > > MIP efficiently solves this problem for a host, but it > does not provide further granularity (i.e. connection > or flow). > > Personally, I think sub-problem (2) is a mobility > problem, by the definition of IP mobility. I believe > that MIP solves two problems: maintaining current connections > while moving, and reachability. > "Moving" in the context of IP mobility effectively means > changing IP address, independently of whether that change > affects all flows or only one or two. > > My 2 cents! > > Hesham > > > > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 08:20:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10867 for ; Mon, 17 Nov 2003 08:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjIV-0006C4-BC for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 08:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDK71b023802 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 08:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjIU-000670-Kq for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:20:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10821 for ; Mon, 17 Nov 2003 08:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjIQ-0006NR-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 08:20:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjIQ-0006NO-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 08:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjIQ-00066W-I6; Mon, 17 Nov 2003 08:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjI6-000622-Gz for mip4@optimus.ietf.org; Mon, 17 Nov 2003 08:19:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10799; Mon, 17 Nov 2003 08:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjI5-0006Mo-00; Mon, 17 Nov 2003 08:19:41 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ALjI4-0006Lq-00; Mon, 17 Nov 2003 08:19:40 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 08:19:04 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Henrik Levkowetz'" Cc: mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Mon, 17 Nov 2003 08:19:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Henrik, It's certainly _a_ solution. And definitely a simple one. But I would view this as being very expensive for MIPv6. Assuming 2 HoAs, in the worst case scenario the MN could end up sending two BUs to the HA and two to each CN that knows about both HoAs. I think this is too expensive, especially if MIP is being used to manage mobility proper. For MIPv4 it's not as expensive, but sending two different RREQs upon movement can still be expensive from the edge of a cell, given the sizes of those messages. Hesham > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Monday, November 17, 2003 7:59 AM > To: Soliman Hesham > Cc: mip4@ietf.org; mip6@ietf.org > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] > Minutes of > Multiple Lin k Flows BAR BOF > > > Hi Hesham, > > That's a pretty good summary. My own thinking on this, > after a bit > of discussion in Minneapolis, is that the MIP solution which is the > least MIP-specific would be to have separate individual MIP > sessions for > each flow (or group of flows) we wanted to move > independently of other > flows. This takes care of the ability to treat flows > individually, and > it does so by providing separate Home IP-addresses for those flows to > pass through. > > I also note that the flow groups, and their IP-addresses, needs to be > established before individual user applications start up and > bind to the > individual HoAs - we have no way to signal most application > to re-bind > to a new IP-address. > > The cost of this solution is in having to do re-registration > of multiple > sessions when you move, but such a cost is already implicit > in the fact > that with multiple connections through different connection media you > have to be able to handle each media individually, whether it is by > separate sessions or by filter adaptations. But I believe completely > separate sessions will adapt better to any other > non-movement-specific > solution to multihoming that may appear. > > Henrik > > Monday 17 November 2003, Hesham wrote: > > Hi, > > > > Just wanted to drop a note on adding flow movement > > capabilities to MIP. > > > > I completely agree that adding new functions to > > MIP just because "it's there" does not make any sense, > > and that where a problem applies to both fixed and mobile > > hosts we should avoid fixing it in a mobility protocol. > > However, when it comes to flow movement, it is not immediately > > obvious to me that it is outside the scope of MIP. > > I'll try to break the problem down in an attempt to realise > > where each component belongs. > > > > The basic problem is that a node needs to decide what > > src address should be used by a particular connection. > > Forgetting about MIP for a minute, this is obvious when > > a host is trying to initiate communication with another host. > > Src address selection can be augmented with various policies > > (user-based or otherwise) to allow the host to pick the > > right src address. However, this is a bit more complex when > > a host is not the initiator of communication. This leads > > to sub-problem (1) > > (1) Informing the initiator of communication of the right > > dst address for the host on the other end. > > > > This information can be communicated implicitly or explicitly. > > One possible example for implicitly informing the other end > > is through using different domain names (e.g. audio.example.com > > returns a different address from video.example.com). On the > > other hand, explicit notification of the address can be done > > by using a protocol to negotiate a connection setup (e.g. SIP > > does this today). > > > > Not withstanding the example solutions above, sub-problem > > (1) is independent of any mobility and applies to any > > multi-addressed host. > > > > Once a connection is established, the right addresses are > > chosen by both ends, end of story. > > > > Now, the other aspect of the problem is this: Once a connection > > is established, using a particular src and destination address > > pair, how can either host modify this information? In other > > words, if WLAN coverage suddenly appeared to my laptop, how > > do I inform the host on the other end to move one of our > > connections to WLAN, while leaving the other on the cellular > > interface? In a few words, I want to change the dst address for > > a particular connection without breaking that connection. > > This requires a protocol to signal that to the other end. > > To me, this problem seems to fall into the IP mobility category > > of problems, although it is addressing a finer granularity > > of mobility. > > Note that SIP also has signalling support for session transfer, > > but: A) it was not intended for this purpose and B) it is > > not widely implemented and C) it is slower than an "optimised" MIP > > (BTW neither A nor B discredits using SIP for this purpose). > > > > So sub-problem (2): > > (2) How to move a flow from one address to another. > > > > MIP efficiently solves this problem for a host, but it > > does not provide further granularity (i.e. connection > > or flow). > > > > Personally, I think sub-problem (2) is a mobility > > problem, by the definition of IP mobility. I believe > > that MIP solves two problems: maintaining current connections > > while moving, and reachability. > > "Moving" in the context of IP mobility effectively means > > changing IP address, independently of whether that change > > affects all flows or only one or two. > > > > My 2 cents! > > > > Hesham > > > > > > > > > > -- > > Mip4 mailing list > > Mip4@ietf.org > > https://www.ietf.org/mailman/listinfo/mip4 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 11:41:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19454 for ; Mon, 17 Nov 2003 11:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmR0-0000EU-Sf for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 11:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHGf6pZ000888 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 11:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmQz-0000Dw-8s for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 11:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19412 for ; Mon, 17 Nov 2003 11:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmQy-0001Au-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 11:41:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALmQx-0001Ar-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 11:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmQw-0000D9-Ln; Mon, 17 Nov 2003 11:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmQf-0000CL-25 for mip4@optimus.ietf.org; Mon, 17 Nov 2003 11:40:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19394; Mon, 17 Nov 2003 11:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmQd-0001AO-00; Mon, 17 Nov 2003 11:40:43 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ALmQc-0001AD-00; Mon, 17 Nov 2003 11:40:42 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAHGe1EY009814; Mon, 17 Nov 2003 17:40:01 +0100 Date: Mon, 17 Nov 2003 17:40:00 +0100 From: Henrik Levkowetz To: Soliman Hesham Cc: mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031117174000.5be9a786.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__17_Nov_2003_17_40_00_+0100_tpTvyQ+VaibCFusR" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Mon__17_Nov_2003_17_40_00_+0100_tpTvyQ+VaibCFusR Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Monday, 17 Nov 2003, Hesham wrote: > It's certainly _a_ solution. And definitely a simple one. > But I would view this as being very expensive for MIPv6. Assuming > 2 HoAs, in the worst case scenario the MN could end up sending two > BUs to the HA and two to each CN that knows about both > HoAs. I think this is too expensive, especially if MIP > is being used to manage mobility proper. > For MIPv4 it's not as expensive, but sending two different > RREQs upon movement can still be expensive from the > edge of a cell, given the sizes of those messages. Mmm, I think mostly it'd be just one BU per CN, but I could be wrong. I also tried to think a little bit about the size of the filter update packets, and I think the chances are they'd be larger than a RRQ - and you might not be able to avoid the RRQ's anyway! I think that before we go for a more complex solution instead of the simpler, we need to do the maths and see that the more complex, less general one really gives a noticeable upside in reasonable scenarios? Henrik > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Monday, November 17, 2003 7:59 AM > > To: Soliman Hesham > > Cc: mip4@ietf.org; mip6@ietf.org > > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] > > Minutes of > > Multiple Lin k Flows BAR BOF > > > > > > Hi Hesham, > > > > That's a pretty good summary. My own thinking on this, > > after a bit > > of discussion in Minneapolis, is that the MIP solution which is the > > least MIP-specific would be to have separate individual MIP > > sessions for > > each flow (or group of flows) we wanted to move > > independently of other > > flows. This takes care of the ability to treat flows > > individually, and > > it does so by providing separate Home IP-addresses for those flows to > > pass through. > > > > I also note that the flow groups, and their IP-addresses, needs to be > > established before individual user applications start up and > > bind to the > > individual HoAs - we have no way to signal most application > > to re-bind > > to a new IP-address. > > > > The cost of this solution is in having to do re-registration > > of multiple > > sessions when you move, but such a cost is already implicit > > in the fact > > that with multiple connections through different connection media you > > have to be able to handle each media individually, whether it is by > > separate sessions or by filter adaptations. But I believe completely > > separate sessions will adapt better to any other > > non-movement-specific > > solution to multihoming that may appear. > > > > Henrik > > > > Monday 17 November 2003, Hesham wrote: > > > Hi, > > > > > > Just wanted to drop a note on adding flow movement > > > capabilities to MIP. > > > > > > I completely agree that adding new functions to > > > MIP just because "it's there" does not make any sense, > > > and that where a problem applies to both fixed and mobile > > > hosts we should avoid fixing it in a mobility protocol. > > > However, when it comes to flow movement, it is not immediately > > > obvious to me that it is outside the scope of MIP. > > > I'll try to break the problem down in an attempt to realise > > > where each component belongs. > > > > > > The basic problem is that a node needs to decide what > > > src address should be used by a particular connection. > > > Forgetting about MIP for a minute, this is obvious when > > > a host is trying to initiate communication with another host. > > > Src address selection can be augmented with various policies > > > (user-based or otherwise) to allow the host to pick the > > > right src address. However, this is a bit more complex when > > > a host is not the initiator of communication. This leads > > > to sub-problem (1) > > > (1) Informing the initiator of communication of the right > > > dst address for the host on the other end. > > > > > > This information can be communicated implicitly or explicitly. > > > One possible example for implicitly informing the other end > > > is through using different domain names (e.g. audio.example.com > > > returns a different address from video.example.com). On the > > > other hand, explicit notification of the address can be done > > > by using a protocol to negotiate a connection setup (e.g. SIP > > > does this today). > > > > > > Not withstanding the example solutions above, sub-problem > > > (1) is independent of any mobility and applies to any > > > multi-addressed host. > > > > > > Once a connection is established, the right addresses are > > > chosen by both ends, end of story. > > > > > > Now, the other aspect of the problem is this: Once a connection > > > is established, using a particular src and destination address > > > pair, how can either host modify this information? In other > > > words, if WLAN coverage suddenly appeared to my laptop, how > > > do I inform the host on the other end to move one of our > > > connections to WLAN, while leaving the other on the cellular > > > interface? In a few words, I want to change the dst address for > > > a particular connection without breaking that connection. > > > This requires a protocol to signal that to the other end. > > > To me, this problem seems to fall into the IP mobility category > > > of problems, although it is addressing a finer granularity > > > of mobility. > > > Note that SIP also has signalling support for session transfer, > > > but: A) it was not intended for this purpose and B) it is > > > not widely implemented and C) it is slower than an "optimised" MIP > > > (BTW neither A nor B discredits using SIP for this purpose). > > > > > > So sub-problem (2): > > > (2) How to move a flow from one address to another. > > > > > > MIP efficiently solves this problem for a host, but it > > > does not provide further granularity (i.e. connection > > > or flow). > > > > > > Personally, I think sub-problem (2) is a mobility > > > problem, by the definition of IP mobility. I believe > > > that MIP solves two problems: maintaining current connections > > > while moving, and reachability. > > > "Moving" in the context of IP mobility effectively means > > > changing IP address, independently of whether that change > > > affects all flows or only one or two. > > > > > > My 2 cents! > > > > > > Hesham > > > > > > > > > > > > > > > -- > > > Mip4 mailing list > > > Mip4@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip4 > > Henrik -- Don't store garlic near other victuals. --Signature=_Mon__17_Nov_2003_17_40_00_+0100_tpTvyQ+VaibCFusR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/uPngeVhrtTJkXCMRAr8nAKCxWZF1sfCBaxioSbXFIeDIMA1O7QCg2XxT dAnnlrDQDTOlLo7ufHXFESU= =eINn -----END PGP SIGNATURE----- --Signature=_Mon__17_Nov_2003_17_40_00_+0100_tpTvyQ+VaibCFusR-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 11:47:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20146 for ; Mon, 17 Nov 2003 11:47:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmWl-0000SU-Qh for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 11:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHGl3wp001756 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 11:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmWk-0000RM-9T for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 11:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20082 for ; Mon, 17 Nov 2003 11:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmWj-0001Q3-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 11:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALmWi-0001Q0-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 11:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmWi-0000Qe-SE; Mon, 17 Nov 2003 11:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmW8-0000PV-4v for mip4@optimus.ietf.org; Mon, 17 Nov 2003 11:46:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19968; Mon, 17 Nov 2003 11:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmW6-0001Mw-00; Mon, 17 Nov 2003 11:46:22 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ALmW6-0001Jn-00; Mon, 17 Nov 2003 11:46:22 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAHGi1R04562; Mon, 17 Nov 2003 10:44:17 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAHGhwp05593; Mon, 17 Nov 2003 10:43:58 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOI958-0000MW-00; Mon, 17 Nov 2003 11:43:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16312.64202.769515.896944@gargle.gargle.HOWL> Date: Mon, 17 Nov 2003 10:43:54 -0600 From: Pete McCann To: Soliman Hesham Cc: "'Henrik Levkowetz'" , mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Hesham, So maybe what we need is an efficient way to handle multi-homed hosts (hosts with multiple home addresses) in MIP6. This could be something like aggregation of BUs or other sorts of tricks. In MIP4, there may be less of an impact from multiple home addresses due to the absence of route optimization. However, IPv4 addresses are more precious than IPv6 addresses. That last fact seems to me to be the only reason why we would think about putting filters into a registration request. It seems much simpler for the application (using SIP or whatever) to advertise a particular home address to the CN. You could still handle mobility independently for each session, using Mobile IP along with the extra level of indirection supplied by the separate IP addresses. There is no need to build mobility into the application protocol. There may be a few unsolved issues with HAs allocating multiple addresses, but I think it could be handled easily with the use of multiple NAIs. I wrote a draft called the "Mobile IP Session Identifier Extension" some years back, but you could do the same thing with some sort of NAI-mangling naming convention (H.Soliman1@flarion.com, H.Soliman2@flarion.com, etc...). -Pete Soliman Hesham writes: > Hi Henrik, > > It's certainly _a_ solution. And definitely a simple one. > But I would view this as being very expensive for MIPv6. Assuming > 2 HoAs, in the worst case scenario the MN could end up sending two > BUs to the HA and two to each CN that knows about both > HoAs. I think this is too expensive, especially if MIP > is being used to manage mobility proper. > For MIPv4 it's not as expensive, but sending two different > RREQs upon movement can still be expensive from the > edge of a cell, given the sizes of those messages. > > Hesham > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Monday, November 17, 2003 7:59 AM > > To: Soliman Hesham > > Cc: mip4@ietf.org; mip6@ietf.org > > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] > > Minutes of > > Multiple Lin k Flows BAR BOF > > > > > > Hi Hesham, > > > > That's a pretty good summary. My own thinking on this, > > after a bit > > of discussion in Minneapolis, is that the MIP solution which is the > > least MIP-specific would be to have separate individual MIP > > sessions for > > each flow (or group of flows) we wanted to move > > independently of other > > flows. This takes care of the ability to treat flows > > individually, and > > it does so by providing separate Home IP-addresses for those flows to > > pass through. > > > > I also note that the flow groups, and their IP-addresses, needs to be > > established before individual user applications start up and > > bind to the > > individual HoAs - we have no way to signal most application > > to re-bind > > to a new IP-address. > > > > The cost of this solution is in having to do re-registration > > of multiple > > sessions when you move, but such a cost is already implicit > > in the fact > > that with multiple connections through different connection media you > > have to be able to handle each media individually, whether it is by > > separate sessions or by filter adaptations. But I believe completely > > separate sessions will adapt better to any other > > non-movement-specific > > solution to multihoming that may appear. > > > > Henrik > > > > Monday 17 November 2003, Hesham wrote: > > > Hi, > > > > > > Just wanted to drop a note on adding flow movement > > > capabilities to MIP. > > > > > > I completely agree that adding new functions to > > > MIP just because "it's there" does not make any sense, > > > and that where a problem applies to both fixed and mobile > > > hosts we should avoid fixing it in a mobility protocol. > > > However, when it comes to flow movement, it is not immediately > > > obvious to me that it is outside the scope of MIP. > > > I'll try to break the problem down in an attempt to realise > > > where each component belongs. > > > > > > The basic problem is that a node needs to decide what > > > src address should be used by a particular connection. > > > Forgetting about MIP for a minute, this is obvious when > > > a host is trying to initiate communication with another host. > > > Src address selection can be augmented with various policies > > > (user-based or otherwise) to allow the host to pick the > > > right src address. However, this is a bit more complex when > > > a host is not the initiator of communication. This leads > > > to sub-problem (1) > > > (1) Informing the initiator of communication of the right > > > dst address for the host on the other end. > > > > > > This information can be communicated implicitly or explicitly. > > > One possible example for implicitly informing the other end > > > is through using different domain names (e.g. audio.example.com > > > returns a different address from video.example.com). On the > > > other hand, explicit notification of the address can be done > > > by using a protocol to negotiate a connection setup (e.g. SIP > > > does this today). > > > > > > Not withstanding the example solutions above, sub-problem > > > (1) is independent of any mobility and applies to any > > > multi-addressed host. > > > > > > Once a connection is established, the right addresses are > > > chosen by both ends, end of story. > > > > > > Now, the other aspect of the problem is this: Once a connection > > > is established, using a particular src and destination address > > > pair, how can either host modify this information? In other > > > words, if WLAN coverage suddenly appeared to my laptop, how > > > do I inform the host on the other end to move one of our > > > connections to WLAN, while leaving the other on the cellular > > > interface? In a few words, I want to change the dst address for > > > a particular connection without breaking that connection. > > > This requires a protocol to signal that to the other end. > > > To me, this problem seems to fall into the IP mobility category > > > of problems, although it is addressing a finer granularity > > > of mobility. > > > Note that SIP also has signalling support for session transfer, > > > but: A) it was not intended for this purpose and B) it is > > > not widely implemented and C) it is slower than an "optimised" MIP > > > (BTW neither A nor B discredits using SIP for this purpose). > > > > > > So sub-problem (2): > > > (2) How to move a flow from one address to another. > > > > > > MIP efficiently solves this problem for a host, but it > > > does not provide further granularity (i.e. connection > > > or flow). > > > > > > Personally, I think sub-problem (2) is a mobility > > > problem, by the definition of IP mobility. I believe > > > that MIP solves two problems: maintaining current connections > > > while moving, and reachability. > > > "Moving" in the context of IP mobility effectively means > > > changing IP address, independently of whether that change > > > affects all flows or only one or two. > > > > > > My 2 cents! > > > > > > Hesham -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 17:50:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11030 for ; Mon, 17 Nov 2003 17:50:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsC8-0004qk-Tz for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 17:50:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHMo8pU018638 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 17:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsC8-0004qO-Oc for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10998 for ; Mon, 17 Nov 2003 17:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsC6-0000gB-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 17:50:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsC5-0000g8-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 17:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsC3-0004pP-EN; Mon, 17 Nov 2003 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsBL-0004cs-3A for mip4@optimus.ietf.org; Mon, 17 Nov 2003 17:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10963; Mon, 17 Nov 2003 17:49:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsBI-0000fG-00; Mon, 17 Nov 2003 17:49:16 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ALsBH-0000f2-00; Mon, 17 Nov 2003 17:49:15 -0500 Message-ID: <045601c3ad5d$10c11940$956015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , , References: <9E3BA3946476AD4EB94672712B12A85F041FFA@ftmail.lab.flarion.com> Date: Mon, 17 Nov 2003 14:49:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Mip6] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, This is a little bit different perspective than the one I've been coming at this from. If I understand you correctly, you seem to be assuming that the correspondent node has knowledge of the additional care of addresses available to the mobile node, correct? Unless the flow is opened directly with the care of address (i.e. the correspondent or mobile node does not go through the home address to start the flow which is somewhat outside the basic Mobile IP scenario) then the only way I can see the correspondent learning about the additional addresses is through MIPv6 route optimization, i.e. the mobile node tells the correspondent to move a particular flow to a different care of address using a binding update that is somehow enhanced to indicate which flow should be handed off (perhaps a use for the new flow label work in the IPv6 WG?) instead of handing off all flows. This is certainly much cleaner than treating the home agent as a middlebox and trying to accomplish the flow handoff there. However, for MIPv4, this won't work because there is no route optimization. Flow handoff will have to occur at the home agent. And, any indication of which flow to handoff will probably require looking into the transport header to determine the port number, the kind of thing typically done by firewalls and NATs in IPv4. This is decidedly less appealing, because it involves middlebox functionality on the home agent. If that's the case, then the issue is what should the signaling look like between the mobile node and home-agent-as-middlebox to accomplish the flow handoff? jak ----- Original Message ----- From: "Soliman Hesham" To: ; Sent: Monday, November 17, 2003 2:20 AM Subject: [Mip6] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF > Hi, > > Just wanted to drop a note on adding flow movement > capabilities to MIP. > > I completely agree that adding new functions to > MIP just because "it's there" does not make any sense, > and that where a problem applies to both fixed and mobile > hosts we should avoid fixing it in a mobility protocol. > However, when it comes to flow movement, it is not immediately > obvious to me that it is outside the scope of MIP. > I'll try to break the problem down in an attempt to realise > where each component belongs. > > The basic problem is that a node needs to decide what > src address should be used by a particular connection. > Forgetting about MIP for a minute, this is obvious when > a host is trying to initiate communication with another host. > Src address selection can be augmented with various policies > (user-based or otherwise) to allow the host to pick the > right src address. However, this is a bit more complex when > a host is not the initiator of communication. This leads > to sub-problem (1) > (1) Informing the initiator of communication of the right > dst address for the host on the other end. > > This information can be communicated implicitly or explicitly. > One possible example for implicitly informing the other end > is through using different domain names (e.g. audio.example.com > returns a different address from video.example.com). On the > other hand, explicit notification of the address can be done > by using a protocol to negotiate a connection setup (e.g. SIP > does this today). > > Not withstanding the example solutions above, sub-problem > (1) is independent of any mobility and applies to any > multi-addressed host. > > Once a connection is established, the right addresses are > chosen by both ends, end of story. > > Now, the other aspect of the problem is this: Once a connection > is established, using a particular src and destination address > pair, how can either host modify this information? In other > words, if WLAN coverage suddenly appeared to my laptop, how > do I inform the host on the other end to move one of our > connections to WLAN, while leaving the other on the cellular > interface? In a few words, I want to change the dst address for > a particular connection without breaking that connection. > This requires a protocol to signal that to the other end. > To me, this problem seems to fall into the IP mobility category > of problems, although it is addressing a finer granularity > of mobility. > Note that SIP also has signalling support for session transfer, > but: A) it was not intended for this purpose and B) it is > not widely implemented and C) it is slower than an "optimised" MIP > (BTW neither A nor B discredits using SIP for this purpose). > > So sub-problem (2): > (2) How to move a flow from one address to another. > > MIP efficiently solves this problem for a host, but it > does not provide further granularity (i.e. connection > or flow). > > Personally, I think sub-problem (2) is a mobility > problem, by the definition of IP mobility. I believe > that MIP solves two problems: maintaining current connections > while moving, and reachability. > "Moving" in the context of IP mobility effectively means > changing IP address, independently of whether that change > affects all flows or only one or two. > > My 2 cents! > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 17:58:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11399 for ; Mon, 17 Nov 2003 17:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsJn-0005Mq-DK for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 17:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHMw33F020626 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 17:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsJn-0005Mb-8d for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11353 for ; Mon, 17 Nov 2003 17:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsJj-0000mZ-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 17:57:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsJi-0000mW-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 17:57:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsJk-0005L5-Pg; Mon, 17 Nov 2003 17:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsIr-0005K2-Pu for mip4@optimus.ietf.org; Mon, 17 Nov 2003 17:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11332; Mon, 17 Nov 2003 17:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsIo-0000ly-00; Mon, 17 Nov 2003 17:57:02 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ALsIo-0000lv-00; Mon, 17 Nov 2003 17:57:02 -0500 Message-ID: <047301c3ad5e$285fe490$956015ac@dclkempt40> From: "James Kempf" To: "Pete McCann" , "Soliman Hesham" Cc: "'Henrik Levkowetz'" , , References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Mon, 17 Nov 2003 14:57:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, > In MIP4, there may be less of an impact from multiple home addresses > due to the absence of route optimization. However, IPv4 addresses are > more precious than IPv6 addresses. That last fact seems to me to be > the only reason why we would think about putting filters into a > registration request. It seems much simpler for the application > (using SIP or whatever) to advertise a particular home address to the > CN. You could still handle mobility independently for each session, > using Mobile IP along with the extra level of indirection supplied by > the separate IP addresses. There is no need to build mobility into > the application protocol. > Agree with IPv4 addresses being scare as the main issue for doing flow handoff at the home agent in MIPv4, but not sure about whether the RREQ is the right place for filters. Seems like it is a generic middlebox problem and should be approached using the same tools as for other middleboxes. > There may be a few unsolved issues with HAs allocating multiple > addresses, but I think it could be handled easily with the use of > multiple NAIs. I wrote a draft called the "Mobile IP Session > Identifier Extension" some years back, but you could do the same thing > with some sort of NAI-mangling naming convention Why would multiple NAIs be necessary if all the CoA to HoA mappings were handled by one HA, as would be the case if the same service provider was providing service on all CoAs? I agree that they would be necessary if the the CoAs were provided by multiple service providers, but the flow handover issue is just the tip of the iceberg in that case, IMHO. jak -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 19:03:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14748 for ; Mon, 17 Nov 2003 19:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtKh-0000kg-15 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 19:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI033cP002889 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 19:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtKg-0000kW-Sx for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 19:03:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14737 for ; Mon, 17 Nov 2003 19:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALtKd-0001uK-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 19:02:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALtKd-0001uH-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 19:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtKf-0000jC-7v; Mon, 17 Nov 2003 19:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtK6-0000hT-IQ for mip4@optimus.ietf.org; Mon, 17 Nov 2003 19:02:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14700; Mon, 17 Nov 2003 19:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALtK3-0001tc-00; Mon, 17 Nov 2003 19:02:23 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ALtK2-0001tX-00; Mon, 17 Nov 2003 19:02:22 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ALtJS-0000iP-00; Tue, 18 Nov 2003 01:01:46 +0100 Date: Tue, 18 Nov 2003 01:01:24 +0100 From: Henrik Levkowetz To: "James Kempf" Cc: "Pete McCann" , , Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031118010124.4d89dabe.henrik@levkowetz.com> In-Reply-To: <047301c3ad5e$285fe490$956015ac@dclkempt40> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> <047301c3ad5e$285fe490$956015ac@dclkempt40> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi James, Monday 17 November 2003, James wrote: > Pete, > > > In MIP4, there may be less of an impact from multiple home addresses > > due to the absence of route optimization. However, IPv4 addresses are > > more precious than IPv6 addresses. That last fact seems to me to be > > the only reason why we would think about putting filters into a > > registration request. It seems much simpler for the application > > (using SIP or whatever) to advertise a particular home address to the > > CN. You could still handle mobility independently for each session, > > using Mobile IP along with the extra level of indirection supplied by > > the separate IP addresses. There is no need to build mobility into > > the application protocol. > > > > Agree with IPv4 addresses being scare as the main issue for doing flow > handoff at the home agent in MIPv4, but not sure about whether the RREQ is > the right place for filters. Seems like it is a generic middlebox problem > and should be approached using the same tools as for other middleboxes. I'm not at all sure that the reasoning about IPv4 address scarcity holds water. MIPv4 works with both HoAs and CoAs being private, behind NATs (even if we don't like'em... :) > > There may be a few unsolved issues with HAs allocating multiple > > addresses, but I think it could be handled easily with the use of > > multiple NAIs. I wrote a draft called the "Mobile IP Session > > Identifier Extension" some years back, but you could do the same thing > > with some sort of NAI-mangling naming convention > > Why would multiple NAIs be necessary if all the CoA to HoA mappings were > handled by one HA, as would be the case if the same service provider was > providing service on all CoAs? I agree that they would be necessary if the > the CoAs were provided by multiple service providers, but the flow handover > issue is just the tip of the iceberg in that case, IMHO. I don't think we can assume neither that the same service provder is providing service on all CoAs, nor that there is only one HA. If public WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, I'd say it's actually quite unlikely. Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 23:44:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22405 for ; Mon, 17 Nov 2003 23:44:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxie-0005yC-HU for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 23:44:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI4i4FK022945 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 23:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxie-0005y0-AW for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 23:44:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22389 for ; Mon, 17 Nov 2003 23:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALxic-0005V3-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 23:44:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALxib-0005V0-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 23:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxib-0005x5-Kq; Mon, 17 Nov 2003 23:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxiX-0005wV-LX for mip4@optimus.ietf.org; Mon, 17 Nov 2003 23:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22376; Mon, 17 Nov 2003 23:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALxiV-0005Ue-00; Mon, 17 Nov 2003 23:43:55 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ALxiU-0005UT-00; Mon, 17 Nov 2003 23:43:54 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 23:43:22 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F041FFE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Henrik Levkowetz'" Cc: mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Mon, 17 Nov 2003 23:43:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > Mmm, I think mostly it'd be just one BU per CN, but I could > be wrong. I > also tried to think a little bit about the size of the filter update > packets, and I think the chances are they'd be larger than a > RRQ - and => I guess that depends on the solution. > you might not be able to avoid the RRQ's anyway! I think > that before we > go for a more complex solution instead of the simpler, we > need to do the > maths and see that the more complex, less general one really gives a > noticeable upside in reasonable scenarios? => Sure, I'm not sure what "less general" means though. Hesham > > Henrik > > > > > > > -----Original Message----- > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > Sent: Monday, November 17, 2003 7:59 AM > > > To: Soliman Hesham > > > Cc: mip4@ietf.org; mip6@ietf.org > > > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] > > > Minutes of > > > Multiple Lin k Flows BAR BOF > > > > > > > > > Hi Hesham, > > > > > > That's a pretty good summary. My own thinking on this, > > > after a bit > > > of discussion in Minneapolis, is that the MIP solution > which is the > > > least MIP-specific would be to have separate individual MIP > > > sessions for > > > each flow (or group of flows) we wanted to move > > > independently of other > > > flows. This takes care of the ability to treat flows > > > individually, and > > > it does so by providing separate Home IP-addresses for > those flows to > > > pass through. > > > > > > I also note that the flow groups, and their > IP-addresses, needs to be > > > established before individual user applications start up and > > > bind to the > > > individual HoAs - we have no way to signal most application > > > to re-bind > > > to a new IP-address. > > > > > > The cost of this solution is in having to do re-registration > > > of multiple > > > sessions when you move, but such a cost is already implicit > > > in the fact > > > that with multiple connections through different > connection media you > > > have to be able to handle each media individually, > whether it is by > > > separate sessions or by filter adaptations. But I > believe completely > > > separate sessions will adapt better to any other > > > non-movement-specific > > > solution to multihoming that may appear. > > > > > > Henrik > > > > > > Monday 17 November 2003, Hesham wrote: > > > > Hi, > > > > > > > > Just wanted to drop a note on adding flow movement > > > > capabilities to MIP. > > > > > > > > I completely agree that adding new functions to > > > > MIP just because "it's there" does not make any sense, > > > > and that where a problem applies to both fixed and mobile > > > > hosts we should avoid fixing it in a mobility protocol. > > > > However, when it comes to flow movement, it is not immediately > > > > obvious to me that it is outside the scope of MIP. > > > > I'll try to break the problem down in an attempt to realise > > > > where each component belongs. > > > > > > > > The basic problem is that a node needs to decide what > > > > src address should be used by a particular connection. > > > > Forgetting about MIP for a minute, this is obvious when > > > > a host is trying to initiate communication with another host. > > > > Src address selection can be augmented with various policies > > > > (user-based or otherwise) to allow the host to pick the > > > > right src address. However, this is a bit more complex when > > > > a host is not the initiator of communication. This leads > > > > to sub-problem (1) > > > > (1) Informing the initiator of communication of the right > > > > dst address for the host on the other end. > > > > > > > > This information can be communicated implicitly or > explicitly. > > > > One possible example for implicitly informing the other end > > > > is through using different domain names (e.g. > audio.example.com > > > > returns a different address from video.example.com). On the > > > > other hand, explicit notification of the address can be done > > > > by using a protocol to negotiate a connection setup (e.g. SIP > > > > does this today). > > > > > > > > Not withstanding the example solutions above, sub-problem > > > > (1) is independent of any mobility and applies to any > > > > multi-addressed host. > > > > > > > > Once a connection is established, the right addresses are > > > > chosen by both ends, end of story. > > > > > > > > Now, the other aspect of the problem is this: Once a > connection > > > > is established, using a particular src and destination address > > > > pair, how can either host modify this information? In other > > > > words, if WLAN coverage suddenly appeared to my laptop, how > > > > do I inform the host on the other end to move one of our > > > > connections to WLAN, while leaving the other on the cellular > > > > interface? In a few words, I want to change the dst > address for > > > > a particular connection without breaking that connection. > > > > This requires a protocol to signal that to the other end. > > > > To me, this problem seems to fall into the IP > mobility category > > > > of problems, although it is addressing a finer granularity > > > > of mobility. > > > > Note that SIP also has signalling support for session > transfer, > > > > but: A) it was not intended for this purpose and B) it is > > > > not widely implemented and C) it is slower than an > "optimised" MIP > > > > (BTW neither A nor B discredits using SIP for this purpose). > > > > > > > > So sub-problem (2): > > > > (2) How to move a flow from one address to another. > > > > > > > > MIP efficiently solves this problem for a host, but it > > > > does not provide further granularity (i.e. connection > > > > or flow). > > > > > > > > Personally, I think sub-problem (2) is a mobility > > > > problem, by the definition of IP mobility. I believe > > > > that MIP solves two problems: maintaining current connections > > > > while moving, and reachability. > > > > "Moving" in the context of IP mobility effectively means > > > > changing IP address, independently of whether that change > > > > affects all flows or only one or two. > > > > > > > > My 2 cents! > > > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > -- > > > > Mip4 mailing list > > > > Mip4@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > > > Henrik > > -- > Don't store garlic near other victuals. > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 17 23:55:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22782 for ; Mon, 17 Nov 2003 23:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxtI-0006Xo-D4 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 23:55:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI4t4uo025144 for mip4-archive@odin.ietf.org; Mon, 17 Nov 2003 23:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxtI-0006XS-3e for mip4-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 23:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22767 for ; Mon, 17 Nov 2003 23:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALxtF-0005gg-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 23:55:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALxtF-0005gd-00 for mip4-web-archive@ietf.org; Mon, 17 Nov 2003 23:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxtG-0006WR-FW; Mon, 17 Nov 2003 23:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALxsJ-0006RO-Ez for mip4@optimus.ietf.org; Mon, 17 Nov 2003 23:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22733; Mon, 17 Nov 2003 23:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALxsH-0005fX-00; Mon, 17 Nov 2003 23:54:01 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ALxsG-0005fB-00; Mon, 17 Nov 2003 23:54:00 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 23:53:32 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F041FFF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pete McCann'" Cc: "'Henrik Levkowetz'" , mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Mon, 17 Nov 2003 23:53:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Pete, > So maybe what we need is an efficient way to handle multi-homed hosts > (hosts with multiple home addresses) in MIP6. This could be > something > like aggregation of BUs or other sorts of tricks. => That used to be in the draft for the HA BUs but was removed because it was difficult to achieve from a security point of view. I'm not sure that this is cleaner than just adding the flow movement extensions. Also another use of those extensions (that I didn't want to bring up yet) is for optimising the handover smoothing for different flows (buffer to eliminate packet loss Vs forward to eliminate delays). > In MIP4, there may be less of an impact from multiple home addresses > due to the absence of route optimization. However, IPv4 > addresses are > more precious than IPv6 addresses. That last fact seems to me to be > the only reason why we would think about putting filters into a > registration request. => In MIPv4 I agree. It seems much simpler for the application > (using SIP or whatever) to advertise a particular home address to the > CN. You could still handle mobility independently for each session, > using Mobile IP along with the extra level of indirection supplied by > the separate IP addresses. There is no need to build mobility into > the application protocol. => There is definitely no need to build mobility into the application protocol, I didn't suggest that. Having SIP advertise an address does not fix the problem when you want to move that connection from one interface to another as I explained in a previous email. The only way to do that today is to terminate the connection and restart it. I don't imagine that we'd want to do that. > > There may be a few unsolved issues with HAs allocating multiple > addresses, but I think it could be handled easily with the use of > multiple NAIs. I wrote a draft called the "Mobile IP Session > Identifier Extension" some years back, but you could do the > same thing > with some sort of NAI-mangling naming convention > (H.Soliman1@flarion.com, H.Soliman2@flarion.com, etc...). => I remember that, it was presented in Adelaide I think. I thought it was worth pursuing back then. Anyway, now we're discussing solution space, I just wanted to highlight the problem. At the moment it's probably a bit premature to decide that one solution is _the_ one (hence I'm being the devil's advocate either way you go :) ). If this topic is important to the WGs perhaps we should do a proper investigation. Hesham > > -Pete > > Soliman Hesham writes: > > Hi Henrik, > > > > It's certainly _a_ solution. And definitely a simple one. > > But I would view this as being very expensive for MIPv6. Assuming > > 2 HoAs, in the worst case scenario the MN could end up sending two > > BUs to the HA and two to each CN that knows about both > > HoAs. I think this is too expensive, especially if MIP > > is being used to manage mobility proper. > > For MIPv4 it's not as expensive, but sending two different > > RREQs upon movement can still be expensive from the > > edge of a cell, given the sizes of those messages. > > > > Hesham > > > > > -----Original Message----- > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > Sent: Monday, November 17, 2003 7:59 AM > > > To: Soliman Hesham > > > Cc: mip4@ietf.org; mip6@ietf.org > > > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] > > > Minutes of > > > Multiple Lin k Flows BAR BOF > > > > > > > > > Hi Hesham, > > > > > > That's a pretty good summary. My own thinking on this, > > > after a bit > > > of discussion in Minneapolis, is that the MIP solution > which is the > > > least MIP-specific would be to have separate individual MIP > > > sessions for > > > each flow (or group of flows) we wanted to move > > > independently of other > > > flows. This takes care of the ability to treat flows > > > individually, and > > > it does so by providing separate Home IP-addresses for > those flows to > > > pass through. > > > > > > I also note that the flow groups, and their > IP-addresses, needs to be > > > established before individual user applications start up and > > > bind to the > > > individual HoAs - we have no way to signal most application > > > to re-bind > > > to a new IP-address. > > > > > > The cost of this solution is in having to do re-registration > > > of multiple > > > sessions when you move, but such a cost is already implicit > > > in the fact > > > that with multiple connections through different > connection media you > > > have to be able to handle each media individually, > whether it is by > > > separate sessions or by filter adaptations. But I > believe completely > > > separate sessions will adapt better to any other > > > non-movement-specific > > > solution to multihoming that may appear. > > > > > > Henrik > > > > > > Monday 17 November 2003, Hesham wrote: > > > > Hi, > > > > > > > > Just wanted to drop a note on adding flow movement > > > > capabilities to MIP. > > > > > > > > I completely agree that adding new functions to > > > > MIP just because "it's there" does not make any sense, > > > > and that where a problem applies to both fixed and mobile > > > > hosts we should avoid fixing it in a mobility protocol. > > > > However, when it comes to flow movement, it is not > immediately > > > > obvious to me that it is outside the scope of MIP. > > > > I'll try to break the problem down in an attempt to realise > > > > where each component belongs. > > > > > > > > The basic problem is that a node needs to decide what > > > > src address should be used by a particular connection. > > > > Forgetting about MIP for a minute, this is obvious when > > > > a host is trying to initiate communication with another host. > > > > Src address selection can be augmented with various policies > > > > (user-based or otherwise) to allow the host to pick the > > > > right src address. However, this is a bit more complex when > > > > a host is not the initiator of communication. This leads > > > > to sub-problem (1) > > > > (1) Informing the initiator of communication of the right > > > > dst address for the host on the other end. > > > > > > > > This information can be communicated implicitly or > explicitly. > > > > One possible example for implicitly informing the other end > > > > is through using different domain names (e.g. > audio.example.com > > > > returns a different address from video.example.com). On the > > > > other hand, explicit notification of the address can be done > > > > by using a protocol to negotiate a connection setup (e.g. SIP > > > > does this today). > > > > > > > > Not withstanding the example solutions above, sub-problem > > > > (1) is independent of any mobility and applies to any > > > > multi-addressed host. > > > > > > > > Once a connection is established, the right addresses are > > > > chosen by both ends, end of story. > > > > > > > > Now, the other aspect of the problem is this: Once a > connection > > > > is established, using a particular src and > destination address > > > > pair, how can either host modify this information? In other > > > > words, if WLAN coverage suddenly appeared to my laptop, how > > > > do I inform the host on the other end to move one of our > > > > connections to WLAN, while leaving the other on the cellular > > > > interface? In a few words, I want to change the dst > address for > > > > a particular connection without breaking that connection. > > > > This requires a protocol to signal that to the other end. > > > > To me, this problem seems to fall into the IP > mobility category > > > > of problems, although it is addressing a finer granularity > > > > of mobility. > > > > Note that SIP also has signalling support for > session transfer, > > > > but: A) it was not intended for this purpose and B) it is > > > > not widely implemented and C) it is slower than an > "optimised" MIP > > > > (BTW neither A nor B discredits using SIP for this purpose). > > > > > > > > So sub-problem (2): > > > > (2) How to move a flow from one address to another. > > > > > > > > MIP efficiently solves this problem for a host, but it > > > > does not provide further granularity (i.e. connection > > > > or flow). > > > > > > > > Personally, I think sub-problem (2) is a mobility > > > > problem, by the definition of IP mobility. I believe > > > > that MIP solves two problems: maintaining current connections > > > > while moving, and reachability. > > > > "Moving" in the context of IP mobility effectively means > > > > changing IP address, independently of whether that change > > > > affects all flows or only one or two. > > > > > > > > My 2 cents! > > > > > > > > Hesham > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 01:02:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24052 for ; Tue, 18 Nov 2003 01:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALyw7-0000Zh-8f for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 01:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI623Vc002208 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 01:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALyw7-0000ZX-2n for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 01:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24022 for ; Tue, 18 Nov 2003 01:01:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALyw4-0006O1-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 01:02:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALyw3-0006Nx-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 01:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALyw5-0000YS-SQ; Tue, 18 Nov 2003 01:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALyvy-0000XC-Fm for mip4@optimus.ietf.org; Tue, 18 Nov 2003 01:01:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24019; Tue, 18 Nov 2003 01:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALyvv-0006Nu-00; Tue, 18 Nov 2003 01:01:51 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ALyvu-0006Ne-00; Tue, 18 Nov 2003 01:01:50 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7F9455D095; Tue, 18 Nov 2003 15:01:20 +0900 (JST) Date: Tue, 18 Nov 2003 14:55:49 +0900 From: Thierry Ernst To: Henrik Levkowetz Cc: kempf@docomolabs-usa.com, mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031118145549.0455aa30.ernst@sfc.wide.ad.jp> In-Reply-To: <20031118010124.4d89dabe.henrik@levkowetz.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> <047301c3ad5e$285fe490$956015ac@dclkempt40> <20031118010124.4d89dabe.henrik@levkowetz.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > > Why would multiple NAIs be necessary if all the CoA to HoA mappings were > > handled by one HA, as would be the case if the same service provider was > > providing service on all CoAs? I agree that they would be necessary if the > > the CoAs were provided by multiple service providers, but the flow handover > > issue is just the tip of the iceberg in that case, IMHO. > > I don't think we can assume neither that the same service provder is > providing service on all CoAs, nor that there is only one HA. If public > WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, > I'd say it's actually quite unlikely. I agree with that, the benefit of multihoming would be moot if we assume a single HA or single ISP (= single point of failures). Such assumptions does not hold in face of the multihoming scenarios, as identified in draft-montavont-mobileip-multihoming-pb-statement. Thierry. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 01:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24296 for ; Tue, 18 Nov 2003 01:14:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALz7k-0001Ga-3t for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 01:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI6E4Zc004862 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 01:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALz7j-0001GL-Vs for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 01:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24267 for ; Tue, 18 Nov 2003 01:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALz7f-0006Tg-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 01:13:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALz7f-0006Tc-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 01:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALz7g-0001F1-T7; Tue, 18 Nov 2003 01:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALz6r-0001EB-6H for mip4@optimus.ietf.org; Tue, 18 Nov 2003 01:13:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24253; Tue, 18 Nov 2003 01:12:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALz6o-0006TP-00; Tue, 18 Nov 2003 01:13:06 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ALz6n-0006TM-00; Tue, 18 Nov 2003 01:13:05 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Nov 2003 01:12:33 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042004@ftmail.lab.flarion.com> From: Soliman Hesham To: "'James Kempf'" , mip4@ietf.org, mip6@ietf.org Date: Tue, 18 Nov 2003 01:12:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Mip4] RE: [Mip6] tying flow movement to MIP RE: [Mipshop] Minutes of M ultiple Lin k Flows BAR BOF Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi James, > This is a little bit different perspective than the one I've > been coming at > this from. If I understand you correctly, you seem to be > assuming that the > correspondent node has knowledge of the additional care of addresses > available to the mobile node, correct? => Not initially. The CN (in MIPv6) can only know that if RO was already done. > i.e. the mobile node tells the correspondent to move a > particular flow to a > different care of address using a binding update that is > somehow enhanced to > indicate which flow should be handed off (perhaps a use for > the new flow > label work in the IPv6 WG?) => That's _a_ solution for sub-problem (2). This is basically how we tried to solve this part in our draft. The flow label is one way, you could also use the port numbers and IP addresses. instead of handing off all flows. This is > certainly much cleaner than treating the home agent as a > middlebox and > trying to accomplish the flow handoff there. => Yes but if you want to aggregate this BU by sending one to the HA/MAP and getting the flows split there, things would certainly be more efficient in terms of signalling overhead. It would also be quicker. > However, for MIPv4, this won't work because there is no > route optimization. > Flow handoff will have to occur at the home agent. And, any > indication of > which flow to handoff will probably require looking into the > transport > header to determine the port number, the kind of thing > typically done by > firewalls and NATs in IPv4. => And routers ;) they do for traffic engineering. This is decidedly less > appealing, because it > involves middlebox functionality on the home agent. => Actually, it's already there today. If > that's the case, then > the issue is what should the signaling look like between the > mobile node and > home-agent-as-middlebox to accomplish the flow handoff? => Yes that's one issue. As we start looking at solutions i'm sure there will be more issues. Hesham -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 08:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20675 for ; Tue, 18 Nov 2003 08:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6E2-0005jO-6H for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 08:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIDn29j022024 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 08:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6E2-0005j9-0p for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 08:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20659 for ; Tue, 18 Nov 2003 08:48:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM6E0-0005US-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 08:49:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM6E0-0005UN-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 08:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6E0-0005i0-QZ; Tue, 18 Nov 2003 08:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6DK-0005hA-Sc for mip4@optimus.ietf.org; Tue, 18 Nov 2003 08:48:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20646; Tue, 18 Nov 2003 08:48:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM6DJ-0005U0-00; Tue, 18 Nov 2003 08:48:17 -0500 Received: from out4.prserv.net ([32.97.166.34] helo=prserv.net) by ietf-mx with esmtp (Exim 4.12) id 1AM6DI-0005Ta-00; Tue, 18 Nov 2003 08:48:16 -0500 Received: from attglobal.net (slip-32-103-176-216.il.us.prserv.net[32.103.176.216]) by prserv.net (out4) with SMTP id <2003111813474320402sve1ee>; Tue, 18 Nov 2003 13:47:45 +0000 Message-ID: <3FBA2326.7090905@attglobal.net> Date: Tue, 18 Nov 2003 07:48:22 -0600 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: Henrik Levkowetz , kempf@docomolabs-usa.com, mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> <047301c3ad5e$285fe490$956015ac@dclkempt40> <20031118010124.4d89dabe.henrik@levkowetz.com> <20031118145549.0455aa30.ernst@sfc.wide.ad.jp> In-Reply-To: <20031118145549.0455aa30.ernst@sfc.wide.ad.jp> Content-Type: multipart/alternative; boundary="------------040203010804080302050705" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040203010804080302050705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Thierry, For supporting multilink flows we cannot assume only one HA. From a service provision perspective, geographic redundancy is preferred to avoid single point failure impacts on service delivery. I agree with your observations. Regards, Sebastian Thierry Ernst wrote: >Hi, > > > >>>Why would multiple NAIs be necessary if all the CoA to HoA mappings were >>>handled by one HA, as would be the case if the same service provider was >>>providing service on all CoAs? I agree that they would be necessary if the >>>the CoAs were provided by multiple service providers, but the flow handover >>>issue is just the tip of the iceberg in that case, IMHO. >>> >>> >>I don't think we can assume neither that the same service provder is >>providing service on all CoAs, nor that there is only one HA. If public >>WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, >>I'd say it's actually quite unlikely. >> >> > >I agree with that, the benefit of multihoming would be moot if we assume >a single HA or single ISP (= single point of failures). Such assumptions >does not hold in face of the multihoming scenarios, as identified in >draft-montavont-mobileip-multihoming-pb-statement. > >Thierry. > > > --------------040203010804080302050705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Thierry,
                    For supporting multilink flows we cannot assume only one HA. From a service provision perspective, geographic redundancy is preferred to avoid single point failure impacts on service delivery. I agree with your observations.

Regards,
    Sebastian

Thierry Ernst wrote:
Hi,

  
Why would multiple NAIs be necessary if all the CoA to HoA mappings were
handled by one HA, as would be the case if the same service provider was
providing service on all CoAs? I agree that they would be necessary if the
the CoAs were provided by multiple service providers, but the flow handover
issue is just the tip of the iceberg in that case, IMHO.
      
I don't think we can assume neither that the same service provder is
providing service on all CoAs, nor that there is only one HA. If public
WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, 
I'd say it's actually quite unlikely.
    

I agree with that, the benefit of multihoming would be moot if we assume
a single HA or single ISP (= single point of failures). Such assumptions
does not hold in face of the multihoming scenarios, as identified in
draft-montavont-mobileip-multihoming-pb-statement.

Thierry.
--------------040203010804080302050705-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 11:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28911 for ; Tue, 18 Nov 2003 11:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8nj-00067A-J2 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 11:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGY3q9023489 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 11:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8nj-00066l-Ar for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 11:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28852 for ; Tue, 18 Nov 2003 11:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8ni-0000Hj-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 11:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM8nh-0000Hc-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 11:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8nh-00065f-K4; Tue, 18 Nov 2003 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8mp-00064I-8U for mip4@optimus.ietf.org; Tue, 18 Nov 2003 11:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28763; Tue, 18 Nov 2003 11:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8mo-0000GS-00; Tue, 18 Nov 2003 11:33:06 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AM8mn-0000GF-00; Tue, 18 Nov 2003 11:33:05 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 17:30:04 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAIGWMp6002841; Tue, 18 Nov 2003 17:32:23 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Nov 2003 16:32:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Tue, 18 Nov 2003 16:32:32 -0000 Message-ID: Thread-Topic: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Thread-Index: AcOt2skp981/qY9ZQL+EJJJceH/aKAAFUzwg From: "Pascal Thubert (pthubert)" To: "Sebastian Thalanany" , "Thierry Ernst" Cc: "Henrik Levkowetz" , , , X-OriginalArrivalTime: 18 Nov 2003 16:32:33.0011 (UTC) FILETIME=[91215430:01C3ADF1] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >>=A0 For supporting multilink flows we cannot assume only one HA. From = a service provision perspective, geographic redundancy is preferred to = avoid single point failure impacts on service delivery. I agree with = your observations. Part of HAHA protocol for MIP6 is to sync the geo-distributed HAs = (proactively, reactively or predictively). Hopefully HAHA is a step = towards multihoming, so understanding the associated requirements seems = critical. The way I see it: MIPv6: Basic Nemo: HAHA geodis: = Multihoming: =20 Link centric half and half Fully L3, single Home location = full distribution -------------------------------------------------------------------------= -------------------> What do you think? Pascal =20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 15:41:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14513 for ; Tue, 18 Nov 2003 15:41:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCen-0006i4-21 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 15:41:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIKf5ao025784 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 15:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCem-0006he-Rq for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 15:41:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14476 for ; Tue, 18 Nov 2003 15:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMCek-0005PF-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 15:41:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMCek-0005PA-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCej-0006gZ-O2; Tue, 18 Nov 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCdp-0006fa-7v for mip4@optimus.ietf.org; Tue, 18 Nov 2003 15:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14383; Tue, 18 Nov 2003 15:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMCdn-0005NK-00; Tue, 18 Nov 2003 15:40:03 -0500 Received: from out1.prserv.net ([32.97.166.31] helo=prserv.net) by ietf-mx with esmtp (Exim 4.12) id 1AMCdn-0005Lw-00; Tue, 18 Nov 2003 15:40:03 -0500 Received: from attglobal.net (slip-32-103-178-133.il.us.prserv.net[32.103.178.133]) by prserv.net (out1) with SMTP id <2003111820391520106jr60de>; Tue, 18 Nov 2003 20:39:17 +0000 Message-ID: <3FBA8399.2030709@attglobal.net> Date: Tue, 18 Nov 2003 14:39:53 -0600 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Thierry Ernst , Henrik Levkowetz , kempf@docomolabs-usa.com, mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010608020909020905050806" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------010608020909020905050806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Pascal, The scenarios identified in the problem statement: "draft-montavont-mobileip-multihoming-pb-statement.txt" seem reasonable. Evaluating the requirements for geo-distributed HAs would be a part of a multihoming solution to avoid single point failures. Regards, Sebastian Pascal Thubert (pthubert) wrote: >>> For supporting multilink flows we cannot assume only one HA. From a service provision perspective, geographic redundancy is preferred to avoid single point failure impacts on service delivery. I agree with your observations. >>> >>> > >Part of HAHA protocol for MIP6 is to sync the geo-distributed HAs (proactively, reactively or predictively). Hopefully HAHA is a step towards multihoming, so understanding the associated requirements seems critical. > >The way I see it: > >MIPv6: Basic Nemo: HAHA geodis: Multihoming: >Link centric half and half Fully L3, single Home location full distribution > >--------------------------------------------------------------------------------------------> > >What do you think? > >Pascal > > > --------------010608020909020905050806 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pascal,
                   The scenarios identified in the problem statement: "draft-montavont-mobileip-multihoming-pb-statement.txt" seem reasonable. Evaluating the requirements for geo-distributed HAs would be a part of a multihoming solution to avoid single point failures.

Regards,
   Sebastian


Pascal Thubert (pthubert) wrote:
  For supporting multilink flows we cannot assume only one HA. From a service provision perspective, geographic redundancy is preferred to avoid single point failure impacts on service delivery. I agree with your observations.
      

Part of HAHA protocol for MIP6 is to sync the geo-distributed HAs (proactively, reactively or predictively). Hopefully HAHA is a step towards multihoming, so understanding the associated requirements seems critical.

The way I see it:

MIPv6:             Basic Nemo:         HAHA geodis:                        Multihoming:           
Link centric       half and half       Fully L3, single Home location      full distribution

-------------------------------------------------------------------------------------------->

What do you think?

Pascal
--------------010608020909020905050806-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 18 18:39:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25839 for ; Tue, 18 Nov 2003 18:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFRD-0001A7-GC for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 18:39:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAINdFnh004463 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 18:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFRD-00019u-7n for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 18:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25795 for ; Tue, 18 Nov 2003 18:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFQy-0002V8-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 18:39:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMFQx-0002V5-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 18:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFQy-00017w-Jd; Tue, 18 Nov 2003 18:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM5SO-00023W-Ph for mip4@optimus.ietf.org; Tue, 18 Nov 2003 07:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19345 for ; Tue, 18 Nov 2003 07:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM5SN-0004fz-00 for mip4@ietf.org; Tue, 18 Nov 2003 07:59:47 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AM5SM-0004fs-00 for mip4@ietf.org; Tue, 18 Nov 2003 07:59:46 -0500 Received: (qmail 18477 invoked for bounce); 18 Nov 2003 12:59:53 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with SMTP; 18 Nov 2003 12:59:53 -0000 Message-ID: <3FBA17B4.1060006@clarinet.u-strasbg.fr> Date: Tue, 18 Nov 2003 13:59:32 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: Soliman Hesham , mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip6] Re: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF References: <9E3BA3946476AD4EB94672712B12A85F041FFA@ftmail.lab.flarion.com> <20031117135844.3e7af1b2.henrik@levkowetz.com> In-Reply-To: <20031117135844.3e7af1b2.henrik@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Henrik Levkowetz wrote: >Hi Hesham, > > That's a pretty good summary. My own thinking on this, after a bit >of discussion in Minneapolis, is that the MIP solution which is the >least MIP-specific would be to have separate individual MIP sessions for >each flow (or group of flows) we wanted to move independently of other >flows. This takes care of the ability to treat flows individually, and >it does so by providing separate Home IP-addresses for those flows to >pass through. > I personnally don't agree with that point. First point, it is not sure that a MN can benefit of having as many HoAs as he wants. But, considering the solution of using multiple HoAs, at the initialization of the flow, you should choose the right HoA. If it is the MN which initiates the flow, it is easier, but it may be difficult if it already has many flows: on which criteria the MN will group several flows to be mapped to a HoA, or which criteria tells to MN to use a new HoA for the new flow ? If it is the CN which initiates the communication, it is even more difficult, how can he choose (or even discover ??) the HoA of the MN ? Secondly, if you want to individually manage two flows bound to the same HoA with the same CN (probably you choose the wrong HoA or your preferences had changed), so as you said you have to re-initiate the communication, that means the communication is broken. If we have a way to maintain this communication, why don't use it ? The draft draft-montavont-mip6-mmi-01 (available at http://www.ietf.org/internet-drafts/draft-montavont-mip6-mmi-01.txt) details the different levels of granularity of the mobility (and particulary the limitation of the use of multiple HoAs to manage several flows). The document tries to explain the pros and the cons of each level of granularity. > >I also note that the flow groups, and their IP-addresses, needs to be >established before individual user applications start up and bind to the >individual HoAs - we have no way to signal most application to re-bind >to a new IP-address. > >The cost of this solution is in having to do re-registration of multiple >sessions when you move, but such a cost is already implicit in the fact >that with multiple connections through different connection media you >have to be able to handle each media individually, whether it is by >separate sessions or by filter adaptations. But I believe completely >separate sessions will adapt better to any other non-movement-specific >solution to multihoming that may appear. > > Henrik > >Monday 17 November 2003, Hesham wrote: > > >>Hi, >> >>Just wanted to drop a note on adding flow movement >>capabilities to MIP. >> >>I completely agree that adding new functions to >>MIP just because "it's there" does not make any sense, >>and that where a problem applies to both fixed and mobile >>hosts we should avoid fixing it in a mobility protocol. >>However, when it comes to flow movement, it is not immediately >>obvious to me that it is outside the scope of MIP. >>I'll try to break the problem down in an attempt to realise >>where each component belongs. >> >>The basic problem is that a node needs to decide what >>src address should be used by a particular connection. >>Forgetting about MIP for a minute, this is obvious when >>a host is trying to initiate communication with another host. >>Src address selection can be augmented with various policies >>(user-based or otherwise) to allow the host to pick the >>right src address. However, this is a bit more complex when >>a host is not the initiator of communication. This leads >>to sub-problem (1) >> (1) Informing the initiator of communication of the right >> dst address for the host on the other end. >> >>This information can be communicated implicitly or explicitly. >>One possible example for implicitly informing the other end >>is through using different domain names (e.g. audio.example.com >>returns a different address from video.example.com). On the >>other hand, explicit notification of the address can be done >>by using a protocol to negotiate a connection setup (e.g. SIP >>does this today). >> >>Not withstanding the example solutions above, sub-problem >>(1) is independent of any mobility and applies to any >>multi-addressed host. >> >>Once a connection is established, the right addresses are >>chosen by both ends, end of story. >> >>Now, the other aspect of the problem is this: Once a connection >>is established, using a particular src and destination address >>pair, how can either host modify this information? In other >>words, if WLAN coverage suddenly appeared to my laptop, how >>do I inform the host on the other end to move one of our >>connections to WLAN, while leaving the other on the cellular >>interface? In a few words, I want to change the dst address for >>a particular connection without breaking that connection. >>This requires a protocol to signal that to the other end. >>To me, this problem seems to fall into the IP mobility category >>of problems, although it is addressing a finer granularity >>of mobility. >>Note that SIP also has signalling support for session transfer, >>but: A) it was not intended for this purpose and B) it is >>not widely implemented and C) it is slower than an "optimised" MIP >>(BTW neither A nor B discredits using SIP for this purpose). >> >>So sub-problem (2): >> (2) How to move a flow from one address to another. >> >>MIP efficiently solves this problem for a host, but it >>does not provide further granularity (i.e. connection >>or flow). >> >>Personally, I think sub-problem (2) is a mobility >>problem, by the definition of IP mobility. I believe >>that MIP solves two problems: maintaining current connections >>while moving, and reachability. >>"Moving" in the context of IP mobility effectively means >>changing IP address, independently of whether that change >>affects all flows or only one or two. >> >>My 2 cents! >> >>Hesham >> >> >> >> >>-- >>Mip4 mailing list >>Mip4@ietf.org >>https://www.ietf.org/mailman/listinfo/mip4 >> >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 19 07:58:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14997 for ; Wed, 19 Nov 2003 07:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRuE-0007NJ-CR for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 07:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCw2Lv028349 for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 07:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRuE-0007N9-8Z for mip4-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 07:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14971 for ; Wed, 19 Nov 2003 07:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRuD-0006UM-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 07:58:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRuD-0006UI-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 07:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRuD-0007MC-4j; Wed, 19 Nov 2003 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRu8-0007Lj-Ep for mip4@optimus.ietf.org; Wed, 19 Nov 2003 07:57:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14962; Wed, 19 Nov 2003 07:57:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRu7-0006U5-00; Wed, 19 Nov 2003 07:57:55 -0500 Received: from zeus.ruca.ua.ac.be ([143.129.201.210] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMRu6-0006U0-00; Wed, 19 Nov 2003 07:57:54 -0500 Received: from hmacs.ruca.ua.ac.be (hmacs.ruca.ua.ac.be [143.129.75.10]) by zeus.ruca.ua.ac.be (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id NAA17161; Wed, 19 Nov 2003 13:42:44 +0100 (MET) Received: from PCINF15 (pcinf15.ruca.ua.ac.be [143.129.75.67]) by hmacs.ruca.ua.ac.be (8.11.6/Switch-2.0.0) with ESMTP id hAJCgiK28147; Wed, 19 Nov 2003 13:42:44 +0100 (CET) From: "Nik Van den Wijngaert" To: , Date: Wed, 19 Nov 2003 13:42:28 +0100 Message-ID: <001c01c3ae9a$9ac00d20$434b818f@PCINF15> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the HelpDesk for more information X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [Mip4] [CFP] ITC specialist seminar : Announcement and CFP Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Announcement and Call for Papers ITC Specialist Seminar on Performance Evaluation of Wireless and Mobile Systems August 31 - September 02, 2004 University of Antwerp Antwerp - Belgium http://www.itcss16.ua.ac.be ----------------------------------------------------------------------- This ITC Specialist Seminar on Performance Evaluation of Wireless and Mobile Systems is the 16th event in the series of ITC Specialist Seminars that started in 1977, aiming at a specific topic of current or future interest. The 16th ITC Specialist Seminar will take place between August 31 and September 02, 2004 in Antwerp, Belgium. The technical program committee is soliciting papers describing original, previously unpublished, completed research, not currently under review by another conference or journal, addressing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: - Mobility management for wireless internet - QoS protocols for wireless internet - Sensor network planning and performance aspects - Wireless LANs - Routing protocols for Ad Hoc networks - Performance issues in Ad Hoc networks - Medium access control techniques and their performance - Traffic characterization and measurements in mobile networks - Resource allocation in mobile and wireless networks PAPERS SUBMISSION Papers must be submitted electronically (according to the instructions in http://www.itcss16.ua.ac.be ) and their maximum size should be 20 double-spaced pages (using times 12pt as a reference). The cover page must contain an abstract of about 150 words, 3-5 keywords, name and affiliation of author(s), as well as the corresponding author's e-mail, telephone number, fax number and postal address. PAPERS PUBLICATION All submissions will be reviewed by the program committee. Accepted papers will appear in the conference proceedings. The copyright remains with the authors. IMPORTANT DATES Full papers due: February 15, 2004 Notification: April 30, 2004 Camera Ready due: June 30, 2004 CONFERENCE WEBSITE For more information check the conference website, at http://www.itcss16.ua.ac.be -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 19 12:02:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26908 for ; Wed, 19 Nov 2003 12:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMViT-0007m1-PM for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:02:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJH29sf029881 for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:02:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMViQ-0007kb-PX for mip4-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:02:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26886 for ; Wed, 19 Nov 2003 12:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMViN-0003Mx-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:02:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMViN-0003Mu-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMViK-0007jX-QQ; Wed, 19 Nov 2003 12:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQaT-0003Dg-E2 for mip4@optimus.ietf.org; Wed, 19 Nov 2003 06:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13081; Wed, 19 Nov 2003 06:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQaP-0005Kq-00; Wed, 19 Nov 2003 06:33:29 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMQaO-0005Km-00; Wed, 19 Nov 2003 06:33:28 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAJBXEkt007775; Wed, 19 Nov 2003 04:33:18 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hAJBVlF7027247; Wed, 19 Nov 2003 05:31:49 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id A4A3D2EC95; Wed, 19 Nov 2003 12:32:54 +0100 (CET) Message-ID: <3FBB54E6.8030909@motorola.com> Date: Wed, 19 Nov 2003 12:32:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Henrik Levkowetz , mip4@ietf.org, mip6@ietf.org References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <20031117174000.5be9a786.henrik@levkowetz.com> In-Reply-To: <20031117174000.5be9a786.henrik@levkowetz.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: large numerous packets (was: tying flow movement to MIP) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: >> It's certainly _a_ solution. And definitely a simple one. But I >> would view this as being very expensive for MIPv6. Assuming 2 HoAs, >> in the worst case scenario the MN could end up sending two BUs to >> the HA and two to each CN that knows about both HoAs. I think this >> is too expensive, especially if MIP is being used to manage >> mobility proper. Also note when calling it "expensive" that this BU happens only once per "cell", it does not add up to the effective usable app-level communication. One BU or two BU's is almost the same. It does not grow exponentially. It grows only with the number of interfaces or of home addresses one has on a machine. Number of interfaces is clear: no more than 3-4 interfaces on a _mobile_ device which is implicitely small. Number of home addresses per devices is also clear: no more than the number of apps that mobile machine runs simultaneously, also small. >> For MIPv4 it's not as expensive, but sending two different RREQs >> upon movement can still be expensive from the edge of a cell, given >> the sizes of those messages. Again here note remarks from practice where sizes of upstream packets accepted my some widely deployed/adopted/used wireless envs is relatively large with respect to the size of either one RReq or one BU (which are relatively small). Then, if sizes of IP packets are indeed too large, then there is IP fragmentation or IP PMTU discovery as good reusable tools too. Alex GBU -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 19 12:09:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27174 for ; Wed, 19 Nov 2003 12:09:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVp8-0008Lq-Qp for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJH92Nf032096 for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVp8-0008LR-Lt for mip4-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27144 for ; Wed, 19 Nov 2003 12:08:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVp7-0003WY-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:09:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVp6-0003WV-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVp7-0008Kw-LF; Wed, 19 Nov 2003 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVoG-0008Gx-Me for mip4@optimus.ietf.org; Wed, 19 Nov 2003 12:08:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27126; Wed, 19 Nov 2003 12:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVoF-0003VI-00; Wed, 19 Nov 2003 12:08:07 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVoE-0003Ur-00; Wed, 19 Nov 2003 12:08:06 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAJH6lE18792; Wed, 19 Nov 2003 11:06:48 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAJH6kG18356; Wed, 19 Nov 2003 11:06:46 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOLZJ5-00012W-00; Wed, 19 Nov 2003 12:06:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16315.41760.686515.201908@gargle.gargle.HOWL> Date: Wed, 19 Nov 2003 11:06:40 -0600 From: Pete McCann To: Henrik Levkowetz Cc: "James Kempf" , , Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF In-Reply-To: <20031118010124.4d89dabe.henrik@levkowetz.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> <047301c3ad5e$285fe490$956015ac@dclkempt40> <20031118010124.4d89dabe.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Henrik Levkowetz writes: > Hi James, > > Monday 17 November 2003, James wrote: > > Pete, > > > > > In MIP4, there may be less of an impact from multiple home addresses > > > due to the absence of route optimization. However, IPv4 addresses are > > > more precious than IPv6 addresses. That last fact seems to me to be > > > the only reason why we would think about putting filters into a > > > registration request. It seems much simpler for the application > > > (using SIP or whatever) to advertise a particular home address to the > > > CN. You could still handle mobility independently for each session, > > > using Mobile IP along with the extra level of indirection supplied by > > > the separate IP addresses. There is no need to build mobility into > > > the application protocol. > > > > > > > Agree with IPv4 addresses being scare as the main issue for doing flow > > handoff at the home agent in MIPv4, but not sure about whether the RREQ is > > the right place for filters. Seems like it is a generic middlebox problem > > and should be approached using the same tools as for other middleboxes. > > I'm not at all sure that the reasoning about IPv4 address scarcity > holds water. MIPv4 works with both HoAs and CoAs being private, behind > NATs (even if we don't like'em... :) Yes, but we may need to solve this problem for public IPv4 addresses, depending on the deployment scenarios. > > > There may be a few unsolved issues with HAs allocating multiple > > > addresses, but I think it could be handled easily with the use of > > > multiple NAIs. I wrote a draft called the "Mobile IP Session > > > Identifier Extension" some years back, but you could do the same thing > > > with some sort of NAI-mangling naming convention > > > > Why would multiple NAIs be necessary if all the CoA to HoA mappings were > > handled by one HA, as would be the case if the same service provider was > > providing service on all CoAs? I agree that they would be necessary if the > > the CoAs were provided by multiple service providers, but the flow handover > > issue is just the tip of the iceberg in that case, IMHO. > > I don't think we can assume neither that the same service provder is > providing service on all CoAs, nor that there is only one HA. If public > WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, > I'd say it's actually quite unlikely. I wasn't thinking of multiple service providers, I was just trying to find a cheap and easy way to support multiple sessions even on a single HA. The problem with a single NAI is that it becomes impossible to distinguish a retransmission from a request for a new session (IP home address). So we need something like a session ID, or a convention for multiple sessions within the NAI namespace. Such a technique would also allow each flow to be homed on a different home agent, as you point out, which might be needed for additional flexibility. However, all the subsequent posts about HA redundancy, etc, have gotten way off topic and are missing my point entirely. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 19 12:14:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27577 for ; Wed, 19 Nov 2003 12:14:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVu0-0000O6-9O for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHE3qB001365 for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 12:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVtz-0000Kq-MF for mip4-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:14:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27537 for ; Wed, 19 Nov 2003 12:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVtx-0003h9-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVtx-0003h6-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 12:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVtx-0000IA-PL; Wed, 19 Nov 2003 12:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVtK-0000Gi-LN for mip4@optimus.ietf.org; Wed, 19 Nov 2003 12:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27495; Wed, 19 Nov 2003 12:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVtI-0003fn-00; Wed, 19 Nov 2003 12:13:20 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVtI-0003eA-00; Wed, 19 Nov 2003 12:13:20 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAJHCBE22300; Wed, 19 Nov 2003 11:12:12 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAJHCAG01363; Wed, 19 Nov 2003 11:12:11 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOLZS6-0001P8-00; Wed, 19 Nov 2003 12:12:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16315.42086.725515.38907@gargle.gargle.HOWL> Date: Wed, 19 Nov 2003 11:12:06 -0600 From: Pete McCann To: Soliman Hesham Cc: "'Henrik Levkowetz'" , mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFF@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFF@ftmail.lab.flarion.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Hesham, Soliman Hesham writes: > Hi Pete, > > > So maybe what we need is an efficient way to handle multi-homed hosts > > (hosts with multiple home addresses) in MIP6. This could be > > something > > like aggregation of BUs or other sorts of tricks. > > => That used to be in the draft for the HA BUs but was removed > because it was difficult to achieve from a security > point of view. I'm not sure that this is cleaner than > just adding the flow movement extensions. Also another > use of those extensions (that I didn't want to bring up > yet) is for optimising the handover smoothing for different > flows (buffer to eliminate packet loss Vs forward to eliminate > delays). Sure, but I think you could do that with multiple home addresses too. > > In MIP4, there may be less of an impact from multiple home addresses > > due to the absence of route optimization. However, IPv4 > > addresses are > > more precious than IPv6 addresses. That last fact seems to me to be > > the only reason why we would think about putting filters into a > > registration request. > > => In MIPv4 I agree. > > > It seems much simpler for the application > > (using SIP or whatever) to advertise a particular home address to the > > CN. You could still handle mobility independently for each session, > > using Mobile IP along with the extra level of indirection supplied by > > the separate IP addresses. There is no need to build mobility into > > the application protocol. > > => There is definitely no need to build mobility into the > application protocol, I didn't suggest that. Having SIP > advertise an address does not fix the problem when you > want to move that connection from one interface to another > as I explained in a previous email. The only way to do that > today is to terminate the connection and restart it. I > don't imagine that we'd want to do that. No, you wouldn't need to do that, assuming each application was using its own home address. Each application flow could be moved completely independently, based on application needs and interface availability. You just send a registration request binding the home address to the right CoA. > > There may be a few unsolved issues with HAs allocating multiple > > addresses, but I think it could be handled easily with the use of > > multiple NAIs. I wrote a draft called the "Mobile IP Session > > Identifier Extension" some years back, but you could do the > > same thing > > with some sort of NAI-mangling naming convention > > (H.Soliman1@flarion.com, H.Soliman2@flarion.com, etc...). > > => I remember that, it was presented in Adelaide I think. > I thought it was worth pursuing back then. Anyway, now we're > discussing solution space, I just wanted to highlight the problem. > > At the moment it's probably a bit premature to decide that > one solution is _the_ one (hence I'm being the devil's > advocate either way you go :) ). If this topic is important > to the WGs perhaps we should do a proper investigation. Agreed - I guess we need to understand where this requirement is coming from. Also, we need to understand whether commercial production mobiles will want to include the necessary APIs for people to build these kinds of adaptive applications, or whether this is all just an academic exercise. -Pete > Hesham -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 19 15:56:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11373 for ; Wed, 19 Nov 2003 15:56:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZMq-0007uG-Cm for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 15:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKu4f5030391 for mip4-archive@odin.ietf.org; Wed, 19 Nov 2003 15:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZMq-0007u2-1C for mip4-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11370 for ; Wed, 19 Nov 2003 15:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZMo-00022d-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 15:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMZMn-00022a-00 for mip4-web-archive@ietf.org; Wed, 19 Nov 2003 15:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZMo-0007tX-H3; Wed, 19 Nov 2003 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZMQ-0007sQ-F0 for mip4@optimus.ietf.org; Wed, 19 Nov 2003 15:55:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11363 for ; Wed, 19 Nov 2003 15:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZMN-00022W-00 for mip4@ietf.org; Wed, 19 Nov 2003 15:55:35 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AMZMM-00021v-00 for mip4@ietf.org; Wed, 19 Nov 2003 15:55:34 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAJKrSm00961 for ; Wed, 19 Nov 2003 14:54:07 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAJKrOG05697; Wed, 19 Nov 2003 14:53:26 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOMA0V-0001OG-00 for mip4@ietf.org; Wed, 19 Nov 2003 15:53:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16315.55355.819515.98554@gargle.gargle.HOWL> Date: Wed, 19 Nov 2003 14:53:15 -0600 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] Draft minutes from IETF58 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Attached are the draft minutes from IETF58. Please send any comments to the list. Especially welcome would be for the people whose comments are marked as "???" to identify themselves. These will get mailed to the minutes archives in a week or so. -Pete 


IETF58 mip4 Working Group Minutes
=================================

Monday, November 10, 2003
1300 to 1500
Chairs: Henrik Levkowetz, Pete McCann

Thanks to Sami Vaarala and Eva Gustafsson for taking great notes.


- unclear things marked with XXX

- '???' refers to one and the same person who commented
  on the mike but whose name i did not get



mobile ipv4 agenda (henrik levkowetz and pete mccann)
-----------------------------------------------------

introductions and agenda (pete)

preliminaries (henrik)
	- work status web page http://www.mip4.org/
	
	- draft status

		draft-ietf-mip4-aaa-nai-00
			- reviewed by iesg, comments addressed in new text
			- one new issue by Bjorn Andersson
			- not re-submitted yet

		draft-ietf-mip4-vpn-problem-statement-00
			- pretty much done, needs writeup by chairs, will send to iesg

		draft-ietf-mobileip-lowlatency-handoffs-07
			- waiting for writeup, then to iesg

		draft-ietf-mip4-rfc2006bis-01
			- waiting for mivp4 specific mib review
			- after that, mib doctor review, finally iesg

		draft-ietf-mobileip-vpn-problem-solution-03
			- all comments addressed in latest version
			- but document needs peer review to go forward
			- wg chair review to be done soon

	- charlie perkins
		- what happened to the regional registration draft?
		- seems that since it is done, should be sent to iesg?
        - Defer this question a bit while chairs confer with ADs


aaa key draft (pete mccann)
----------------------------
    draft-ietf-mip4-aaa-key-01

	- editorial mistake corrected in -01

	- revisions from draft-ietf-mobileip-aaa-key-13
		- clarify: for ipv4, not ipv6
		- terminology cleanup
		- clarified what happens if reg. reply fails
		- iana considerations clarified
		- explicit security requirements for aaa key
			distribution infratstructure

	- next steps
		- one more ietf last call, then to iesg

	- charlie perkins
		- thought review was a response to iesg comments?

	- pete mccan
		- these were informal comments from iesg

	- alpesh patel
		- any work to support radius attributes?

	- pete mccann
        - There is ongoing work on the Diameter MIP4 application in aaa WG
		- mip4 not the place for RADIUS extensions, perhaps radiusext
          could take that work on


experimental messages (alpesh patel)
-----------------------------------------------
    draft-patel-mobileip-experimental-messages-02

	- problem statement
		- defines an experimental message, extensions and error code
		- used to aid interoperability before standardization
		- avoids overlap with reserved numbers

	- status -- -02 published
		- experimenteral message, extensions and error codes for mipv4

	- where do we go from here?

	- henrik levkowetz
		- this problem has been added to charter, question is whether
			this is the proper solution for the problem
		- hum vote on whether this should be a work item
			=> no hums in either direction
		- hand voting
			=> no hands for or against

	- thomas narten
		- is there interest in this work, do people know the issue?

	- alpesh patel
		- recap of motivation for the draft
		- this is a problem, practical feedback from partners

	- charlie perkins
		- could not personally vote either way because had not read
			the draft
		- is this experimental?  sometimes you want to experiment with
			two things, does the draft have subextensions

	- alpesh patel
		- yes, experimental

	- thomas narten
		- need to be able to experiment with protocols;
			chicken-and-egg problem, need codepoints but iana
			won't give you experimental allocations

	- alpesh patel
		- what if we need multiple numbers (e.g. two or three
			message types?)

	- thomas narten
		- you could need requests and responses to be experimental

	- alpesh patel
		- you can also use experimental extensions etc

	- henrik levkowetz
		- we already have subtypes for extensions
		- actually good to not reserve too many experimental numbers,
			because you want to limit the number of extension
			numbers you take for one single application

	- thomas narten
		- balance, you don't want to reserve too many, so that
			numbers don't become permanent.  if number is
			small enough, numbers cannot become permanent
		- mobile ip has a history of having allocated without
			talking to iana, sometimes problems in standardization
			because numbers already iana
		- idea here is that for experimentation and testing you
			can do it the right way

	- henrik levkowetz
		- who's read the draft? ==> same hands that had an opinion
		- we'll need more feedback on this
		- please read the draft, chairs will post the question on
			the list in a couple of weeks


issues with rfc 3344 (charlie perkins)
--------------------------------------

	- tracker for issues

	- issue 9: fa should not reject rrq with error code 136
		- conflicts with language describring the use of code 136
		- straightforward solution: new error code
		- this also provides the solution for issue 18?

		(no discussion)

	- issue 17: enhanced registration request processing at the home agent
		- what is the motivation for the proposed text?
		- error #129 is non-specific, #132 would do
		- idea: what the ha is allowed to do if it gets a rrq to
		  a unicast address the ha does not own?
		- can't remember discussion why this would be interesting

		- pete mccann
			- some deployments where rrq might arrive at the ha
			  maybe after being forwarded from another home agent,
			  so the home agent address may not be set to any
			  unicast address of the (final) home agent

		 	- in those case, proposal was to allow ha to process
			  that request and return a success indication but
			  fill in its own address in the reply

			- propose that we reject the issue

		- charlie perkins
			- agree, lot of recent discussion about ha failover
			  in mipv6 context, starts to look like
			  some sort of failover operation

			-  also propose reject it

		- rejected

	- issue 18: the fa is rejecting with error code 137 which is
			meant for the home agent

		- proposal:  create a new error code in range 64-127, which
			will then be a valid fa error code

		(no discussion -- accepted?)

	- issue 19: multiple authorization-enabling extensions should
			be permitted

		- suggestion: relax current restriction, we have multiple types
			of authorization-enabling extensions now
		- problem: what if one fails but other does not?
			- possiblity: the ha checks until it finds one that
			is verifiable?
		- proposal: table the issue unless motivation increases or
			problem is solved

		- what is the motivation?
			- which scenario is this a solution to?
			- not personally favoring changes to do this,
				introduces problems
			- no strong feeling about this

		- pete mccann
			- there are cases where mn has both mn-ha and aaa
			  extensions out in the field today, should be ok to
			  append more than one extension, might be to
			  authenticate yourself to two different nodes in the
			  network

		- charlie perkins
			- aaa authenticates use of charge card, and mn-ha
			  authenticates mobility, for instance

		- pete mccann
			- reasonable use case

		- charlie perkings
			- can we require that all need to be verified, and
			  must be rejected if any extension does not verify,
			  different codes for different authentication failures

		- charlie perkins:
			- any other comments? (=> no)

		- will take to the list

	- issue 20: missing description - fa rejection code when
		mn-ha auth ext invalid

		- proposal: fa does not requre the existence of mn-ha
			extension, nor reject the reg req if it is absent
		- for this reason, related to issue 21
		- is there a need for the fa to check "formatting" of the rrq?
			- the packet will be rejected anyway by the ha
			- rare case, imposing new requirements on the fa
			- suggest fa does not need to check the mn-ha extension (XXX)

		(no discussion)

	- issue 21: mn-aaa ext. not considered in fa-to-ha forwarding rules
		- proposal. reword to use "authentication-enabling" language
			instead
		- observation: if, in future, more such authentication-enabling
			extensions are defined, the fa may not be able to
			identify those extensions as enabling
		- suggestion: make sure that draft allows forwarding even
			when fa does not understand some new auth extension
		- want to avoid the situation where future authentication
			extensions would not work in the specified model

		(no discussion)


challenge extensions (revised) (jayshree bharatia)
--------------------------------------------------
	draft-ietf-mip4-rfc3012bis-00

	- changes from mobileip-rfc2013bis-06
		- terminology changes, error codes renamed
		- defined/clarified order of mn-aaa auth ext when coexists
			with mn-ha existing in rfc 3344
		- handling of solicited agent adv. at the fa is clarified
		- suggestions are added to security considerations to
			prevent invalidation of challenges caused by large
			number of agent soliciations pr bogus registration
			requests
		- editorial changes based on feedback from list

	- issue 1: potential deadlock for slow reg. replies associated with
			small (re)transmit rate at mn
		- occurs when mn is busy downloading some large file and
			trying to re-reg at the same time
		- first identification field is old when first rrp arrives
			(mn already sent a new rrq with new identification
			field)
		- proposals:
			1. introduce retransmitted challenge whose value
				equal the challenge value used in the last
				req reg + some constant value, and let fa
				accept this retransmitted challenge as valid
				=> potential security issues

			2. reconfigure timer value at mn

		- pete mccann
			- this has been discussed on the mailing list
			- root cause is link buffer that is getting full
			- probably forward direction link towards the mn
			- timer X has been set too short; rfc 3344 says,
			  rexmit should be longer than roundtrip time
			- proposal 2 used in the field, seems lower cost
			  solution, least impact on standards
			- one implementation trick: keep context around
			  for the old request; if you get a response to
			  an old request, you can accept it if this is
			  valid;  this would also not affect the standards
			- should consider lower cost alternatives

		- charlie perkins
			- consider handheld device case, chances of
			  (end user) reconfiguring the timer in a mn
			  are slim; most people would not do that even if
			  option offered
			- would like to see fa oriented solution

		- pete mccann
			- just increasing challenge window does not solve
				the problem; same challenge would not work?

		- charlie perkins
			- it makes sense, does not seem like a big
			  security problem  (XXX did not quite catch this)

		- jayshree bharatia
			- (XXX jayshree commented about the challenge
			  being retransmitted, did not catch this)

		- pete mccann
			- because identifier changes it looks like a
			  different request
			- maybe we want to relax fa so that even if
			  challenge previously used, it would still be ok
			- we need to be careful with security considerations
			- don't think this is a matter of user configuration
			  of the timer, more manufacturer problem so that the
		 	  manufacturer configures the proper timer (e.g. 4
			  seconds), don't think that manufacturers are doing
			  that correctly

		- jayshree bharatia
			- trade-off situation, rare scenario, the mn will
			  most likely recover even without changes

		- henrik levkowetz
			- option 2 as a way to go?

		- charlie perkins
			- comment was just made that this is a fatal error
			  and is recoverable
			- thrust of pete's argument is that depending on
			  traffic, the timer should be done by the manufacturer
			  to antipicate these problems
			- charlie agrees

	- issue 2: processing of the invalid challenge at the fa upon receipt
		of a registration reply from the ha
		- MN => FA: reg req, chal = x
		- FA => HA: reg req, chal = x
		- HA => FA: reg rep, chal = z
		- FA => MN: reg rep, chal = y 

		- proposals
			1. add text in sec. cons. regarding invalidation of
		 	   the data supplied by the ha
			2. discard received reg rep and send the reg rep with
			   an appropriate error code once the time waiting for
			   the valid response expires

		- charlie perkins
			- just wanted to expand on what the fa might do if
			  it has bad format
			- for a long time we had problem that if fa messes
			  with code in reg rep, so was wondering whether we
			  might have an extension where the fa could say
			  "dont want to change reg rep code, but here's the
			  code i would like to use")
			- could have the original authentication data still
			  verifiable, but still get the same data

		- henrik levkowetz
			- seems like the cleanest solution I heard so far
            - in favor of charlie's proposal

		- jayshree bharatia
			- (XXX take on the list?)


vendor specific round up (henrik levkowetz)
-------------------------------------------

	- new possible charter item, currently a number of vendor specific
		extensions for mipv4, which is good

	- purposes of round-up
		- catalogue v-s extensions found in the wild
		- document purpoases and details of the messages
			- understand why necessary
			- see if there are commnon needs which new standard
			  mipv4 extensions should be defined

	- not work on
		- v-s extensions that vendor does not want to share
		- link specific v-s extensions

	- is this a wortwhile effort for the wg to take on?
		- espen klovning
			- catalog would be nice, not aware of any
			  actual vendor specific extensions

		- thomas narten
            - I initiated this
			- long time in ppp there was a similar situation, 
			  having a document that listed the extensions useful
			  in debugging
			- simply provide information to people, but not
			  necessarily take the work on

		- henrik levkowetz
			- we should add the debugging aspect

		- charlie perkins
			- might interact with iana work?  Individuals might get assignments
              that they would not have gotten otherwise

		- thomas narten:
			- good question, if people are using same numbers
			  improperly

		- charlie perkins: (XXX: did not get this)

		- pete mccann
			- clarification: charlie, are you talking about people who didn't use
			  v-s extensions, but used the standards-track extension space without
              asking?

		- charlie perkins
			- yes

		- henrik levkowetz
			- since these are vendor specific, they are orthogonal
			  to each other, no collisions, are and will continue
			  to be owned by the respective vendors;  if we
			  standardize, we need to go through the normal
			  routine and iana process

		- pete mccann
			- should not be a problem with iana

		- thomas narten
			- theory is that having more information is better
			  than not having information

		- ???
			- practically every protocol has vendor specific
			  options, not sure if this is useful

		- thomas narten
			- not necessarily, if its useful they do it, if not,
			  they don't

		- ???
			- not ietf's job to find variations from vendors

		- pete mccann
			- will take cooperation of vendors, not a polling
			  exercise to get extensions, vendors will need to
			  volunteer

		- ???
			- how we actually do this?

		- pete mccann
			- will need to use our contacts in the industry

		- ???
			- the effort will be incomplete

		- pete mccann
			- some items are specificallty excluded, there is no
			  intention to get a comprehensive list

		- alpesh patel
			- vendors can add proprietary information to messages
			- why would vendors tell that information?

		- henrik levkowetz
			- maybe they wont

		- alpesh patel
			- if vendors think extensions add value, vendor should
			  try to standardize the extensions themselves, the
			  working group should not do it

		- pete mccann
			- this effort could be best seen as a way to facilitate
			  the process

		- thomas narten
			- are there interoperabilty issues here, e.g. people
			  need to implement vendor specific stuff to make
			  things work, sometimes vendor specific extension
			  becomes de facto standard, so vendors just need to
			  implement
			- not useful to have "the definitive list", but still
			  might be a useful effort

		- henrik levkowetz
			- does the wg feel this is a wortwhile exercise?
			- for: a few, opposed: a few
			- no clear consensus
			=> won't go into this at this time

		- pete mccann
			- if more interest in the list, might pick up later

		- thomas narten
			- do people feel there are issues with vendor
			  specific extensions?

		- pete mccann
			- any examples?

		- ???
			- example with a test suite vendor who has test suites
			  for vendor specific extensions; ietf has nothing
			  to do with it

		- henrik levkowetz
			- at my company, we have only had problems in this
			  area only once, where we came across a v-s ext
			  and could not handle it correctly; the ext was
			  skippable, so the processing was fixed to skip
			- having skippable extensions makes this a non-issue
			  for interoperability

		- pete mccann
			- we'll put this on the shelf for now, unless
			  there is more interst on the mailing list


dynamic ha assignment (alpesh patel)
------------------------------------
	draft-kulkarni-mobileip-dynamic-assignment-02

	- status
		- version 02 published
		- major changes from 01 to 02
		- active interest from vendors
		- at least 2 working implementations

	- resolved issues / changes in 02
		- terminology and editorial
		- loop free routing of rrq
		- load balancing by rejecting the rrq with special code and
			suggesting an ha
		- security consiederations

	- terminology and editorial
		- requested/assigned ha -- denote a single ha, indicates the
			meaning depending on the message type
		- redirected ha -- new ha that is being referred to for load
			balancing, administrative policies etc, when the reply
			message carries a special error code (TBD by IANA)
		- changed text to take care of "outside the scope" as in -01

	- loop free routing of rrq
		- no ha redirection in network (as in version 01), ha could
			forward rrq to another ha
		- ha receiving rrq (assigned ha) may reject the request and
			point to a redirected ha
		- since ha does not forward rrq in network, no chance of same
			rrq looping in the network
		- also fixes a nat traversal problem

	- load balancing
		- requested ha can suggest an alternate ha to use by
			rejecting with special error code and redirected ha
			address in extension
		- if special error code is present, the extension carrying
			redirect ha address must be present

	- security considerations
		- since there is no redirection in network, fa receives rrp
			from the ha it fowraded to rrq (no address mismatch)
		- statement that "mn and all has may share same sa" removed
		- mn and ha can derive dynamic seucrity association

	- open issues
		- in extension carrying redirected ha address, including
			public and pricate ha ip address if available
		- would like to get feedback on this

	- questions ?

	- ???
		- question regarding redirection, how do you redirect without
		  knowing the status of the target ha?  Could be redirecting into
          a black hole

	- alpesh patel
		- this is outside the scope, could be a heartbeat protocol,
		  whatever

	- ???
		- suppose that redirections start "bouncing"

	- alpesh patel
		- not enforcing that, management layer in mn could detect

	- ???
		- protocol should take care of reconfiguration

	- alpesh patel
		- can be built on client side, mn can simply keep state of
		  registration attempts and redirections

	- ???
		- have to build state for each registration in the client,
		  loop can be longer

	- henrik levkowetz
		- sounds like an earlier version of the draft, there is no
		  forwarding of the rrq in the draft

	- pete mccann
		- i think the draft now puts mn in control of every reg
		  retransmits, mn can decide what to do, much more in line
		  with the end-to-end principle, and can detect config errors

	- henrik levkowetz
		- who has read the draft?  (=> a few hands)

	- henrik levkowetz
		- the issue is within the wg charter, sooner or later we
		  need to decide whether this draft is a good solution to
		  the accepted problem in the charter
		- with the few readers who read, will not do this now
		- will solicit a few more people to read, then get
		  feedback from list


ipv6 in mipv4 tunnels (scott corson)
------------------------------------
Representing George Tsirtsis & Hesham Soliman

	draft-tsirtsis-v4v6-mipv4-00
	draft-tsitrsis-v4v6-mipv4-00
	draft-soliman-v4v6-mipv4-00 (incorrect file)

	- the problem - 1
		- mipv4 allows ipv4 node to move in ipv4 networks
		- same for mipv6 (for mipv6 networks)
		- but internet is a micture of ipv4, ipv6, and dual
		  stack networks, interop issues

	- best case scenario today - what works and what doesn't?
		- mipv4 => IPv4 and dual stack
		- mipv6 => IPv6 and dual stack
		- mn supports mipv4 and mipv6 => ipv4, ipv6, dual stack okay
			- but e.g. v4 => to v6 handover does not work
		=> undesirable overhead, unpredictable connectivity

	- the problem - 2
		- double overheads
		- inability maintaining sessions when doing v4/v6 handovers
		- mobility micromanagement impossible

	- solution: ds-mip
		- use mip as a v4/v6 migration tool
			- use the tunneling capaibility of mip to forward
			  both ipv4 and ipv6 traffic over the same mip
			  created tunnel
		- mipv4 extension
			- allow ipv4 and ipv6 hoas to bind to an ipv4 coa
		- mipv6 extensions
			- similarly
		- mn can use either ds-mipv4 only (initially), or ds-mipv6
		  only (future)   (XXX?)

	- scenarios
		- ds-mipv4 scenario - ipv4 dominant
		- ds-mipv6 scenario - ipv6 dominant
		- ds-mipv4 and ds-mipv6 solution works with both ipv4
		  and ipv6 networks

	- james kempf
		- draft looks ugly, but maybe the problem is that the
		  problem is ugly and requires an ugly solution
		- not too common to wander from network to another and
		  change from v4 to v6 or vice versa
		- haven't seen a solution that looks nice

	- pete mccann
		- suggest that we adopt ipv6 everywhere? (:-)

	- james kempf
		- of course
		- would like to see more thought on this, alternative
		  solutions

	- alpesh patel
		- couple of years ago there was a relevant contribution
		- draft from Pat Calhoun & others

	- pete mccann
		- participated in the draft, no interest at the time
		- i think the ds-mip approach solves some problems not
		  in the previous draft

	- pete mccann
		- first exercise: do we want to add this to the charter?

	- henrik levkowetz
		- we will not make any decisions now
		- we'd still like to see who thinks this is an interesting
		  problem to look at?
		- for: ~10 ? against: none  (XXX)


filters for mobile ipv4 bindings (carsten bormann)
--------------------------------------------------
	draft-nomad-mobileip-filters-05

	- motivation
		- simultaneous use of multiple points of attachments on a
		  single mobile device

	- mobile ipv4
		- simultaneous binding, s-bit, duplicates traffic
		- if duplication is unwanted, only one poa can be active
		- one hand-off affects all flows
		- not enough ip addresses for multihoming

	- filtering for mobile ip bindings (nomad)
		- simultanous use of multiple points of attachment with
		  a single home ip addresses without duplicating traffic
		- distribution of multiple flows / single flow
		- flow rejection

	- applications
		- load balancing
		- network management (flow mgmt initiated by core network)
		- enchanged terminal mobility (partial/smoothed handoffs)
		=> better utilization of available network resources

	- idea: send filters from mn to ha, mn can specify which parts of
		data flow should be sent through which interfaces / points
		of attachment

	- mode of operation (slide illustrating modes of operation with
		different filters)
		- may have "competing" filter specifications, e.g. same filter
		  but can specify that 20% to interface 1, 80% to interface 2
		- also weights

	- dynamic format filters
		- nine types of filter modules, OR and AND between predicates

	- conclusions

	- do we want to do this work in this working group?

	- ???
        - good idea, but have fundamental problems
		- how will you stop from requesting a large number of flows?
		- very complex filter policies, will affect traffic to
		  every other device

	- carsten bormann
		- this is between mn and ha

	- ???
		- no, can affect other mns, e.g. huge number of filters

	- carsten bormann
		- you can work around this

	- ???
		- although theory is novel, not practical?

	- james kempf
		- i think this is a really bad idea; home agent is a
		  convenient middle box, so we can do all nice things
		  in the middle box [is often thought]
		- you don't have some of this information in the ip
		  layer to do this, relevant information may be in
		  the transport layer
		- i don't see any real usefulness

	- carsten bormann
		- several things in the question; are you addressing
		  the case where one transport is through multiple
		  connections, or several transports through multiple
		  connections

	- james kempf
		- any case where you use multiple interfaces for
		  other than sending traffic through them
		- don't think this is the right way to deal with the
		  problem

	- pete mccann
		- i see some good motivations for doing this thing,
		  we have many interface types which are suitable
		  for different things; e.g. voice over 3g, data
		  over wlan.  if application can distinguish those
		  things, app could control routing
		- but, not convinced that mobile ipv4 is the right
		  way to do it, what if all interfaces are at home?
          Then there is no home agent to do the filtering, and
          we need another solution.
		- a bit confusing, not sure what is the right solution,
		  should perhaps be independent of mipv4

	- carsten bormann
		- many situations where you want someone in the network
		  to do something for you, addresses james's comments
		  as well.  would be nice to have a general architectural
		  approach for having this, a "friend" in the network
		  to do this for you.

		- rsvp does something similar but is a one connection
		  protocol.  nsis is doing something similar.

		- if you have an identifiable thing in the network
		  where to do this work, it might be a good place
		  to do the changes; you could also have a completely
		  separate protocol for doing this. seems to me that 
		  mobile ipv4 would be a good match for this problem.

	- henrik levkowetz
		- i have a couple of issues; first, basic idea of
		  route appropriate flows over appropriate channels;
		  i think really belongs in the end nodes, the appropriate
		  would be to let applications select which interface to use

		- second, if you want to go down this road, you want to do
		  this for other things than mobile ipv4 (signaling), this
		  is completely  incomplete as long as you don't have a
		  way for applications to signal their needs and then some
		  transport with filtering capability

		- multiple interfaces with multiple capabilities, don't do
		  anything except in end node

	- carsten bormann
		- counter-argument is that much depends on the mobile node
		  actually moving, so the characterization of an interface
		  changes as the mobile node moves; not clear that you want
		  to involve correspondent node architecturally
		- can you put this into one domain and without changing the
		  correspondent node?  from protocol point of view, ha seems
		  like a good choice
		- i think there are good arguments for considering
		  mobility aspects

	- james kempf
		- there are other possibilties in transport area for instance
		- point is that it's not wise to complicate the home agent by
		  putting this functionality in; it's not clear that you get
		  the necessary nformation at the ip layer to do this
		- one could consider another mechanism 	separate from mipv4

	- henrik levkowetz
		- some aspects are enticing, but feel that there are good
		  things but not sure it has "landed" completely yet

	- bof tonight

	- any more comments? (=> no)


-----------------------------

	- henrik levkowetz
		- agenda done, any more issues?

	- charlie perkins
		- loose question about the regional registration draft

	- henrik levkowetz
		- when mobile ip split to three groups, no-one took
		  the draft
		- merit to go forward?

	- charlie perkins
		- several people asked, several requests on the
		  mailing list

	- henrik levkowetz
		- true

	- charlie perkins
		- expectation was this would be published

	- thomas narten
		- should take this off-line, the document was
		  expired and appeared to be dead when documents
		  were divided

	- henrik levkowetz
		- we're done
-- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 20 00:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05502 for ; Thu, 20 Nov 2003 00:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhqJ-0006yp-CG for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 00:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK5x3KI026831 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 00:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhqJ-0006yK-6b for mip4-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 00:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05481 for ; Thu, 20 Nov 2003 00:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMhqH-00049H-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 00:59:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMhqG-00049E-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 00:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhqH-0006xe-I2; Thu, 20 Nov 2003 00:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhpW-0006wv-Fx for mip4@optimus.ietf.org; Thu, 20 Nov 2003 00:58:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05466; Thu, 20 Nov 2003 00:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMhpU-00048l-00; Thu, 20 Nov 2003 00:58:12 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AMhpU-00047j-00; Thu, 20 Nov 2003 00:58:12 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 00:57:36 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042011@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pete McCann'" Cc: "'Henrik Levkowetz'" , mip4@ietf.org, mip6@ietf.org Subject: RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Date: Thu, 20 Nov 2003 00:57:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > > => That used to be in the draft for the HA BUs but was removed > > because it was difficult to achieve from a security > > point of view. I'm not sure that this is cleaner than > > just adding the flow movement extensions. Also another > > use of those extensions (that I didn't want to bring up > > yet) is for optimising the handover smoothing for different > > flows (buffer to eliminate packet loss Vs forward to eliminate > > delays). > > Sure, but I think you could do that with multiple home addresses too. => See below. > > > => There is definitely no need to build mobility into the > > application protocol, I didn't suggest that. Having SIP > > advertise an address does not fix the problem when you > > want to move that connection from one interface to another > > as I explained in a previous email. The only way to do that > > today is to terminate the connection and restart it. I > > don't imagine that we'd want to do that. > > No, you wouldn't need to do that, assuming each application was using > its own home address. Each application flow could be moved > completely > independently, based on application needs and interface availability. > You just send a registration request binding the home address to the > right CoA. => I know you can do it with multiple HoAs but I think it's too "expensive" in terms of signalling over the air, especially during a handover. I think one BU/RREQ is about as much as you can send during handover, that is if MIP is being used to manage mobility. > Also, we need to understand whether commercial > production mobiles will want to include the necessary APIs for people > to build these kinds of adaptive applications, => I wouldn't hold my breath about getting companies to tell us about these sorts of plans, but if it works then great... Hesham -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 20 11:09:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10989 for ; Thu, 20 Nov 2003 11:09:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrMc-0004cf-M0 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 11:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKG92fd017765 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 11:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrMc-0004ba-EM for mip4-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10983 for ; Thu, 20 Nov 2003 11:08:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrMZ-0005Fe-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:08:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrMZ-0005Fb-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrMb-0004bG-8M; Thu, 20 Nov 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrMX-0004b4-5r for mip4@optimus.ietf.org; Thu, 20 Nov 2003 11:08:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10980 for ; Thu, 20 Nov 2003 11:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrMU-0005FY-00 for mip4@ietf.org; Thu, 20 Nov 2003 11:08:54 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AMrMU-0005F8-00 for mip4@ietf.org; Thu, 20 Nov 2003 11:08:54 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAKG8HE10151; Thu, 20 Nov 2003 10:08:18 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAKG8GG03338; Thu, 20 Nov 2003 10:08:17 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HONRHO-0000F4-00; Thu, 20 Nov 2003 11:08:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16316.59116.492515.842455@gargle.gargle.HOWL> Date: Thu, 20 Nov 2003 10:08:12 -0600 From: Pete McCann To: "Karim El-Malki (HF/EAB)" Cc: mip4@ietf.org, "'Basavaraj.Patil@nokia.com'" Subject: RE: [Mip4] Draft minutes from IETF58 In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639938@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639938@ESEALNT442.al.sw.ericsson.se> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Karim, By "writeup" we mean the one that must be done by the chairs prior to submission to the IESG. This writeup needs to document the process followed by the draft so far and should note any difficult or problem issues with the draft. As far as I know this has not been done for the lowlatency draft. We will be taking care of it soon, hopefully within a couple of weeks. -Pete Karim El-Malki (HF/EAB) writes: > Hi > > A comment on the minutes: > > > draft-ietf-mobileip-lowlatency-handoffs-07 > > - waiting for writeup, then to iesg > > The draft was resubmitted before IETF (since for some > reason it disappeared from the archives): > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-07.txt > So the writeup was out and should have been sent off > to IESG already. Raj has it been sent to IESG? > > /Karim -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Nov 20 11:15:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11258 for ; Thu, 20 Nov 2003 11:15:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrSS-0005BG-Qn for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 11:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGF44W019878 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 11:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrSS-0005AN-5n for mip4-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:15:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11228 for ; Thu, 20 Nov 2003 11:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrSR-0005Kc-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:15:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrSQ-0005KZ-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrSQ-00059u-VC; Thu, 20 Nov 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrS3-00058u-9Y for mip4@optimus.ietf.org; Thu, 20 Nov 2003 11:14:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11217 for ; Thu, 20 Nov 2003 11:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrS2-0005KH-00 for mip4@ietf.org; Thu, 20 Nov 2003 11:14:38 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AMrS1-0005Jn-00 for mip4@ietf.org; Thu, 20 Nov 2003 11:14:37 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAKGDtEY032533; Thu, 20 Nov 2003 17:13:55 +0100 Date: Thu, 20 Nov 2003 17:13:54 +0100 From: Henrik Levkowetz To: "Karim El-Malki (HF/EAB)" Cc: "'Pete McCann'" , mip4@ietf.org, "'Basavaraj.Patil@nokia.com'" Subject: Re: [Mip4] Draft minutes from IETF58 Message-Id: <20031120171354.1c2438bd.henrik@levkowetz.com> In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5639938@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F5639938@ESEALNT442.al.sw.ericsson.se> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__20_Nov_2003_17_13_54_+0100_rAiTVH2_fPBqQBhE" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Thu__20_Nov_2003_17_13_54_+0100_rAiTVH2_fPBqQBhE Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thursday, 20 Nov 2003, Karim wrote: > A comment on the minutes: > > > draft-ietf-mobileip-lowlatency-handoffs-07 > > - waiting for writeup, then to iesg > > The draft was resubmitted before IETF (since for some > reason it disappeared from the archives): > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-07.txt > So the writeup was out and should have been sent off > to IESG already. Raj has it been sent to IESG? Karim, the writeup referred to is the writeup that the chairs are now required to do on the draft, not the draft itself. So there is still one step (for the chairs) to complete before sending the document to the IESG. Pete and myself will try to get this done soon. Regards, Henrik --Signature=_Thu__20_Nov_2003_17_13_54_+0100_rAiTVH2_fPBqQBhE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vOhCeVhrtTJkXCMRAiy2AJ9iuGet1DQwTdB8V/+S5Pbumb++AwCfSFFT BjJOdIu7f7UH6W+NG8rU+Ig= =BRct -----END PGP SIGNATURE----- --Signature=_Thu__20_Nov_2003_17_13_54_+0100_rAiTVH2_fPBqQBhE-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 04:11:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06338 for ; Fri, 21 Nov 2003 04:11:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7JN-0000Kr-NB for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 04:10:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9AjY8001285 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 04:10:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7JN-0000Ke-0f for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 04:10:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06295 for ; Fri, 21 Nov 2003 04:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7JK-0006fE-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 04:10:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN7JJ-0006ew-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 04:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7Ig-0000Fr-Ec; Fri, 21 Nov 2003 04:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7I0-0000CK-HX for mip4@optimus.ietf.org; Fri, 21 Nov 2003 04:09:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06285 for ; Fri, 21 Nov 2003 04:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7Hx-0006eh-00 for mip4@ietf.org; Fri, 21 Nov 2003 04:09:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AN7Hw-0006ee-00 for mip4@ietf.org; Fri, 21 Nov 2003 04:09:16 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAL99Fe9020218 for ; Fri, 21 Nov 2003 18:09:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAL99FXG002853 for ; Fri, 21 Nov 2003 18:09:15 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id UAA02852 ; Fri, 21 Nov 2003 18:09:15 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id SAA17628; Fri, 21 Nov 2003 18:09:14 +0900 (JST) Received: by toshiba.co.jp id SAA16828; Fri, 21 Nov 2003 18:09:14 +0900 (JST) Message-Id: <200311210909.SAA16828@toshiba.co.jp> Date: Fri, 21 Nov 2003 00:09:13 -0800 From: Yoshiyuki Tsuda To: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hello, the authors and all, I've found there are two more possible scenarios where an assigned HA can initiate a redirection of a binding to another HA between registrations. That is: Scenario-A) If there is a group of HAs, an assigned HA will be anchored at the 1st registration. But, due to load balance or so on, the assigned HA may want to redirect a specific binding to another HA in the meantime of registrations by sending a registration reply with - the error code of REDIRECT-HA-REQ and - Redirected HA address extension. After receiving the above registration reply, an MN can send a registration request to the redirected HA. Scenrio-B) If there are an active HA and a standby HA, and if the active HA fails, the standby HA can take over the role by sending registration replies, like the above, to all binding MNs. Are the above scenarios acceptable ? Thanks in advance. -Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 06:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10618 for ; Fri, 21 Nov 2003 06:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9ii-0001Vf-FV for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 06:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALBj4pc005799 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 06:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9ii-0001VS-8H for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 06:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10611 for ; Fri, 21 Nov 2003 06:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9ie-0000wm-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 06:45:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN9id-0000wj-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 06:44:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9ig-0001Uz-5q; Fri, 21 Nov 2003 06:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9i6-0001Sc-Qb for mip4@optimus.ietf.org; Fri, 21 Nov 2003 06:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10598 for ; Fri, 21 Nov 2003 06:44:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9i2-0000wP-00 for mip4@ietf.org; Fri, 21 Nov 2003 06:44:22 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AN9i2-0000wM-00 for mip4@ietf.org; Fri, 21 Nov 2003 06:44:22 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AN9i0-0000II-00; Fri, 21 Nov 2003 12:44:20 +0100 Date: Fri, 21 Nov 2003 12:44:12 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031121124412.35c9edcd.henrik@levkowetz.com> In-Reply-To: <200311210909.SAA16828@toshiba.co.jp> References: <200311210909.SAA16828@toshiba.co.jp> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yoshi, > I've found there are two more possible scenarios where an > assigned HA can initiate a redirection of a binding to another > HA between registrations. That is: > > Scenario-A) If there is a group of HAs, an assigned HA will > be anchored at the 1st registration. But, due to load balance or > so on, the assigned HA may want to redirect a specific binding > to another HA in the meantime of registrations by sending a > registration reply with > - the error code of REDIRECT-HA-REQ and > - Redirected HA address extension. > After receiving the above registration reply, an MN can send > a registration request to the redirected HA. This scenario seems to me a straightforward application of the dynamic HA-assignment draft. > Scenrio-B) If there are an active HA and a standby HA, and if > the active HA fails, the standby HA can take over the role by > sending registration replies, like the above, to all binding MNs. This scenario would _not_ (if I understand you correctly) be handled by the mechanism in the HA-assignment draft, but is exactly one of the scenarios which would be handled by an upcoming HA-re-assignment draft I'm writing. Best regards, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 10:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19008 for ; Fri, 21 Nov 2003 10:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDgV-0007a4-7b for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 10:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFx3TU029140 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 10:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDgV-0007Zv-4N for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 10:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18983 for ; Fri, 21 Nov 2003 10:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDgS-00048A-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 10:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANDgS-000486-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 10:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDgT-0007Zb-C7; Fri, 21 Nov 2003 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDg4-0007ZI-A4 for mip4@optimus.ietf.org; Fri, 21 Nov 2003 10:58:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18974 for ; Fri, 21 Nov 2003 10:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDg1-00047z-00 for mip4@ietf.org; Fri, 21 Nov 2003 10:58:33 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=shiraz) by ietf-mx with esmtp (Exim 4.12) id 1ANDg1-00047v-00 for mip4@ietf.org; Fri, 21 Nov 2003 10:58:33 -0500 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz ident=www-data) by shiraz with esmtp (Exim 3.35 #1 (Debian)) id 1ANDg0-0001AD-00 for ; Fri, 21 Nov 2003 16:58:32 +0100 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: Henrik Levkowetz Reply-To: Mip4 issue tracker Date: Fri, 21 Nov 2003 15:58:29 +0000 MIME-Version: 1.0 Message-Id: <1069430308.63.0.88486324312.issue25@levkowetz.com> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue25] AAA-NAI extension sub-types for non-AAA NAIs Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This has been entered in the issue tracker as issue 25. owner: Henrik Levkowetz : category: Technical draft: draft-ietf-mobileip-aaa-nai priority: Should fix status: No discussion title: AAA-NAI extension sub-types for non-AAA NAIs The draft-ietf-mip4-aaa-nai-00.txt has been submitted to, and discussed by, the IESG, which had a few comments. These comments should be handled in the intermediate draft version -01.a available here: http://www.mip4.org/drafts/aaa-nai/ One comment has also been made on the list on this draft, which is that it would be better to define a generalized NAI extension, rather than this AAA nai extension. In view of how far the draft has advanced, and the fact that the AAA NAI extension is referred to in the diameter mip4 application draft (draft-ietf-aaa-diameter-mobileip-15.txt), so any larger delay are rather bad, I propose to resolve this issue as follows: Add to IANA Considerations section: The content and format for this extension is not specific to AAA NAIs, so if in the future new NAIs are defined which does not strictly fall=20 within the category of AAA NAIs, they may nevertheless be accomodated=20 within the subtype numbering space defined for the AAA NAI Extension=20 defined in this document. _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 11:23:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19920 for ; Fri, 21 Nov 2003 11:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE3n-0000Qj-AF for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 11:23:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGN7s2001652 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 11:23:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE3n-0000QZ-6Q for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 11:23:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19906 for ; Fri, 21 Nov 2003 11:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE3m-0004Qa-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 11:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANE3l-0004QX-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 11:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE3g-0000OP-K1; Fri, 21 Nov 2003 11:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE2s-0000KP-K5 for mip4@optimus.ietf.org; Fri, 21 Nov 2003 11:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19860 for ; Fri, 21 Nov 2003 11:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE2r-0004Q2-00 for mip4@ietf.org; Fri, 21 Nov 2003 11:22:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ANE2r-0004Pa-00 for mip4@ietf.org; Fri, 21 Nov 2003 11:22:09 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2003 08:21:59 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALGLaAt025426; Fri, 21 Nov 2003 08:21:36 -0800 (PST) Received: from cisco.com (sjc-vpn3-1065.cisco.com [10.21.68.41]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANU63914; Fri, 21 Nov 2003 08:21:35 -0800 (PST) Message-ID: <3FBE3B8F.7010400@cisco.com> Date: Fri, 21 Nov 2003 08:21:35 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mip4 issue tracker CC: mip4@ietf.org Subject: Re: [Mip4] [issue25] AAA-NAI extension sub-types for non-AAA NAIs References: <1069430308.63.0.88486324312.issue25@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik - I agree that we want to keep it extensible. I am okay with the statement that other types of NAI can be defined in the sub-type field in future. -a Henrik Levkowetz wrote: >This has been entered in the issue tracker as issue 25. > >owner: Henrik Levkowetz : > >category: Technical >draft: draft-ietf-mobileip-aaa-nai >priority: Should fix >status: No discussion >title: AAA-NAI extension sub-types for non-AAA NAIs > >The draft-ietf-mip4-aaa-nai-00.txt has been submitted to, and >discussed by, the IESG, which had a few comments. These comments should >be handled in the intermediate draft version -01.a available here: > > http://www.mip4.org/drafts/aaa-nai/ > >One comment has also been made on the list on this draft, which is >that it would be better to define a generalized NAI extension, rather >than this AAA nai extension. > >In view of how far the draft has advanced, and the fact that the AAA >NAI extension is referred to in the diameter mip4 application draft >(draft-ietf-aaa-diameter-mobileip-15.txt), so any larger delay are >rather bad, I propose to resolve this issue as follows: > > >Add to IANA Considerations section: > > The content and format for this extension is not specific to AAA NAIs, > so if in the future new NAIs are defined which does not strictly fall > within the category of AAA NAIs, they may nevertheless be accomodated > within the subtype numbering space defined for the AAA NAI Extension > defined in this document. >_________________________________________________ >Mip4 issue tracker > >_________________________________________________ > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 11:47:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20940 for ; Fri, 21 Nov 2003 11:47:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEQx-0002IC-Eh for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 11:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGl3hX008806 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 11:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEQx-0002Hr-6k for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 11:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20907 for ; Fri, 21 Nov 2003 11:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEQv-0004nt-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 11:47:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANEQv-0004nn-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 11:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEQv-0002HM-K6; Fri, 21 Nov 2003 11:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEQO-0002F8-NR for mip4@optimus.ietf.org; Fri, 21 Nov 2003 11:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20835 for ; Fri, 21 Nov 2003 11:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEQN-0004n0-00 for mip4@ietf.org; Fri, 21 Nov 2003 11:46:27 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANEQM-0004kc-00 for mip4@ietf.org; Fri, 21 Nov 2003 11:46:26 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALGjqE24699; Fri, 21 Nov 2003 10:45:52 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hALGjo606125; Fri, 21 Nov 2003 10:45:50 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOPNW6-0000H8-00; Fri, 21 Nov 2003 11:45:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16318.16695.11515.403051@gargle.gargle.HOWL> Date: Fri, 21 Nov 2003 10:45:43 -0600 From: Pete McCann To: mip4@ietf.org, aaa-wg@merit.edu X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] [Issue] Name for the nonces in aaa-keys and diameter-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, During my presentation of the Diameter Mobile IPv4 application to the AAA working group, an item came up around the use of the term "Key Material" in the Diameter Mobile IPv4 application and the Mobile IP aaa-key draft. It was noted that the term "Key Material" usually denotes stuff that should be kept secret, whereas the "Key Material" sent in a Registration Reply are actually nonces intended to be used by the MN to derive session keys. They will be visible to third parties while in transit. To resolve this, I suggest that we change all instances of "Key Material" in both of these drafts to something more descriptive, like "Nonce for Key Generation" or just "Nonce" when the context is clear. Is that acceptable to everyone? Hopefully we can make this change quickly and get both drafts ready for IESG submission. Thanks, -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 12:23:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23288 for ; Fri, 21 Nov 2003 12:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEzm-0005xT-Ji for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 12:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHN2YN022897 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 12:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEzm-0005xE-Bu for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23272 for ; Fri, 21 Nov 2003 12:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEzk-0005fN-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 12:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANEzk-0005fK-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 12:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEzl-0005ws-0H; Fri, 21 Nov 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEeT-0003od-2L for mip4@optimus.ietf.org; Fri, 21 Nov 2003 12:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22311 for ; Fri, 21 Nov 2003 12:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEeR-0005Fp-00 for mip4@ietf.org; Fri, 21 Nov 2003 12:00:59 -0500 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1ANEeP-0005Fm-00 for mip4@ietf.org; Fri, 21 Nov 2003 12:00:59 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hALHJ5n10424; Fri, 21 Nov 2003 09:19:05 -0800 Date: Fri, 21 Nov 2003 09:19:05 -0800 (PST) From: Bernard Aboba To: Pete McCann cc: mip4@ietf.org, aaa-wg@merit.edu In-Reply-To: <16318.16695.11515.403051@gargle.gargle.HOWL> Message-ID: References: <16318.16695.11515.403051@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] Re: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diameter-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This change is ok with me as long as the term "Nonce" refers to a non-secret quantity. It would appears to me that at least some of the quantities referred to as "Key Material" in the Diameter MIPv4 draft are in fact secret. Also, I'd prefer to use the term "Session Key" for an ephemeral key that is refreshed by a nonce, and "Pre-shared key" for a quantity that is a long-term secret (such as that shared between the MN and HA). Getting the terminology straight is probably half the battle in getting these drafts completed. On Fri, 21 Nov 2003, Pete McCann wrote: > > Hi, > > During my presentation of the Diameter Mobile IPv4 application to the > AAA working group, an item came up around the use of the term "Key > Material" in the Diameter Mobile IPv4 application and the Mobile IP > aaa-key draft. It was noted that the term "Key Material" usually > denotes stuff that should be kept secret, whereas the "Key Material" > sent in a Registration Reply are actually nonces intended to be used > by the MN to derive session keys. They will be visible to third > parties while in transit. > > To resolve this, I suggest that we change all instances of "Key > Material" in both of these drafts to something more descriptive, > like "Nonce for Key Generation" or just "Nonce" when the context is > clear. > > Is that acceptable to everyone? Hopefully we can make this change > quickly and get both drafts ready for IESG submission. > > Thanks, > > -Pete > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 12:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24056 for ; Fri, 21 Nov 2003 12:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFL6-0007T9-8F for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 12:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHj4oE028705 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 12:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFL6-0007Su-34 for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24040 for ; Fri, 21 Nov 2003 12:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFL4-0005xp-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 12:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANFL4-0005xm-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 12:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFL5-0007SZ-1L; Fri, 21 Nov 2003 12:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFKS-0007QD-0q for mip4@optimus.ietf.org; Fri, 21 Nov 2003 12:44:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24010 for ; Fri, 21 Nov 2003 12:44:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFKQ-0005wq-00 for mip4@ietf.org; Fri, 21 Nov 2003 12:44:22 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=shiraz) by ietf-mx with esmtp (Exim 4.12) id 1ANFKP-0005wn-00 for mip4@ietf.org; Fri, 21 Nov 2003 12:44:21 -0500 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz ident=www-data) by shiraz with esmtp (Exim 3.35 #1 (Debian)) id 1ANFKM-0002tr-00; Fri, 21 Nov 2003 18:44:18 +0100 Content-Type: text/plain; charset=utf-8 To: henrik@levkowetz.com, mip4@ietf.org From: admin Reply-To: Mip4 issue tracker Date: Fri, 21 Nov 2003 17:44:15 +0000 MIME-Version: 1.0 Message-Id: <1069436655.91.0.138375748764.issue25@levkowetz.com> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue25] AAA-NAI extension sub-types for non-AAA NAIs Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This comment from admin has been added to iss= ue 25: draft: draft-ietf-mobileip-aaa-nai -> draft-ietf-mobileip-aaa-nai From Thomas Narten: Sounds good. Other possible improvements: Update title to something more like: OLD: Mobile IPv4 Extension for AAA Network Access Identifiers New: Mobile IPv4 Extension for carrying Network Access Identifiers (i.e., remove AAA part). =20 In section 3, take out all references to AAA, and just make it a generic option. Sections 4-5 can be the AAA specific stuff. Then, make the IANA considerations more generic, as you suggest. Maybe double check that the abstract/intro don't need tweaking a bit. Just looking at the abstract, it seems OK. _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 13:45:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26318 for ; Fri, 21 Nov 2003 13:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGHA-0003bU-Bz for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 13:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIj43H013846 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGHA-0003bF-7M for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 13:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26310 for ; Fri, 21 Nov 2003 13:44:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGH7-0006rw-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 13:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANGH7-0006rs-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 13:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGH7-0003Zz-Or; Fri, 21 Nov 2003 13:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGGU-0003ZN-BY for mip4@optimus.ietf.org; Fri, 21 Nov 2003 13:44:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26288 for ; Fri, 21 Nov 2003 13:44:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGGS-0006rc-00 for mip4@ietf.org; Fri, 21 Nov 2003 13:44:20 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANGGR-0006r1-00 for mip4@ietf.org; Fri, 21 Nov 2003 13:44:19 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALIhIo23084; Fri, 21 Nov 2003 12:43:22 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hALIhH618823; Fri, 21 Nov 2003 12:43:18 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOPTBV-0001S4-00; Fri, 21 Nov 2003 13:43:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16318.23735.685515.762980@gargle.gargle.HOWL> Date: Fri, 21 Nov 2003 12:43:03 -0600 From: Pete McCann To: Bernard Aboba Cc: mip4@ietf.org, aaa-wg@merit.edu In-Reply-To: References: <16318.16695.11515.403051@gargle.gargle.HOWL> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diameter-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Bernard, Ok, let's make sure to check the context in each case. Also, please note that the only long-term secret required is the one shared between MN and AAAH. The Diameter-MIP4 application can dynamically distribute the MN-HA session key (and the nonce that was used to generated it) to the HA. You are of course allowed to have a long-term secret between the MN and HA as part of a manually (or otherwise) configured mobility security association, but it isn't required. -Pete Bernard Aboba writes: > This change is ok with me as long as the term "Nonce" refers to a > non-secret quantity. It would appears to me that at least some of the > quantities referred to as "Key Material" in the Diameter MIPv4 draft are > in fact secret. > > Also, I'd prefer to use the term "Session Key" for an ephemeral key that > is refreshed by a nonce, and "Pre-shared key" for a quantity that is a > long-term secret (such as that shared between the MN and HA). > > Getting the terminology straight is probably half the battle in getting > these drafts completed. > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > Hi, > > > > During my presentation of the Diameter Mobile IPv4 application to the > > AAA working group, an item came up around the use of the term "Key > > Material" in the Diameter Mobile IPv4 application and the Mobile IP > > aaa-key draft. It was noted that the term "Key Material" usually > > denotes stuff that should be kept secret, whereas the "Key Material" > > sent in a Registration Reply are actually nonces intended to be used > > by the MN to derive session keys. They will be visible to third > > parties while in transit. > > > > To resolve this, I suggest that we change all instances of "Key > > Material" in both of these drafts to something more descriptive, > > like "Nonce for Key Generation" or just "Nonce" when the context is > > clear. > > > > Is that acceptable to everyone? Hopefully we can make this change > > quickly and get both drafts ready for IESG submission. > > > > Thanks, > > > > -Pete > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 14:03:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26930 for ; Fri, 21 Nov 2003 14:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGYX-0004Y1-Ju for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 14:03:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJ31J4017481 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGYX-0004Xs-GH for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 14:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26909 for ; Fri, 21 Nov 2003 14:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGYV-00078F-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 14:02:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANGYU-00078C-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 14:02:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGYW-0004X9-Iw; Fri, 21 Nov 2003 14:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGXy-0004Wk-KQ for mip4@optimus.ietf.org; Fri, 21 Nov 2003 14:02:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26883 for ; Fri, 21 Nov 2003 14:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGXw-00077y-00 for mip4@ietf.org; Fri, 21 Nov 2003 14:02:24 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ANGXv-00077W-00 for mip4@ietf.org; Fri, 21 Nov 2003 14:02:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 11:02:28 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hALJ1pjq018050; Fri, 21 Nov 2003 11:01:51 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALR57939; Fri, 21 Nov 2003 11:01:51 -0800 (PST) Message-ID: <3FBE611F.1000400@cisco.com> Date: Fri, 21 Nov 2003 11:01:51 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshiyuki Tsuda CC: mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 References: <200311210909.SAA16828@toshiba.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yoshi, Please see below... Yoshiyuki Tsuda wrote: > Hello, the authors and all, > > I've found there are two more possible scenarios where an > assigned HA can initiate a redirection of a binding to another > HA between registrations. That is: > > Scenario-A) If there is a group of HAs, an assigned HA will > be anchored at the 1st registration. But, due to load balance or > so on, the assigned HA may want to redirect a specific binding > to another HA in the meantime of registrations by sending a > registration reply with > - the error code of REDIRECT-HA-REQ and > - Redirected HA address extension. > After receiving the above registration reply, an MN can send > a registration request to the redirected HA. If this is initial registration request, then the draft takes care of this exactly as pointed by Henrik. If you mean transferring the bindings in the middle of the session, it is a different problem and hence out of scope of the draft. > > Scenrio-B) If there are an active HA and a standby HA, and if > the active HA fails, the standby HA can take over the role by > sending registration replies, like the above, to all binding MNs. I assume there is 1:1 HA redundancy. In such case the standby HA will take over, without Mobile IP getting involved. The redundancy protocol should transparently handle switchovers without Dynamic HA assignment getting involved. Milind > > Are the above scenarios acceptable ? > > Thanks in advance. > -Yoshi > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 17:13:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07089 for ; Fri, 21 Nov 2003 17:13:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWS-0000lA-Bm for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMD4At002919 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWS-0000l0-6K for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07037 for ; Fri, 21 Nov 2003 17:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJWP-0002Qn-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJWP-0002Qi-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWQ-0000jn-KI; Fri, 21 Nov 2003 17:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWA-0000hm-0x for mip4@optimus.ietf.org; Fri, 21 Nov 2003 17:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07023 for ; Fri, 21 Nov 2003 17:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJW7-0002QP-00 for mip4@ietf.org; Fri, 21 Nov 2003 17:12:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ANJW6-0002QM-00 for mip4@ietf.org; Fri, 21 Nov 2003 17:12:43 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hALMCBe9014817; Sat, 22 Nov 2003 07:12:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hALMCBkn007280; Sat, 22 Nov 2003 07:12:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA07276 ; Sat, 22 Nov 2003 07:12:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09621; Sat, 22 Nov 2003 07:12:10 +0900 (JST) Received: by toshiba.co.jp id HAA24312; Sat, 22 Nov 2003 07:12:09 +0900 (JST) Message-Id: <200311212212.HAA24312@toshiba.co.jp> Date: Fri, 21 Nov 2003 13:12:09 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 To: Milind Kulkarni Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <3FBE611F.1000400@cisco.com> References: <200311210909.SAA16828@toshiba.co.jp> <3FBE611F.1000400@cisco.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , at Fri, 21 Nov 2003 11:01:51 -0800 Milind Kulkarni wrote: >Yoshi, > >Please see below... > >Yoshiyuki Tsuda wrote: >> Hello, the authors and all, >> >> I've found there are two more possible scenarios where an >> assigned HA can initiate a redirection of a binding to another >> HA between registrations. That is: >> >> Scenario-A) If there is a group of HAs, an assigned HA will >> be anchored at the 1st registration. But, due to load balance or >> so on, the assigned HA may want to redirect a specific binding >> to another HA in the meantime of registrations by sending a >> registration reply with >> - the error code of REDIRECT-HA-REQ and >> - Redirected HA address extension. >> After receiving the above registration reply, an MN can send >> a registration request to the redirected HA. > >If this is initial registration request, then the draft takes >care of this exactly as pointed by Henrik. > >If you mean transferring the bindings in the middle of >the session, it is a different problem and hence out of scope >of the draft. OK. I understood it was out of scope. I think, the only problem about my scenario is a binding termination by an HA in the middle of session. Are there any other problems in such a scenario ? >> Scenrio-B) If there are an active HA and a standby HA, and if >> the active HA fails, the standby HA can take over the role by >> sending registration replies, like the above, to all binding MNs. > >I assume there is 1:1 HA redundancy. In such case the standby >HA will take over, without Mobile IP getting involved. The >redundancy protocol should transparently handle switchovers >without Dynamic HA assignment getting involved. OK. This scenario is also out of scope. I'd like to wait for Henrik's coming I-D, and discuss there. Thank you. -Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Nov 21 17:13:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07120 for ; Fri, 21 Nov 2003 17:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWV-0000mj-GX for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMD78d003008 for mip4-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWS-0000kz-61 for mip4-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07038 for ; Fri, 21 Nov 2003 17:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJWP-0002Qp-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJWP-0002Qj-00 for mip4-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJWP-0000j8-HL; Fri, 21 Nov 2003 17:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJVa-0000gt-90 for mip4@optimus.ietf.org; Fri, 21 Nov 2003 17:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06997 for ; Fri, 21 Nov 2003 17:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJVX-0002Pa-00 for mip4@ietf.org; Fri, 21 Nov 2003 17:12:08 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ANJVW-0002PX-00 for mip4@ietf.org; Fri, 21 Nov 2003 17:12:07 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hALMBwe9014771; Sat, 22 Nov 2003 07:11:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hALMBwGm007259; Sat, 22 Nov 2003 07:11:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA07258 ; Sat, 22 Nov 2003 07:11:58 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09559; Sat, 22 Nov 2003 07:11:57 +0900 (JST) Received: by toshiba.co.jp id HAA24136; Sat, 22 Nov 2003 07:11:57 +0900 (JST) Message-Id: <200311212211.HAA24136@toshiba.co.jp> Date: Fri, 21 Nov 2003 13:11:57 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 To: Henrik Levkowetz Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20031121124412.35c9edcd.henrik@levkowetz.com> References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Henrik, Thank you for your email. My comments are inlined: at Fri, 21 Nov 2003 12:44:12 +0100 Henrik Levkowetz wrote: >Hi Yoshi, > >> I've found there are two more possible scenarios where an >> assigned HA can initiate a redirection of a binding to another >> HA between registrations. That is: >> >> Scenario-A) If there is a group of HAs, an assigned HA will >> be anchored at the 1st registration. But, due to load balance or >> so on, the assigned HA may want to redirect a specific binding >> to another HA in the meantime of registrations by sending a >> registration reply with >> - the error code of REDIRECT-HA-REQ and >> - Redirected HA address extension. >> After receiving the above registration reply, an MN can send >> a registration request to the redirected HA. > >This scenario seems to me a straightforward application of the >dynamic HA-assignment draft. Which do you assume "at the 1st registration" or "in the middle of session" ? If you assumed at the 1st registration, I agree this scenario is a straightforward application. But, I meant in the middle of session. As Milind pointed out in his email, it seems to be out of scope of the current dynamic HA I-D. I think, the only problem of this scenario is a binding termination in the middle of session by HA, although I believe it is acceptable to an MN. >> Scenrio-B) If there are an active HA and a standby HA, and if >> the active HA fails, the standby HA can take over the role by >> sending registration replies, like the above, to all binding MNs. > >This scenario would _not_ (if I understand you correctly) be >handled by the mechanism in the HA-assignment draft, but is exactly >one of the scenarios which would be handled by an upcoming HA-re-assignment >draft I'm writing. OK. I'm looking forward to seeing your new I-D. :) Have a nice weekend! Best regards. -Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 22 00:32:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20921 for ; Sat, 22 Nov 2003 00:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANQNH-0002Qw-Un for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 00:32:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM5W3Dp009350 for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 00:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANQNH-0002Qj-Fz for mip4-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 00:32:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20888 for ; Sat, 22 Nov 2003 00:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANQNE-0000Mm-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 00:32:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANQNE-0000Mj-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 00:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANQNF-0002QN-8Y; Sat, 22 Nov 2003 00:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANQMu-0002Q1-U3 for mip4@optimus.ietf.org; Sat, 22 Nov 2003 00:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20864 for ; Sat, 22 Nov 2003 00:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANQMr-0000M8-00 for mip4@ietf.org; Sat, 22 Nov 2003 00:31:37 -0500 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1ANQMr-0000M5-00 for mip4@ietf.org; Sat, 22 Nov 2003 00:31:37 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAM5pNW21307; Fri, 21 Nov 2003 21:51:23 -0800 Date: Fri, 21 Nov 2003 21:51:23 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: "'Pete McCann'" , mip4@ietf.org, aaa-wg@merit.edu In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , > In the AAA Keys for Mobile IPv4 draft it is defined as such: > > Key Material Data (e.g., a nonce) used for the purpose of > creating a key. > In the section for Key Material Creation and Derivation it state that the > 'Key Material' is a random value. Typically the term "Key Material" is used to refer to something from which a Session Key is derived. Both the Keying Material and the Session Key are secrets. Is that the case here? > Does that random value have to be different from previous choices inserted > in a message to protect against replays? If replay protection is desired, a counter or other monotonic value will generally do the job. But "freshness" can be provided a nonce. They aren't necessarily the same thing (e.g. assuring that a nonce isn't replayed requires a large cache, while assuring against replay of a counter is easy). kk -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 22 07:40:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10351 for ; Sat, 22 Nov 2003 07:40:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANX3W-0007bO-1J for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 07:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMCe53X029218 for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 07:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANX3V-0007b3-5U for mip4-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 07:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10344 for ; Sat, 22 Nov 2003 07:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANX3U-0004IV-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 07:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANX3U-0004IS-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 07:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANX3S-0007af-Iw; Sat, 22 Nov 2003 07:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANX36-0007a3-Iv for mip4@optimus.ietf.org; Sat, 22 Nov 2003 07:39:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10337 for ; Sat, 22 Nov 2003 07:39:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANX35-0004IL-00 for mip4@ietf.org; Sat, 22 Nov 2003 07:39:39 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ANX35-0004II-00 for mip4@ietf.org; Sat, 22 Nov 2003 07:39:39 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ANX31-0000BL-00; Sat, 22 Nov 2003 13:39:35 +0100 Date: Sat, 22 Nov 2003 13:39:18 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031122133918.781f2fa0.henrik@levkowetz.com> In-Reply-To: <200311212211.HAA24136@toshiba.co.jp> References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> <200311212211.HAA24136@toshiba.co.jp> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sat__22_Nov_2003_13_39_18_+0100_Lp6StCVALuMnOZg3" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Sat__22_Nov_2003_13_39_18_+0100_Lp6StCVALuMnOZg3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Friday 21 November 2003, Yoshiyuki wrote: > >> Scenario-A) If there is a group of HAs, an assigned HA will > >> be anchored at the 1st registration. But, due to load balance or > >> so on, the assigned HA may want to redirect a specific binding > >> to another HA in the meantime of registrations by sending a > >> registration reply with > >> - the error code of REDIRECT-HA-REQ and > >> - Redirected HA address extension. > >> After receiving the above registration reply, an MN can send > >> a registration request to the redirected HA. > > > >This scenario seems to me a straightforward application of the > >dynamic HA-assignment draft. > > Which do you assume "at the 1st registration" or "in the middle of > session" ? I ment at the 1st registration. > If you assumed at the 1st registration, I agree this scenario is a > straightforward application. But, I meant in the middle of > session. As Milind pointed out in his email, it seems to be out > of scope of the current dynamic HA I-D. > > I think, the only > problem of this scenario is a binding termination in the middle > of session by HA, although I believe it is acceptable to an MN. Possibly this could be made to work. But there would have to be a bit more text in the draft to describe this scenario, then; additionally it seems to be a bit at odds with the base premise of this draft. We probably should think a bit about this, whether we should extend the dynamic HA assignment draft in this direction, or whether we should put it in the HA re-assignment draft. What do other folks think? Henrik --Signature=_Sat__22_Nov_2003_13_39_18_+0100_Lp6StCVALuMnOZg3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/v1j9eVhrtTJkXCMRAvXtAKD6JJjeb77CzT/xggK+J40N+Uim9ACZAVy/ 1+vw2sQvLSqOqajWrvjOC44= =HwUw -----END PGP SIGNATURE----- --Signature=_Sat__22_Nov_2003_13_39_18_+0100_Lp6StCVALuMnOZg3-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 22 07:56:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10602 for ; Sat, 22 Nov 2003 07:56:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXIw-0007p4-NN for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 07:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMCu2fF030064 for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 07:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXIw-0007op-Ho for mip4-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 07:56:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10599 for ; Sat, 22 Nov 2003 07:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANXIv-0004Qt-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 07:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANXIv-0004Qq-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 07:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXIv-0007oR-KK; Sat, 22 Nov 2003 07:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXIN-0007o0-HG for mip4@optimus.ietf.org; Sat, 22 Nov 2003 07:55:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10596 for ; Sat, 22 Nov 2003 07:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANXIM-0004Qm-00 for mip4@ietf.org; Sat, 22 Nov 2003 07:55:26 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ANXIM-0004Qj-00 for mip4@ietf.org; Sat, 22 Nov 2003 07:55:26 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ANXIF-0000C5-00; Sat, 22 Nov 2003 13:55:19 +0100 Date: Sat, 22 Nov 2003 13:55:11 +0100 From: Henrik Levkowetz To: Milind Kulkarni Cc: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031122135511.17c004e3.henrik@levkowetz.com> In-Reply-To: <3FBE611F.1000400@cisco.com> References: <200311210909.SAA16828@toshiba.co.jp> <3FBE611F.1000400@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Friday 21 November 2003, Milind wrote: > > > > Scenrio-B) If there are an active HA and a standby HA, and if > > the active HA fails, the standby HA can take over the role by > > sending registration replies, like the above, to all binding MNs. > > I assume there is 1:1 HA redundancy. In such case the standby > HA will take over, without Mobile IP getting involved. The > redundancy protocol should transparently handle switchovers > without Dynamic HA assignment getting involved. This assumes use of something like VRRP or CARP, with additional add-ons to take care of synchronization of MIP registrations between the 2 HA's. As VRRP isn't IPR free, this has been a bit of a problem to some HA providers. Now that CARP is becoming available, this way of handling it may become more interesting, though. Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Nov 22 16:07:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21772 for ; Sat, 22 Nov 2003 16:07:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANey7-0005va-U6 for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 16:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAML73Vt022780 for mip4-archive@odin.ietf.org; Sat, 22 Nov 2003 16:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANey7-0005vD-91 for mip4-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 16:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21735 for ; Sat, 22 Nov 2003 16:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANey5-0002Cv-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 16:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANey5-0002Cr-00 for mip4-web-archive@ietf.org; Sat, 22 Nov 2003 16:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANey5-0005u7-9I; Sat, 22 Nov 2003 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANOz7-0005nR-Rs for mip4@optimus.ietf.org; Fri, 21 Nov 2003 23:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18215 for ; Fri, 21 Nov 2003 23:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANOz4-0006uJ-00 for mip4@ietf.org; Fri, 21 Nov 2003 23:02:58 -0500 Received: from bws10.bridgewatersystems.com ([216.113.7.10] helo=exch01.bridgewatersys.com) by ietf-mx with esmtp (Exim 4.12) id 1ANOz3-0006tz-00 for mip4@ietf.org; Fri, 21 Nov 2003 23:02:57 -0500 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Nov 2003 23:02:28 -0500 Message-ID: From: Avi Lior To: "'Pete McCann'" , Bernard Aboba Cc: mip4@ietf.org, aaa-wg@merit.edu Date: Fri, 21 Nov 2003 23:02:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mip4] RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Pete, Bernard, If you look at RFC 3344 nonce is defined this way: A randomly chosen value, different from previous choices, inserted in a message to protect against replays. If this is a correct definition then the proposed usage is not consistant with the above definition, right? In the AAA Keys for Mobile IPv4 draft it is defined as such: Key Material Data (e.g., a nonce) used for the purpose of creating a key. That is it could be a nonce but it doesn't have to be. In the section for Key Material Creation and Derivation it state that the 'Key Material' is a random value. Does that random value have to be different from previous choices inserted in a message to protect against replays? BTW: If it does have to have propreties consistant with RFC 3344's definition of nonce, then I suggest that AAA Keys for Mobile IPv4 should be tightened. Just my 2cents worth. BTW I took a look around and I don't have a problem with Key Material here is a definition that is common: Keying Material The data (e.g., keys and IVs) necessary to establish and maintain cryptographic keying relationships. Avi > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: November 21, 2003 1:43 PM > To: Bernard Aboba > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [Issue] Name for the nonces in > aaa-keys and diameter-mip > > > > Hi, Bernard, > > Ok, let's make sure to check the context in each case. > > Also, please note that the only long-term secret required is > the one shared between MN and AAAH. The Diameter-MIP4 > application can dynamically distribute the MN-HA session key > (and the nonce that was used to generated it) to the HA. You > are of course allowed to have a long-term secret between the > MN and HA as part of a manually (or > otherwise) configured mobility security association, but it > isn't required. > > -Pete > > Bernard Aboba writes: > > This change is ok with me as long as the term "Nonce" > refers to a > non-secret quantity. It would appears to me > that at least some of the > quantities referred to as "Key > Material" in the Diameter MIPv4 draft are > in fact secret. > > > Also, I'd prefer to use the term "Session Key" for an > ephemeral key that > is refreshed by a nonce, and > "Pre-shared key" for a quantity that is a > long-term secret > (such as that shared between the MN and HA). > > > Getting the terminology straight is probably half the > battle in getting > these drafts completed. > > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > > > > Hi, > > > > > > During my presentation of the Diameter Mobile IPv4 > application to the > > AAA working group, an item came up > around the use of the term "Key > > Material" in the > Diameter Mobile IPv4 application and the Mobile IP > > > aaa-key draft. It was noted that the term "Key Material" > usually > > denotes stuff that should be kept secret, > whereas the "Key Material" > > sent in a Registration Reply > are actually nonces intended to be used > > by the MN to > derive session keys. They will be visible to third > > > parties while in transit. > > > > To resolve this, I > suggest that we change all instances of "Key > > Material" > in both of these drafts to something more descriptive, > > > like "Nonce for Key Generation" or just "Nonce" when the > context is > > clear. > > > > Is that acceptable to > everyone? Hopefully we can make this change > > quickly and > get both drafts ready for IESG submission. > > > > Thanks, > > > > > -Pete > > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 24 00:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13254 for ; Mon, 24 Nov 2003 00:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9hb-00070f-K0 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 00:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO5u3cw026944 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 00:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9hb-00070V-EZ for mip4-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 00:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13246 for ; Mon, 24 Nov 2003 00:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9hY-0006PX-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 00:56:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9hY-0006PT-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 00:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9hZ-00070B-NG; Mon, 24 Nov 2003 00:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9hG-0006zw-29 for mip4@optimus.ietf.org; Mon, 24 Nov 2003 00:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13225 for ; Mon, 24 Nov 2003 00:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9hD-0006PN-00 for mip4@ietf.org; Mon, 24 Nov 2003 00:55:39 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9hC-0006Ox-00 for mip4@ietf.org; Mon, 24 Nov 2003 00:55:38 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAO5spj18145; Sun, 23 Nov 2003 23:55:34 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAO5osd06848; Sun, 23 Nov 2003 23:50:54 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOUDKL-00011S-00; Mon, 24 Nov 2003 00:50:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16321.39992.755515.876655@gargle.gargle.HOWL> Date: Sun, 23 Nov 2003 23:50:48 -0600 From: Pete McCann To: Avi Lior Cc: Bernard Aboba , mip4@ietf.org, aaa-wg@merit.edu In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] RE: [AAA-WG]: [Issue] Name for the nonces in aaa-keys and diamete r-mip Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Avi, You could say that the nonces in the "key material" field serve to make the key fresh, which in turn helps defeat replay attacks using old keys. So it is a "value, different from previous choices, inserted in a message to protect against replays" but it is not required to be random, and the replay protection is somewhat indirect. I think the use of the term nonce for this value would be consistent with existing cryptography literature, even if it may not be consistent with the definition in 3344, which is really there for the nonce-based replay protection that is part of the base Mobile IPv4 protocol. The definition for keying material that you cite shows why we shouldn't use that term for the nonce value. -Pete Avi Lior writes: > Hi Pete, Bernard, > > If you look at RFC 3344 nonce is defined this way: > > A randomly chosen value, different from previous choices, > inserted in a message to protect against replays. > > If this is a correct definition then the proposed usage is not consistant > with the above definition, right? > > In the AAA Keys for Mobile IPv4 draft it is defined as such: > > Key Material Data (e.g., a nonce) used for the purpose of > creating a key. > > That is it could be a nonce but it doesn't have to be. > > In the section for Key Material Creation and Derivation it state that the > 'Key Material' is a random value. > > Does that random value have to be different from previous choices inserted > in a message to protect against replays? > > BTW: If it does have to have propreties consistant with RFC 3344's > definition of nonce, then I suggest that AAA Keys for Mobile IPv4 should be > tightened. > > Just my 2cents worth. > > BTW I took a look around and I don't have a problem with Key Material here > is a definition that is common: > > Keying Material > > The data (e.g., keys and IVs) necessary to establish and maintain > cryptographic keying relationships. > > > Avi > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: November 21, 2003 1:43 PM > > To: Bernard Aboba > > Cc: mip4@ietf.org; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: [Issue] Name for the nonces in > > aaa-keys and diameter-mip > > > > > > > > Hi, Bernard, > > > > Ok, let's make sure to check the context in each case. > > > > Also, please note that the only long-term secret required is > > the one shared between MN and AAAH. The Diameter-MIP4 > > application can dynamically distribute the MN-HA session key > > (and the nonce that was used to generated it) to the HA. You > > are of course allowed to have a long-term secret between the > > MN and HA as part of a manually (or > > otherwise) configured mobility security association, but it > > isn't required. > > > > -Pete > > > > Bernard Aboba writes: > > > This change is ok with me as long as the term "Nonce" > > refers to a > non-secret quantity. It would appears to me > > that at least some of the > quantities referred to as "Key > > Material" in the Diameter MIPv4 draft are > in fact secret. > > > > Also, I'd prefer to use the term "Session Key" for an > > ephemeral key that > is refreshed by a nonce, and > > "Pre-shared key" for a quantity that is a > long-term secret > > (such as that shared between the MN and HA). > > > > Getting the terminology straight is probably half the > > battle in getting > these drafts completed. > > > > On Fri, 21 Nov 2003, Pete McCann wrote: > > > > > > > > > > > Hi, > > > > > > > > During my presentation of the Diameter Mobile IPv4 > > application to the > > AAA working group, an item came up > > around the use of the term "Key > > Material" in the > > Diameter Mobile IPv4 application and the Mobile IP > > > > aaa-key draft. It was noted that the term "Key Material" > > usually > > denotes stuff that should be kept secret, > > whereas the "Key Material" > > sent in a Registration Reply > > are actually nonces intended to be used > > by the MN to > > derive session keys. They will be visible to third > > > > parties while in transit. > > > > To resolve this, I > > suggest that we change all instances of "Key > > Material" > > in both of these drafts to something more descriptive, > > > > like "Nonce for Key Generation" or just "Nonce" when the > > context is > > clear. > > > > Is that acceptable to > > everyone? Hopefully we can make this change > > quickly and > > get both drafts ready for IESG submission. > > > > Thanks, > > > > > > -Pete > > > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 24 15:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26835 for ; Mon, 24 Nov 2003 15:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONDg-0006M9-G3 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKM4kG024432 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONDg-0006Lz-7q for mip4-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26819 for ; Mon, 24 Nov 2003 15:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONDe-0003s1-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:22:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONDe-0003ry-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONDd-0006Ld-Bm; Mon, 24 Nov 2003 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONDJ-0006Kq-9T for mip4@optimus.ietf.org; Mon, 24 Nov 2003 15:21:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26809 for ; Mon, 24 Nov 2003 15:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOND7-0003rm-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:21:30 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AOND7-0003r4-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:21:29 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAOKLrD03583 for ; Mon, 24 Nov 2003 14:21:55 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hAOKFxC06200; Mon, 24 Nov 2003 14:15:59 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HOVHME-0001QG-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:15:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16322.26357.232206.379182@gargle.gargle.HOWL> Date: Mon, 24 Nov 2003 14:15:49 -0600 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, The MIP4 workgroup has received a query from the DHC workgroup regarding the draft draft-ietf-dhc-mipadvert-opt-01.txt. The viewpoint of the MIP4 working group is needed in order to advance or retire this document. Responses are needed before 1700 EST on Thursday November 27th. The WG last call on this document was announced before the Minneapolis meeting, on both the DHC list and the MIP4 list. There were responses on the DHC list, but none on the MIP4 list. We therefore again ask for input from the MIP4 workgroup. Please respond to this query. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Please respond at the latest before 1700 EST on Thursday November 27th. draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the Mobility Agent Option, and two sub-options of the Mobility Agent Option: the Network Access Identifier Sub-Option, which provides identifying information about a DHCP client to the DHCP server and the Mobility Agent Announcement sub-option, which announces the address of one or more mobility agents available to a host. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 24 15:39:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28258 for ; Mon, 24 Nov 2003 15:39:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONU7-0007u5-OR for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKd37k030375 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONU7-0007tp-JV for mip4-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28195 for ; Mon, 24 Nov 2003 15:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONU6-0004Bj-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:39:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONU5-0004Bg-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONU6-0007rK-AC; Mon, 24 Nov 2003 15:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONTx-0007pU-R9 for mip4@optimus.ietf.org; Mon, 24 Nov 2003 15:38:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28156 for ; Mon, 24 Nov 2003 15:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONTu-0004BT-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:38:50 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AONTt-0004BL-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:38:50 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AONTs-0000GQ-00 for ; Mon, 24 Nov 2003 21:38:48 +0100 Date: Mon, 24 Nov 2003 21:38:41 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031124213841.456642a8.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__24_Nov_2003_21_38_41_+0100_dHIIgJQ=E=mchh2J" Subject: [Mip4] Advancing mip4 work items Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Mon__24_Nov_2003_21_38_41_+0100_dHIIgJQ=E=mchh2J Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, During the Minneapolis workgroup meeting, we posed a number of questions to the group present; but in many cases too few people had read the drafts in question and were prepared to signal an opinion. This is a list of the issues which we will present on the list in the coming weeks, asking for the list's viewpoint on each issue. (The first query will be sent to the list later today) : * Adoption of the draft draft-patel-mobileip-experimental-messages-02.txt as a workgroup draft. This draft proposes the assignment of IANA numbers for experimental MIP v4 messages, extensions and error codes, in accordance with work item 7 of the MIP4 charter. * Adoption of the draft draft-kulkarni-mobileip-dynamic-assignment-02.txt as a workgroup draft. This draft proposes extensions for the purpose of dynamically allocate an HA at the time of registration, rather than statically preconfigured, in accordance with charter work item 4. * Workgroup opinion on looking at a charter extension to work on MIP v4 to mip v6 transition mechanisms according to draft-tsirtsis-v4v6-mipv4-00.txt. The workgroup charter does not currently have any item supporting such work, so first of all we have to judge the group's interest in the work to know if we should apply for a charter extension. * Additionally, we have received a query from the dhc workgroup about this group's viewpoint on the draft draft-ietf-dhc-mipadvert-opt-01.txt, which is a work item of the dhc working group. Since this dhc option provides a new mechanism for distribution of MIP v4 agent advertisments, the draft will not advance if the MIP4 wg doesn't give it its support. Please respond to the individual queries we will send to the list on these items, starting with the first one later today. Regards, Henrik and Pete --Signature=_Mon__24_Nov_2003_21_38_41_+0100_dHIIgJQ=E=mchh2J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/wmxReVhrtTJkXCMRAmBUAJ93t10gQuk8oVHlvBslYzFA36K8UQCg2O6D cWQ3E57kuWZ587GvVHF2JkI= =v7NQ -----END PGP SIGNATURE----- --Signature=_Mon__24_Nov_2003_21_38_41_+0100_dHIIgJQ=E=mchh2J-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Nov 24 15:53:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29045 for ; Mon, 24 Nov 2003 15:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONhe-0000Ww-9R for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKr2AX002031 for mip4-archive@odin.ietf.org; Mon, 24 Nov 2003 15:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONhe-0000Wg-3r for mip4-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29023 for ; Mon, 24 Nov 2003 15:52:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONhc-0004Rx-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONhc-0004Rt-00 for mip4-web-archive@ietf.org; Mon, 24 Nov 2003 15:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONhd-0000WJ-2R; Mon, 24 Nov 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONgv-0000VT-Nt for mip4@optimus.ietf.org; Mon, 24 Nov 2003 15:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29013 for ; Mon, 24 Nov 2003 15:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONgt-0004RX-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:52:15 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AONgt-0004RP-00 for mip4@ietf.org; Mon, 24 Nov 2003 15:52:15 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AONgs-0000Gz-00 for ; Mon, 24 Nov 2003 21:52:14 +0100 Date: Mon, 24 Nov 2003 21:52:14 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031124215214.7326a34d.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__24_Nov_2003_21_52_14_+0100_cMU0t0oW+c_=R734" Subject: [Mip4] draft-patel-mobileip-experimental-messages-02.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Mon__24_Nov_2003_21_52_14_+0100_cMU0t0oW+c_=R734 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit This is an advance notification, in order for you to have some time to read through the draft mentioned in the subject line: In one week, on Monday December 1st, we will ask for the workgroup's viewpoint on making this draft a workgroup item, with the purpose of standardising experimental messages, extensions and error codes for MIP v4. The draft is 8 pages long. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-patel-mobileip-experimental-messages-02.txt Regards, Henrik and Pete --Signature=_Mon__24_Nov_2003_21_52_14_+0100_cMU0t0oW+c_=R734 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/wm9+eVhrtTJkXCMRAoezAJ9o7t2mP4eDN69yELgUutJx6PV3agCgmOME JLYQ7foZk8XswmNK6tGa8UA= =ZbRZ -----END PGP SIGNATURE----- --Signature=_Mon__24_Nov_2003_21_52_14_+0100_cMU0t0oW+c_=R734-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 11:43:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26287 for ; Tue, 25 Nov 2003 11:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgHO-0007BY-1h for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 11:43:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGhACu027616 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 11:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgHN-0007BL-S1 for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 11:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26260 for ; Tue, 25 Nov 2003 11:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgHM-0000iX-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 11:43:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgHM-0000iT-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 11:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgHK-0007Ax-LL; Tue, 25 Nov 2003 11:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgGp-0006xW-VO for mip4@optimus.ietf.org; Tue, 25 Nov 2003 11:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26218; Tue, 25 Nov 2003 11:42:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGo-0000iA-00; Tue, 25 Nov 2003 11:42:34 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGn-0000hC-00; Tue, 25 Nov 2003 11:42:33 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAPGg1g6322690; Tue, 25 Nov 2003 11:42:02 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPGg0je129326; Tue, 25 Nov 2003 11:42:00 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hAPGeboA032254; Tue, 25 Nov 2003 11:40:37 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hAPGebE2032249; Tue, 25 Nov 2003 11:40:37 -0500 Message-Id: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> To: Pete McCann cc: dhcwg@ietf.org, mip4@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt In-Reply-To: Message from mccap@lucent.com of "Mon, 24 Nov 2003 14:15:49 CST." <16322.26357.232206.379182@gargle.gargle.HOWL> Date: Tue, 25 Nov 2003 11:40:37 -0500 From: Thomas Narten Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Here is my review of this document. Note that I'm crossposting because some of my comments are more DHCP-ish, while others are MIP4-ish. Thomas > The Mobility Agent Information field shall NOT be terminated with a > 255 sub-option. The length N of the DHCP Mobility Agent Information Why is this here? There is presumably no "255 sub-option" defined, since this document definess all the suboptions that are applicable to this option. Or am I just confused? > tuples. Since at least one sub-option must be defined, the minimum > Mobility Agent Information length is two (2). The length N of the s/must be defined/must be included in the option/ > value field. A sub-option length may be zero. The sub-options need > not appear in sub-option code order. Would it be appropriate to go further and say: The sub-options need not appear in any particular order. (Just asking, I don't have a strong opinion, other than if ordering is important, now is the time to make the rules clear.) > The Network Access Identifier sub-option of the Mobility Agent > Information Option MAY be used by the DHCP client to provide > identifying information to the DHCP server, as part of the > DHCPDISCOVER message. The server may then use this information in > selecting mobility agent announcement parameters for the client. Can this sub-option only be provide in the DISCOVER, or can it also appear in the REQUEST? (I would assume both, i.e., I think clients can provide options in the REQUEST normally) > Option code > DHCP_MIP_OPTION (to be assigned by IANA) > > Length > Length in bytes of this option, not including the Option code and > Length bytes. Not sure why you include this here (section 3.3.) the picture shows only a suboption. Shouldn't the description just include the sub-option fields? (This is also for consistency, since the other suboption doesn't seem to include the code/length of DHC option itself). > The address trough which the Mobile Node may reach the announced s/trough/through/ > Sequence Number > The count of Mobility Agent DHCP announcements made since the DHCP > server was initialized (RFC 3220, Section 2.3.2 [5]). This is copied from the MIP advertisement. But does it make sense here? Isn't this for replay protection (or something?)? Not sure the same rational applies here. Also, this is a potentially significant new requirement on the DCHP server. I'm not aware of any other option that requires this sort of state me maintained. Also, what does it mean in the context of DHC, where the server may be talking to multiple different clients... Is this a per-client count, or a total count? > B > Busy. The foreign agent will not accept registrations from > additional mobile nodes. Also copied from the MIP message. But the DHC server generally won't be able to set this bit sensibly as I would assume only very loose syncronization between the DHC server and specific mobility agents. > 6. IANA Considerations > > The value for the DHCP_MIP_OPTION code must be assigned from the > numbering space defined for public DHCP Options in RFC 2939 [10]. Create a new IANA registry for future subtypes? -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 11:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26511 for ; Tue, 25 Nov 2003 11:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgKB-0007X3-Ew for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 11:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGk329028947 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 11:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgKB-0007Wl-8u for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 11:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26477 for ; Tue, 25 Nov 2003 11:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgKA-0000mX-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 11:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgK9-0000mS-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 11:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgKA-0007VR-3Y; Tue, 25 Nov 2003 11:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgJf-0007Th-Lq for mip4@optimus.ietf.org; Tue, 25 Nov 2003 11:45:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26427 for ; Tue, 25 Nov 2003 11:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgJe-0000lS-00 for mip4@ietf.org; Tue, 25 Nov 2003 11:45:30 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AOgJd-0000kR-00 for mip4@ietf.org; Tue, 25 Nov 2003 11:45:29 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAPGiuEY013670 for ; Tue, 25 Nov 2003 17:44:56 +0100 X-Authentication-Warning: irina.super.nu: bin set sender to tracker-mip4@levkowetz.com using -f Content-Type: text/plain; charset=utf-8 To: henrik@levkowetz.com From: Mip4 Issue Tracker Admin Reply-To: Mip4 issue tracker Date: Tue, 25 Nov 2003 16:08:35 +0000 Mime-Version: 1.0 Message-Id: <1069776515.75.0.850687956727.issue25@levkowetz.com> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello X-Loop: henrik@levkowetz.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailgw.local.ipunplugged.com id hAPG8iEY013163 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-Spam-Status: No, hits=-4.9 required=4.5 tests=BAYES_00 autolearn=ham version=2.60 Status: Resent-Date: Tue, 25 Nov 2003 17:44:57 +0100 Resent-From: Henrik Levkowetz Resent-Message-Id: <20031125174457.60371802.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 8bit Subject: [Mip4] [issue25] AAA-NAI extension sub-types for non-AAA NAIs Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit This comment from Mip4 Issue Tracker Admin has been added to issue 25: draft: draft-ietf-mobileip-aaa-nai -> draft-ietf-mobileip-aaa-nai status: Text proposed -> Accepted Having had no adverse responses to the proposed changes to the aaa-nai draft, here is the proposed resolution: (an updated draft is available at http://mip4.org/drafts/aaa-nai/ ) Change the title: Old: Mobile IPv4 Extension for AAA Network Access Identifiers New: Mobile IPv4 Extension for carrying Network Access Identifiers Throughout the document, change "AAA NAI Extension" to "NAI Carrying Extension" In the abstract, change Old: This document defines a Mobile IP extension that enables the HA to pass its identity to the mobile node which can then pass it on to the new AAA server when changing point of attachment. New: This document defines a Mobile IP extension that carries identities in the form of Network Access Identifiers (NAIs), which may be used by an HA to pass its identity to the mobile node which can then pass it on to the new AAA server when changing point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. Section 3, first paragraph, change Old: This section defines the AAA NAI Extension which may be carried in Mobile IP Registration Request and Reply messages [1]. The extension may be used by any node that wants to send identity information in the form of a NAI [3]. This document defines subtype numbers which identify the NAI as a HA identity and a Home AAA identity, respectively. New: This section defines the NAI Carrying Extension which may be used in Mobile IP Registration Request and Reply messages, and also in Mobile IP Agent Advertisements [1]. The extension may be used by any node that wants to send identity information in the form of a NAI [3]. This document also defines some subtype numbers which identify the specific type of NAI carried, in Section 4 and Section 5. It is expected that other types of NAI will be defined by other documents in the future. Change the description of the Sub-Type field: Old: Sub-Type This field describes the type of the entity which owns the NAI. The following subtypes are defined: 1 HA Identity NAI (Section 4) 2 AAAH Identity NAI (Section 5) New: Sub-Type This field describes the particular type NAI which is carried in the NAI field. In IANA Considerations section, add: New: The content and format for this extension is not specific to AAA NAIs, so if in the future new NAIs are defined which does not strictly fall within the category of AAA NAIs, they may nevertheless be accomodated within the subtype numbering space defined for the AAA NAI Extension defined in this document. _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 12:25:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28316 for ; Tue, 25 Nov 2003 12:25:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvu-0002ks-QC for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 12:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHP2U2010584 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 12:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvu-0002kY-DP for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28275 for ; Tue, 25 Nov 2003 12:24:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgvs-0001WU-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 12:25:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgvs-0001WR-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 12:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvt-0002k5-B9; Tue, 25 Nov 2003 12:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgvB-0002jQ-KA for mip4@optimus.ietf.org; Tue, 25 Nov 2003 12:24:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28272; Tue, 25 Nov 2003 12:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgv9-0001WB-00; Tue, 25 Nov 2003 12:24:15 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AOgv9-0001Vv-00; Tue, 25 Nov 2003 12:24:15 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAPHNcEY014286; Tue, 25 Nov 2003 18:23:38 +0100 Date: Tue, 25 Nov 2003 18:23:39 +0100 From: Henrik Levkowetz To: Thomas Narten Cc: Pete McCann , dhcwg@ietf.org, mip4@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031125182339.0664010e.henrik@levkowetz.com> In-Reply-To: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> References: <16322.26357.232206.379182@gargle.gargle.HOWL> <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thank you, Thomas. Comments below. /Henrik On Tuesday, 25 Nov 2003, Thomas wrote: > Here is my review of this document. Note that I'm crossposting because > some of my comments are more DHCP-ish, while others are MIP4-ish. > > Thomas > > > The Mobility Agent Information field shall NOT be terminated with a > > 255 sub-option. The length N of the DHCP Mobility Agent Information > > Why is this here? There is presumably no "255 sub-option" defined, > since this document definess all the suboptions that are applicable to > this option. Or am I just confused? I doubt the latter :-) I included this here as there exists an 255 end option (not sub-option) which seems to have prompted the same clarifying (or confusing!) text in some other documents defining suboptions. It doesn't seem needed, but maybe there is history lurking here? > > > tuples. Since at least one sub-option must be defined, the minimum > > Mobility Agent Information length is two (2). The length N of the > > s/must be defined/must be included in the option/ Yes. > > value field. A sub-option length may be zero. The sub-options need > > not appear in sub-option code order. > > Would it be appropriate to go further and say: > > The sub-options need not appear in any particular order. Yes. And (as urged by other people on the dhcwg list) I'll change the zero length part to require a flag instead of using the option presence itself as a flag. > > The Network Access Identifier sub-option of the Mobility Agent > > Information Option MAY be used by the DHCP client to provide > > identifying information to the DHCP server, as part of the > > DHCPDISCOVER message. The server may then use this information in > > selecting mobility agent announcement parameters for the client. > > Can this sub-option only be provide in the DISCOVER, or can it also > appear in the REQUEST? (I would assume both, i.e., I think clients can > provide options in the REQUEST normally) Both make sense to me. Will rectify. > > Option code > > DHCP_MIP_OPTION (to be assigned by IANA) > > > > Length > > Length in bytes of this option, not including the Option code and > > Length bytes. > > Not sure why you include this here (section 3.3.) the picture shows > only a suboption. Shouldn't the description just include the > sub-option fields? (This is also for consistency, since the other > suboption doesn't seem to include the code/length of DHC option > itself). Yes. should be sub-option, not option. > > The address trough which the Mobile Node may reach the announced > > s/trough/through/ Yes. > > Sequence Number > > The count of Mobility Agent DHCP announcements made since the DHCP > > server was initialized (RFC 3220, Section 2.3.2 [5]). > > This is copied from the MIP advertisement. But does it make sense > here? Isn't this for replay protection (or something?)? Not sure the > same rational applies here. Also, this is a potentially significant > new requirement on the DCHP server. I'm not aware of any other option > that requires this sort of state me maintained. There are instances where the use of this field would make sense, mostly to signal a re-boot of a box with co-located dhcp server and fa. But in most cases, it should be possible to signal that this field should be ignored. My thought is to add a bit field whereby this and any other selected field may be marked "to be ignored". > Also, what does it mean in the context of DHC, where the server may be > talking to multiple different clients... Is this a per-client count, > or a total count? Total count, not per client. > > B > > Busy. The foreign agent will not accept registrations from > > additional mobile nodes. > > Also copied from the MIP message. But the DHC server generally won't > be able to set this bit sensibly as I would assume only very loose > syncronization between the DHC server and specific mobility agents. Agree; basically the same comment applies here as above for the sequence number. > > 6. IANA Considerations > > > > The value for the DHCP_MIP_OPTION code must be assigned from the > > numbering space defined for public DHCP Options in RFC 2939 [10]. > > Create a new IANA registry for future subtypes? Yes. --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/w5AbeVhrtTJkXCMRAhIlAJ4mjqOq7rISXKUCSUC89a63002aYgCgjDpR YnVMFDP+6PQc6UIJJMTgYO0= =vqxC -----END PGP SIGNATURE----- --Signature=_Tue__25_Nov_2003_18_23_39_+0100_wTAVj=UqlxihvFQW-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 12:37:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28927 for ; Tue, 25 Nov 2003 12:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh7X-0003kS-P3 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 12:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHb3q4014393 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 12:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh7W-0003jq-QD for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:37:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28886 for ; Tue, 25 Nov 2003 12:36:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOh7V-0001lB-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 12:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOh7U-0001l8-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 12:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh7V-0003i6-7m; Tue, 25 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgbR-0000Lf-FM for mip4@optimus.ietf.org; Tue, 25 Nov 2003 12:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27237; Tue, 25 Nov 2003 12:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbP-00016Y-00; Tue, 25 Nov 2003 12:03:51 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbO-00016T-00; Tue, 25 Nov 2003 12:03:50 -0500 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 071D81B200F; Tue, 25 Nov 2003 11:02:41 -0600 (CST) In-Reply-To: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> References: <200311251640.hAPGebE2032249@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5--869180668" Message-Id: <4ECCF485-1F69-11D8-8AC9-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mip4@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Date: Tue, 25 Nov 2003 11:03:36 -0600 To: Thomas Narten X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.606) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Apple-Mail-5--869180668 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thomas, FYI, I think that the extra wording about ordering and end options is there because implementors sometimes (often enough that it's been an observed problem) fail to read the documents carefully, and this creates interoperability problems, so repeating things that are already obvious if one has carefully read, e.g., RFC2132, is actually constructive. We have, for example, encountered DHCP client implementations that blow up if you send the options in an unexpected order, or expect options to be padded so that multibyte values are appropriately aligned for picky architectures. Usually these implementations either don't last, or get fixed, but IMHO it's worth adding a little extra verbiage to try to nip these errors in the bud. --Apple-Mail-5--869180668 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/w4tqfAsUA+esjrARAhpAAJ4nEcDEC6NvJYNnwGS5OS0bFgpwMACePgr5 b5cfYmdxH0mel/N70XPwN58= =VjtZ -----END PGP SIGNATURE----- --Apple-Mail-5--869180668-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 13:26:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00596 for ; Tue, 25 Nov 2003 13:26:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhsy-0005nW-7l for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 13:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPIQ4sm022286 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 13:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhsy-0005nN-3S for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 13:26:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00583 for ; Tue, 25 Nov 2003 13:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhsw-0002Q3-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 13:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOhsv-0002Q0-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 13:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhsw-0005n0-B9; Tue, 25 Nov 2003 13:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhsK-0005m7-QF for mip4@optimus.ietf.org; Tue, 25 Nov 2003 13:25:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00559 for ; Tue, 25 Nov 2003 13:25:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhsI-0002PN-00 for mip4@ietf.org; Tue, 25 Nov 2003 13:25:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOhsI-0002PD-00 for mip4@ietf.org; Tue, 25 Nov 2003 13:25:22 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2003 10:26:24 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAPIOmjq029775; Tue, 25 Nov 2003 10:24:48 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALT48900; Tue, 25 Nov 2003 10:24:48 -0800 (PST) Message-ID: <3FC39E70.1060907@cisco.com> Date: Tue, 25 Nov 2003 10:24:48 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> <200311212211.HAA24136@toshiba.co.jp> <20031122133918.781f2fa0.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik, Yoshi, Please see inline.... Henrik Levkowetz wrote: > Friday 21 November 2003, Yoshiyuki wrote: > >>>> Scenario-A) If there is a group of HAs, an assigned HA will >>>> be anchored at the 1st registration. But, due to load balance or >>>> so on, the assigned HA may want to redirect a specific binding >>>> to another HA in the meantime of registrations by sending a >>>> registration reply with >>>> - the error code of REDIRECT-HA-REQ and >>>> - Redirected HA address extension. >>>> After receiving the above registration reply, an MN can send >>>> a registration request to the redirected HA. >>> >>>This scenario seems to me a straightforward application of the >>>dynamic HA-assignment draft. >> >> Which do you assume "at the 1st registration" or "in the middle of >> session" ? > > > I ment at the 1st registration. > > >> If you assumed at the 1st registration, I agree this scenario is a >> straightforward application. But, I meant in the middle of >> session. As Milind pointed out in his email, it seems to be out >> of scope of the current dynamic HA I-D. >> >> I think, the only >> problem of this scenario is a binding termination in the middle >> of session by HA, although I believe it is acceptable to an MN. > > > Possibly this could be made to work. But there would have to be > a bit more text in the draft to describe this scenario, then; > additionally it seems to be a bit at odds with the base premise > of this draft. We probably should think a bit about this, whether > we should extend the dynamic HA assignment draft in this direction, > or whether we should put it in the HA re-assignment draft. Following up on this thread, I am not sure what you have in mind. Is it (a) HA re-assignment in the middle of the session where session can be terminated or (b) HA re-assignment in the session where the session remains un-interrupted? If it's (a), then I think it's easy to extend the current Dynamic HA assignment draft. Thanks, Milind > > What do other folks think? > > Henrik > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 14:48:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04830 for ; Tue, 25 Nov 2003 14:48:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjAI-00034l-Te for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 14:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJm2Cw011817 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 14:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjAI-00034W-Oh for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:48:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04811 for ; Tue, 25 Nov 2003 14:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjAF-000445-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 14:47:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjAF-00043z-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 14:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjAH-000340-NQ; Tue, 25 Nov 2003 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjAB-00033M-Jo for mip4@optimus.ietf.org; Tue, 25 Nov 2003 14:47:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04802; Tue, 25 Nov 2003 14:47:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjA8-00043m-00; Tue, 25 Nov 2003 14:47:52 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjA8-000430-00; Tue, 25 Nov 2003 14:47:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2003 11:48:56 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAPJlBw7003613; Tue, 25 Nov 2003 11:47:19 -0800 (PST) Received: from cisco.com (jharper-w2k.cisco.com [128.107.163.44]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANX50536; Tue, 25 Nov 2003 11:47:10 -0800 (PST) Message-ID: <3FC3B1BD.60506@cisco.com> Date: Tue, 25 Nov 2003 11:47:09 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org, henrik@levkowetz.com, dhcwg@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt References: <16322.26357.232206.379182@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, Henrik - I have a few comments/questions regarding the draft -- 1. Looks like the option (along with the sub-options) can be used in both discover/request and reply (DHCP) messages. Can you add text to clarify this? 2. How do you suggest the DHC server use the NAI? Is any form of interpretation recommended? 3. What happens when the Mobile is from a different domain and so the DHCP server cannot understand the realm in the NAI. (Related to #2 above). 4. Would it be helpful to tie the NAI with the ci_addr field? This way, when some other client makes a DHCP request using the ci_addr field (and not the mobility option with NAI suboption), DHC server can do some co-relation? I say this because I think ci_addr is a well understood/implemented option. 5. RFC 3118 (I haven't read it in detail) specifies mechanism to authenticate DHC messages. THe security section mentions that this is one advantage of using agent advertisements from DHC as opposed to FA as from 3344. My question is, what if the MN is roaming in the foreign domain? How are keys distributed to authenticate the signature (authenticator field)? Isn't that the reason the FA advertisements are not authenticated? 6. Since FA/DHC servers are supposed to be autonomous entities (running on same or different boxes), how does the DHC server keep track of the availability/loading conditions at the FA (especially if they are separate boxes)? 7. Also, as Thomas suggested, I would like to have text clarifying that further sub-options may be added. Thanks Alpesh Pete McCann wrote: >Hi, > >The MIP4 workgroup has received a query from the DHC workgroup regarding >the draft draft-ietf-dhc-mipadvert-opt-01.txt. The viewpoint of the MIP4 >working group is needed in order to advance or retire this document. >Responses are needed before 1700 EST on Thursday November 27th. > >The WG last call on this document was announced before the Minneapolis >meeting, on both the DHC list and the MIP4 list. There were responses >on the DHC list, but none on the MIP4 list. We therefore again ask for >input from the MIP4 workgroup. > >Please respond to this query. If you support acceptance of the document >without change, respond with a simple acknowledgment, so that support >for the document can be assessed. Please respond at the latest before >1700 EST on Thursday November 27th. > >draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the >Mobility Agent Option, and two sub-options of the Mobility Agent Option: the >Network Access Identifier Sub-Option, which provides >identifying information about a DHCP client to the DHCP server and the >Mobility Agent Announcement sub-option, which announces the address of one >or more mobility agents available to a host. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > > >-Pete > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 15:47:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08946 for ; Tue, 25 Nov 2003 15:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk5O-00007q-6R for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 15:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKl2fO000478 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 15:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk5O-00007d-1L for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08932 for ; Tue, 25 Nov 2003 15:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOk5M-0005ao-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 15:47:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOk5M-0005al-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 15:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk5M-00007E-U6; Tue, 25 Nov 2003 15:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk4w-00006c-1K for mip4@optimus.ietf.org; Tue, 25 Nov 2003 15:46:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08907 for ; Tue, 25 Nov 2003 15:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOk4q-0005Xc-00 for mip4@ietf.org; Tue, 25 Nov 2003 15:46:28 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AOk4q-0005XZ-00 for mip4@ietf.org; Tue, 25 Nov 2003 15:46:28 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AOk4M-0000Ag-00; Tue, 25 Nov 2003 21:45:58 +0100 Date: Tue, 25 Nov 2003 21:45:26 +0100 From: Henrik Levkowetz To: Milind Kulkarni Cc: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031125214526.291a0db3.henrik@levkowetz.com> In-Reply-To: <3FC39E70.1060907@cisco.com> References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> <200311212211.HAA24136@toshiba.co.jp> <20031122133918.781f2fa0.henrik@levkowetz.com> <3FC39E70.1060907@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__25_Nov_2003_21_45_26_+0100_3.7V8xtPxS0B=tH7" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Tue__25_Nov_2003_21_45_26_+0100_3.7V8xtPxS0B=tH7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 25 November 2003, Milind wrote: > Henrik Levkowetz wrote: [...] > > Possibly this could be made to work. But there would have to be > > a bit more text in the draft to describe this scenario, then; > > additionally it seems to be a bit at odds with the base premise > > of this draft. We probably should think a bit about this, whether > > we should extend the dynamic HA assignment draft in this direction, > > or whether we should put it in the HA re-assignment draft. > > Following up on this thread, I am not sure what you have > in mind. Is it (a) HA re-assignment in the middle of the > session where session can be terminated or (b) HA re-assignment > in the session where the session remains un-interrupted? > > If it's (a), then I think it's easy to extend the current > Dynamic HA assignment draft. > Actually, I think (a) would be rather bad. I don't think we should go there, personally. (b) should be covered by the HA re-assignment drafts, rather than this one -- the solutions have different focus, are useful in different scenarios, and don't really overlap, I think. Regards, Henrik --Signature=_Tue__25_Nov_2003_21_45_26_+0100_3.7V8xtPxS0B=tH7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/w79veVhrtTJkXCMRAgIGAJ9w+b91MeX4hT/TFb/MwZtt3Ntq4ACgwh9b 4qJCwyvVGrGFdC7U9C4Ylg0= =Etmc -----END PGP SIGNATURE----- --Signature=_Tue__25_Nov_2003_21_45_26_+0100_3.7V8xtPxS0B=tH7-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 17:13:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13728 for ; Tue, 25 Nov 2003 17:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlQd-0005Bo-Ho for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 17:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMD32g019945 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 17:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlQd-0005Bc-BS for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13707 for ; Tue, 25 Nov 2003 17:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlQb-0000H8-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 17:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOlQa-0000H5-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 17:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlQb-0005B3-Em; Tue, 25 Nov 2003 17:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlPo-00059d-U6 for mip4@optimus.ietf.org; Tue, 25 Nov 2003 17:12:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13676 for ; Tue, 25 Nov 2003 17:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlPm-0000Fi-00 for mip4@ietf.org; Tue, 25 Nov 2003 17:12:10 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOlPm-0000EZ-00 for mip4@ietf.org; Tue, 25 Nov 2003 17:12:10 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Nov 2003 14:13:03 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAPMBaAv021512; Tue, 25 Nov 2003 14:11:38 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-138.cisco.com [128.107.163.138]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALT73561; Tue, 25 Nov 2003 14:11:35 -0800 (PST) Message-ID: <3FC3D398.9050905@cisco.com> Date: Tue, 25 Nov 2003 14:11:36 -0800 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> <200311212211.HAA24136@toshiba.co.jp> <20031122133918.781f2fa0.henrik@levkowetz.com> <3FC39E70.1060907@cisco.com> <20031125214526.291a0db3.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > Tuesday 25 November 2003, Milind wrote: > >>Henrik Levkowetz wrote: > > [...] > >>>Possibly this could be made to work. But there would have to be >>>a bit more text in the draft to describe this scenario, then; >>>additionally it seems to be a bit at odds with the base premise >>>of this draft. We probably should think a bit about this, whether >>>we should extend the dynamic HA assignment draft in this direction, >>>or whether we should put it in the HA re-assignment draft. >> >>Following up on this thread, I am not sure what you have >>in mind. Is it (a) HA re-assignment in the middle of the >>session where session can be terminated or (b) HA re-assignment >>in the session where the session remains un-interrupted? >> >>If it's (a), then I think it's easy to extend the current >>Dynamic HA assignment draft. >> > > > Actually, I think (a) would be rather bad. I don't think we > should go there, personally. I agree this is not the path to go. However, I am interested in knowing your reasons why you think it's bad, other than obvious session termination. > > (b) should be covered by the HA re-assignment drafts, rather > than this one -- the solutions have different focus, are > useful in different scenarios, and don't really overlap, > I think. I agree completly. Milind > > Regards, > Henrik > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Nov 25 17:34:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14693 for ; Tue, 25 Nov 2003 17:34:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlkv-0006qF-PS for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 17:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMY1pO026298 for mip4-archive@odin.ietf.org; Tue, 25 Nov 2003 17:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlkv-0006q5-Ky for mip4-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:34:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14668 for ; Tue, 25 Nov 2003 17:33:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlkt-0000oJ-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 17:33:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOlks-0000oG-00 for mip4-web-archive@ietf.org; Tue, 25 Nov 2003 17:33:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlku-0006pE-Ls; Tue, 25 Nov 2003 17:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlkT-0006m0-CL for mip4@optimus.ietf.org; Tue, 25 Nov 2003 17:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14638 for ; Tue, 25 Nov 2003 17:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlkQ-0000nT-00 for mip4@ietf.org; Tue, 25 Nov 2003 17:33:30 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AOlkQ-0000nF-00 for mip4@ietf.org; Tue, 25 Nov 2003 17:33:30 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AOlkJ-0000FC-00; Tue, 25 Nov 2003 23:33:23 +0100 Date: Tue, 25 Nov 2003 23:33:07 +0100 From: Henrik Levkowetz To: Milind Kulkarni Cc: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031125233307.63dd25c3.henrik@levkowetz.com> In-Reply-To: <3FC3D398.9050905@cisco.com> References: <200311210909.SAA16828@toshiba.co.jp> <20031121124412.35c9edcd.henrik@levkowetz.com> <200311212211.HAA24136@toshiba.co.jp> <20031122133918.781f2fa0.henrik@levkowetz.com> <3FC39E70.1060907@cisco.com> <20031125214526.291a0db3.henrik@levkowetz.com> <3FC3D398.9050905@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__25_Nov_2003_23_33_07_+0100__V+8dwvjngw0Hx=l" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Tue__25_Nov_2003_23_33_07_+0100__V+8dwvjngw0Hx=l Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Milind, Tuesday 25 November 2003, Milind wrote: > >>Following up on this thread, I am not sure what you have > >>in mind. Is it (a) HA re-assignment in the middle of the > >>session where session can be terminated or (b) HA re-assignment > >>in the session where the session remains un-interrupted? > >> > >>If it's (a), then I think it's easy to extend the current > >>Dynamic HA assignment draft. > >> > > > > > > Actually, I think (a) would be rather bad. I don't think we > > should go there, personally. > > I agree this is not the path to go. However, I am interested > in knowing your reasons why you think it's bad, other than > obvious session termination. - The obvious session termination :-) Henrik --Signature=_Tue__25_Nov_2003_23_33_07_+0100__V+8dwvjngw0Hx=l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/w9ijeVhrtTJkXCMRAq6fAKDoLgE/7wct+njy8uO8s3VU8vZ+owCcCuFo gA0Bv4FV9acQUpguRIf2LgI= =6IPd -----END PGP SIGNATURE----- --Signature=_Tue__25_Nov_2003_23_33_07_+0100__V+8dwvjngw0Hx=l-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 26 03:52:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27847 for ; Wed, 26 Nov 2003 03:52:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvPa-0004if-KA for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 03:52:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ8qc4I018129 for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 03:52:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvPa-0004iI-0c for mip4-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 03:52:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27809 for ; Wed, 26 Nov 2003 03:52:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOvPX-0001fU-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 03:52:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOvPW-0001fJ-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 03:52:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvOz-0004fQ-OH; Wed, 26 Nov 2003 03:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvO3-0004dG-Mv for mip4@optimus.ietf.org; Wed, 26 Nov 2003 03:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27759 for ; Wed, 26 Nov 2003 03:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOvO1-0001eZ-00 for mip4@ietf.org; Wed, 26 Nov 2003 03:51:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AOvO0-0001eW-00 for mip4@ietf.org; Wed, 26 Nov 2003 03:51:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAQ8ose9020778; Wed, 26 Nov 2003 17:50:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAQ8osNd006851; Wed, 26 Nov 2003 17:50:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id TAA06846 ; Wed, 26 Nov 2003 17:50:54 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id RAA20764; Wed, 26 Nov 2003 17:50:53 +0900 (JST) Received: by toshiba.co.jp id RAA07304; Wed, 26 Nov 2003 17:50:52 +0900 (JST) Message-Id: <200311260850.RAA07304@toshiba.co.jp> Date: Tue, 25 Nov 2003 23:50:52 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 To: Henrik Levkowetz Cc: Milind Kulkarni , mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20031125233307.63dd25c3.henrik@levkowetz.com> References: <20031122133918.781f2fa0.henrik@levkowetz.com> <3FC39E70.1060907@cisco.com> <20031125214526.291a0db3.henrik@levkowetz.com> <3FC3D398.9050905@cisco.com> <20031125233307.63dd25c3.henrik@levkowetz.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Henrik and Milind, My comment is at the bottom... at Tue, 25 Nov 2003 23:33:07 +0100 Henrik Levkowetz wrote: >Hi Milind, > >Tuesday 25 November 2003, Milind wrote: >> >>Following up on this thread, I am not sure what you have >> >>in mind. Is it (a) HA re-assignment in the middle of the >> >>session where session can be terminated or (b) HA re-assignment >> >>in the session where the session remains un-interrupted? >> >> >> >>If it's (a), then I think it's easy to extend the current >> >>Dynamic HA assignment draft. >> > >> > Actually, I think (a) would be rather bad. I don't think we >> > should go there, personally. >> >> I agree this is not the path to go. However, I am interested >> in knowing your reasons why you think it's bad, other than >> obvious session termination. > >- The obvious session termination :-) The session can be continued, if a next HA is assigned in the same subnet with the previous HA, and if the same home address is assigned. But, additional spec is required. Without an additional spec, an MN cannot receive a registration reply (RRP) because of an ID mismatch error, if an RRP is received without sending a registration request. I was afraid this kind of additional spec might be bad... Thanks. -Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 26 05:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01376 for ; Wed, 26 Nov 2003 05:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwwr-0001Iv-67 for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 05:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQAV5f2005008 for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 05:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwwq-0001IV-Cw for mip4-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 05:31:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01353 for ; Wed, 26 Nov 2003 05:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwwm-0003Db-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 05:31:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOwwm-0003DY-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 05:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwwo-0001Hl-UA; Wed, 26 Nov 2003 05:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwvq-0001Ax-R3 for mip4@optimus.ietf.org; Wed, 26 Nov 2003 05:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01306 for ; Wed, 26 Nov 2003 05:29:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwvn-0003CN-00 for mip4@ietf.org; Wed, 26 Nov 2003 05:29:59 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AOwvm-0003CG-00 for mip4@ietf.org; Wed, 26 Nov 2003 05:29:58 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AOwve-0000Aw-00; Wed, 26 Nov 2003 11:29:50 +0100 Date: Wed, 26 Nov 2003 11:29:27 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 Message-Id: <20031126112927.143b70cc.henrik@levkowetz.com> In-Reply-To: <200311260850.RAA07304@toshiba.co.jp> References: <20031122133918.781f2fa0.henrik@levkowetz.com> <3FC39E70.1060907@cisco.com> <20031125214526.291a0db3.henrik@levkowetz.com> <3FC3D398.9050905@cisco.com> <20031125233307.63dd25c3.henrik@levkowetz.com> <200311260850.RAA07304@toshiba.co.jp> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__26_Nov_2003_11_29_27_+0100_.k25/0noTWNA17+M" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Wed__26_Nov_2003_11_29_27_+0100_.k25/0noTWNA17+M Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Yoshi, Tuesday 25 November 2003, Yoshiyuki wrote: [...] > >> >>Following up on this thread, I am not sure what you have > >> >>in mind. Is it (a) HA re-assignment in the middle of the > >> >>session where session can be terminated or (b) HA re-assignment > >> >>in the session where the session remains un-interrupted? > >> >> > >> >>If it's (a), then I think it's easy to extend the current > >> >>Dynamic HA assignment draft. > >> > > >> > Actually, I think (a) would be rather bad. I don't think we > >> > should go there, personally. > >> > >> I agree this is not the path to go. However, I am interested > >> in knowing your reasons why you think it's bad, other than > >> obvious session termination. > > > >- The obvious session termination :-) > > The session can be continued, if a next HA is assigned in the > same subnet with the previous HA, and if the same home > address is assigned. > But, additional spec is required. Without an additional spec, > an MN cannot receive a registration reply (RRP) because of > an ID mismatch error, if an RRP is received without sending > a registration request. I was afraid this kind of additional spec > might be bad... As I mentioned earlier, I think in this case it should be handled in the upcoming HA re-assignment draft, rather than in this draft. I'm working on it, but I'm afraid it'll be a few weeks yet before I can submit. Can you wait? Henrik --Signature=_Wed__26_Nov_2003_11_29_27_+0100_.k25/0noTWNA17+M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xICOeVhrtTJkXCMRAp/wAKC/oAEu+eXcmcJJt5BInjoIwcAm8QCeJ3iA 8a9QXhN33nCGFZq7gBVf2kk= =ShqH -----END PGP SIGNATURE----- --Signature=_Wed__26_Nov_2003_11_29_27_+0100_.k25/0noTWNA17+M-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Nov 26 16:26:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28781 for ; Wed, 26 Nov 2003 16:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7As-0003fc-Hx for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 16:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQLQE2Z014104 for mip4-archive@odin.ietf.org; Wed, 26 Nov 2003 16:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7As-0003fP-Cx for mip4-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 16:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28748 for ; Wed, 26 Nov 2003 16:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7Aq-00051I-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 16:26:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP7Ao-000519-00 for mip4-web-archive@ietf.org; Wed, 26 Nov 2003 16:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7Af-0003bt-3l; Wed, 26 Nov 2003 16:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7AR-0003bC-OV for mip4@optimus.ietf.org; Wed, 26 Nov 2003 16:25:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28740 for ; Wed, 26 Nov 2003 16:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7AP-000514-00 for mip4@ietf.org; Wed, 26 Nov 2003 16:25:45 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AP7AP-000510-00 for mip4@ietf.org; Wed, 26 Nov 2003 16:25:45 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAQLPce9005905; Thu, 27 Nov 2003 06:25:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAQLPcnC008487; Thu, 27 Nov 2003 06:25:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA08486 ; Thu, 27 Nov 2003 06:25:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA09316; Thu, 27 Nov 2003 06:25:37 +0900 (JST) Received: by toshiba.co.jp id GAA18664; Thu, 27 Nov 2003 06:25:37 +0900 (JST) Message-Id: <200311262125.GAA18664@toshiba.co.jp> Date: Wed, 26 Nov 2003 12:25:37 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] A comment on draft-kulkarni-mobileip-dynamic-assignment-02 To: Henrik Levkowetz Cc: Milind Kulkarni , mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20031126112927.143b70cc.henrik@levkowetz.com> References: <20031125214526.291a0db3.henrik@levkowetz.com> <3FC3D398.9050905@cisco.com> <20031125233307.63dd25c3.henrik@levkowetz.com> <200311260850.RAA07304@toshiba.co.jp> <20031126112927.143b70cc.henrik@levkowetz.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi Henrik, at Wed, 26 Nov 2003 11:29:27 +0100 Henrik Levkowetz wrote: >Hi Yoshi, > >Tuesday 25 November 2003, Yoshiyuki wrote: > >[...] >> >> >>Following up on this thread, I am not sure what you have >> >> >>in mind. Is it (a) HA re-assignment in the middle of the >> >> >>session where session can be terminated or (b) HA re-assignment >> >> >>in the session where the session remains un-interrupted? >> >> >> >> >> >>If it's (a), then I think it's easy to extend the current >> >> >>Dynamic HA assignment draft. >> >> > >> >> > Actually, I think (a) would be rather bad. I don't think we >> >> > should go there, personally. >> >> >> >> I agree this is not the path to go. However, I am interested >> >> in knowing your reasons why you think it's bad, other than >> >> obvious session termination. >> > >> >- The obvious session termination :-) >> >> The session can be continued, if a next HA is assigned in the >> same subnet with the previous HA, and if the same home >> address is assigned. >> But, additional spec is required. Without an additional spec, >> an MN cannot receive a registration reply (RRP) because of >> an ID mismatch error, if an RRP is received without sending >> a registration request. I was afraid this kind of additional spec >> might be bad... > >As I mentioned earlier, I think in this case it should be handled in the >upcoming HA re-assignment draft, rather than in this draft. I'm working >on it, but I'm afraid it'll be a few weeks yet before I can submit. Can >you wait? > > Henrik No problem. I'm looking forward to it. Please, be sure to make some differences with the RO and binding-update I-Ds. Have a nice thanks-giving day! Thanks. - Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4