From exim@www1.ietf.org Mon Dec 1 10:27:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14679 for ; Mon, 1 Dec 2003 10:27: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 1AQpx3-0005Sh-5L for mip4-archive@odin.ietf.org; Mon, 01 Dec 2003 10:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1FR5JH020995 for mip4-archive@odin.ietf.org; Mon, 1 Dec 2003 10:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpx2-0005SY-Vy for mip4-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 10:27: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 KAA14671 for ; Mon, 1 Dec 2003 10:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQpx0-0003HZ-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 10:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQpx0-0003HU-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 10:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpwy-0005S4-QR; Mon, 01 Dec 2003 10:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpwf-0005Rj-2D for mip4@optimus.ietf.org; Mon, 01 Dec 2003 10:26: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 KAA14663 for ; Mon, 1 Dec 2003 10:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQpwc-0003HH-00 for mip4@ietf.org; Mon, 01 Dec 2003 10:26:38 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AQpwb-0003Gn-00 for mip4@ietf.org; Mon, 01 Dec 2003 10:26:38 -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 hB1FQ3HW014975; Mon, 1 Dec 2003 16:26:03 +0100 Date: Mon, 1 Dec 2003 16:26:05 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031201162605.12c02305.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=_Mon__1_Dec_2003_16_26_05_+0100_=PkWvWmii0C.zDFR" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] WG adoption call on 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__1_Dec_2003_16_26_05_+0100_=PkWvWmii0C.zDFR Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit This is a call to assess the support in the workgroup for adoption of "draft-patel-mobileip-experimental-messages-02.txt" as a workgroup document with the purpose of standardising experimental messages, extensions and error codes for MIP v4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-patel-mobileip-experimental-messages-02.txt If you have no comments on the draft at this time, and supports its adoption, simply respond with a line containing something like "I support the adoption of this document as a workgroup document" If you have no comments on the draft at this time, but *don't* supports its adoption, simply respond with a line containing something like "I don't support the adoption of this document as a workgroup document" If you have comments, please use a line like one of the two quoted above, and supplement this with your comments. Regards, Henrik --Signature=_Mon__1_Dec_2003_16_26_05_+0100_=PkWvWmii0C.zDFR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/y12NeVhrtTJkXCMRAoWSAJ4rwWsIZgqAgp//HopcBNKPZLcGxQCgmUuH IVqDLpdXgz/L1yk+uRv8ubs= =tQdn -----END PGP SIGNATURE----- --Signature=_Mon__1_Dec_2003_16_26_05_+0100_=PkWvWmii0C.zDFR-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 1 13:21:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21204 for ; Mon, 1 Dec 2003 13:21: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 1AQsfQ-0007oQ-2L for mip4-archive@odin.ietf.org; Mon, 01 Dec 2003 13:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IL4R5030024 for mip4-archive@odin.ietf.org; Mon, 1 Dec 2003 13: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 1AQsfP-0007oB-TN for mip4-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13: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 NAA21173 for ; Mon, 1 Dec 2003 13:20:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsfN-0006GE-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 13:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQsfN-0006GA-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 13:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsfO-0007ne-52; Mon, 01 Dec 2003 13: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 1AQsex-0007my-Ay for mip4@optimus.ietf.org; Mon, 01 Dec 2003 13:20: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 NAA21115 for ; Mon, 1 Dec 2003 13:20:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsev-0006G1-00 for mip4@ietf.org; Mon, 01 Dec 2003 13:20:33 -0500 Received: from mail45-s.fg.online.no ([148.122.161.45] helo=mail45.fg.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AQseu-0006FP-00 for mip4@ietf.org; Mon, 01 Dec 2003 13:20:32 -0500 Received: from espenlapxp (ti211110a080-3731.bb.online.no [80.212.206.147]) by mail45.fg.online.no (8.9.3p2/8.9.3) with SMTP id TAA11716; Mon, 1 Dec 2003 19:19:05 +0100 (MET) Message-ID: <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> From: "Espen Klovning" To: "Henrik Levkowetz" , References: <20031201162605.12c02305.henrik@levkowetz.com> Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Date: Mon, 1 Dec 2003 13:19:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 "I support the adoption of this document as a workgroup document" We need a better system to handle experimental messages/codes. Recent experiences with repeated renumbering have been annoying. The current draft is an attempt to handle that. My only concern is that the subtype allocation needs some thought to avoid the same problem all over again. espen Espen Klovning Birdstep Technology ASA -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 1 14:15:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23201 for ; Mon, 1 Dec 2003 14:15: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 1AQtVh-0002oK-T2 for mip4-archive@odin.ietf.org; Mon, 01 Dec 2003 14:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JF5cf010798 for mip4-archive@odin.ietf.org; Mon, 1 Dec 2003 14:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtVh-0002o5-OE for mip4-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:15: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 OAA23184 for ; Mon, 1 Dec 2003 14:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtVf-00071p-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 14:15:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtVe-00071m-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 14: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 1AQtVd-0002ma-RH; Mon, 01 Dec 2003 14:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtUz-0002lr-Pk for mip4@optimus.ietf.org; Mon, 01 Dec 2003 14:14:21 -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 OAA23127 for ; Mon, 1 Dec 2003 14:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtUx-00070z-00 for mip4@ietf.org; Mon, 01 Dec 2003 14:14:19 -0500 Received: from smtp-2.hut.fi ([130.233.228.92] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AQtUw-00070q-00 for mip4@ietf.org; Mon, 01 Dec 2003 14:14:18 -0500 Received: from maldini.hut.fi (maldini-m.hut.fi [130.233.228.122]) by smtp-2.hut.fi (8.12.10/8.12.10) with ESMTP id hB1JEAud030440 for ; Mon, 1 Dec 2003 21:14:10 +0200 Received: (from apache@localhost) by maldini.hut.fi (8.12.10/8.12.6/Submit) id hB1JEArA026982 for mip4@ietf.org; Mon, 1 Dec 2003 21:14:10 +0200 To: mip4@ietf.org Message-ID: <1070306050.3fcb93020d799@webmail2.hut.fi> Date: Mon, 01 Dec 2003 21:14:10 +0200 (EET) From: sami.vaarala@iki.fi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: HUT webmail, IMP 2.2.6 X-Authenticated-Sender: svaarala@cc.hut.fi X-Originating-IP: 62.71.113.91 X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi) Content-Transfer-Encoding: 8bit Subject: [Mip4] Comments on 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: 8bit Content-Transfer-Encoding: 8bit Hi, A late response to the poll on the list: Overall: I support the acceptance of this document, it seems to provide a useful mechanism that may be relevant in more complicated foreign agent scenarios (e.g. multi-provider environment). On the details, a few comments: - If possible, the duplication of agent advertisement format from RFC 3344 to this document should be avoided, as it introduces a dependency and does not make it clear is the format updated if the corresponding ICMP format is updated (although the flags field is discussed separately, but other changes to the format may at least theoretically happen :-). One concrete suggestion for Section 3.3: - Specify the extension as having exactly one agent advertisement (for simplicity, personal preference), the extension beginning with Mobility Agent IP Address. - Keep the extension format otherwise as-is, but instead of re-specifying the extension, refer to RFC 3344 Section 2.1.1. Expand the current flags discussion to cover other fields of the advertisement as well. - An alternative would be to provide the MN with only the FA IP addresses, but this does not seem to work well with ICMP router solicitation (the router is allowed to answer with multicast which might confuse other MNs in the network). Was this alternative considered (and rejected) ? - Nit: RFC 3220 references should be changed to RFC 3344 references. Best regards, -Sami -- Sami Vaarala Senior System Architect Netseal (http://www.netseal.com) -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 1 19:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13215 for ; Mon, 1 Dec 2003 19:02: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 1AQxzR-0005gL-WF for mip4-archive@odin.ietf.org; Mon, 01 Dec 2003 19:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2025RF021841 for mip4-archive@odin.ietf.org; Mon, 1 Dec 2003 19:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxzR-0005gC-RR for mip4-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 19:02: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 TAA13187 for ; Mon, 1 Dec 2003 19:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxzO-00067c-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 19:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQxzO-00067Z-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 19:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxzO-0005fr-18; Mon, 01 Dec 2003 19:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxz1-0005fE-CF for mip4@optimus.ietf.org; Mon, 01 Dec 2003 19:01: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 TAA13166 for ; Mon, 1 Dec 2003 19:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxyy-000676-00 for mip4@ietf.org; Mon, 01 Dec 2003 19:01:36 -0500 Received: from mail44-s.fg.online.no ([148.122.161.44] helo=mail44.fg.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AQxyx-00066H-00 for mip4@ietf.org; Mon, 01 Dec 2003 19:01:35 -0500 Received: from espenlapxp (ti211110a080-3731.bb.online.no [80.212.206.147]) by mail44.fg.online.no (8.9.3p2/8.9.3) with SMTP id BAA23018; Tue, 2 Dec 2003 01:00:17 +0100 (MET) Message-ID: <008401c3b867$45622cb0$bae3fea9@espenlapxp> From: "Espen Klovning" To: Cc: "Henrik Levkowetz" Date: Mon, 1 Dec 2003 19:00:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C3B83D.5BA3E790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Mip4] Comments on 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C3B83D.5BA3E790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another late response to the poll on the list: As Sami pointed out, the mechanism discussed in this draft has merit in = more complicated foreign agent scenarios. I support such a mechanism. Apart from all the other comments I have seen regarding this draft, I am = still left with a few questions/comments. Any clarification will be = appreciated. 1) I agree with Sami that a duplication of the existing agent = advertisement format is not necessarily a good thing. Mostly because = ICMP advertisements include more information than just the Mobility = Agent Advertisment Extension, e.g. MAC addresses, ICMP Code fields, = Prefix Length. The current extension is a good starting point though. 2) How is the MN supposed to use this mechanism? As far as I can tell, = it is not mentioned at all. It might be intentional for all I know. So, = should the MN: A) Use the DHCP Mobility Agent Announcement directly without soliciting = for an agent. B) Solicit for agents but only accept the one(s) indicated in the = Mobility Agent Announcement when the DHCP operation is completed. There seems to be some issues with both approaches when the FA is not = co-located but a separate physical entity. Will the authentication implied by the draft still be useful? How will = the MN get the necessary MAC address? Will the MN know whether the FA = performs generic routing services or not?=20 regards espen=20 Espen Klovning Birdstep Technology ASA ------=_NextPart_000_0081_01C3B83D.5BA3E790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another late response to the poll on = the=20 list:
 
As Sami pointed out, the mechanism = discussed in=20 this draft has merit in more complicated foreign agent scenarios. I = support=20 such a mechanism.
 
Apart from all the other comments I = have seen=20 regarding this draft, I am still left with a few = questions/comments. Any=20 clarification will be appreciated.
 
1) I agree = with Sami that=20 a duplication of the existing agent advertisement format is not = necessarily=20 a good thing. Mostly because ICMP advertisements include more = information=20 than just the Mobility Agent Advertisment Extension, e.g. MAC = addresses,=20 ICMP Code fields, Prefix Length. The current extension is a good = starting point=20 though.
 
2) How is the MN supposed to use this mechanism? As far as I = can tell,=20 it is not mentioned at all. It might be intentional for all I = know. So,=20 should the MN:
 
A) Use the DHCP Mobility Agent = Announcement=20 directly without soliciting for an agent.
B) Solicit for agents but = only accept the=20 one(s) indicated in the Mobility Agent Announcement when the DHCP = operation=20 is completed.
 
There seems to be some = issues with=20 both approaches when the FA is not co-located but a separate = physical=20 entity.
Will the authentication implied by the = draft still=20 be useful? How will the MN get the necessary MAC address? Will the MN = know=20 whether the FA performs generic routing services or not?
 
regards
espen
Espen Klovning
Birdstep Technology ASA
 
 
 
 
 
------=_NextPart_000_0081_01C3B83D.5BA3E790-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 1 22:25:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18325 for ; Mon, 1 Dec 2003 22:25: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 1AR19s-0007EL-St for mip4-archive@odin.ietf.org; Mon, 01 Dec 2003 22:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB23P4Mg027789 for mip4-archive@odin.ietf.org; Mon, 1 Dec 2003 22: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 1AR19s-0007E8-La for mip4-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 22: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 WAA18316 for ; Mon, 1 Dec 2003 22:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR19p-0000Oj-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 22:25:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR19p-0000Og-00 for mip4-web-archive@ietf.org; Mon, 01 Dec 2003 22: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 1AR19p-0007Dd-IK; Mon, 01 Dec 2003 22: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 1AR19h-0007DK-NS for mip4@optimus.ietf.org; Mon, 01 Dec 2003 22:24: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 WAA18313 for ; Mon, 1 Dec 2003 22:24:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR19e-0000Od-00 for mip4@ietf.org; Mon, 01 Dec 2003 22:24:50 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AR19d-0000OM-00 for mip4@ietf.org; Mon, 01 Dec 2003 22:24:49 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hB23OsD5010000; Tue, 2 Dec 2003 03:24:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hB23DIF28587; Tue, 2 Dec 2003 03:13:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003120119235106537 ; Mon, 01 Dec 2003 19:23:51 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Dec 2003 19:23:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Date: Mon, 1 Dec 2003 19:23:51 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BACB@orsmsx410.jf.intel.com> Thread-Topic: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Thread-Index: AcO4N+XNqKfN6c51TUyYn22vr4RCsQAS04TA From: "Adrangi, Farid" To: Cc: "Henrik Levkowetz" X-OriginalArrivalTime: 02 Dec 2003 03:23:52.0283 (UTC) FILETIME=[B58FC2B0:01C3B883] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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 "I support the adoption of this document as a workgroup document" I have the same concerns as Espen regarding the subtype allocation though. BR, Farid -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 02:26:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06201 for ; Tue, 2 Dec 2003 02:26: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 1AR4vG-00070B-D6 for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 02:26:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB27QDJi026908 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 02:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4vE-0006zv-Qf for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 02:26:12 -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 CAA06167 for ; Tue, 2 Dec 2003 02:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4vB-0002bu-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 02:26:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR4vA-0002br-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 02:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4v7-0006zW-19; Tue, 02 Dec 2003 02:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4ud-0006xu-MV for mip4@optimus.ietf.org; Tue, 02 Dec 2003 02:25: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 CAA06145 for ; Tue, 2 Dec 2003 02:25:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4uZ-0002aj-00 for mip4@ietf.org; Tue, 02 Dec 2003 02:25:32 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AR4uZ-0002ab-00 for mip4@ietf.org; Tue, 02 Dec 2003 02:25:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hB27PUvD024141; Tue, 2 Dec 2003 16:25:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hB27PUaP018386; Tue, 2 Dec 2003 16:25:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id SAA18375 ; Tue, 2 Dec 2003 16:25:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id QAA10468; Tue, 2 Dec 2003 16:25:29 +0900 (JST) Received: by toshiba.co.jp id QAA28625; Tue, 2 Dec 2003 16:25:28 +0900 (JST) Message-Id: <200312020725.QAA28625@toshiba.co.jp> Date: Mon, 01 Dec 2003 22:25:28 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt To: Henrik Levkowetz Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20031201162605.12c02305.henrik@levkowetz.com> References: <20031201162605.12c02305.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: , "I support the adoption of this document as a workgroup document" I think, this I-D is quite useful, because: - it will provide a way to do some MIP message experiments by MIP standard-based devices. - It enables those vendors which don't have any specific vendor IDs to do some MIP extension experiments. Thanks. -Yoshi Yoshiyuki Tsuda Corporate R&D Center, Toshiba Corporation -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 11:43:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25978 for ; Tue, 2 Dec 2003 11:43: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 1ARDbW-0000Gy-7O for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 11:42:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GgGCI001019 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 11:42:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDbL-0000FR-Fe for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:42: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 LAA25897 for ; Tue, 2 Dec 2003 11:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDb0-0003qv-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 11:41:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDb0-0003qs-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 11:41:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDZE-00008D-UX; Tue, 02 Dec 2003 11:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDYR-0008Uq-UO for mip4@optimus.ietf.org; Tue, 02 Dec 2003 11: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 LAA25746 for ; Tue, 2 Dec 2003 11:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDYQ-0003ny-00 for mip4@ietf.org; Tue, 02 Dec 2003 11:39:14 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARDYQ-0003np-00 for mip4@ietf.org; Tue, 02 Dec 2003 11:39:14 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARDYO-0000Bz-00; Tue, 02 Dec 2003 17:39:12 +0100 Date: Tue, 2 Dec 2003 17:39:08 +0100 From: Henrik Levkowetz To: "Espen Klovning" Cc: Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Message-Id: <20031202173908.44ab7d81.henrik@levkowetz.com> In-Reply-To: <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> 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 Monday 1 December 2003, Espen wrote: > We need a better system to handle experimental messages/codes. Recent > experiences with repeated renumbering have been annoying. The current draft > is an attempt to handle that. My only concern is that the subtype allocation > needs some thought to avoid the same problem all over again. That's a good point. So maybe we should predefine one or two numbers out of all mip v4 subtype ranges as experimental for that subtype, too? Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 12:26:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28956 for ; Tue, 2 Dec 2003 12:26: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 1AREHk-0006B5-7Z for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 12:26:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2HQ4wn023746 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 12: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 1AREHk-0006Av-3x for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12: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 MAA28923 for ; Tue, 2 Dec 2003 12:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREHi-0004zd-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AREHi-0004za-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREHj-0006Aa-4N; Tue, 02 Dec 2003 12:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREHD-00068Q-3c for mip4@optimus.ietf.org; Tue, 02 Dec 2003 12:25: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 MAA28892 for ; Tue, 2 Dec 2003 12:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREHB-0004yr-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:25:29 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AREHA-0004yj-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:25:28 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AREH6-0000Di-00; Tue, 02 Dec 2003 18:25:24 +0100 Date: Tue, 2 Dec 2003 18:25:14 +0100 From: Henrik Levkowetz To: "Espen Klovning" Cc: Subject: Re: [Mip4] Comments on draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031202182514.5f386816.henrik@levkowetz.com> In-Reply-To: <008401c3b867$45622cb0$bae3fea9@espenlapxp> References: <008401c3b867$45622cb0$bae3fea9@espenlapxp> 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__2_Dec_2003_18_25_14_+0100_L4kxFVD3Vubp24jD" 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__2_Dec_2003_18_25_14_+0100_L4kxFVD3Vubp24jD Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Espen, Thanks for the response. Some replies inline: Monday 1 December 2003, Espen wrote: > Another late response to the poll on the list: > > As Sami pointed out, the mechanism discussed in this draft has merit > in more complicated foreign agent scenarios. I support such a > mechanism. > > Apart from all the other comments I have seen regarding this draft, I > am still left with a few questions/comments. Any clarification will be > appreciated. > > 1) I agree with Sami that a duplication of the existing agent > advertisement format is not necessarily a good thing. Mostly because > ICMP advertisements include more information than just the Mobility > Agent Advertisment Extension, e.g. MAC addresses, ICMP Code fields, > Prefix Length. The current extension is a good starting point though. Ok. This seems to parallel some comments received earlier; I'll propose some new text to make it possible to indicate fields as inactive. > 2) How is the MN supposed to use this mechanism? As far as I can tell, > it is not mentioned at all. It might be intentional for all I know. > So, should the MN: > > A) Use the DHCP Mobility Agent Announcement directly without > soliciting for an agent. B) Solicit for agents but only accept the > one(s) indicated in the Mobility Agent Announcement when the DHCP > operation is completed. Not describing this was intentional; it would really be up to vendors and deployers. But the most straightforward way would be for a mobile arriving at for instance a WiFi hotspot to acquire a dhcp address and solicit for FAs in parallel. To differentiate between possible services, the FAs would be announced only through DHCP, not by responding to router solicitations; this way the FA and service level offered could be dependent on the NAI provided by the MN. > There seems to be some issues with both approaches when the FA is not > co-located but a separate physical entity. Will the authentication > implied by the draft still be useful? How will the MN get the > necessary MAC address? Will the MN know whether the FA performs > generic routing services or not? As for the authentication, this will be as feasible or not as the corresponding key distribution problem, I guess. Given the IP address, the MN should be able to ARP for the MAC address. That's at least the way I thought about it. To know what node(s) provides generic routing services, you'd need to provide the router(s) by DHCP, too, using the router option. I guess all of this should go into the updated draft :-) Regards, Henrik --Signature=_Tue__2_Dec_2003_18_25_14_+0100_L4kxFVD3Vubp24jD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zMsCeVhrtTJkXCMRAlTYAJ45oMFWyJYgIoBNXfvZxBF5VOxWlgCePVnH Egz4i3vp9D+3sWmZRvH5RYc= =UYt7 -----END PGP SIGNATURE----- --Signature=_Tue__2_Dec_2003_18_25_14_+0100_L4kxFVD3Vubp24jD-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 12:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29653 for ; Tue, 2 Dec 2003 12:51: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 1AREfv-00071E-97 for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 12:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Hp3U8026977 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 12:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREfv-000712-2d for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:51: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 MAA29617 for ; Tue, 2 Dec 2003 12:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREft-0005Ft-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:51:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AREft-0005Fq-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREft-00070l-US; Tue, 02 Dec 2003 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREfs-0006zw-Bk for mip4@optimus.ietf.org; Tue, 02 Dec 2003 12:51: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 MAA29608 for ; Tue, 2 Dec 2003 12:50:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREfp-0005Fd-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:50:57 -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 1AREfo-0005FO-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:50:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 09:53:22 +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 hB2HoMw5024159; Tue, 2 Dec 2003 09:50:23 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-65.cisco.com [128.107.163.65]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOB46721; Tue, 2 Dec 2003 09:50:22 -0800 (PST) Message-ID: <3FCCD0DE.4070709@cisco.com> Date: Tue, 02 Dec 2003 09:50:22 -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: Henrik Levkowetz CC: Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.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 Agreed. Probably, we can reserve a number in higher range - 254 or 255 as experimental for all extensions defined in "Long Extension Format" as specified in 1.10 of RFC 3344? -a Henrik Levkowetz wrote: >Monday 1 December 2003, Espen wrote: > > >>We need a better system to handle experimental messages/codes. Recent >>experiences with repeated renumbering have been annoying. The current draft >>is an attempt to handle that. My only concern is that the subtype allocation >>needs some thought to avoid the same problem all over again. >> >> > >That's a good point. So maybe we should predefine one or two numbers out of >all mip v4 subtype ranges as experimental for that subtype, too? > > Henrik > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 13:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00162 for ; Tue, 2 Dec 2003 13:02: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 1AREqZ-0007Lk-OI for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 13:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2I23gL028246 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 13: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 1AREqZ-0007Kb-Hz for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 13: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 NAA00152 for ; Tue, 2 Dec 2003 13:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREqW-0005So-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:02:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AREqV-0005Sl-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13: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 1AREqW-0007K3-Cg; Tue, 02 Dec 2003 13: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 1AREpd-0007JW-2g for mip4@optimus.ietf.org; Tue, 02 Dec 2003 13:01: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 NAA00125 for ; Tue, 2 Dec 2003 13:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREpb-0005Ri-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:01:03 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AREpa-0005Ra-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:01:02 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AREpI-0000JB-00; Tue, 02 Dec 2003 19:00:44 +0100 Date: Tue, 2 Dec 2003 19:00:36 +0100 From: Henrik Levkowetz To: Alpesh Cc: Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Message-Id: <20031202190036.7a6ec0a5.henrik@levkowetz.com> In-Reply-To: <3FCCD0DE.4070709@cisco.com> References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@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__2_Dec_2003_19_00_37_+0100_uNjWhBsg/GXQIFSw" 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__2_Dec_2003_19_00_37_+0100_uNjWhBsg/GXQIFSw Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Alpesh, Tuesday 2 December 2003, Alpesh wrote: > Agreed. Probably, we can reserve a number in higher range - 254 or 255 as > experimental for all extensions defined in "Long Extension Format" as > specified in 1.10 of RFC 3344? Any reason to limit this to subtypes of the long extension format, rather than applying it to all extensions which define subtypes? Henrik --Signature=_Tue__2_Dec_2003_19_00_37_+0100_uNjWhBsg/GXQIFSw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zNNFeVhrtTJkXCMRAiaTAJoC/JPi2scFadg8m3Xof+gNNFP4EQCbBOrt WnRsVqNTm1MJfdkS4f/7fY0= =ssYN -----END PGP SIGNATURE----- --Signature=_Tue__2_Dec_2003_19_00_37_+0100_uNjWhBsg/GXQIFSw-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 13:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00422 for ; Tue, 2 Dec 2003 13:12: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 1ARF0J-0007qN-Ej for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 13:12:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2IC71O030149 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 13:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARF0J-0007qC-7p for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 13:12: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 NAA00412 for ; Tue, 2 Dec 2003 13:11:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARF0C-0005XS-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:12:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARF0C-0005XP-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARF0D-0007pL-77; Tue, 02 Dec 2003 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AREzb-0007oO-B6 for mip4@optimus.ietf.org; Tue, 02 Dec 2003 13:11: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 NAA00388 for ; Tue, 2 Dec 2003 13:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AREzZ-0005Wq-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:11:21 -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 1AREzY-0005Wm-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:11:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 10:13:46 +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 hB2IAiw5026829; Tue, 2 Dec 2003 10:10:44 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-65.cisco.com [128.107.163.65]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOB49468; Tue, 2 Dec 2003 10:10:40 -0800 (PST) Message-ID: <3FCCD5A0.3040006@cisco.com> Date: Tue, 02 Dec 2003 10:10:40 -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: Henrik Levkowetz CC: Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@cisco.com> <20031202190036.7a6ec0a5.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 - No specific reason - just forgot to confirm that the short extension format defined in section 1.11 of rfc3344 also defines sub-types. We can reserve a number there as well. There are too many experimental elements in the title (already 3 and this potential 4th). Maybe we can just have the title changed to *-experimental-elements-* ?? Thanks for pointing it out. -a Henrik Levkowetz wrote: >Hi Alpesh, > >Tuesday 2 December 2003, Alpesh wrote: > > >>Agreed. Probably, we can reserve a number in higher range - 254 or 255 as >>experimental for all extensions defined in "Long Extension Format" as >>specified in 1.10 of RFC 3344? >> >> > >Any reason to limit this to subtypes of the long extension format, >rather than applying it to all extensions which define subtypes? > > Henrik > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 13:27:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00815 for ; Tue, 2 Dec 2003 13:27: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 1ARFEm-0008QT-2f for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 13:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2IR4iR032383 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 13: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 1ARFEl-0008QE-U5 for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 13: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 NAA00807 for ; Tue, 2 Dec 2003 13:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFEj-0005fm-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARFEj-0005fi-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFEi-0008Pu-NA; Tue, 02 Dec 2003 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFEZ-0008Pg-CZ for mip4@optimus.ietf.org; Tue, 02 Dec 2003 13:26: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 NAA00802 for ; Tue, 2 Dec 2003 13:26:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFEX-0005ff-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:26:49 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARFEW-0005fb-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:26:48 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARFDH-0000KI-00; Tue, 02 Dec 2003 19:25:31 +0100 Date: Tue, 2 Dec 2003 19:25:20 +0100 From: Henrik Levkowetz To: Alpesh Cc: Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Message-Id: <20031202192520.5540e814.henrik@levkowetz.com> In-Reply-To: <3FCCD5A0.3040006@cisco.com> References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@cisco.com> <20031202190036.7a6ec0a5.henrik@levkowetz.com> <3FCCD5A0.3040006@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__2_Dec_2003_19_25_20_+0100_Orxk_9eI3jhxvT4i" 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__2_Dec_2003_19_25_20_+0100_Orxk_9eI3jhxvT4i Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 2 December 2003, Alpesh wrote: > No specific reason - just forgot to confirm that the short extension format > defined in section 1.11 of rfc3344 also defines sub-types. We can reserve > a number there as well. Ok. Maybe even better might be to say that any extensions with sub-type numbers, such as for instance extensions according to rfc 3344 section 1.10 and 1.11, have sub-type number so-and-so reserved as experimental? > There are too many experimental elements in the title (already > 3 and this potential 4th). Maybe we can just have the title changed to > *-experimental-elements-* ?? What about "Experimental Numbers for Mobile IPv4" ? Henrik --Signature=_Tue__2_Dec_2003_19_25_20_+0100_Orxk_9eI3jhxvT4i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zNkQeVhrtTJkXCMRAtFKAKCEtJCdEH9iZ4ITAK1GdcEFvqMjDACdEVyu M2mnQn0hiH8qsSRTG//yNgI= =Omql -----END PGP SIGNATURE----- --Signature=_Tue__2_Dec_2003_19_25_20_+0100_Orxk_9eI3jhxvT4i-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 13:44:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01609 for ; Tue, 2 Dec 2003 13:44: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 1ARFVC-000151-5W for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 13:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ii2t3004123 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 13:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFVB-00013s-Ty for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 13:44: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 NAA01594 for ; Tue, 2 Dec 2003 13:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFV9-0005yx-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:43:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARFV9-0005yu-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 13:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFVB-00013J-02; Tue, 02 Dec 2003 13: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 1ARFUP-0000xD-0o for mip4@optimus.ietf.org; Tue, 02 Dec 2003 13:43: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 NAA01555 for ; Tue, 2 Dec 2003 13:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFUM-0005yG-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:43:10 -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 1ARFUM-0005y7-00 for mip4@ietf.org; Tue, 02 Dec 2003 13:43:10 -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 hB2Igcw5013639; Tue, 2 Dec 2003 10:42:38 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-65.cisco.com [128.107.163.65]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOB53994; Tue, 2 Dec 2003 10:42:37 -0800 (PST) Message-ID: <3FCCDD1D.6020801@cisco.com> Date: Tue, 02 Dec 2003 10:42:37 -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: Henrik Levkowetz CC: Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@cisco.com> <20031202190036.7a6ec0a5.henrik@levkowetz.com> <3FCCD5A0.3040006@cisco.com> <20031202192520.5540e814.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 - Okay, we will add a new section with the text to keep a specific sub-type number reserved for current and future extensions. Thx -a Henrik Levkowetz wrote: >Tuesday 2 December 2003, Alpesh wrote: > > >>No specific reason - just forgot to confirm that the short extension format >>defined in section 1.11 of rfc3344 also defines sub-types. We can reserve >>a number there as well. >> >> > >Ok. Maybe even better might be to say that any extensions with >sub-type numbers, such as for instance extensions according to >rfc 3344 section 1.10 and 1.11, have sub-type number so-and-so >reserved as experimental? > > > >>There are too many experimental elements in the title (already >>3 and this potential 4th). Maybe we can just have the title changed to >>*-experimental-elements-* ?? >> >> > >What about "Experimental Numbers for Mobile IPv4" ? > > Henrik > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 15:01:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05388 for ; Tue, 2 Dec 2003 15:01: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 1ARGhi-000514-8k for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 15:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2K12WJ019281 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 15:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGhi-00050u-35 for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:01: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 PAA05371 for ; Tue, 2 Dec 2003 15:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGhf-0007Lr-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15:00:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGhe-0007Lo-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15:00:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGhg-00050W-Q6; Tue, 02 Dec 2003 15:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGgk-0004yF-1q for mip4@optimus.ietf.org; Tue, 02 Dec 2003 15:00: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 OAA05319 for ; Tue, 2 Dec 2003 14:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGgh-0007LC-00 for mip4@ietf.org; Tue, 02 Dec 2003 14:59:59 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGgg-0007Kk-00 for mip4@ietf.org; Tue, 02 Dec 2003 14:59:58 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB2JvEw10646; Tue, 2 Dec 2003 13:57:41 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB2Jv6o24719; Tue, 2 Dec 2003 13:57:06 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HPAA2P-0000ZS-00; Tue, 02 Dec 2003 14:56:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16332.61058.748267.87202@gargle.gargle.HOWL> Date: Tue, 2 Dec 2003 13:56:50 -0600 From: Pete McCann To: Alpesh Cc: Henrik Levkowetz , Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt In-Reply-To: <3FCCDD1D.6020801@cisco.com> References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@cisco.com> <20031202190036.7a6ec0a5.henrik@levkowetz.com> <3FCCD5A0.3040006@cisco.com> <20031202192520.5540e814.henrik@levkowetz.com> <3FCCDD1D.6020801@cisco.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 I think we should be careful here; I don't see a good way to define the term "subtype" unless we are referring to the specific extension formats identified in RFC 3344 (long and short). So I would hope you can be explicit about the subtype fields instead of making a statement like: > >any extensions with > >sub-type numbers, such as for instance extensions according to > >rfc 3344 section 1.10 and 1.11, have sub-type number so-and-so > >reserved as experimental? -Pete Alpesh writes: > Henrik - > > Okay, we will add a new section with the text to keep a specific sub-type > number reserved for current and future extensions. > > Thx > -a > > Henrik Levkowetz wrote: > > >Tuesday 2 December 2003, Alpesh wrote: > > > > > >>No specific reason - just forgot to confirm that the short extension format > >>defined in section 1.11 of rfc3344 also defines sub-types. We can reserve > >>a number there as well. > >> > >> > > > >Ok. Maybe even better might be to say that any extensions with > >sub-type numbers, such as for instance extensions according to > >rfc 3344 section 1.10 and 1.11, have sub-type number so-and-so > >reserved as experimental? > > > > > > > >>There are too many experimental elements in the title (already > >>3 and this potential 4th). Maybe we can just have the title changed to > >>*-experimental-elements-* ?? > >> > >> > > > >What about "Experimental Numbers for Mobile IPv4" ? > > > > Henrik > > > > > > > > -- > 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 Tue Dec 2 15:10:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06651 for ; Tue, 2 Dec 2003 15:10: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 1ARGqQ-0005ns-Uu for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 15:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KA2i9022300 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 15: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 1ARGqQ-0005na-Ms for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:10: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 PAA06598 for ; Tue, 2 Dec 2003 15:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGqN-0007ad-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15:09:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGqN-0007aY-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGqP-0005mz-7S; Tue, 02 Dec 2003 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGpr-0005mJ-7H for mip4@optimus.ietf.org; Tue, 02 Dec 2003 15:09: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 PAA06475 for ; Tue, 2 Dec 2003 15:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGpo-0007Yk-00 for mip4@ietf.org; Tue, 02 Dec 2003 15:09:24 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARGpn-0007Yh-00 for mip4@ietf.org; Tue, 02 Dec 2003 15:09:23 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARGnv-0000SQ-00; Tue, 02 Dec 2003 21:07:27 +0100 Date: Tue, 2 Dec 2003 21:07:17 +0100 From: Henrik Levkowetz To: Pete McCann Cc: Alpesh , Espen Klovning , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Message-Id: <20031202210717.08f31e07.henrik@levkowetz.com> In-Reply-To: <16332.61058.748267.87202@gargle.gargle.HOWL> References: <20031201162605.12c02305.henrik@levkowetz.com> <002801c3b837$9ab0dca0$bae3fea9@espenlapxp> <20031202173908.44ab7d81.henrik@levkowetz.com> <3FCCD0DE.4070709@cisco.com> <20031202190036.7a6ec0a5.henrik@levkowetz.com> <3FCCD5A0.3040006@cisco.com> <20031202192520.5540e814.henrik@levkowetz.com> <3FCCDD1D.6020801@cisco.com> <16332.61058.748267.87202@gargle.gargle.HOWL> 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 Tuesday 2 December 2003, Pete wrote: > I think we should be careful here; I don't see a good way to define > the term "subtype" unless we are referring to the specific extension > formats identified in RFC 3344 (long and short). So I would hope you > can be explicit about the subtype fields instead of making a statement > like: > > > >any extensions with > > >sub-type numbers, such as for instance extensions according to > > >rfc 3344 section 1.10 and 1.11, have sub-type number so-and-so > > >reserved as experimental? Seems you're a bit more cautious than me here, but I can go with this, too. Best, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 15:40:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09243 for ; Tue, 2 Dec 2003 15:40: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 1ARHJZ-0007js-QU for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 15:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ke8HV029714 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 15:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHJX-0007j8-NY for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:40: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 PAA09225 for ; Tue, 2 Dec 2003 15:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHJU-0000Gn-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15:40:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHJU-0000Gj-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 15: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 1ARHJV-0007id-9I; Tue, 02 Dec 2003 15: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 1ARHIq-0007h9-Rh for mip4@optimus.ietf.org; Tue, 02 Dec 2003 15:39: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 PAA09189 for ; Tue, 2 Dec 2003 15:39:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHIp-0000Fi-00 for mip4@ietf.org; Tue, 02 Dec 2003 15:39:23 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ARHIo-0000F8-00 for mip4@ietf.org; Tue, 02 Dec 2003 15:39:22 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB2KYNw04898 for ; Tue, 2 Dec 2003 14:34:49 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB2KYHo11895; Tue, 2 Dec 2003 14:34: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 HPABSO-0001F4-00 for mip4@ietf.org; Tue, 02 Dec 2003 15:34:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16332.63289.436267.968198@gargle.gargle.HOWL> Date: Tue, 2 Dec 2003 14:34:01 -0600 From: Pete McCann To: mip4@ietf.org Subject: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt In-Reply-To: <16322.26357.232206.379182@gargle.gargle.HOWL> References: <16322.26357.232206.379182@gargle.gargle.HOWL> 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 One more late comment on this draft (I don't have an opinion at this time on whether it should be advanced): Is it required that all mobility agents configured by this option be on-link? That seems to be implied by text like the following: > H > Home agent. This agent offers service as a home agent on the link > on which this mobility agent announcement is sent. > > F > Foreign agent. This agent offers service as a foreign agent on > the link on which this mobility agent announcement is sent. But is it really necessary? For example, you should be able to configure a home agent that is on a remote link, right? Then your DHCP-configured address could be used like a co-located CoA for a MIP registration, and you could keep the HA for subsequent handoffs. This might be a good way to, for example, configure an HA in the local network while roaming, but when you haven't deployed Mobile IP FAs, and you want to centralize the HAs on links other than the access links. I assume this sort of functionality would be supported by the existing Mobile IP Home Agent option specified in RFC 2132. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 16:26:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11910 for ; Tue, 2 Dec 2003 16:26: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 1ARI1y-0001FS-Nr for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 16:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2LQ2sv004795 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 16: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 1ARI1y-0001FG-K7 for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 16:26: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 QAA11903 for ; Tue, 2 Dec 2003 16:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARI1w-0001Gy-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 16:26:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARI1w-0001Gv-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 16:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARI1x-0001Es-AE; Tue, 02 Dec 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 1ARI1g-0001EQ-Us for mip4@optimus.ietf.org; Tue, 02 Dec 2003 16:25: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 QAA11894 for ; Tue, 2 Dec 2003 16:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARI1f-0001Gk-00 for mip4@ietf.org; Tue, 02 Dec 2003 16:25:43 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARI1e-0001GL-00 for mip4@ietf.org; Tue, 02 Dec 2003 16:25:42 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARI0X-0000W9-00; Tue, 02 Dec 2003 22:24:33 +0100 Date: Tue, 2 Dec 2003 22:24:27 +0100 From: Henrik Levkowetz To: Pete McCann Cc: mip4@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031202222427.590361f6.henrik@levkowetz.com> In-Reply-To: <16332.63289.436267.968198@gargle.gargle.HOWL> References: <16322.26357.232206.379182@gargle.gargle.HOWL> <16332.63289.436267.968198@gargle.gargle.HOWL> 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 Pete Tuesday 2 December 2003, Pete wrote: > One more late comment on this draft (I don't have an opinion at this > time on whether it should be advanced): Ok > Is it required that all mobility agents configured by this option be > on-link? That seems to be implied by text like the following: > > > H > > Home agent. This agent offers service as a home agent on the link > > on which this mobility agent announcement is sent. > > > > F > > Foreign agent. This agent offers service as a foreign agent on > > the link on which this mobility agent announcement is sent. > > But is it really necessary? For example, you should be able to > configure a home agent that is on a remote link, right? Then your > DHCP-configured address could be used like a co-located CoA for a MIP > registration, and you could keep the HA for subsequent handoffs. Yes. Quite right. The text implies it, but unnecessarily. > This might be a good way to, for example, configure an HA in the local > network while roaming, but when you haven't deployed Mobile IP FAs, > and you want to centralize the HAs on links other than the access > links. Not sure I see exactly what you mean here. Are you thinking in terms of virtual home networks / never-at-home mobiles? > I assume this sort of functionality would be supported by the existing > Mobile IP Home Agent option specified in RFC 2132. Yes; if you only want to configure an HA the Home Agent option should be sufficient. I originally wrote a draft defining only an FA option, (as that's what we needed) but as the numbers of fields grew, and I included almost all of the regular advertisement fields, I thought I might just as well make it general. Also, as the number of available dhcp option codes are quite limited, I thought I'd define this as a more general option with sub-options so as to make room for possible future mobility-related options without depleting the option space further. Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 17:43:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19508 for ; Tue, 2 Dec 2003 17: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 1ARJEV-0006Mf-9Q for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 17:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Mh3ST024459 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 17: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 1ARJEV-0006MQ-5I for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 17: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 RAA19505 for ; Tue, 2 Dec 2003 17:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJES-0004OX-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 17:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARJES-0004OU-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 17:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJET-0006M6-BQ; Tue, 02 Dec 2003 17: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 1ARJEC-0006Ls-Gb for mip4@optimus.ietf.org; Tue, 02 Dec 2003 17:42: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 RAA19502 for ; Tue, 2 Dec 2003 17:42:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJE9-0004OQ-00 for mip4@ietf.org; Tue, 02 Dec 2003 17:42:42 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ARJE9-0004OE-00 for mip4@ietf.org; Tue, 02 Dec 2003 17:42:41 -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 hB2MfdF03281; Tue, 2 Dec 2003 16:42:00 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB2MeQo10949; Tue, 2 Dec 2003 16:40: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 HPAHMX-00011C-00; Tue, 02 Dec 2003 17:40:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16333.5322.823267.305132@gargle.gargle.HOWL> Date: Tue, 2 Dec 2003 16:40:10 -0600 From: Pete McCann To: Henrik Levkowetz Cc: mip4@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt In-Reply-To: <20031202222427.590361f6.henrik@levkowetz.com> References: <16322.26357.232206.379182@gargle.gargle.HOWL> <16332.63289.436267.968198@gargle.gargle.HOWL> <20031202222427.590361f6.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, Henrik Levkowetz writes: > > This might be a good way to, for example, configure an HA in the local > > network while roaming, but when you haven't deployed Mobile IP FAs, > > and you want to centralize the HAs on links other than the access > > links. > > Not sure I see exactly what you mean here. Are you thinking in terms > of virtual home networks / never-at-home mobiles? That's a possible use case but not the only one. MNs wouldn't be prevented from going home, it is just that when they initially attach to the network and start a session, they may not be on the same link as the one on which the operator has deployed HAs. The HAs would be in the same network (same administrative domain) but could be on another link. If that link does not provide access, then the MNs would never go home. > > I assume this sort of functionality would be supported by the existing > > Mobile IP Home Agent option specified in RFC 2132. > > Yes; if you only want to configure an HA the Home Agent option should > be sufficient. Ok. > I originally wrote a draft defining only an FA option, (as that's what > we needed) but as the numbers of fields grew, and I included almost all > of the regular advertisement fields, I thought I might just as well make > it general. Yeah, that's the impression I got while reading it. > Also, as the number of available dhcp option codes are quite > limited, I thought I'd define this as a more general option with > sub-options so as to make room for possible future mobility-related > options without depleting the option space further. Ok, but maybe the language describing the H bit (at least) should be touched up a bit. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 2 18:21:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22341 for ; Tue, 2 Dec 2003 18:21: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 1ARJpI-0008H4-HY for mip4-archive@odin.ietf.org; Tue, 02 Dec 2003 18:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2NL4L8031800 for mip4-archive@odin.ietf.org; Tue, 2 Dec 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 1ARJpI-0008Gp-CS for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 18:21: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 SAA22291 for ; Tue, 2 Dec 2003 18:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJpF-00052m-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 18:21:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARJpF-00052j-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 18:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJpF-0008GC-5w; Tue, 02 Dec 2003 18: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 1ARJot-0008F2-La for mip4@optimus.ietf.org; Tue, 02 Dec 2003 18:20: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 SAA22246 for ; Tue, 2 Dec 2003 18:20:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJoo-00050M-00 for mip4@ietf.org; Tue, 02 Dec 2003 18:20:35 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARJoo-00050F-00 for mip4@ietf.org; Tue, 02 Dec 2003 18:20:34 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARJmh-00029o-00; Wed, 03 Dec 2003 00:18:23 +0100 Date: Wed, 3 Dec 2003 00:17:05 +0100 From: Henrik Levkowetz To: Pete McCann Cc: mip4@ietf.org Subject: Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031203001705.67393160.henrik@levkowetz.com> In-Reply-To: <16333.5322.823267.305132@gargle.gargle.HOWL> References: <16322.26357.232206.379182@gargle.gargle.HOWL> <16332.63289.436267.968198@gargle.gargle.HOWL> <20031202222427.590361f6.henrik@levkowetz.com> <16333.5322.823267.305132@gargle.gargle.HOWL> 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__3_Dec_2003_00_17_05_+0100_/YW48r_Ghn6SQSj." 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__3_Dec_2003_00_17_05_+0100_/YW48r_Ghn6SQSj. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Pete, Tuesday 2 December 2003, Pete wrote: > Henrik Levkowetz writes: > > > This might be a good way to, for example, configure an HA in the local > > > network while roaming, but when you haven't deployed Mobile IP FAs, > > > and you want to centralize the HAs on links other than the access > > > links. > > > > Not sure I see exactly what you mean here. Are you thinking in terms > > of virtual home networks / never-at-home mobiles? > > That's a possible use case but not the only one. MNs wouldn't be > prevented from going home, it is just that when they initially attach > to the network and start a session, they may not be on the same link > as the one on which the operator has deployed HAs. The HAs would be > in the same network (same administrative domain) but could be on > another link. If that link does not provide access, then the MNs > would never go home. Ok, so you're here thinking of the dhcp assignment of HA as a provisioning mechanism, I guess. In combination with the dynamic HA assignment draft it would be a way of provisioning the first HA to contact (now called the Requested HA in that draft), for instance. > > > I assume this sort of functionality would be supported by the existing > > > Mobile IP Home Agent option specified in RFC 2132. > > > > Yes; if you only want to configure an HA the Home Agent option should > > be sufficient. > > Ok. > > > I originally wrote a draft defining only an FA option, (as that's what > > we needed) but as the numbers of fields grew, and I included almost all > > of the regular advertisement fields, I thought I might just as well make > > it general. > > Yeah, that's the impression I got while reading it. Right :-) > > Also, as the number of available dhcp option codes are quite > > limited, I thought I'd define this as a more general option with > > sub-options so as to make room for possible future mobility-related > > options without depleting the option space further. > > Ok, but maybe the language describing the H bit (at least) should be > touched up a bit. Yes, I'll take care of that. Henrik --Signature=_Wed__3_Dec_2003_00_17_05_+0100_/YW48r_Ghn6SQSj. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zR17eVhrtTJkXCMRAjBJAJ0fxDp/g1uOygffaoqCqZ+nbP3F4QCgnFx+ /fcVSLKC1iORn1BDmrG15gU= =Um+7 -----END PGP SIGNATURE----- --Signature=_Wed__3_Dec_2003_00_17_05_+0100_/YW48r_Ghn6SQSj.-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 3 08:45:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14651 for ; Wed, 3 Dec 2003 08:45: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 1ARXJS-0005cZ-5G for mip4-archive@odin.ietf.org; Wed, 03 Dec 2003 08:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Dj6WL021601 for mip4-archive@odin.ietf.org; Wed, 3 Dec 2003 08:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXJR-0005cK-Ul for mip4-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 08: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 IAA14648 for ; Wed, 3 Dec 2003 08:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJQ-00013y-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 08:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARXJQ-00013v-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 08:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXJP-0005bo-3h; Wed, 03 Dec 2003 08: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 1ARXJJ-0005bL-BL for mip4@optimus.ietf.org; Wed, 03 Dec 2003 08:44: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 IAA14621 for ; Wed, 3 Dec 2003 08:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJI-00013Z-00 for mip4@ietf.org; Wed, 03 Dec 2003 08:44:56 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ARXJH-000134-00 for mip4@ietf.org; Wed, 03 Dec 2003 08:44:55 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 08:44:24 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA1C@ftmail.lab.flarion.com> From: Tsirtsis George To: Henrik Levkowetz Cc: mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-patel-mobileip-experimental- messages-02.txt Date: Wed, 3 Dec 2003 08:44:20 -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: , "I support the adoption of this document as a workgroup document" For what is worth I am also in favour of this work. I would also like to remind people that this is about accepting the draft as a WG item...if that is done I am sure we can figure out the details :-) George -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 3 11:49:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23073 for ; Wed, 3 Dec 2003 11:49: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 1ARaBT-0007tx-F5 for mip4-archive@odin.ietf.org; Wed, 03 Dec 2003 11:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Gn3qo030367 for mip4-archive@odin.ietf.org; Wed, 3 Dec 2003 11:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaBT-0007ti-63 for mip4-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:49: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 LAA23049 for ; Wed, 3 Dec 2003 11:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaBS-0004CD-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 11:49:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARaBR-0004CA-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 11:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaBQ-0007tO-Tt; Wed, 03 Dec 2003 11: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 1ARaB8-0007sn-Hp for mip4@optimus.ietf.org; Wed, 03 Dec 2003 11:48: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 LAA23043 for ; Wed, 3 Dec 2003 11:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaB7-0004Bu-00 for mip4@ietf.org; Wed, 03 Dec 2003 11:48:41 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ARaB6-0004B2-00 for mip4@ietf.org; Wed, 03 Dec 2003 11:48:40 -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 hB3Gm5HW022026; Wed, 3 Dec 2003 17:48:05 +0100 Date: Wed, 3 Dec 2003 17:48:08 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031203174808.0a63ad28.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=_Wed__3_Dec_2003_17_48_08_+0100_+NCv9CmP37GBE_7V" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] 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: , --Signature=_Wed__3_Dec_2003_17_48_08_+0100_+NCv9CmP37GBE_7V 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 Wednesday December 10th, we will ask for the workgroup's viewpoint on making this draft a workgroup item, with the purpose of standardising extensions to dynamically allocate an HA at the time of registration, rather than statically preconfigured, in accordance with workgroup charter item 4. The draft is 21 pages long. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt Regards, Henrik and Pete --Signature=_Wed__3_Dec_2003_17_48_08_+0100_+NCv9CmP37GBE_7V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zhPIeVhrtTJkXCMRAi4JAJ90rPzgVPG5qopAAvM4vm949mHqGQCggArj RmyNrtBBx0YQwOnWOKSbNqo= =5f69 -----END PGP SIGNATURE----- --Signature=_Wed__3_Dec_2003_17_48_08_+0100_+NCv9CmP37GBE_7V-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 3 12:32:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24605 for ; Wed, 3 Dec 2003 12:32:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARar5-00028L-Oa for mip4-archive@odin.ietf.org; Wed, 03 Dec 2003 12:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3HW3Cr008195 for mip4-archive@odin.ietf.org; Wed, 3 Dec 2003 12: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 1ARar5-000286-Js for mip4-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12: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 MAA24587 for ; Wed, 3 Dec 2003 12:31:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARar4-0004p6-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 12:32:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARar3-0004p3-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 12:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARar2-00027l-Oj; Wed, 03 Dec 2003 12:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaqm-00027O-C3 for mip4@optimus.ietf.org; Wed, 03 Dec 2003 12:31: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 MAA24565 for ; Wed, 3 Dec 2003 12:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaqk-0004oJ-00 for mip4@ietf.org; Wed, 03 Dec 2003 12:31:42 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ARaqj-0004lx-00 for mip4@ietf.org; Wed, 03 Dec 2003 12:31: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 hB3HVBHW022640; Wed, 3 Dec 2003 18:31:11 +0100 Date: Wed, 3 Dec 2003 18:31:11 +0100 From: Henrik Levkowetz Cc: mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-patel-mobileip-experimental-messages-02.txt Message-Id: <20031203183111.5258f75b.henrik@levkowetz.com> In-Reply-To: <20031201162605.12c02305.henrik@levkowetz.com> References: <20031201162605.12c02305.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=_Wed__3_Dec_2003_18_31_11_+0100_PgCoMxyRg1.bGF2b" 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=_Wed__3_Dec_2003_18_31_11_+0100_PgCoMxyRg1.bGF2b Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit > "I support the adoption of this document as a workgroup document" I can see the use for this document, and supports its adoption. Having experimental numbers makes sense to me, and I especially hope it will help avoid extension number collisions in the future. Thanks Alpesh and Kent for writing this up. Henrik --Signature=_Wed__3_Dec_2003_18_31_11_+0100_PgCoMxyRg1.bGF2b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zh3feVhrtTJkXCMRAp6CAKDdZZxg5gr/rwQYAoGtJeXxzXdr2gCg392E viB0sFbLheJafhY2OctROPc= =XCWK -----END PGP SIGNATURE----- --Signature=_Wed__3_Dec_2003_18_31_11_+0100_PgCoMxyRg1.bGF2b-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 3 15:30:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04188 for ; Wed, 3 Dec 2003 15:30: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 1ARddO-00029P-5e for mip4-archive@odin.ietf.org; Wed, 03 Dec 2003 15:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KU6YD008267 for mip4-archive@odin.ietf.org; Wed, 3 Dec 2003 15:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddN-000294-Uu for mip4-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 15:30: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 PAA04136 for ; Wed, 3 Dec 2003 15:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARddM-0007fd-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARddL-0007fZ-00 for mip4-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddL-00027P-Rz; Wed, 03 Dec 2003 15: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 1ARdcc-00021B-92 for mip4@optimus.ietf.org; Wed, 03 Dec 2003 15:29:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03997; Wed, 3 Dec 2003 15:29:02 -0500 (EST) Message-Id: <200312032029.PAA03997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Dec 2003 15:29:02 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-nai-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for AAA Network Access Identifiers Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mip4-aaa-nai-01.txt Pages : 10 Date : 2003-12-3 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple Authentication Authorization and Accounting (AAA) servers the reauthentication request may not be received by the same Home AAA server as previous authentication requests. In order for the new Home AAA server to be able to forward the request to the correct Home Agent it has to know the identity of the Home Agent. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-nai-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-aaa-nai-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-aaa-nai-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-3152930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-aaa-nai-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-aaa-nai-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3152930.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 5 06:10:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00151 for ; Fri, 5 Dec 2003 06:10: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 1ASDqj-0007iv-6Z for mip4-archive@odin.ietf.org; Fri, 05 Dec 2003 06:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5BAHsB029685 for mip4-archive@odin.ietf.org; Fri, 5 Dec 2003 06:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASDqi-0007ii-UX for mip4-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 06:10: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 GAA00116 for ; Fri, 5 Dec 2003 06:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASDqe-0006vt-00 for mip4-web-archive@ietf.org; Fri, 05 Dec 2003 06:10:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ASDqe-0006vk-00 for mip4-web-archive@ietf.org; Fri, 05 Dec 2003 06:10:12 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ASDoX-0002Vu-RC for mip4-web-archive@ietf.org; Fri, 05 Dec 2003 06:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASDoW-0007fB-9j; Fri, 05 Dec 2003 06:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS4Ui-0002iL-KD for mip4@optimus.ietf.org; Thu, 04 Dec 2003 20:10: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 UAA29411 for ; Thu, 4 Dec 2003 20:10:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS4UU-0006Bv-00 for mip4@ietf.org; Thu, 04 Dec 2003 20:10:42 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AS4UT-0006Bs-00 for mip4@ietf.org; Thu, 04 Dec 2003 20:10:41 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hB51Af213917 for ; Thu, 4 Dec 2003 17:10:41 -0800 (PST) From: Elizabeth Belding-Royer To: mip4@ietf.org Content-Type: text/plain Message-Id: <1070586644.13966.14.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Dec 2003 17:10:44 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] MobiHoc CFP Deadline Reminder 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 Reminder: The paper submission deadline is December 11, 2003, only a week away!!! ====================================================================== CALL FOR PAPERS The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing MobiHoc 2004 www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. In general this symposium is interested in papers that address networking or computing problems in the context of mobile and wireless ad hoc networks, ad hoc computing systems, and sensor networks, with the focus being on issues above the physical layer. Specific topics of interest include the following: * Routing protocols (unicast, multicast, geocast, content-based, etc.) * Media access techniques * Transport-layer issues * Hardware and software platforms, systems, and testbeds * Applications for ad hoc networks * Power-aware, low-power, and energy-efficient designs * Quality-of-service issues * Security and fault tolerance issues * Self-configuration in ad hoc networks * Processing and fusion of data in sensor networks * Location discovery and management * Timing synchronization * Distributed algorithms for ad hoc networks * Biologically inspired mechanisms * Ad hoc networks of autonomous intelligent systems * Analytic methods and modeling for performance evaluation * Cross-layer interactions, including between higher and physical layers * Other ad hoc networking and computing topics above the physical layer Please consult the program co-chairs Charlie Perkins and Leandros Tassiulas if you are uncertain whether your paper falls within the scope of the symposium. SUBMISSION INSTRUCTIONS: All submissions will be handled electronically and must be in PDF or PostScript format. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. Accepted papers will be published in the symposium proceedings. We will adopt a double-blind process for paper review, where the identities of the authors are withheld from the reviewers. Authors' names and their affiliations must not be revealed or mentioned anywhere in the paper or in the PDF or PostScript file. Submitted papers should describe original research, not published and not currently under review for any other conference or journal. Papers not following these guidelines will be summarily rejected. To submit a paper, please refer to the paper submission link at the conference website, www.sigmobile.org/mobihoc/2004/. Questions about the submission process should be directed to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter for the symposium. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair, Maria Papadopouli by the paper submission deadline below. IMPORTANT DATES: Paper Submission Deadline December 11, 2003 Notification of Acceptance March 10, 2004 Camera-ready version Due March 25, 2004 Please visit the MobiHoc 2004 Home Page at www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai or to for any questions or for more information about the symposium. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 8 00:31:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14086 for ; Mon, 8 Dec 2003 00:31: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 1ATDz6-00051r-4G for mip4-archive@odin.ietf.org; Mon, 08 Dec 2003 00:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB85V40E019325 for mip4-archive@odin.ietf.org; Mon, 8 Dec 2003 00:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATDz5-00051c-U8 for mip4-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 00: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 AAA14048 for ; Mon, 8 Dec 2003 00:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATDz3-0004oQ-00 for mip4-web-archive@ietf.org; Mon, 08 Dec 2003 00:31:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATDz2-0004oM-00 for mip4-web-archive@ietf.org; Mon, 08 Dec 2003 00: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 1ATDz4-00050u-Cx; Mon, 08 Dec 2003 00: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 1ATDyP-000500-Dv for mip4@optimus.ietf.org; Mon, 08 Dec 2003 00:30:21 -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 AAA14033 for ; Mon, 8 Dec 2003 00:30:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATDyM-0004o6-00 for mip4@ietf.org; Mon, 08 Dec 2003 00:30:18 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ATDyM-0004np-00 for mip4@ietf.org; Mon, 08 Dec 2003 00:30:18 -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 hB85SJZ18096; Sun, 7 Dec 2003 23:28:40 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hB85SID23888; Sun, 7 Dec 2003 23:28: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 HPK9UM-0001LS-00; Mon, 08 Dec 2003 00:27:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16340.3036.536416.497843@gargle.gargle.HOWL> Date: Sun, 7 Dec 2003 23:27:56 -0600 From: Pete McCann To: mip4@ietf.org Cc: Henrik Levkowetz Subject: Re: [Mip4] Summary: WG adoption call on draft-patel-mobileip-experimental-messages-02.txt In-Reply-To: <20031203183111.5258f75b.henrik@levkowetz.com> References: <20031201162605.12c02305.henrik@levkowetz.com> <20031203183111.5258f75b.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 Looking back over the responses received to date, it looks like we have seen several voices in favor of adopting this item and not a single WG member has spoken up in opposition. So, I think it's fair to say that a consensus exists for adopting this item. There was some constructive discussion around the addition of an experimental subtype code, which I think can be handled in due course by the working group. Alpesh, go ahead and submit the current version as draft-ietf-mip4-experimental-messages-00.txt. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 9 15:40:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14829 for ; Tue, 9 Dec 2003 15:40: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 1AToeP-0000DA-Ky for mip4-archive@odin.ietf.org; Tue, 09 Dec 2003 15:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Ke905000805 for mip4-archive@odin.ietf.org; Tue, 9 Dec 2003 15:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToeO-0000Cs-P4 for mip4-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 15:40: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 PAA14785 for ; Tue, 9 Dec 2003 15:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AToeN-0007b8-00 for mip4-web-archive@ietf.org; Tue, 09 Dec 2003 15:40:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AToeM-0007b4-00 for mip4-web-archive@ietf.org; Tue, 09 Dec 2003 15:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToeM-0000B3-6a; Tue, 09 Dec 2003 15:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToe6-00009O-KY for mip4@optimus.ietf.org; Tue, 09 Dec 2003 15:39:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14698; Tue, 9 Dec 2003 15:39:34 -0500 (EST) Message-Id: <200312092039.PAA14698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Dec 2003 15:39:34 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-experimental-messages-00.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Experimental Message, Extension and Error Codes for Mobile IPv4 Author(s) : A. Patel Filename : draft-ietf-mip4-experimental-messages-00.txt Pages : 9 Date : 2003-12-9 Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purpose, to evaluate enhancements to Mobile IPv4 messages before formal standards proposal. Mobile IPv4 defines a general Extension mechanism to allow optional information to be carried by Mobile IP control messages. Extensions are not skippable, if defined in range [0- 127] and skippable, if defined in range [128-255]. This document reserves extension types in both the skippable and non-skippable range for experimental use. Also, Mobile IPv4 defines error codes for use by FA [64-127] and HA [128-192]. This document reserves an error code in both these ranges for experimental use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-experimental-messages-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-experimental-messages-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-experimental-messages-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-9160056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-experimental-messages-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-experimental-messages-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-9160056.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 10 17:31:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22071 for ; Wed, 10 Dec 2003 17:31: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 1AUCrI-0002jM-Gz for mip4-archive@odin.ietf.org; Wed, 10 Dec 2003 17:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAMV4Ap010492 for mip4-archive@odin.ietf.org; Wed, 10 Dec 2003 17:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCrI-0002j9-C4 for mip4-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 17: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 RAA22022 for ; Wed, 10 Dec 2003 17:31:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCrF-0003i8-00 for mip4-web-archive@ietf.org; Wed, 10 Dec 2003 17:31:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUCrE-0003i4-00 for mip4-web-archive@ietf.org; Wed, 10 Dec 2003 17: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 1AUCrG-0002ip-80; Wed, 10 Dec 2003 17: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 1AUCr9-0002i7-Sv for mip4@optimus.ietf.org; Wed, 10 Dec 2003 17:30: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 RAA21985 for ; Wed, 10 Dec 2003 17:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCr6-0003hF-00 for mip4@ietf.org; Wed, 10 Dec 2003 17:30:52 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AUCr6-0003hB-00 for mip4@ietf.org; Wed, 10 Dec 2003 17:30:52 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AUCr6-0000II-00; Wed, 10 Dec 2003 23:30:52 +0100 Date: Wed, 10 Dec 2003 23:30:44 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20031210233044.69e3e853.henrik@levkowetz.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 Subject: [Mip4] WG adoption call 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a call to assess the support in the workgroup for adoption of "draft-kulkarni-mobileip-dynamic-assignment-02.txt" as a workgroup document with the purpose of standardising extensions to dynamically allocate an HA at the time of registration, rather than statically preconfigured, in accordance with workgroup charter item 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt If you have no comments on the draft at this time, and supports its adoption, simply respond with a line containing something like "I support the adoption of this document as a workgroup document" If you have no comments on the draft at this time, but *don't* supports its adoption, simply respond with a line containing something like "I don't support the adoption of this document as a workgroup document" If you have comments, please use a line like one of the two quoted above, and supplement this with your comments. Regards, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Dec 10 17:33:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22316 for ; Wed, 10 Dec 2003 17:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCtB-0002oB-Ob for mip4-archive@odin.ietf.org; Wed, 10 Dec 2003 17:33:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAMX1ES010789 for mip4-archive@odin.ietf.org; Wed, 10 Dec 2003 17: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 1AUCtB-0002nw-Jd for mip4-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 17:33: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 RAA22285 for ; Wed, 10 Dec 2003 17:32:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCt8-0003lZ-00 for mip4-web-archive@ietf.org; Wed, 10 Dec 2003 17:32:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUCt8-0003lW-00 for mip4-web-archive@ietf.org; Wed, 10 Dec 2003 17:32:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCtA-0002me-Nt; Wed, 10 Dec 2003 17:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUCsu-0002mD-5d for mip4@optimus.ietf.org; Wed, 10 Dec 2003 17:32: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 RAA22263 for ; Wed, 10 Dec 2003 17:32:40 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUCsr-0003lF-00 for mip4@ietf.org; Wed, 10 Dec 2003 17:32:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUCsq-0003lC-00 for mip4@ietf.org; Wed, 10 Dec 2003 17:32:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBAMWen04246 for ; Thu, 11 Dec 2003 00:32:40 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Dec 2003 00:32:39 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 14:32:12 -0800 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: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt Date: Wed, 10 Dec 2003 16:32:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBB54@daebe007.americas.nokia.com> Thread-Topic: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt Thread-Index: AcO/bVK2SW08QicTTf2YbmlG5IxsywAABKAA To: , Cc: X-OriginalArrivalTime: 10 Dec 2003 22:32:12.0828 (UTC) FILETIME=[74CA95C0:01C3BF6D] 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 I support the adoption of this document as a WG doc. -Basavaraj >=20 >=20 > This is a call to assess the support in the workgroup for adoption > of "draft-kulkarni-mobileip-dynamic-assignment-02.txt" as a workgroup > document with the purpose of standardising extensions to dynamically > allocate an HA at the time of registration, rather than statically > preconfigured, in accordance with workgroup charter item 4. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dy namic-assignment-02.txt If you have no comments on the draft at this time, and supports its adoption, simply respond with a line containing something like "I support the adoption of this document as a workgroup document" If you have no comments on the draft at this time, but *don't* supports its adoption, simply respond with a line containing something like "I don't support the adoption of this document as a workgroup document" If you have comments, please use a line like one of the two quoted above, and supplement this with your comments. Regards, Henrik --=20 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 Thu Dec 11 04:03:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22827 for ; Thu, 11 Dec 2003 04:03: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 1AUMiv-0002Ho-Pb for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 04:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB935pD008769 for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 04:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMiu-0002HF-9K for mip4-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04:03: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 EAA22809 for ; Thu, 11 Dec 2003 04:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUMir-0006CA-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 04:03:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUMiq-0006C7-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 04:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMir-0002GC-E0; Thu, 11 Dec 2003 04: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 1AUMhx-0002Ai-Hr for mip4@optimus.ietf.org; Thu, 11 Dec 2003 04:02: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 EAA22779 for ; Thu, 11 Dec 2003 04:02:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUMhu-0006Ak-00 for mip4@ietf.org; Thu, 11 Dec 2003 04:02:02 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AUMht-0006AU-00 for mip4@ietf.org; Thu, 11 Dec 2003 04:02:01 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBB920Y9020731; Thu, 11 Dec 2003 18:02:01 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBB920oA006431; Thu, 11 Dec 2003 18:02:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id UAA06429 ; Thu, 11 Dec 2003 18:02:00 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id SAA21580; Thu, 11 Dec 2003 18:02:00 +0900 (JST) Received: by toshiba.co.jp id SAA20826; Thu, 11 Dec 2003 18:01:46 +0900 (JST) Message-Id: <200312110901.SAA20826@toshiba.co.jp> Date: Thu, 11 Dec 2003 00:01:45 -0800 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt To: Henrik Levkowetz Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20031210233044.69e3e853.henrik@levkowetz.com> References: <20031210233044.69e3e853.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: , "I support the adoption of this document as a workgroup document" Thanks. -Yoshi Yoshiyuki Tsuda Corporate R&D Center, Toshiba Corporation at Wed, 10 Dec 2003 23:30:44 +0100 Henrik Levkowetz wrote: > This is a call to assess the support in the workgroup for adoption >of "draft-kulkarni-mobileip-dynamic-assignment-02.txt" as a workgroup >document with the purpose of standardising extensions to dynamically >allocate an HA at the time of registration, rather than statically >preconfigured, in accordance with workgroup charter item 4. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt > >If you have no comments on the draft at this time, and supports its >adoption, simply respond with a line containing something like > > "I support the adoption of this document as a workgroup document" > > >If you have no comments on the draft at this time, but *don't* supports >its adoption, simply respond with a line containing something like > > "I don't support the adoption of this document as a workgroup document" > > >If you have comments, please use a line like one of the two quoted >above, and supplement this with your comments. > > > Regards, > > Henrik > >-- >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 Thu Dec 11 04:17:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23056 for ; Thu, 11 Dec 2003 04:17: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 1AUMwU-0002sr-2P for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 04:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB9H5qY011051 for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 04:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMwR-0002sA-8u for mip4-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04:17: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 EAA23052 for ; Thu, 11 Dec 2003 04:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUMwN-0006Nz-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 04:16:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUMwN-0006Nw-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 04:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMwP-0002rp-Pd; Thu, 11 Dec 2003 04:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMvy-0002rA-Su for mip4@optimus.ietf.org; Thu, 11 Dec 2003 04:16: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 EAA23046 for ; Thu, 11 Dec 2003 04:16:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUMvv-0006Ni-00 for mip4@ietf.org; Thu, 11 Dec 2003 04:16:31 -0500 Received: from mail.birdstep.com ([80.239.52.35]) by ietf-mx with esmtp (Exim 4.12) id 1AUMvu-0006N5-00 for mip4@ietf.org; Thu, 11 Dec 2003 04:16:30 -0500 Received: from espenlaptop (dhcp-12-255.birdstep.com [10.0.12.255]) by mail.birdstep.com (8.12.8/8.12.8) with SMTP id hBB9G1iP031355; Thu, 11 Dec 2003 10:16:01 +0100 Reply-To: From: "Espen Klovning" To: "Henrik Levkowetz" Cc: Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt Date: Thu, 11 Dec 2003 10:13:07 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200312110901.SAA20826@toshiba.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 "I support the adoption of this document as a workgroup document" espen Espen Klovning Birdstep Technology -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Dec 11 06:28:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25675 for ; Thu, 11 Dec 2003 06:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUOzC-0007E6-QI for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 06:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBBS2x5027775 for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 06:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUOzC-0007Du-KP for mip4-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 06:28: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 GAA25664 for ; Thu, 11 Dec 2003 06:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUOz8-0000Zp-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 06:27:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUOz7-0000Zm-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 06:27:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUOzA-0007DZ-UG; Thu, 11 Dec 2003 06: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 1AUOyV-0007D1-4Z for mip4@optimus.ietf.org; Thu, 11 Dec 2003 06:27: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 GAA25630 for ; Thu, 11 Dec 2003 06:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUOyQ-0000Yp-00 for mip4@ietf.org; Thu, 11 Dec 2003 06:27:14 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUOyQ-0000YV-00 for mip4@ietf.org; Thu, 11 Dec 2003 06:27:14 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Dec 2003 06:26:45 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA5A@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Henrik Levkowetz'" , mip4@ietf.org Cc: Pete McCann Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Thu, 11 Dec 2003 06:26:41 -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: , "I support the adoption of this document as a workgroup document" A little bit more thought should be put into redirection from one assigned HA to another. This is the case where a MN is registered with HAx and potentially has active sessions based on the assigned HoAx. Based on section 4.2.2, HAx may for example detect that the MN is moving too far away from HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current text the MN has now no choice but dropping HoAx (and all its associated sessions) to register with HAy which should provide HoAy. This will cause sessions to drop for the benefit of optimizing routing...not ideal IMO. One way to avoid this is to introduce a flag that specifies the redirection as optional or compulsory. If it is optional the MN should be able to stay with HAx for a while longer (e.g.: until current sessions stop and MN is idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with flag=optional) to be attached to positive RREP rather than rejections. If, however, flag=compulsory (due to policy or other reasons) then the MN will have to register with HAy immediately per current draft and REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP. Thoughts? Finally, I think the draft would benefit from some clarification about how dynamic/static HoA allocation is affected by HA redirection. When HA redirection is used for load balancing (i.e.: all HAs are likely to be able to handle all HoA prefixes) MNs with static HoAs may be redirect. This can not be done if the HA redirection is used to provide a local HA to the MN in which case the assigned HAs are not likely to support all the HoA prefixes. Regards George -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Dec 11 18:42:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03236 for ; Thu, 11 Dec 2003 18:42: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 1AUaRW-00080c-TF for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 18:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBNg2Pd030782 for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 18:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaRW-00080P-O9 for mip4-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 18:42: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 SAA03210 for ; Thu, 11 Dec 2003 18:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaRT-0005eR-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 18:41:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUaRT-0005eN-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 18:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaRU-000803-Je; Thu, 11 Dec 2003 18:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaQZ-0007zQ-PN for mip4@optimus.ietf.org; Thu, 11 Dec 2003 18: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 SAA03188 for ; Thu, 11 Dec 2003 18:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaQW-0005e1-00 for mip4@ietf.org; Thu, 11 Dec 2003 18:41:00 -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 1AUaQW-0005dv-00 for mip4@ietf.org; Thu, 11 Dec 2003 18:41:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 15:42:55 +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 hBBNeNBN014774; Thu, 11 Dec 2003 15:40:23 -0800 (PST) Received: from kleung-w2k01.cisco.com ([128.107.176.244]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK09939; Thu, 11 Dec 2003 15:40:22 -0800 (PST) Message-Id: <4.3.2.7.2.20031211151743.02a64220@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Dec 2003 15:40:22 -0800 To: Tsirtsis George From: Kent Leung Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Cc: "'Henrik Levkowetz'" , mip4@ietf.org, Pete McCann In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA5A@ftmail.lab.flarion. 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: , At 06:26 AM 12/11/2003 -0500, Tsirtsis George wrote: > "I support the adoption of this document as a workgroup document" > > >A little bit more thought should be put into redirection from one assigned >HA to another. This is the case where a MN is registered with HAx and >potentially has active sessions based on the assigned HoAx. Based on section >4.2.2, HAx may for example detect that the MN is moving too far away from >HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a >REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current >text the MN has now no choice but dropping HoAx (and all its associated >sessions) to register with HAy which should provide HoAy. This will cause >sessions to drop for the benefit of optimizing routing...not ideal IMO. Right. The assumption is that the MN is intelligent enough to decide exactly when to re-anchor with a new HA (such as in idle state). While MN has an active session, it needs to maintain HoAx by setting the HA Address field to HAx and not AZOA. >One way to avoid this is to introduce a flag that specifies the redirection >as optional or compulsory. If it is optional the MN should be able to stay >with HAx for a while longer (e.g.: until current sessions stop and MN is >idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with >flag=optional) to be attached to positive RREP rather than rejections. If, >however, flag=compulsory (due to policy or other reasons) then the MN will >have to register with HAy immediately per current draft and >REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP. > >Thoughts? Redirection is optional or compulsory based on the HA address field being set to HAx or AZOA. If MN wants to stay with HAx until the active session terminates, then the HA address field is set to HAx. If MN don't care which HA is being used, and want optimal routing, then AZOA should be used in RRQ. Does this satisfy your needs? >Finally, I think the draft would benefit from some clarification about how >dynamic/static HoA allocation is affected by HA redirection. When HA >redirection is used for load balancing (i.e.: all HAs are likely to be able >to handle all HoA prefixes) MNs with static HoAs may be redirect. This can >not be done if the HA redirection is used to provide a local HA to the MN in >which case the assigned HAs are not likely to support all the HoA prefixes. Right, we should add more content on this topic. My take on this is that for RRQs with static HoAs, the HoA field provides indication to the entity that's doing redirection to reach the proper HA (one that has the HoA subnet). Kent -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Dec 11 18:46:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03355 for ; Thu, 11 Dec 2003 18:46:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaVP-0008I8-5k for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 18:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBNk39q031866 for mip4-archive@odin.ietf.org; Thu, 11 Dec 2003 18: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 1AUaVO-0008Hr-UF for mip4-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 18: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 SAA03344 for ; Thu, 11 Dec 2003 18:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaVL-0005iE-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 18:46:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUaVL-0005iA-00 for mip4-web-archive@ietf.org; Thu, 11 Dec 2003 18:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaVN-0008GQ-VZ; Thu, 11 Dec 2003 18:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaUs-0008Cm-9D for mip4@optimus.ietf.org; Thu, 11 Dec 2003 18:45:30 -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 SAA03319 for ; Thu, 11 Dec 2003 18:45:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaUp-0005hv-00 for mip4@ietf.org; Thu, 11 Dec 2003 18:45:27 -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 1AUaUo-0005ho-00 for mip4@ietf.org; Thu, 11 Dec 2003 18:45:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Dec 2003 15:47:02 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBBNisAt008664; Thu, 11 Dec 2003 15:44:55 -0800 (PST) Received: from cisco.com (naveenpk-u10.cisco.com [128.107.162.121]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANI03489; Thu, 11 Dec 2003 15:44:51 -0800 (PST) Message-ID: <3FD90173.7050308@cisco.com> Date: Thu, 11 Dec 2003 15:44:51 -0800 From: Naveen Paulkandasamy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org, Pete McCann Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <20031210233044.69e3e853.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 "I support the adoption of this document as a workgroup document" -naveen. Henrik Levkowetz wrote: > > This is a call to assess the support in the workgroup for adoption > of "draft-kulkarni-mobileip-dynamic-assignment-02.txt" as a workgroup > document with the purpose of standardising extensions to dynamically > allocate an HA at the time of registration, rather than statically > preconfigured, in accordance with workgroup charter item 4. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kulkarni-mobileip-dynamic-assignment-02.txt > > If you have no comments on the draft at this time, and supports its > adoption, simply respond with a line containing something like > > "I support the adoption of this document as a workgroup document" > > > If you have no comments on the draft at this time, but *don't* supports > its adoption, simply respond with a line containing something like > > "I don't support the adoption of this document as a workgroup document" > > > If you have comments, please use a line like one of the two quoted > above, and supplement this with your comments. > > > Regards, > > Henrik > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 05:08:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03424 for ; Fri, 12 Dec 2003 05:08:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkDS-0003Qb-Fq for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 05:08:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCA8AUt013144 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 05:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkDM-0003Pv-NT for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 05:08: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 FAA03418 for ; Fri, 12 Dec 2003 05:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUkDJ-0001Uu-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 05:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUkDJ-0001Ur-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 05:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkDK-0003PM-9S; Fri, 12 Dec 2003 05:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkCX-0003FJ-HE for mip4@optimus.ietf.org; Fri, 12 Dec 2003 05:07: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 FAA03412 for ; Fri, 12 Dec 2003 05:07:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUkCU-0001TD-00 for mip4@ietf.org; Fri, 12 Dec 2003 05:07:10 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUkCT-0001SN-00 for mip4@ietf.org; Fri, 12 Dec 2003 05:07:09 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 05:06:39 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA76@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Kent Leung'" Cc: mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 05:06:27 -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: , Inline... -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com] Sent: Thursday, December 11, 2003 11:40 PM To: Tsirtsis George Cc: 'Henrik Levkowetz'; mip4@ietf.org; Pete McCann Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt At 06:26 AM 12/11/2003 -0500, Tsirtsis George wrote: > "I support the adoption of this document as a workgroup document" > > >A little bit more thought should be put into redirection from one assigned >HA to another. This is the case where a MN is registered with HAx and >potentially has active sessions based on the assigned HoAx. Based on section >4.2.2, HAx may for example detect that the MN is moving too far away from >HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a >REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current >text the MN has now no choice but dropping HoAx (and all its associated >sessions) to register with HAy which should provide HoAy. This will cause >sessions to drop for the benefit of optimizing routing...not ideal IMO. Right. The assumption is that the MN is intelligent enough to decide exactly when to re-anchor with a new HA (such as in idle state). While MN has an active session, it needs to maintain HoAx by setting the HA Address field to HAx and not AZOA. GT> Section 4.2.2 does not seem to say this. Instead, it says that the RREQ sent by the MN may have HA = (ALL-ZERO-ONE-ADDR OR unicast address)....see packet format in step 1&2. In EITHER case the HA is able to reject and redirect (step 3). >One way to avoid this is to introduce a flag that specifies the redirection >as optional or compulsory. If it is optional the MN should be able to stay >with HAx for a while longer (e.g.: until current sessions stop and MN is >idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with >flag=optional) to be attached to positive RREP rather than rejections. If, >however, flag=compulsory (due to policy or other reasons) then the MN will >have to register with HAy immediately per current draft and >REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP. > >Thoughts? Redirection is optional or compulsory based on the HA address field being set to HAx or AZOA. If MN wants to stay with HAx until the active session terminates, then the HA address field is set to HAx. If MN don't care which HA is being used, and want optimal routing, then AZOA should be used in RRQ. Does this satisfy your needs? GT> Almost. Maybe both things should be possible. If the MN wants to optimize routing then it should be able to send an ALL-ZERO-ONE-ADDR to the HA. This assumes that the MN has some understanding of the topology which may be true in some cases. In other cases, however, it might be the HA that has understanding of the topology, in which case the HA should be able to send either: - a *positive* RREP with an *optional* REDIRECTED-HA-ADDRESS extension OR - a *negative* RREP with a *compulsory* REDIRECTED-HA-ADDRESS extension. >Finally, I think the draft would benefit from some clarification about how >dynamic/static HoA allocation is affected by HA redirection. When HA >redirection is used for load balancing (i.e.: all HAs are likely to be able >to handle all HoA prefixes) MNs with static HoAs may be redirect. This can >not be done if the HA redirection is used to provide a local HA to the MN in >which case the assigned HAs are not likely to support all the HoA prefixes. Right, we should add more content on this topic. My take on this is that for RRQs with static HoAs, the HoA field provides indication to the entity that's doing redirection to reach the proper HA (one that has the HoA subnet). GT> Agreed. Thanks George -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 06:15:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04350 for ; Fri, 12 Dec 2003 06:15:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlGb-0005ak-R7 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 06:15:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCBFTYU021482 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 06:15:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlGb-0005aM-9F for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 06:15: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 GAA04288 for ; Fri, 12 Dec 2003 06:15:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUlGW-0002AC-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 06:15:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUlGW-00029y-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 06:15:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlG8-0005RE-Jg; Fri, 12 Dec 2003 06: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 1AUlFM-0005JA-Us for mip4@optimus.ietf.org; Fri, 12 Dec 2003 06:14:12 -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 GAA04240 for ; Fri, 12 Dec 2003 06:14:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUlFJ-00029D-00 for mip4@ietf.org; Fri, 12 Dec 2003 06:14:09 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUlFI-00028q-00 for mip4@ietf.org; Fri, 12 Dec 2003 06:14:08 -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 hBCBDFQe020977; Fri, 12 Dec 2003 12:13:15 +0100 Date: Fri, 12 Dec 2003 12:13:15 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212121315.11dfa27b.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA76@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA76@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=_Fri__12_Dec_2003_12_13_15_+0100_KP1ZhlwJmDYAPlQ2" 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=_Fri__12_Dec_2003_12_13_15_+0100_KP1ZhlwJmDYAPlQ2 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit George, Kent, My impression of what this draft sets out to do is to provide a mechanism for dynamically assigning a HA at the time of initial registration. Assigning a new HA during an active session for the reasons given in this draft (primarily more optimal routing) does not seem like a magnificient idea, as there is the assumption of different geographic location, and hence different home addresses for the two HA assignments, which means that such a re-assignment during ongoing call will result in disruption of TCP sessions. _Re_-assignment of HA during an active session for reasons like fail-over I believe needs a different handling, and hopefully will be covered to your satisfaction in the dynamic HA re-assignment draft I'm working on, and hopefully will have out in a few weeks. So I'm a bit doubtful about building in options in this draft which will result in session disruption. Henrik On Friday, 12 Dec 2003, George wrote: > > Inline... > > > > -----Original Message----- > > From: Kent Leung [mailto:kleung@cisco.com] > > Sent: Thursday, December 11, 2003 11:40 PM > > To: Tsirtsis George > > Cc: 'Henrik Levkowetz'; mip4@ietf.org; Pete McCann > > Subject: RE: [Mip4] WG adoption call on > > draft-kulkarni-mobileip-dynamic-as signment-02.txt > > > > > > At 06:26 AM 12/11/2003 -0500, Tsirtsis George wrote: > > > > > > > "I support the adoption of this document as a workgroup document" > > > > > > > > >A little bit more thought should be put into redirection from one assigned > > >HA to another. This is the case where a MN is registered with HAx and > > >potentially has active sessions based on the assigned HoAx. Based on > > section > > >4.2.2, HAx may for example detect that the MN is moving too far away from > > >HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a > > >REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current > > >text the MN has now no choice but dropping HoAx (and all its associated > > >sessions) to register with HAy which should provide HoAy. This will cause > > >sessions to drop for the benefit of optimizing routing...not ideal IMO. > > > > > > Right. The assumption is that the MN is intelligent enough to decide > > exactly when > > to re-anchor with a new HA (such as in idle state). While MN has an active > > session, it needs to maintain HoAx by setting the HA Address field to HAx > > and not AZOA. > > GT> Section 4.2.2 does not seem to say this. Instead, it says that the RREQ > sent by the MN may have HA = (ALL-ZERO-ONE-ADDR OR unicast address)....see > packet format in step 1&2. In EITHER case the HA is able to reject and > redirect (step 3). > > > >One way to avoid this is to introduce a flag that specifies the redirection > > >as optional or compulsory. If it is optional the MN should be able to stay > > >with HAx for a while longer (e.g.: until current sessions stop and MN is > > >idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with > > >flag=optional) to be attached to positive RREP rather than rejections. If, > > >however, flag=compulsory (due to policy or other reasons) then the MN will > > >have to register with HAy immediately per current draft and > > >REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP. > > > > > >Thoughts? > > > > Redirection is optional or compulsory based on the HA address field being > > set to > > HAx or AZOA. If MN wants to stay with HAx until the active session > > terminates, then the HA address field is set to HAx. If MN don't care which > > HA > > is being used, and want optimal routing, then AZOA should be used in RRQ. > > > > Does this satisfy your needs? > > > GT> Almost. Maybe both things should be possible. If the MN wants to > optimize routing then it should be able to send an ALL-ZERO-ONE-ADDR to the > HA. This assumes that the MN has some understanding of the topology which > may be true in some cases. In other cases, however, it might be the HA that > has understanding of the topology, in which case the HA should be able to > send either: > - a *positive* RREP with an *optional* REDIRECTED-HA-ADDRESS extension OR > - a *negative* RREP with a *compulsory* REDIRECTED-HA-ADDRESS extension. > > > > > >Finally, I think the draft would benefit from some clarification about how > > >dynamic/static HoA allocation is affected by HA redirection. When HA > > >redirection is used for load balancing (i.e.: all HAs are likely to be able > > >to handle all HoA prefixes) MNs with static HoAs may be redirect. This can > > >not be done if the HA redirection is used to provide a local HA to the MN > > in > > >which case the assigned HAs are not likely to support all the HoA prefixes. > > > > > > Right, we should add more content on this topic. My take on this is that > > for > > RRQs with static HoAs, the HoA field provides indication to the entity > > that's > > doing redirection to reach the proper HA (one that has the HoA subnet). > > > GT> Agreed. --Signature=_Fri__12_Dec_2003_12_13_15_+0100_KP1ZhlwJmDYAPlQ2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2aLLeVhrtTJkXCMRAkxNAKC7hlagBCL8WpTV8UgfKcn4xoFqyQCfQf9p g38ES73MQN1HMRbH11FujCI= =Yc0+ -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_12_13_15_+0100_KP1ZhlwJmDYAPlQ2-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 08:08:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07138 for ; Fri, 12 Dec 2003 08:08:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUn1a-0001EL-Hh for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 08:08:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCD85s4004710 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 08:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUn1Y-0001Dt-9P for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 08:08: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 IAA07078 for ; Fri, 12 Dec 2003 08:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUn1X-00045j-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 08:08:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUn1W-00045g-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 08:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUn1W-0001DY-0h; Fri, 12 Dec 2003 08:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUn12-00016G-On for mip4@optimus.ietf.org; Fri, 12 Dec 2003 08:07: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 IAA07059 for ; Fri, 12 Dec 2003 08:07:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUn11-00043X-00 for mip4@ietf.org; Fri, 12 Dec 2003 08:07: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 1AUn11-00042f-00 for mip4@ietf.org; Fri, 12 Dec 2003 08:07:31 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 08:07:01 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA78@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Henrik Levkowetz'" Cc: "'Kent Leung'" , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 08:06:51 -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: , Henrik, I think the point of my suggestion below is to make sure that session disruption does not take place in the normal case: - MN sends ALL-AERO-ONE-ADDR when idle or - HA sends an HA-Redirect in a positive RREP, in which case MN initiates redirect as soon as idle). I think, however, that it is worth letting the HA redirect a mobile in a compulsory way (HA sends HA redirect in negative RREP) if that is what needs to be done from network perspective (e.g.: topology reasons, overloading etc). Note that MIP already allows session disruptions since an HA can always reject a RREQ in which case sessions will be dropped. HA redirection improves on that by allowing an HA to redirect an MN to another HA rather than dropping it altogether. George P.S: So, does your draft compete with this one? or it solves a different problem? -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Friday, December 12, 2003 11:13 AM To: Tsirtsis George Cc: 'Kent Leung'; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt George, Kent, My impression of what this draft sets out to do is to provide a mechanism for dynamically assigning a HA at the time of initial registration. Assigning a new HA during an active session for the reasons given in this draft (primarily more optimal routing) does not seem like a magnificient idea, as there is the assumption of different geographic location, and hence different home addresses for the two HA assignments, which means that such a re-assignment during ongoing call will result in disruption of TCP sessions. _Re_-assignment of HA during an active session for reasons like fail-over I believe needs a different handling, and hopefully will be covered to your satisfaction in the dynamic HA re-assignment draft I'm working on, and hopefully will have out in a few weeks. So I'm a bit doubtful about building in options in this draft which will result in session disruption. Henrik On Friday, 12 Dec 2003, George wrote: > > Inline... > > > > -----Original Message----- > > From: Kent Leung [mailto:kleung@cisco.com] > > Sent: Thursday, December 11, 2003 11:40 PM > > To: Tsirtsis George > > Cc: 'Henrik Levkowetz'; mip4@ietf.org; Pete McCann > > Subject: RE: [Mip4] WG adoption call on > > draft-kulkarni-mobileip-dynamic-as signment-02.txt > > > > > > At 06:26 AM 12/11/2003 -0500, Tsirtsis George wrote: > > > > > > > "I support the adoption of this document as a workgroup document" > > > > > > > > >A little bit more thought should be put into redirection from one assigned > > >HA to another. This is the case where a MN is registered with HAx and > > >potentially has active sessions based on the assigned HoAx. Based on > > section > > >4.2.2, HAx may for example detect that the MN is moving too far away from > > >HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a > > >REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current > > >text the MN has now no choice but dropping HoAx (and all its associated > > >sessions) to register with HAy which should provide HoAy. This will cause > > >sessions to drop for the benefit of optimizing routing...not ideal IMO. > > > > > > Right. The assumption is that the MN is intelligent enough to decide > > exactly when > > to re-anchor with a new HA (such as in idle state). While MN has an active > > session, it needs to maintain HoAx by setting the HA Address field to HAx > > and not AZOA. > > GT> Section 4.2.2 does not seem to say this. Instead, it says that the RREQ > sent by the MN may have HA = (ALL-ZERO-ONE-ADDR OR unicast address)....see > packet format in step 1&2. In EITHER case the HA is able to reject and > redirect (step 3). > > > >One way to avoid this is to introduce a flag that specifies the redirection > > >as optional or compulsory. If it is optional the MN should be able to stay > > >with HAx for a while longer (e.g.: until current sessions stop and MN is > > >idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with > > >flag=optional) to be attached to positive RREP rather than rejections. If, > > >however, flag=compulsory (due to policy or other reasons) then the MN will > > >have to register with HAy immediately per current draft and > > >REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP. > > > > > >Thoughts? > > > > Redirection is optional or compulsory based on the HA address field being > > set to > > HAx or AZOA. If MN wants to stay with HAx until the active session > > terminates, then the HA address field is set to HAx. If MN don't care which > > HA > > is being used, and want optimal routing, then AZOA should be used in RRQ. > > > > Does this satisfy your needs? > > > GT> Almost. Maybe both things should be possible. If the MN wants to > optimize routing then it should be able to send an ALL-ZERO-ONE-ADDR to the > HA. This assumes that the MN has some understanding of the topology which > may be true in some cases. In other cases, however, it might be the HA that > has understanding of the topology, in which case the HA should be able to > send either: > - a *positive* RREP with an *optional* REDIRECTED-HA-ADDRESS extension OR > - a *negative* RREP with a *compulsory* REDIRECTED-HA-ADDRESS extension. > > > > > >Finally, I think the draft would benefit from some clarification about how > > >dynamic/static HoA allocation is affected by HA redirection. When HA > > >redirection is used for load balancing (i.e.: all HAs are likely to be able > > >to handle all HoA prefixes) MNs with static HoAs may be redirect. This can > > >not be done if the HA redirection is used to provide a local HA to the MN > > in > > >which case the assigned HAs are not likely to support all the HoA prefixes. > > > > > > Right, we should add more content on this topic. My take on this is that > > for > > RRQs with static HoAs, the HoA field provides indication to the entity > > that's > > doing redirection to reach the proper HA (one that has the HoA subnet). > > > GT> Agreed. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 09:02:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08589 for ; Fri, 12 Dec 2003 09:02: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 1AUnrm-0003PI-QZ for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 09:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCE22mN013090 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 09:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUnrm-0003P3-L2 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 09:02: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 JAA08584 for ; Fri, 12 Dec 2003 09:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUnrl-0005YC-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 09:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUnrl-0005Y9-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUnrl-0003Oj-DC; Fri, 12 Dec 2003 09: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 1AUnr5-0003OL-W9 for mip4@optimus.ietf.org; Fri, 12 Dec 2003 09:01: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 JAA08574 for ; Fri, 12 Dec 2003 09:01:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUnr4-0005Xj-00 for mip4@ietf.org; Fri, 12 Dec 2003 09:01:18 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUnr3-0005XJ-00 for mip4@ietf.org; Fri, 12 Dec 2003 09:01:18 -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 hBCE0YQe023393; Fri, 12 Dec 2003 15:00:35 +0100 Date: Fri, 12 Dec 2003 15:00:36 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212150036.3e5ec831.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA78@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA78@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=_Fri__12_Dec_2003_15_00_36_+0100_96pq8IAo6C4D2WvV" 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=_Fri__12_Dec_2003_15_00_36_+0100_96pq8IAo6C4D2WvV Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Friday, 12 Dec 2003, Tsirtsis wrote: > I think the point of my suggestion below is to make sure that session > disruption does not take place in the normal case: > - MN sends ALL-AERO-ONE-ADDR when idle or > - HA sends an HA-Redirect in a positive RREP, in which case MN initiates > redirect as soon as idle). Ok so far, > I think, however, that it is worth letting the HA redirect a mobile in a > compulsory way (HA sends HA redirect in negative RREP) if that is what needs > to be done from network perspective (e.g.: topology reasons, overloading > etc). Yes, but I'm not sure whether it belongs in this draft or in the other. > Note that MIP already allows session disruptions since an HA can always > reject a RREQ in which case sessions will be dropped. HA redirection > improves on that by allowing an HA to redirect an MN to another HA rather > than dropping it altogether. Right, but see below. > P.S: So, does your draft compete with this one? or it solves a different The intention is to _not_ compete. The charter says: Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task. So the draft I'm working on will propose a message which can be originated by the HA, saying in essence "from now on, the registration you had with HA so-and-so will insead be handled by me"; the intention being to support failover, overload etc. One prerequisite for this mechanism is that the two HA's have some way to share state - the most straightforward way being to forward registration request and reply messages from the active HA to the standby HA. So I guess the dividing line would be whether the circumstances were such that you could continue a session, or whether you anyhow would need to break and re-establish. In the latter case, it seems reasonable to make it part of dyn-assignment, in the other case it seems to belong with the upcoming draft (reg-reassignment? failover? xxxx?). Henrik --Signature=_Fri__12_Dec_2003_15_00_36_+0100_96pq8IAo6C4D2WvV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2coEeVhrtTJkXCMRAgF0AJ9H7Fy/cq1F8wOfnxcq/sM97+mhrQCfaPk5 WooAw8XWpJqN8YObeitOSbM= =zJhf -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_15_00_36_+0100_96pq8IAo6C4D2WvV-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 09:14:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08833 for ; Fri, 12 Dec 2003 09:14: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 1AUo3O-0003xK-Ni for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 09:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCEE23S015200 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 09:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUo3O-0003x5-Ag for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 09:14: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 JAA08822 for ; Fri, 12 Dec 2003 09:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUo3M-0005hV-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 09:14:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUo3M-0005hS-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 09:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUo3M-0003wj-M1; Fri, 12 Dec 2003 09: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 1AUo39-0003wS-G1 for mip4@optimus.ietf.org; Fri, 12 Dec 2003 09:13: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 JAA08819 for ; Fri, 12 Dec 2003 09:13:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUo37-0005hO-00 for mip4@ietf.org; Fri, 12 Dec 2003 09:13:45 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUo37-0005hL-00 for mip4@ietf.org; Fri, 12 Dec 2003 09:13:45 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 09:13:10 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA7B@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Henrik Levkowetz'" , Tsirtsis George Cc: "'Kent Leung'" , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 09:12:49 -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: , The discussion was, however, about redirection to an HA that does not necessarily share any state with the current HA. The question is whether such redirection should only be optional or whether optional and compulsory redirection should be allowed....(I prefer the latter). Non of this seems to me to be affecting your draft as you describe below but I will wait for it to come out so I can get the full picture of what is being proposed. Thanks George -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Friday, December 12, 2003 2:01 PM To: Tsirtsis George Cc: 'Kent Leung'; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt On Friday, 12 Dec 2003, Tsirtsis wrote: > I think the point of my suggestion below is to make sure that session > disruption does not take place in the normal case: > - MN sends ALL-AERO-ONE-ADDR when idle or > - HA sends an HA-Redirect in a positive RREP, in which case MN initiates > redirect as soon as idle). Ok so far, > I think, however, that it is worth letting the HA redirect a mobile in a > compulsory way (HA sends HA redirect in negative RREP) if that is what needs > to be done from network perspective (e.g.: topology reasons, overloading > etc). Yes, but I'm not sure whether it belongs in this draft or in the other. > Note that MIP already allows session disruptions since an HA can always > reject a RREQ in which case sessions will be dropped. HA redirection > improves on that by allowing an HA to redirect an MN to another HA rather > than dropping it altogether. Right, but see below. > P.S: So, does your draft compete with this one? or it solves a different The intention is to _not_ compete. The charter says: Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task. So the draft I'm working on will propose a message which can be originated by the HA, saying in essence "from now on, the registration you had with HA so-and-so will insead be handled by me"; the intention being to support failover, overload etc. One prerequisite for this mechanism is that the two HA's have some way to share state - the most straightforward way being to forward registration request and reply messages from the active HA to the standby HA. So I guess the dividing line would be whether the circumstances were such that you could continue a session, or whether you anyhow would need to break and re-establish. In the latter case, it seems reasonable to make it part of dyn-assignment, in the other case it seems to belong with the upcoming draft (reg-reassignment? failover? xxxx?). Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 10:42:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12926 for ; Fri, 12 Dec 2003 10:42: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 1AUpQa-0007qM-8w for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 10:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCFg4Fx030146 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 10:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpQa-0007q9-55 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10:42: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 KAA12914 for ; Fri, 12 Dec 2003 10:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpQW-0007JJ-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 10:42:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpQW-0007JE-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 10:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpQX-0007pn-ML; Fri, 12 Dec 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpQF-0007pX-B4 for mip4@optimus.ietf.org; Fri, 12 Dec 2003 10:41:43 -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 KAA12892 for ; Fri, 12 Dec 2003 10:41:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpQC-0007J5-00 for mip4@ietf.org; Fri, 12 Dec 2003 10:41:40 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUpQB-0007IY-00 for mip4@ietf.org; Fri, 12 Dec 2003 10:41:39 -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 hBCFejQe024692; Fri, 12 Dec 2003 16:40:45 +0100 Date: Fri, 12 Dec 2003 16:40:45 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: Tsirtsis George , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212164045.1ae015ad.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA7B@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA7B@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=_Fri__12_Dec_2003_16_40_45_+0100_HKTXwEiaUwkvqxnu" 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=_Fri__12_Dec_2003_16_40_45_+0100_HKTXwEiaUwkvqxnu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Friday, 12 Dec 2003, George Tsirtsis wrote: > The discussion was, however, about redirection to an HA that does not > necessarily share any state with the current HA. Ok. It wasn't clear to me at first that this was what you desired, rather than what you thought you at best could get... > The question is whether > such redirection should only be optional or whether optional and compulsory > redirection should be allowed....(I prefer the latter). From the viewpoint of the problem the dyn-assignment draft originally aimed to solve, only dynamic assignment at the start of a session was considered and seemed to make sense. If we are now talking about extending this to a mechanism which will break off a session, but include a next-ha in the RRP refusal, I think we need to make sure we have a constituency which needs such a thing, and we have to weigh the benefits against the drawbacks of having a re-assignment mechanism which breaks off the current session. If we're going to have a mechanism to refuse a re-registration with a pointer to another HA, I'd prefer to be able to have it both optional and compulsory, as you seem to prefer too. But I'm not quite sure if the benefits in reduced round-trips of such a solution outweigh the simplicity of the HA simply refusing a registration, and the MN subsequently trying to register a new session and at that time be assigned a new HA, according to the mechanism of the current draft. Possibly it does. > Non of this seems to me to be affecting your draft as you describe below but > I will wait for it to come out so I can get the full picture of what is > being proposed. Fair enough. Henrik --Signature=_Fri__12_Dec_2003_16_40_45_+0100_HKTXwEiaUwkvqxnu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2eF9eVhrtTJkXCMRAtLXAKCHPy6VczL//vvTLM1CUA1eq5vIJQCg4AnM 7gkPtoQcU/wsCV2GDjW04xo= =BsIv -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_16_40_45_+0100_HKTXwEiaUwkvqxnu-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 10:58:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13592 for ; Fri, 12 Dec 2003 10:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpg2-0008Nk-AL for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 10:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCFw2cB032214 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 10: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 1AUpg2-0008NV-2x for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10: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 KAA13578 for ; Fri, 12 Dec 2003 10:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpfz-0007fW-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 10:57:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpfz-0007fT-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 10:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpg0-0008N1-NB; Fri, 12 Dec 2003 10: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 1AUpfm-0008Me-3g for mip4@optimus.ietf.org; Fri, 12 Dec 2003 10:57: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 KAA13572 for ; Fri, 12 Dec 2003 10:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpfj-0007eK-00 for mip4@ietf.org; Fri, 12 Dec 2003 10:57:43 -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 1AUpfj-0007cm-00 for mip4@ietf.org; Fri, 12 Dec 2003 10:57:43 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2003 07:59:44 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBCFvAZ0028425; Fri, 12 Dec 2003 07:57:10 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-706.cisco.com [10.21.98.194]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK62337; Fri, 12 Dec 2003 07:57:09 -0800 (PST) Message-Id: <4.3.2.7.2.20031212075344.01be14e8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Dec 2003 07:57:09 -0800 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Cc: Tsirtsis George , Tsirtsis George , mip4@ietf.org In-Reply-To: <20031212164045.1ae015ad.henrik@levkowetz.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA7B@ftmail.lab.flarion.com> <9E3BA3946476AD4EB94672712B12A85F03AA7B@ftmail.lab.flarion.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: , Right, the solution provided in this draft is for dynamically assigning an HA for initial registration. The mechanism allows the network to choose an HA when MN request with AZOA or notify the MN the assigned HA when MN request an administratively prohibited HA in RRQ. Kent At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: >On Friday, 12 Dec 2003, George Tsirtsis wrote: > > > The discussion was, however, about redirection to an HA that does not > > necessarily share any state with the current HA. > > > Ok. It wasn't clear to me at first that this was what you desired, > rather than what you thought you at best could get... > > > > The question is whether > > such redirection should only be optional or whether optional and compulsory > > redirection should be allowed....(I prefer the latter). > > > From the viewpoint of the problem the dyn-assignment draft originally > aimed to solve, only dynamic assignment at the start of a session was > considered and seemed to make sense. > > If we are now talking about extending this to a mechanism which will > break off a session, but include a next-ha in the RRP refusal, I think > we need to make sure we have a constituency which needs such a thing, > and we have to weigh the benefits against the drawbacks of having > a re-assignment mechanism which breaks off the current session. > > > > If we're going to have a mechanism to refuse a re-registration with > a pointer to another HA, I'd prefer to be able to have it both > optional and compulsory, as you seem to prefer too. But I'm not > quite sure if the benefits in reduced round-trips of such a solution > outweigh the simplicity of the HA simply refusing a registration, and > the MN subsequently trying to register a new session and at that time > be assigned a new HA, according to the mechanism of the current draft. > Possibly it does. > > > > Non of this seems to me to be affecting your draft as you describe > below but > > I will wait for it to come out so I can get the full picture of what is > > being proposed. > > > Fair enough. > > > Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 11:07:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14329 for ; Fri, 12 Dec 2003 11:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpol-0000jd-1l for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11:07:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCG72B9002809 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11: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 1AUpok-0000j2-Dc for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:07: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 LAA14299 for ; Fri, 12 Dec 2003 11:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpoh-00009Z-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpoh-00009Q-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpoi-0000h3-ON; Fri, 12 Dec 2003 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpoZ-0000g5-3c for mip4@optimus.ietf.org; Fri, 12 Dec 2003 11:06: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 LAA14278 for ; Fri, 12 Dec 2003 11:06:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpoW-000093-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:06:48 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUpoW-00006y-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:06:48 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 11:06:14 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA7F@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Kent Leung'" , Henrik Levkowetz Cc: mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 11:06:04 -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: , But the draft clearly *also* talks about redirection for the purpose of routing optimality....mind you I think this is a good thing :-) George -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com] Sent: Friday, December 12, 2003 3:57 PM To: Henrik Levkowetz Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Right, the solution provided in this draft is for dynamically assigning an HA for initial registration. The mechanism allows the network to choose an HA when MN request with AZOA or notify the MN the assigned HA when MN request an administratively prohibited HA in RRQ. Kent At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: >On Friday, 12 Dec 2003, George Tsirtsis wrote: > > > The discussion was, however, about redirection to an HA that does not > > necessarily share any state with the current HA. > > > Ok. It wasn't clear to me at first that this was what you desired, > rather than what you thought you at best could get... > > > > The question is whether > > such redirection should only be optional or whether optional and compulsory > > redirection should be allowed....(I prefer the latter). > > > From the viewpoint of the problem the dyn-assignment draft originally > aimed to solve, only dynamic assignment at the start of a session was > considered and seemed to make sense. > > If we are now talking about extending this to a mechanism which will > break off a session, but include a next-ha in the RRP refusal, I think > we need to make sure we have a constituency which needs such a thing, > and we have to weigh the benefits against the drawbacks of having > a re-assignment mechanism which breaks off the current session. > > > > If we're going to have a mechanism to refuse a re-registration with > a pointer to another HA, I'd prefer to be able to have it both > optional and compulsory, as you seem to prefer too. But I'm not > quite sure if the benefits in reduced round-trips of such a solution > outweigh the simplicity of the HA simply refusing a registration, and > the MN subsequently trying to register a new session and at that time > be assigned a new HA, according to the mechanism of the current draft. > Possibly it does. > > > > Non of this seems to me to be affecting your draft as you describe > below but > > I will wait for it to come out so I can get the full picture of what is > > being proposed. > > > Fair enough. > > > Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 11:27:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15076 for ; Fri, 12 Dec 2003 11:27: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 1AUq86-0001ku-FT for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCGR2Q5006742 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUq86-0001kf-9O for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:27: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 LAA15003 for ; Fri, 12 Dec 2003 11:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUq85-0000dL-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11:27:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUq85-0000dI-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUq84-0001kG-Dh; Fri, 12 Dec 2003 11:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUq7N-0001jm-SH for mip4@optimus.ietf.org; Fri, 12 Dec 2003 11:26: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 LAA14983 for ; Fri, 12 Dec 2003 11:26:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUq7L-0000cS-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:26:15 -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 1AUq7K-0000c1-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:26:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2003 08:28:17 +0000 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 hBCGPgAt011457; Fri, 12 Dec 2003 08:25:42 -0800 (PST) Received: from cisco.com (sjc-vpn3-1045.cisco.com [10.21.68.21]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK64561; Fri, 12 Dec 2003 08:25:40 -0800 (PST) Message-ID: <3FD9EC04.8090707@cisco.com> Date: Fri, 12 Dec 2003 08:25:40 -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: Tsirtsis George CC: "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA7F@ftmail.lab.flarion.com> Content-Type: multipart/alternative; boundary="------------050101010405080006060507" 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: , --------------050101010405080006060507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George - Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/ expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without losing session - probably both methods can be supported?? Alpesh Tsirtsis George wrote: >But the draft clearly *also* talks about redirection for the purpose of >routing optimality....mind you I think this is a good thing :-) > >George >-----Original Message----- >From: Kent Leung [mailto:kleung@cisco.com] >Sent: Friday, December 12, 2003 3:57 PM >To: Henrik Levkowetz >Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org >Subject: Re: [Mip4] WG adoption call on >draft-kulkarni-mobileip-dynamic-as signment-02.txt > > >Right, the solution provided in this draft is for dynamically assigning >an HA for initial registration. The mechanism allows the network to >choose an HA when MN request with AZOA or notify the MN the assigned >HA when MN request an administratively prohibited HA in RRQ. > >Kent > >At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: > > >>On Friday, 12 Dec 2003, George Tsirtsis wrote: >> >> >> >>>The discussion was, however, about redirection to an HA that does not >>>necessarily share any state with the current HA. >>> >>> >> >> Ok. It wasn't clear to me at first that this was what you desired, >> rather than what you thought you at best could get... >> >> >> >> >>>The question is whether >>>such redirection should only be optional or whether optional and >>> >>> >compulsory > > >>>redirection should be allowed....(I prefer the latter). >>> >>> >> >> From the viewpoint of the problem the dyn-assignment draft originally >> aimed to solve, only dynamic assignment at the start of a session was >> considered and seemed to make sense. >> >> If we are now talking about extending this to a mechanism which will >> break off a session, but include a next-ha in the RRP refusal, I think >> we need to make sure we have a constituency which needs such a thing, >> and we have to weigh the benefits against the drawbacks of having >> a re-assignment mechanism which breaks off the current session. >> >> >> >> If we're going to have a mechanism to refuse a re-registration with >> a pointer to another HA, I'd prefer to be able to have it both >> optional and compulsory, as you seem to prefer too. But I'm not >> quite sure if the benefits in reduced round-trips of such a solution >> outweigh the simplicity of the HA simply refusing a registration, and >> the MN subsequently trying to register a new session and at that time >> be assigned a new HA, according to the mechanism of the current draft. >> Possibly it does. >> >> >> >> >>>Non of this seems to me to be affecting your draft as you describe >>> >>> >>below but >> >> >>>I will wait for it to come out so I can get the full picture of what is >>>being proposed. >>> >>> >> >> Fair enough. >> >> >> Henrik >> >> > > > --------------050101010405080006060507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit George -

Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/
expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring
that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without
losing session - probably both methods can be supported??

Alpesh

Tsirtsis George wrote:
But the draft clearly *also* talks about redirection for the purpose of
routing optimality....mind you I think this is a good thing :-)

George
-----Original Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Friday, December 12, 2003 3:57 PM
To: Henrik Levkowetz
Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt


Right, the solution provided in this draft is for dynamically assigning
an HA for initial registration.  The mechanism allows the network to
choose an HA when MN request with AZOA or notify the MN the assigned
HA when MN request an administratively prohibited HA in RRQ.

Kent

At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote:
  
On Friday, 12 Dec 2003, George Tsirtsis wrote:

    
The discussion was, however, about redirection to an HA that does not
necessarily share any state with the current HA.
      
<chair hat off>
  Ok. It wasn't clear to me at first that this was what you desired,
  rather than what you thought you at best could get...
</chair hat off>

    
The question is whether
such redirection should only be optional or whether optional and
      
compulsory
  
redirection should be allowed....(I prefer the latter).
      
<chair hat on>
  From the viewpoint of the problem the dyn-assignment draft originally
  aimed to solve, only dynamic assignment at the start of a session was
  considered and seemed to make sense.

  If we are now talking about extending this to a mechanism which will
  break off a session, but include a next-ha in the RRP refusal, I think
  we need to make sure we have a constituency which needs such a thing,
  and we have to weigh the benefits against the drawbacks of having
  a re-assignment mechanism which breaks off the current session.
</chair hat on>

<chair hat off>
  If we're going to have a mechanism to refuse a re-registration with
  a pointer to another HA, I'd prefer to be able to have it both
  optional and compulsory, as you seem to prefer too. But I'm not
  quite sure if the benefits in reduced round-trips of such a solution
  outweigh the simplicity of the HA simply refusing a registration, and
  the MN subsequently trying to register a new session and at that time
  be assigned a new HA, according to the mechanism of the current draft.
  Possibly it does.
</chair hat off>

    
Non of this seems to me to be affecting your draft as you describe 
      
below but
    
I will wait for it to come out so I can get the full picture of what is
being proposed.
      
<chair hat off>
  Fair enough.
</chair hat off>

        Henrik

--------------050101010405080006060507-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 11:56:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16126 for ; Fri, 12 Dec 2003 11:56: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 1AUqaB-0003PR-LZ for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCGu3Bt013095 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 11: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 1AUqaB-0003P6-DM for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11: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 LAA16116 for ; Fri, 12 Dec 2003 11:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqaA-0001Hz-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUqa9-0001Hw-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 11: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 1AUqaA-0003OE-1H; Fri, 12 Dec 2003 11: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 1AUqZB-0003Hh-DG for mip4@optimus.ietf.org; Fri, 12 Dec 2003 11:55: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 LAA16079 for ; Fri, 12 Dec 2003 11:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqZA-0001G8-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:55:00 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUqZ9-0001FF-00 for mip4@ietf.org; Fri, 12 Dec 2003 11:54:59 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 11:54:29 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA80@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Alpesh'" Cc: "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 11:54:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C0CF.66A07B64" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C0CF.66A07B64 Content-Type: text/plain; charset="iso-8859-1" I am suggesting two things: 1) Allow the HA to send a positive RREP with an optional HA redirection extensions. This will allow a MN to change to the new HA at a time that is convenient to it i.e.: when it is idle and thus sessions will not be interrupted 2) Allow the HA to send a negative RREP with a compulsory HA redirection extensions. This will allow an HA to offload a MN for whatever reason to another HA (with which it may or may not share state) Suggestion (1) above does not cause any session interruption and I sense that you guys are ok with? Suggestion (2) may cause session interruption and at least Henrik was not a big fan of this. Henrik's draft, if I understand this correctly, allows HA redirection at any time but only between HAs that *share* state. The kulkarni draft also allows for HA redirection during initial registration as it has already been stated Is this making any sense? :-) George -----Original Message----- From: Alpesh [mailto:alpesh@cisco.com] Sent: Friday, December 12, 2003 4:26 PM To: Tsirtsis George Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt George - Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/ expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without losing session - probably both methods can be supported?? Alpesh Tsirtsis George wrote: But the draft clearly *also* talks about redirection for the purpose of routing optimality....mind you I think this is a good thing :-) George -----Original Message----- From: Kent Leung [ mailto:kleung@cisco.com ] Sent: Friday, December 12, 2003 3:57 PM To: Henrik Levkowetz Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Right, the solution provided in this draft is for dynamically assigning an HA for initial registration. The mechanism allows the network to choose an HA when MN request with AZOA or notify the MN the assigned HA when MN request an administratively prohibited HA in RRQ. Kent At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: On Friday, 12 Dec 2003, George Tsirtsis wrote: The discussion was, however, about redirection to an HA that does not necessarily share any state with the current HA. Ok. It wasn't clear to me at first that this was what you desired, rather than what you thought you at best could get... The question is whether such redirection should only be optional or whether optional and compulsory redirection should be allowed....(I prefer the latter). From the viewpoint of the problem the dyn-assignment draft originally aimed to solve, only dynamic assignment at the start of a session was considered and seemed to make sense. If we are now talking about extending this to a mechanism which will break off a session, but include a next-ha in the RRP refusal, I think we need to make sure we have a constituency which needs such a thing, and we have to weigh the benefits against the drawbacks of having a re-assignment mechanism which breaks off the current session. If we're going to have a mechanism to refuse a re-registration with a pointer to another HA, I'd prefer to be able to have it both optional and compulsory, as you seem to prefer too. But I'm not quite sure if the benefits in reduced round-trips of such a solution outweigh the simplicity of the HA simply refusing a registration, and the MN subsequently trying to register a new session and at that time be assigned a new HA, according to the mechanism of the current draft. Possibly it does. Non of this seems to me to be affecting your draft as you describe below but I will wait for it to come out so I can get the full picture of what is being proposed. Fair enough. Henrik ------_=_NextPart_001_01C3C0CF.66A07B64 Content-Type: text/html; charset="iso-8859-1"
I am suggesting two things:
 
1) Allow the HA to send a positive RREP with an optional HA redirection extensions. This will allow a MN to change to the new HA at a time that is convenient to it i.e.: when it is idle and thus sessions will not be interrupted
 
2) Allow the HA to send a negative RREP with a compulsory HA redirection extensions. This will allow an HA to offload a MN for whatever reason to another HA (with which it may or may not share state)
 
Suggestion (1) above does not cause any session interruption and I sense that you guys are ok with? Suggestion (2) may cause session interruption and at least Henrik was not a big fan of this.
 
Henrik's draft, if I understand this correctly, allows HA redirection at any time but only between HAs that *share* state.
 
The kulkarni draft also allows for HA redirection during initial registration as it has already been stated
 
Is this making any sense? :-)
 
George
-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Friday, December 12, 2003 4:26 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt

George -

Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/
expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring
that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without
losing session - probably both methods can be supported??

Alpesh

Tsirtsis George wrote:
But the draft clearly *also* talks about redirection for the purpose of
routing optimality....mind you I think this is a good thing :-)

George
-----Original Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Friday, December 12, 2003 3:57 PM
To: Henrik Levkowetz
Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt


Right, the solution provided in this draft is for dynamically assigning
an HA for initial registration.  The mechanism allows the network to
choose an HA when MN request with AZOA or notify the MN the assigned
HA when MN request an administratively prohibited HA in RRQ.

Kent

At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote:
  
On Friday, 12 Dec 2003, George Tsirtsis wrote:

    
The discussion was, however, about redirection to an HA that does not
necessarily share any state with the current HA.
      
<chair hat off>
  Ok. It wasn't clear to me at first that this was what you desired,
  rather than what you thought you at best could get...
</chair hat off>

    
The question is whether
such redirection should only be optional or whether optional and
      
compulsory
  
redirection should be allowed....(I prefer the latter).
      
<chair hat on>
  From the viewpoint of the problem the dyn-assignment draft originally
  aimed to solve, only dynamic assignment at the start of a session was
  considered and seemed to make sense.

  If we are now talking about extending this to a mechanism which will
  break off a session, but include a next-ha in the RRP refusal, I think
  we need to make sure we have a constituency which needs such a thing,
  and we have to weigh the benefits against the drawbacks of having
  a re-assignment mechanism which breaks off the current session.
</chair hat on>

<chair hat off>
  If we're going to have a mechanism to refuse a re-registration with
  a pointer to another HA, I'd prefer to be able to have it both
  optional and compulsory, as you seem to prefer too. But I'm not
  quite sure if the benefits in reduced round-trips of such a solution
  outweigh the simplicity of the HA simply refusing a registration, and
  the MN subsequently trying to register a new session and at that time
  be assigned a new HA, according to the mechanism of the current draft.
  Possibly it does.
</chair hat off>

    
Non of this seems to me to be affecting your draft as you describe 
      
below but
    
I will wait for it to come out so I can get the full picture of what is
being proposed.
      
<chair hat off>
  Fair enough.
</chair hat off>

        Henrik

------_=_NextPart_001_01C3C0CF.66A07B64-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 12:16:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17136 for ; Fri, 12 Dec 2003 12:16:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtI-00056E-B7 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:15:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHFmC5019590 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtH-00055r-U0 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:15: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 MAA17096 for ; Fri, 12 Dec 2003 12:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqtG-0001u4-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:15:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUqsr-0001tq-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqsY-00052v-HX; Fri, 12 Dec 2003 12: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 1AUqrr-00052J-NB for mip4@optimus.ietf.org; Fri, 12 Dec 2003 12:14: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 MAA17064 for ; Fri, 12 Dec 2003 12:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqrq-0001sf-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:14:18 -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 1AUqrp-0001rR-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:14:18 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2003 09:16:20 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBCHDjZ0004365; Fri, 12 Dec 2003 09:13:45 -0800 (PST) Received: from cisco.com (sjc-vpn3-1045.cisco.com [10.21.68.21]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK69113; Fri, 12 Dec 2003 09:13:40 -0800 (PST) Message-ID: <3FD9F744.80805@cisco.com> Date: Fri, 12 Dec 2003 09:13:40 -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: Tsirtsis George , "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA7F@ftmail.lab.flarion.com> <3FD9EC04.8090707@cisco.com> <3FD9F391.1050604@motorola.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 - We are in the same boat as you. Anchoring with HA's on the local subnet is not a problem. Henrik is solving the geographic reanchoring - or so I think. Henrik - I think the WG is waiting for you to break the suspense :) -a Alexandru Petrescu wrote: > Alpesh wrote: > >> Henrik's draft would achieve reanchoring without losing session > > > I'm trying to understand how that could happen. > > I was directed to read about VRRP and CARP, which I did. Both VRRP and > CARP seem to act on a local subnet. VRRP (HSRP, VSTB) seem to offer > end-hosts a means to dynamically select first-hop routers instead of > statically configuring a default route. CARP seems to provide > load-balancing of several routers on same link that would be addressable > by a unique IP address. This is my first reading, sorry if > misinterpreting. > > So VRRP and CARP act only within the scope of a same link. > > So, I was wondering whether the HA re-anchoring considers that HA's are > separated by routers, or that HA's are all linked together by a unique > link? > > Alex > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 12:16:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17153 for ; Fri, 12 Dec 2003 12:16:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtd-0005AK-Tu for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHG2mL019847 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtW-00058c-8L for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:16: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 MAA17133 for ; Fri, 12 Dec 2003 12:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqtU-0001vo-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:16:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUqtU-0001vl-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtV-00057T-5O; Fri, 12 Dec 2003 12:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqtP-000578-RR for mip4@optimus.ietf.org; Fri, 12 Dec 2003 12:15: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 MAA17127 for ; Fri, 12 Dec 2003 12:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqtO-0001vb-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:15:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AUqtN-0001ty-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:15:53 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Dec 2003 17:15:34 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBCHFIrZ029558; Fri, 12 Dec 2003 09:15:21 -0800 (PST) Received: from cisco.com (sjc-vpn3-1045.cisco.com [10.21.68.21]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK69298; Fri, 12 Dec 2003 09:15:08 -0800 (PST) Message-ID: <3FD9F79C.8080809@cisco.com> Date: Fri, 12 Dec 2003 09:15:08 -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: Tsirtsis George CC: "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA80@ftmail.lab.flarion.com> Content-Type: multipart/alternative; boundary="------------070304000500070309050106" 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: , --------------070304000500070309050106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George - Oh, don't get me wrong - I totally agree with both the suggestions and understand them. We had been thinking of a revision on similar sort a little before last IETF, but are holding for Henrik's draft to come out :) Alpesh Tsirtsis George wrote: > I am suggesting two things: > > 1) Allow the HA to send a positive RREP with an optional HA > redirection extensions. This will allow a MN to change to the new HA > at a time that is convenient to it i.e.: when it is idle and thus > sessions will not be interrupted > > 2) Allow the HA to send a negative RREP with a compulsory HA > redirection extensions. This will allow an HA to offload a MN for > whatever reason to another HA (with which it may or may not share state) > > Suggestion (1) above does not cause any session interruption and I > sense that you guys are ok with? Suggestion (2) may cause session > interruption and at least Henrik was not a big fan of this. > > Henrik's draft, if I understand this correctly, allows HA redirection > at any time but only between HAs that *share* state. > > The kulkarni draft also allows for HA redirection during initial > registration as it has already been stated > > Is this making any sense? :-) > > George > > -----Original Message----- > From: Alpesh [mailto:alpesh@cisco.com] > Sent: Friday, December 12, 2003 4:26 PM > To: Tsirtsis George > Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org > Subject: Re: [Mip4] WG adoption call on > draft-kulkarni-mobileip-dynamic-as signment-02.txt > > George - > > Yes, but the 'redirection' was intended to happen during the > initial registration. With little extension/ > expansion of interpretation of the text we can accomodate the > 'in-session' redirection/reanchoring > that you suggest. But that would break the session. Henrik's draft > would achieve reanchoring without > losing session - probably both methods can be supported?? > > Alpesh > > Tsirtsis George wrote: > >>But the draft clearly *also* talks about redirection for the purpose of >>routing optimality....mind you I think this is a good thing :-) >> >>George >>-----Original Message----- >>From: Kent Leung [mailto:kleung@cisco.com] >>Sent: Friday, December 12, 2003 3:57 PM >>To: Henrik Levkowetz >>Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org >>Subject: Re: [Mip4] WG adoption call on >>draft-kulkarni-mobileip-dynamic-as signment-02.txt >> >> >>Right, the solution provided in this draft is for dynamically assigning >>an HA for initial registration. The mechanism allows the network to >>choose an HA when MN request with AZOA or notify the MN the assigned >>HA when MN request an administratively prohibited HA in RRQ. >> >>Kent >> >>At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: >> >> >>>On Friday, 12 Dec 2003, George Tsirtsis wrote: >>> >>> >>> >>>>The discussion was, however, about redirection to an HA that does not >>>>necessarily share any state with the current HA. >>>> >>>> >>> >>> Ok. It wasn't clear to me at first that this was what you desired, >>> rather than what you thought you at best could get... >>> >>> >>> >>> >>>>The question is whether >>>>such redirection should only be optional or whether optional and >>>> >>>> >>compulsory >> >> >>>>redirection should be allowed....(I prefer the latter). >>>> >>>> >>> >>> From the viewpoint of the problem the dyn-assignment draft originally >>> aimed to solve, only dynamic assignment at the start of a session was >>> considered and seemed to make sense. >>> >>> If we are now talking about extending this to a mechanism which will >>> break off a session, but include a next-ha in the RRP refusal, I think >>> we need to make sure we have a constituency which needs such a thing, >>> and we have to weigh the benefits against the drawbacks of having >>> a re-assignment mechanism which breaks off the current session. >>> >>> >>> >>> If we're going to have a mechanism to refuse a re-registration with >>> a pointer to another HA, I'd prefer to be able to have it both >>> optional and compulsory, as you seem to prefer too. But I'm not >>> quite sure if the benefits in reduced round-trips of such a solution >>> outweigh the simplicity of the HA simply refusing a registration, and >>> the MN subsequently trying to register a new session and at that time >>> be assigned a new HA, according to the mechanism of the current draft. >>> Possibly it does. >>> >>> >>> >>> >>>>Non of this seems to me to be affecting your draft as you describe >>>> >>>> >>>below but >>> >>> >>>>I will wait for it to come out so I can get the full picture of what is >>>>being proposed. >>>> >>>> >>> >>> Fair enough. >>> >>> >>> Henrik >>> >>> >> >> >> > --------------070304000500070309050106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit George -

Oh, don't get me wrong - I totally agree with both the suggestions and understand them. We had been thinking
of a revision on similar sort a little before last IETF, but are holding for Henrik's draft to come out :)

Alpesh

Tsirtsis George wrote:
I am suggesting two things:
 
1) Allow the HA to send a positive RREP with an optional HA redirection extensions. This will allow a MN to change to the new HA at a time that is convenient to it i.e.: when it is idle and thus sessions will not be interrupted
 
2) Allow the HA to send a negative RREP with a compulsory HA redirection extensions. This will allow an HA to offload a MN for whatever reason to another HA (with which it may or may not share state)
 
Suggestion (1) above does not cause any session interruption and I sense that you guys are ok with? Suggestion (2) may cause session interruption and at least Henrik was not a big fan of this.
 
Henrik's draft, if I understand this correctly, allows HA redirection at any time but only between HAs that *share* state.
 
The kulkarni draft also allows for HA redirection during initial registration as it has already been stated
 
Is this making any sense? :-)
 
George
-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Friday, December 12, 2003 4:26 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt

George -

Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/
expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring
that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without
losing session - probably both methods can be supported??

Alpesh

Tsirtsis George wrote:
But the draft clearly *also* talks about redirection for the purpose of
routing optimality....mind you I think this is a good thing :-)

George
-----Original Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Friday, December 12, 2003 3:57 PM
To: Henrik Levkowetz
Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt


Right, the solution provided in this draft is for dynamically assigning
an HA for initial registration.  The mechanism allows the network to
choose an HA when MN request with AZOA or notify the MN the assigned
HA when MN request an administratively prohibited HA in RRQ.

Kent

At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote:
  
On Friday, 12 Dec 2003, George Tsirtsis wrote:

    
The discussion was, however, about redirection to an HA that does not
necessarily share any state with the current HA.
      
<chair hat off>
  Ok. It wasn't clear to me at first that this was what you desired,
  rather than what you thought you at best could get...
</chair hat off>

    
The question is whether
such redirection should only be optional or whether optional and
      
compulsory
  
redirection should be allowed....(I prefer the latter).
      
<chair hat on>
  From the viewpoint of the problem the dyn-assignment draft originally
  aimed to solve, only dynamic assignment at the start of a session was
  considered and seemed to make sense.

  If we are now talking about extending this to a mechanism which will
  break off a session, but include a next-ha in the RRP refusal, I think
  we need to make sure we have a constituency which needs such a thing,
  and we have to weigh the benefits against the drawbacks of having
  a re-assignment mechanism which breaks off the current session.
</chair hat on>

<chair hat off>
  If we're going to have a mechanism to refuse a re-registration with
  a pointer to another HA, I'd prefer to be able to have it both
  optional and compulsory, as you seem to prefer too. But I'm not
  quite sure if the benefits in reduced round-trips of such a solution
  outweigh the simplicity of the HA simply refusing a registration, and
  the MN subsequently trying to register a new session and at that time
  be assigned a new HA, according to the mechanism of the current draft.
  Possibly it does.
</chair hat off>

    
Non of this seems to me to be affecting your draft as you describe 
      
below but
    
I will wait for it to come out so I can get the full picture of what is
being proposed.
      
<chair hat off>
  Fair enough.
</chair hat off>

        Henrik


--------------070304000500070309050106-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 12:30:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17618 for ; Fri, 12 Dec 2003 12:30: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 1AUr78-0005vU-3u for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHU62l022774 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUr77-0005vA-2R for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:30: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 MAA17593 for ; Fri, 12 Dec 2003 12:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUr75-0002Im-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:30:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUr74-0002If-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUr75-0005uo-3o; Fri, 12 Dec 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 1AUr6v-0005tc-44 for mip4@optimus.ietf.org; Fri, 12 Dec 2003 12:29: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 MAA17566 for ; Fri, 12 Dec 2003 12:29:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUr6t-0002Hn-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:29:51 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUr6t-0002Gn-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:29:51 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 12:29:21 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Alpesh'" Cc: "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 12:29:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C0D4.DC112CFE" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C0D4.DC112CFE Content-Type: text/plain; charset="iso-8859-1" Ack, lets wait for Henrik. Henrik, no pressure mate....we are all just shitting on our hands waiting for you :-) George -----Original Message----- From: Alpesh [mailto:alpesh@cisco.com] Sent: Friday, December 12, 2003 5:15 PM To: Tsirtsis George Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt George - Oh, don't get me wrong - I totally agree with both the suggestions and understand them. We had been thinking of a revision on similar sort a little before last IETF, but are holding for Henrik's draft to come out :) Alpesh Tsirtsis George wrote: I am suggesting two things: 1) Allow the HA to send a positive RREP with an optional HA redirection extensions. This will allow a MN to change to the new HA at a time that is convenient to it i.e.: when it is idle and thus sessions will not be interrupted 2) Allow the HA to send a negative RREP with a compulsory HA redirection extensions. This will allow an HA to offload a MN for whatever reason to another HA (with which it may or may not share state) Suggestion (1) above does not cause any session interruption and I sense that you guys are ok with? Suggestion (2) may cause session interruption and at least Henrik was not a big fan of this. Henrik's draft, if I understand this correctly, allows HA redirection at any time but only between HAs that *share* state. The kulkarni draft also allows for HA redirection during initial registration as it has already been stated Is this making any sense? :-) George -----Original Message----- From: Alpesh [ mailto:alpesh@cisco.com ] Sent: Friday, December 12, 2003 4:26 PM To: Tsirtsis George Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt George - Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/ expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without losing session - probably both methods can be supported?? Alpesh Tsirtsis George wrote: But the draft clearly *also* talks about redirection for the purpose of routing optimality....mind you I think this is a good thing :-) George -----Original Message----- From: Kent Leung [ mailto:kleung@cisco.com ] Sent: Friday, December 12, 2003 3:57 PM To: Henrik Levkowetz Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Right, the solution provided in this draft is for dynamically assigning an HA for initial registration. The mechanism allows the network to choose an HA when MN request with AZOA or notify the MN the assigned HA when MN request an administratively prohibited HA in RRQ. Kent At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: On Friday, 12 Dec 2003, George Tsirtsis wrote: The discussion was, however, about redirection to an HA that does not necessarily share any state with the current HA. Ok. It wasn't clear to me at first that this was what you desired, rather than what you thought you at best could get... The question is whether such redirection should only be optional or whether optional and compulsory redirection should be allowed....(I prefer the latter). From the viewpoint of the problem the dyn-assignment draft originally aimed to solve, only dynamic assignment at the start of a session was considered and seemed to make sense. If we are now talking about extending this to a mechanism which will break off a session, but include a next-ha in the RRP refusal, I think we need to make sure we have a constituency which needs such a thing, and we have to weigh the benefits against the drawbacks of having a re-assignment mechanism which breaks off the current session. If we're going to have a mechanism to refuse a re-registration with a pointer to another HA, I'd prefer to be able to have it both optional and compulsory, as you seem to prefer too. But I'm not quite sure if the benefits in reduced round-trips of such a solution outweigh the simplicity of the HA simply refusing a registration, and the MN subsequently trying to register a new session and at that time be assigned a new HA, according to the mechanism of the current draft. Possibly it does. Non of this seems to me to be affecting your draft as you describe below but I will wait for it to come out so I can get the full picture of what is being proposed. Fair enough. Henrik ------_=_NextPart_001_01C3C0D4.DC112CFE Content-Type: text/html; charset="iso-8859-1"
Ack, lets wait for Henrik.
 
Henrik, no pressure mate....we are all just shitting on our hands waiting for you :-)
 
George
-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Friday, December 12, 2003 5:15 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt

George -

Oh, don't get me wrong - I totally agree with both the suggestions and understand them. We had been thinking
of a revision on similar sort a little before last IETF, but are holding for Henrik's draft to come out :)

Alpesh

Tsirtsis George wrote:
I am suggesting two things:
 
1) Allow the HA to send a positive RREP with an optional HA redirection extensions. This will allow a MN to change to the new HA at a time that is convenient to it i.e.: when it is idle and thus sessions will not be interrupted
 
2) Allow the HA to send a negative RREP with a compulsory HA redirection extensions. This will allow an HA to offload a MN for whatever reason to another HA (with which it may or may not share state)
 
Suggestion (1) above does not cause any session interruption and I sense that you guys are ok with? Suggestion (2) may cause session interruption and at least Henrik was not a big fan of this.
 
Henrik's draft, if I understand this correctly, allows HA redirection at any time but only between HAs that *share* state.
 
The kulkarni draft also allows for HA redirection during initial registration as it has already been stated
 
Is this making any sense? :-)
 
George
-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Friday, December 12, 2003 4:26 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt

George -

Yes, but the 'redirection' was intended to happen during the initial registration. With little extension/
expansion of interpretation of the text we can accomodate the 'in-session' redirection/reanchoring
that you suggest. But that would break the session. Henrik's draft would achieve reanchoring without
losing session - probably both methods can be supported??

Alpesh

Tsirtsis George wrote:
But the draft clearly *also* talks about redirection for the purpose of
routing optimality....mind you I think this is a good thing :-)

George
-----Original Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Friday, December 12, 2003 3:57 PM
To: Henrik Levkowetz
Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org
Subject: Re: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt


Right, the solution provided in this draft is for dynamically assigning
an HA for initial registration.  The mechanism allows the network to
choose an HA when MN request with AZOA or notify the MN the assigned
HA when MN request an administratively prohibited HA in RRQ.

Kent

At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote:
  
On Friday, 12 Dec 2003, George Tsirtsis wrote:

    
The discussion was, however, about redirection to an HA that does not
necessarily share any state with the current HA.
      
<chair hat off>
  Ok. It wasn't clear to me at first that this was what you desired,
  rather than what you thought you at best could get...
</chair hat off>

    
The question is whether
such redirection should only be optional or whether optional and
      
compulsory
  
redirection should be allowed....(I prefer the latter).
      
<chair hat on>
  From the viewpoint of the problem the dyn-assignment draft originally
  aimed to solve, only dynamic assignment at the start of a session was
  considered and seemed to make sense.

  If we are now talking about extending this to a mechanism which will
  break off a session, but include a next-ha in the RRP refusal, I think
  we need to make sure we have a constituency which needs such a thing,
  and we have to weigh the benefits against the drawbacks of having
  a re-assignment mechanism which breaks off the current session.
</chair hat on>

<chair hat off>
  If we're going to have a mechanism to refuse a re-registration with
  a pointer to another HA, I'd prefer to be able to have it both
  optional and compulsory, as you seem to prefer too. But I'm not
  quite sure if the benefits in reduced round-trips of such a solution
  outweigh the simplicity of the HA simply refusing a registration, and
  the MN subsequently trying to register a new session and at that time
  be assigned a new HA, according to the mechanism of the current draft.
  Possibly it does.
</chair hat off>

    
Non of this seems to me to be affecting your draft as you describe 
      
below but
    
I will wait for it to come out so I can get the full picture of what is
being proposed.
      
<chair hat off>
  Fair enough.
</chair hat off>

        Henrik


------_=_NextPart_001_01C3C0D4.DC112CFE-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 12:44:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17986 for ; Fri, 12 Dec 2003 12:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrKc-0006ZF-E1 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHi2Ch025241 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrKc-0006Z2-5y for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:44: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 MAA17964 for ; Fri, 12 Dec 2003 12:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrKa-0002hW-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:44:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrKa-0002hT-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrKa-0006Yh-N8; Fri, 12 Dec 2003 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrKR-0006YI-Tk for mip4@optimus.ietf.org; Fri, 12 Dec 2003 12:43: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 MAA17959 for ; Fri, 12 Dec 2003 12:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrKQ-0002hE-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:43:50 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUrKP-0002gj-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:43:49 -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 hBCHggQe026129; Fri, 12 Dec 2003 18:42:42 +0100 Date: Fri, 12 Dec 2003 18:42:41 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212184241.318c0467.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA80@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA80@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=_Fri__12_Dec_2003_18_42_41_+0100_XVcWMcIkjf0r+hXV" 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=_Fri__12_Dec_2003_18_42_41_+0100_XVcWMcIkjf0r+hXV Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi George, On Friday, 12 Dec 2003, George Tsirtsis wrote: > I am suggesting two things: > > 1) Allow the HA to send a positive RREP with an optional HA redirection > extensions. This will allow a MN to change to the new HA at a time that is > convenient to it i.e.: when it is idle and thus sessions will not be > interrupted But if the MN is idle it doesn't send RRQ and won't get a RRP anyway, while as soon as it needs to leave idle and sends an initial RRQ it can be dynamically assigned a new HA, no? > 2) Allow the HA to send a negative RREP with a compulsory HA redirection > extensions. This will allow an HA to offload a MN for whatever reason to > another HA (with which it may or may not share state) Yes, but it will only let you offload it at the time of re-registration, not at an optional time. > > Suggestion (1) above does not cause any session interruption and I sense > that you guys are ok with? Suggestion (2) may cause session interruption and > at least Henrik was not a big fan of this. I'm undecided on this one at the moment. > Henrik's draft, if I understand this correctly, allows HA redirection at any > time but only between HAs that *share* state. That was the intention. But as that mechanism requires a message originated by the HA anyway, we might open it up for both cases... --Signature=_Fri__12_Dec_2003_18_42_41_+0100_XVcWMcIkjf0r+hXV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2f4ReVhrtTJkXCMRAjqXAKD9ZqnULRMzWKIUTQOBvt6of+xARACfbVIg eSjK3mVOnQ2QiHvItk8v6qw= =CMsl -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_18_42_41_+0100_XVcWMcIkjf0r+hXV-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 12:53:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18228 for ; Fri, 12 Dec 2003 12:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrTK-0006qr-EX for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHr26p026331 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 12: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 1AUrTK-0006qX-5i for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12: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 MAA18219 for ; Fri, 12 Dec 2003 12:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrTI-0002ty-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrTH-0002tu-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 12: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 1AUrTJ-0006q9-3U; Fri, 12 Dec 2003 12: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 1AUrSS-0006ox-8S for mip4@optimus.ietf.org; Fri, 12 Dec 2003 12:52: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 MAA18168 for ; Fri, 12 Dec 2003 12:52:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrSQ-0002sY-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:52: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 1AUrSQ-0002s5-00 for mip4@ietf.org; Fri, 12 Dec 2003 12:52:06 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 12:51:37 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA83@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Henrik Levkowetz'" , Tsirtsis George Cc: "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 12:51: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: , -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Friday, December 12, 2003 5:43 PM To: Tsirtsis George Cc: 'Alpesh'; 'Kent Leung'; mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Hi George, On Friday, 12 Dec 2003, George Tsirtsis wrote: > I am suggesting two things: > > 1) Allow the HA to send a positive RREP with an optional HA redirection > extensions. This will allow a MN to change to the new HA at a time that is > convenient to it i.e.: when it is idle and thus sessions will not be > interrupted But if the MN is idle it doesn't send RRQ and won't get a RRP anyway, while as soon as it needs to leave idle and sends an initial RRQ it can be dynamically assigned a new HA, no? GT> Well, I assumed that RREQs are sent based on some timer expiring and are orthogonal to any data traffic. What you describe seams to assume that you return the dynamic HoA when you go idle and then request a new one when you want to start a session.....I am not sure I like this but I guess it could be done this way too. > 2) Allow the HA to send a negative RREP with a compulsory HA redirection > extensions. This will allow an HA to offload a MN for whatever reason to > another HA (with which it may or may not share state) Yes, but it will only let you offload it at the time of re-registration, not at an optional time. GT> Correct. This is not good enough for real load balancing. I guess this is where your draft comes in. > > Suggestion (1) above does not cause any session interruption and I sense > that you guys are ok with? Suggestion (2) may cause session interruption and > at least Henrik was not a big fan of this. I'm undecided on this one at the moment. GT> OK, sorry for putting words in your mouth. > Henrik's draft, if I understand this correctly, allows HA redirection at any > time but only between HAs that *share* state. That was the intention. But as that mechanism requires a message originated by the HA anyway, we might open it up for both cases... GT> Ack. George -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 13:07:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18477 for ; Fri, 12 Dec 2003 13:07: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 1AUrgr-0007AX-O6 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13:07:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCI71B5027549 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13: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 1AUrgr-0007A6-7T for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:07: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 NAA18471 for ; Fri, 12 Dec 2003 13:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrgp-00038x-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrgp-00038u-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrgq-00079M-1W; Fri, 12 Dec 2003 13:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrgY-00078j-AZ for mip4@optimus.ietf.org; Fri, 12 Dec 2003 13:06: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 NAA18465 for ; Fri, 12 Dec 2003 13:06:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrgW-00038f-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:06:40 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUrgV-00038R-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:06:39 -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 hBCI52Qe026365; Fri, 12 Dec 2003 19:05:03 +0100 Date: Fri, 12 Dec 2003 19:05:03 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212190503.7ad1a4a2.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA82@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=_Fri__12_Dec_2003_19_05_03_+0100_c0Kea..jXmACzTNC" 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=_Fri__12_Dec_2003_19_05_03_+0100_c0Kea..jXmACzTNC Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Guys, It's Friday evening here, and I should have gone home an hour ago :) but was held up in a coupld of other discussions. As I mentioned in an earlier post, the mechanism is to let a HA signal an MN that it is taking over responsibility for an ongoing session from another HA. To me this has only made sense if the HA's can serve the MN with the same home address; otherwise you'd get a broken session. The HA's would be situated physically close, but with different routes to the internet, to provide a greater redundancy than what you could get with a pure VRRP or CARP solution. I didn't intend at all to go into the area of HAs providing different home addresses, as I felt that if that should be done at all (it's a break against one of the fundamentals of Mobile IP that you're not at a fixed well known home address any more) it should be done at session start, not in the middle of a session. But now it seems that we're potentially extending the area of interest for both drafts to the point where they may overlap: * The dyn-assignment draft might be extended to send redirection RRPs back not only at session start, but also during an ongoing session * The upcoming re-assignment or redundancy draft could be extended to let an backup HA initiate a message not only when it serves the same home network, but also in the case where it would provide a new home address, and session disruption would follow but service could be maintained (after the disruption) Do we need this? Do we need both mechanisms? It seems to me that the major difference between these convergent functions is that in one case (good if you want to offload MNs to sister HA's) the signal comes from the old serving HA, while in the other case (good if you want to take over if a sister HA has failed) the signal comes from the new HA. Henrik On Friday, 12 Dec 2003, George Tsirtsis wrote: > Ack, lets wait for Henrik. > > Henrik, no pressure mate....we are all just shitting on our hands waiting > for you :-) > > George > > -----Original Message----- > From: Alpesh [mailto:alpesh@cisco.com] > Sent: Friday, December 12, 2003 5:15 PM > To: Tsirtsis George > Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org > Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as > signment-02.txt > > > George - > > Oh, don't get me wrong - I totally agree with both the suggestions and > understand them. We had been thinking > of a revision on similar sort a little before last IETF, but are holding for > Henrik's draft to come out :) > > Alpesh > > Tsirtsis George wrote: > > > I am suggesting two things: > > 1) Allow the HA to send a positive RREP with an optional HA redirection > extensions. This will allow a MN to change to the new HA at a time that is > convenient to it i.e.: when it is idle and thus sessions will not be > interrupted > > 2) Allow the HA to send a negative RREP with a compulsory HA redirection > extensions. This will allow an HA to offload a MN for whatever reason to > another HA (with which it may or may not share state) > > Suggestion (1) above does not cause any session interruption and I sense > that you guys are ok with? Suggestion (2) may cause session interruption and > at least Henrik was not a big fan of this. > > Henrik's draft, if I understand this correctly, allows HA redirection at any > time but only between HAs that *share* state. > > The kulkarni draft also allows for HA redirection during initial > registration as it has already been stated > > Is this making any sense? :-) > > George > > -----Original Message----- > From: Alpesh [ mailto:alpesh@cisco.com ] > Sent: Friday, December 12, 2003 4:26 PM > To: Tsirtsis George > Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org > Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as > signment-02.txt > > > George - > > Yes, but the 'redirection' was intended to happen during the initial > registration. With little extension/ > expansion of interpretation of the text we can accomodate the 'in-session' > redirection/reanchoring > that you suggest. But that would break the session. Henrik's draft would > achieve reanchoring without > losing session - probably both methods can be supported?? > > Alpesh > > Tsirtsis George wrote: > > > But the draft clearly *also* talks about redirection for the purpose of > > routing optimality....mind you I think this is a good thing :-) > > > > George > > -----Original Message----- > > From: Kent Leung [ mailto:kleung@cisco.com ] > > Sent: Friday, December 12, 2003 3:57 PM > > To: Henrik Levkowetz > > Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org > > Subject: Re: [Mip4] WG adoption call on > > draft-kulkarni-mobileip-dynamic-as signment-02.txt > > > > > > Right, the solution provided in this draft is for dynamically assigning > > an HA for initial registration. The mechanism allows the network to > > choose an HA when MN request with AZOA or notify the MN the assigned > > HA when MN request an administratively prohibited HA in RRQ. > > > > Kent > > > > At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: > > > > On Friday, 12 Dec 2003, George Tsirtsis wrote: > > > > > > The discussion was, however, about redirection to an HA that does not > > necessarily share any state with the current HA. > > > > > > Ok. It wasn't clear to me at first that this was what you desired, > > rather than what you thought you at best could get... > > > > > > > > The question is whether > > such redirection should only be optional or whether optional and > > > > compulsory > > > > redirection should be allowed....(I prefer the latter). > > > > > > From the viewpoint of the problem the dyn-assignment draft originally > > aimed to solve, only dynamic assignment at the start of a session was > > considered and seemed to make sense. > > > > If we are now talking about extending this to a mechanism which will > > break off a session, but include a next-ha in the RRP refusal, I think > > we need to make sure we have a constituency which needs such a thing, > > and we have to weigh the benefits against the drawbacks of having > > a re-assignment mechanism which breaks off the current session. > > > > > > > > If we're going to have a mechanism to refuse a re-registration with > > a pointer to another HA, I'd prefer to be able to have it both > > optional and compulsory, as you seem to prefer too. But I'm not > > quite sure if the benefits in reduced round-trips of such a solution > > outweigh the simplicity of the HA simply refusing a registration, and > > the MN subsequently trying to register a new session and at that time > > be assigned a new HA, according to the mechanism of the current draft. > > Possibly it does. > > > > > > > > Non of this seems to me to be affecting your draft as you describe > > > > below but > > > > I will wait for it to come out so I can get the full picture of what is > > being proposed. > > > > > > Fair enough. > > > > > > Henrik > > > > > > > > > > --Signature=_Fri__12_Dec_2003_19_05_03_+0100_c0Kea..jXmACzTNC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2gNPeVhrtTJkXCMRAg+zAJ92LA79zAmkMX7JLME/zoHxv+sKVwCeOZox gJoFsS+M2OtGnwlGq1EaI64= =dSkk -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_19_05_03_+0100_c0Kea..jXmACzTNC-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 13:16:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18715 for ; Fri, 12 Dec 2003 13:16: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 1AUrpZ-00083c-S9 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13:16:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIG1I2030968 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrpZ-00083P-Ng for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:16: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 NAA18685 for ; Fri, 12 Dec 2003 13:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrpX-0003HN-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:15:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrpX-0003HK-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrpY-00082t-U8; Fri, 12 Dec 2003 13:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrpE-00082A-LU for mip4@optimus.ietf.org; Fri, 12 Dec 2003 13:15: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 NAA18680 for ; Fri, 12 Dec 2003 13:15:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrpC-0003HA-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:15:38 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AUrpC-0003Gu-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:15:38 -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 hBCIEgQe026453; Fri, 12 Dec 2003 19:14:42 +0100 Date: Fri, 12 Dec 2003 19:14:41 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212191441.09833cf1.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA83@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA83@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=_Fri__12_Dec_2003_19_14_41_+0100_o.FTtpFSgH=SFwWI" 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=_Fri__12_Dec_2003_19_14_41_+0100_o.FTtpFSgH=SFwWI Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi again George and all, On Friday, 12 Dec 2003, GeorgeTsirtsis wrote: [...] > > Hi George, > > > > On Friday, 12 Dec 2003, George Tsirtsis wrote: > > > > > I am suggesting two things: > > > > > > 1) Allow the HA to send a positive RREP with an optional HA redirection > > > extensions. This will allow a MN to change to the new HA at a time that is > > > convenient to it i.e.: when it is idle and thus sessions will not be > > > interrupted > > > > But if the MN is idle it doesn't send RRQ and won't get a RRP anyway, > > while as soon as it needs to leave idle and sends an initial RRQ it can > > be dynamically assigned a new HA, no? > > GT> Well, I assumed that RREQs are sent based on some timer expiring and are > orthogonal to any data traffic. What you describe seams to assume that you > return the dynamic HoA when you go idle and then request a new one when you > want to start a session.....I am not sure I like this but I guess it could > be done this way too. Right, I see. I wasn't thinking of 'returning' the dynamic HA, on the contrary I'd expect that the first HA contacted on a following initial registration would be the most recently used HA. But I guess that in your network, you might have sessions which stretch for days or weeks, as long as a user don't turn off his mobile; and in that case it seems silly to sit around and wait for the next session if you need to change HA. > > > 2) Allow the HA to send a negative RREP with a compulsory HA redirection > > > extensions. This will allow an HA to offload a MN for whatever reason to > > > another HA (with which it may or may not share state) > > > > Yes, but it will only let you offload it at the time of re-registration, > > not at an optional time. > > > > GT> Correct. This is not good enough for real load balancing. I guess this > is where your draft comes in. Yes, that's what I intended. > > > > > Suggestion (1) above does not cause any session interruption and I sense > > > that you guys are ok with? Suggestion (2) may cause session interruption > > and > > > at least Henrik was not a big fan of this. > > > > I'm undecided on this one at the moment. > > > GT> OK, sorry for putting words in your mouth. No prob. > > > Henrik's draft, if I understand this correctly, allows HA redirection at > > any > > > time but only between HAs that *share* state. > > > > That was the intention. But as that mechanism requires a message originated > > by the HA anyway, we might open it up for both cases... > > > GT> Ack. Ok, let's see where we end up here. Regards, Henrik --Signature=_Fri__12_Dec_2003_19_14_41_+0100_o.FTtpFSgH=SFwWI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2gWReVhrtTJkXCMRAteQAKCnhtWT7/I3hSJmILsmGuteAfYNHgCgzhst 0Ty3vICgDfjHdaliBEeSZbQ= =tw7H -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_19_14_41_+0100_o.FTtpFSgH=SFwWI-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 13:59:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20059 for ; Fri, 12 Dec 2003 13:59: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 1AUsVC-0001ZM-BF for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIx27B006026 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 13:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsVC-0001Z7-12 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:59: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 NAA20039 for ; Fri, 12 Dec 2003 13:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUsV9-00046Q-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:58:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUsV9-00046N-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 13:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsVB-0001Yn-2N; Fri, 12 Dec 2003 13: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 1AUsUf-0001Y7-3f for mip4@optimus.ietf.org; Fri, 12 Dec 2003 13:58: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 NAA20023 for ; Fri, 12 Dec 2003 13:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUsUc-00045p-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:58:26 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AUsUc-00045H-00 for mip4@ietf.org; Fri, 12 Dec 2003 13:58: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 hBCIuf005692; Fri, 12 Dec 2003 12:56:41 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id hBCIua426100; Fri, 12 Dec 2003 12:56:37 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HPSPXK-0001VC-00; Fri, 12 Dec 2003 13:56:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16346.3911.779505.772357@gargle.gargle.HOWL> Date: Fri, 12 Dec 2003 12:56:07 -0600 From: Pete McCann To: Tsirtsis George Cc: "'Alpesh'" , "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA82@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 George, I'm sure you didn't mean that exactly. :) Anyway, I wonder why the HA is in a good position to do a redirect to a "more local" HA, especially because the two HAs are by definition not local to each other and are likely to be in different administrative domains. Instead, it seems like the MN could implement some policy for shifting its HA, based on information about the domain to which it is connected (FA NAI?) and the existence of any local sessions. Note that "local sessions" may include low-traffic TCP connections (terminal shells) which it may be difficult or impossible for the HA to detect. When no local sessions exist, the MN could request the assignment of a new HA based on the existing draft. It could even leave its existing registration in place for a period of time if it wanted to overlap the two registrations. Load balancing/failover (within the same location/administrative domain) might be a better motivation for redirecting an in-progress session. However, it is possible to solve at least some aspects of this problem without any new protocol changes to Mobile IP, see, e.g.: http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z -Pete Tsirtsis George writes: > Ack, lets wait for Henrik. > > Henrik, no pressure mate....we are all just shitting on our hands waiting > for you :-) > > George > > -----Original Message----- > From: Alpesh [mailto:alpesh@cisco.com] > Sent: Friday, December 12, 2003 5:15 PM > To: Tsirtsis George > Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org > Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as > signment-02.txt > > > George - > > Oh, don't get me wrong - I totally agree with both the suggestions and > understand them. We had been thinking > of a revision on similar sort a little before last IETF, but are holding for > Henrik's draft to come out :) > > Alpesh > > Tsirtsis George wrote: > > > I am suggesting two things: > > 1) Allow the HA to send a positive RREP with an optional HA redirection > extensions. This will allow a MN to change to the new HA at a time that is > convenient to it i.e.: when it is idle and thus sessions will not be > interrupted > > 2) Allow the HA to send a negative RREP with a compulsory HA redirection > extensions. This will allow an HA to offload a MN for whatever reason to > another HA (with which it may or may not share state) > > Suggestion (1) above does not cause any session interruption and I sense > that you guys are ok with? Suggestion (2) may cause session interruption and > at least Henrik was not a big fan of this. > > Henrik's draft, if I understand this correctly, allows HA redirection at any > time but only between HAs that *share* state. > > The kulkarni draft also allows for HA redirection during initial > registration as it has already been stated > > Is this making any sense? :-) > > George > > -----Original Message----- > From: Alpesh [ mailto:alpesh@cisco.com ] > Sent: Friday, December 12, 2003 4:26 PM > To: Tsirtsis George > Cc: 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org > Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as > signment-02.txt > > > George - > > Yes, but the 'redirection' was intended to happen during the initial > registration. With little extension/ > expansion of interpretation of the text we can accomodate the 'in-session' > redirection/reanchoring > that you suggest. But that would break the session. Henrik's draft would > achieve reanchoring without > losing session - probably both methods can be supported?? > > Alpesh > > Tsirtsis George wrote: > > > But the draft clearly *also* talks about redirection for the purpose of > > routing optimality....mind you I think this is a good thing :-) > > > > George > > -----Original Message----- > > From: Kent Leung [ mailto:kleung@cisco.com ] > > Sent: Friday, December 12, 2003 3:57 PM > > To: Henrik Levkowetz > > Cc: Tsirtsis George; Tsirtsis George; mip4@ietf.org > > Subject: Re: [Mip4] WG adoption call on > > draft-kulkarni-mobileip-dynamic-as signment-02.txt > > > > > > Right, the solution provided in this draft is for dynamically assigning > > an HA for initial registration. The mechanism allows the network to > > choose an HA when MN request with AZOA or notify the MN the assigned > > HA when MN request an administratively prohibited HA in RRQ. > > > > Kent > > > > At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote: > > > > On Friday, 12 Dec 2003, George Tsirtsis wrote: > > > > > > The discussion was, however, about redirection to an HA that does not > > necessarily share any state with the current HA. > > > > > > Ok. It wasn't clear to me at first that this was what you desired, > > rather than what you thought you at best could get... > > > > > > > > The question is whether > > such redirection should only be optional or whether optional and > > > > compulsory > > > > redirection should be allowed....(I prefer the latter). > > > > > > From the viewpoint of the problem the dyn-assignment draft originally > > aimed to solve, only dynamic assignment at the start of a session was > > considered and seemed to make sense. > > > > If we are now talking about extending this to a mechanism which will > > break off a session, but include a next-ha in the RRP refusal, I think > > we need to make sure we have a constituency which needs such a thing, > > and we have to weigh the benefits against the drawbacks of having > > a re-assignment mechanism which breaks off the current session. > > > > > > > > If we're going to have a mechanism to refuse a re-registration with > > a pointer to another HA, I'd prefer to be able to have it both > > optional and compulsory, as you seem to prefer too. But I'm not > > quite sure if the benefits in reduced round-trips of such a solution > > outweigh the simplicity of the HA simply refusing a registration, and > > the MN subsequently trying to register a new session and at that time > > be assigned a new HA, according to the mechanism of the current draft. > > Possibly it does. > > > > > > > > Non of this seems to me to be affecting your draft as you describe > > > > below but > > > > I will wait for it to come out so I can get the full picture of what is > > being proposed. > > > > > > Fair enough. > > > > > > Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 14:33:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21436 for ; Fri, 12 Dec 2003 14:33: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 1AUt27-0003jI-1Y for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14:33:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCJX38f014336 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14: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 1AUt26-0003j9-TT for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 14:33: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 OAA21405 for ; Fri, 12 Dec 2003 14:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUt24-0005ET-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:33:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUt23-0005EQ-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUt25-0003ip-DS; Fri, 12 Dec 2003 14: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 1AUt1R-0003hS-OZ for mip4@optimus.ietf.org; Fri, 12 Dec 2003 14:32:21 -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 OAA21393 for ; Fri, 12 Dec 2003 14:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUt1P-0005D1-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:32:19 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AUt1O-0005C7-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:32:18 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Dec 2003 14:31:46 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA84@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Pete McCann'" Cc: "'Alpesh'" , "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Date: Fri, 12 Dec 2003 14:31: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: , inline -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Friday, December 12, 2003 6:56 PM To: Tsirtsis George Cc: 'Alpesh'; 'Kent Leung'; Henrik Levkowetz; mip4@ietf.org Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt George, I'm sure you didn't mean that exactly. :) GT> just joking :-) Anyway, I wonder why the HA is in a good position to do a redirect to a "more local" HA, especially because the two HAs are by definition not local to each other and are likely to be in different administrative domains. GT> Whether the HAs are in same or different administrative domains is a matter of deployment. In my day job I am dealing with wide area Mobile IP deployments and as such it is very possible that clusters of HAs are serving different geographical areas under the same administrative domain. Instead, it seems like the MN could implement some policy for shifting its HA, based on information about the domain to which it is connected (FA NAI?) and the existence of any local sessions. Note that "local sessions" may include low-traffic TCP connections (terminal shells) which it may be difficult or impossible for the HA to detect. GT> Thus I think redirection should most of the time be optional/ When no local sessions exist, the MN could request the assignment of a new HA based on the existing draft. It could even leave its existing registration in place for a period of time if it wanted to overlap the two registrations. GT> Well, my point is that it might not be possible for the mobile to know that it would be a good idea to redirect. Anyway, I am trying to make a logical point in this case but I do not see this as a major requirement in the real world at least as far as I can see. To make that clear, in the part of the real world that I am dealing with the mobile is in a position to know when it is time to choose another HA and thus to optimize its routing. GT> As an engineer, however, I see that in the general case it might be the case that the HA knows the topology better than the mobile. Generally speaking operators do not like end points to know a lot about the topology of the network (and NAIs are not always advertised by FAs and are not available when CCoAs are used). The HA, however, IS part of the topology so an operator may configure such info in the HAs. GT> Anyway, I am not going to defend this idea for too much longer :-) George -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 14:46:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21796 for ; Fri, 12 Dec 2003 14:46: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 1AUtEh-0004jY-9c for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCJk3XA018190 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14: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 1AUtEh-0004jD-2R for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 14: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 OAA21789 for ; Fri, 12 Dec 2003 14:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtEe-0005fF-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:46:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUtEd-0005f7-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtEf-0004iO-BX; Fri, 12 Dec 2003 14:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtDm-0004hX-Ld for mip4@optimus.ietf.org; Fri, 12 Dec 2003 14:45: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 OAA21765 for ; Fri, 12 Dec 2003 14:45:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtDj-0005dV-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:45:04 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AUtDj-0005dO-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:45:03 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBCJiu5D014861; Fri, 12 Dec 2003 12:44:57 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hBCJfQD9015838; Fri, 12 Dec 2003 13:41:27 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1E4E32EC95; Fri, 12 Dec 2003 20:41:42 +0100 (CET) Message-ID: <3FDA19F5.4020505@nal.motlabs.com> Date: Fri, 12 Dec 2003 20:41:41 +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: Pete McCann Cc: Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , Henrik Levkowetz , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <16346.3911.779505.772357@gargle.gargle.HOWL> In-Reply-To: <16346.3911.779505.772357@gargle.gargle.HOWL> 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 Pete McCann wrote: > Anyway, I wonder why the HA is in a good position to do a redirect to > a "more local" HA, especially because the two HAs are by definition > not local to each other and are likely to be in different > administrative domains. I have the same doubt, among others. > Load balancing/failover (within the same location/administrative > domain) might be a better motivation for redirecting an in-progress > session. However, it is possible to solve at least some aspects of > this problem without any new protocol changes to Mobile IP, see, > e.g.: > > http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z Thanks for the reference. I think it is also possible to achieve a certain degree of load balancing by assigning two HA's on the same link the same IP address, at least with CARP. I do not think there is any problem in achieving load balancing for HA in this way. Alex -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 14:49:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22038 for ; Fri, 12 Dec 2003 14:49:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtHm-0004ui-LF for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14:49:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCJnEwt018882 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 14:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtHm-0004uT-Gd for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 14:49: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 OAA21916 for ; Fri, 12 Dec 2003 14:49:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtHj-0005pv-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:49:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUtHj-0005oi-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 14:49:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtHa-0004rf-I3; Fri, 12 Dec 2003 14: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 1AUtHT-0004oq-Um for mip4@optimus.ietf.org; Fri, 12 Dec 2003 14:48: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 OAA21884 for ; Fri, 12 Dec 2003 14:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtHR-0005n5-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:48:53 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AUtHQ-0005n1-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:48:52 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hBCJmTsj023820; Fri, 12 Dec 2003 12:48:29 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hBCJlvD9021234; Fri, 12 Dec 2003 13:47:58 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 53E592EC95; Fri, 12 Dec 2003 20:48:13 +0100 (CET) Message-ID: <3FDA1B7C.8010906@nal.motlabs.com> Date: Fri, 12 Dec 2003 20:48:12 +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: Tsirtsis George Cc: "'Henrik Levkowetz'" , mip4@ietf.org, Pete McCann Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA5A@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA5A@ftmail.lab.flarion.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 Tsirtsis George wrote: > A little bit more thought should be put into redirection from one > assigned HA to another. This is the case where a MN is registered > with HAx and potentially has active sessions based on the assigned > HoAx. Based on section 4.2.2, HAx may for example detect that the MN > is moving too far away from HAx and closer to HAy. HAx can then > reject the next RREQ from the MN with a REDIRECTED-HA-ADDRESS > Extension pointing to HAy. In case HAx and HAy are on the same link, another possibility might be for HAx to send an ICMP redirect through the tunnel to MH instructing it of the better HAy. > One way to avoid this is to introduce a flag that specifies the > redirection as optional or compulsory. If it is optional the MN > should be able to stay with HAx for a while longer (e.g.: until > current sessions stop and MN is idle). This may also require the > REDIRECTED-HA-ADDRESS Extension (with flag=optional) to be attached > to positive RREP rather than rejections. If, however, flag=compulsory > (due to policy or other reasons) then the MN will have to register > with HAy immediately per current draft and REDIRECTED-HA-ADDRESS > Extensions will be attached to a reject RREP. If HAx sends a compulsory message to MH such as MH is forced to end its sessions and anchor to HAy, I think there is no need for this compulsory message. I think MH has more information about its present location being closer to HAy (than to HAx) and can take that decision itself, no need to exchange compulsory messages with HAx. My oppinion is. Alex -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 15:16:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24035 for ; Fri, 12 Dec 2003 15:16: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 1AUthi-00065J-Om for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKG2k3023360 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUthi-00064M-40 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:16: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 PAA23917 for ; Fri, 12 Dec 2003 15:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUthg-00070J-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:16:00 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUthV-0006yw-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:15:49 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUth9-0006d2-T9 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtgo-0005w7-Io; Fri, 12 Dec 2003 15:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtgV-0005t0-Bw for mip4@optimus.ietf.org; Fri, 12 Dec 2003 15:14: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 PAA23663 for ; Fri, 12 Dec 2003 15:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtOa-00066A-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:56:16 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AUtOa-000667-00 for mip4@ietf.org; Fri, 12 Dec 2003 14:56:16 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBCJu15D023677; Fri, 12 Dec 2003 12:56:01 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hBCJtwal012593; Fri, 12 Dec 2003 13:55:58 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 82D852EC95; Fri, 12 Dec 2003 20:55:57 +0100 (CET) Message-ID: <3FDA1D4C.70705@nal.motlabs.com> Date: Fri, 12 Dec 2003 20:55:56 +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: Tsirtsis George Cc: "'Henrik Levkowetz'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA78@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA78@ftmail.lab.flarion.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 Tsirtsis George wrote: > I think, however, that it is worth letting the HA redirect a mobile > in a compulsory way (HA sends HA redirect in negative RREP) if that > is what needs to be done from network perspective (e.g.: topology > reasons, overloading etc). If it is worth considering that the network indicates the MH what to do and how to do it, then there are some other additional proposals, draft-lach-nac-* being one and there were many others in the past. Alex -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 15:51:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25779 for ; Fri, 12 Dec 2003 15:51: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 1AUuFb-0007vR-7d for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKp3JA030459 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuFb-0007vC-0I for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:51: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 PAA25765 for ; Fri, 12 Dec 2003 15:51:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuFZ-0000GE-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:51:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUuFZ-0000GB-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuFY-0007uQ-So; Fri, 12 Dec 2003 15:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuF9-0007u1-Ry for mip4@optimus.ietf.org; Fri, 12 Dec 2003 15:50: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 PAA25759 for ; Fri, 12 Dec 2003 15:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuF8-0000Fe-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:50:34 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AUuF7-0000Fb-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:50:34 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AUuAs-0000E0-00; Fri, 12 Dec 2003 21:46:10 +0100 Date: Fri, 12 Dec 2003 21:45:56 +0100 From: Henrik Levkowetz To: Alexandru Petrescu Cc: Pete McCann , Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt Message-Id: <20031212214556.54176f54.henrik@levkowetz.com> In-Reply-To: <3FDA19F5.4020505@nal.motlabs.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <16346.3911.779505.772357@gargle.gargle.HOWL> <3FDA19F5.4020505@nal.motlabs.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 12 December 2003, Alexandru wrote: > > Load balancing/failover (within the same location/administrative > > domain) might be a better motivation for redirecting an in-progress > > session. However, it is possible to solve at least some aspects of > > this problem without any new protocol changes to Mobile IP, see, > > e.g.: > > > > http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z > > Thanks for the reference. > > I think it is also possible to achieve a certain degree of load > balancing by assigning two HA's on the same link the same IP address, at > least with CARP. I do not think there is any problem in achieving load > balancing for HA in this way. Not a problem, but remember you still have to arrange to have registration requests to be forwarded between the two HA's, but only replied to by one of them. CARP (or VRRP) won't take care of that for you. Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 15:58:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26269 for ; Fri, 12 Dec 2003 15:58: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 1AUuMM-00086p-EI for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKw276031160 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15: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 1AUuML-00086V-TF for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:58: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 PAA26255 for ; Fri, 12 Dec 2003 15:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuMK-0000c4-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUuMJ-0000c1-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuMK-000869-PU; Fri, 12 Dec 2003 15: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 1AUuM0-00085f-3Q for mip4@optimus.ietf.org; Fri, 12 Dec 2003 15:57: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 PAA26248 for ; Fri, 12 Dec 2003 15:57:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuLy-0000ak-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:57:38 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AUuLy-0000ah-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:57:38 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AUuLS-0000Ez-00; Fri, 12 Dec 2003 21:57:06 +0100 Date: Fri, 12 Dec 2003 21:56:51 +0100 From: Henrik Levkowetz To: Alexandru Petrescu Cc: Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt Message-Id: <20031212215651.428d4a0a.henrik@levkowetz.com> In-Reply-To: <3FDA20BB.90905@nal.motlabs.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <20031212190503.7ad1a4a2.henrik@levkowetz.com> <3FDA20BB.90905@nal.motlabs.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=_Fri__12_Dec_2003_21_56_51_+0100_bWHoQuPG.IrB4ewd" 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=_Fri__12_Dec_2003_21_56_51_+0100_bWHoQuPG.IrB4ewd Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Friday 12 December 2003, Alexandru wrote: > Henrik Levkowetz wrote: > > The HA's would be situated physically close, but with different > > routes to the internet, to provide a greater redundancy than what you > > could get with a pure VRRP or CARP solution. > > I don't think that CARP requires the HA's to have same unique route to > the Internet. In my understanding it's just required the two hosts to > have a common link such that ARP works on that common link. VRRP and CARP lets one box take over and operate on the address of the other box, catching remote and local registrations at that address. If the MN is going to route it's RRQs to a completely different address, which is routed through other paths, you'll need something in addition to - or instead of - CARP. Henrik --Signature=_Fri__12_Dec_2003_21_56_51_+0100_bWHoQuPG.IrB4ewd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/2iuieVhrtTJkXCMRAsIAAKCYtTOS+LfmS0G9AJn4lzvjNw3WUQCguMam 5kVZSuXwW8YGHkVaOb7LFAQ= =lb1i -----END PGP SIGNATURE----- --Signature=_Fri__12_Dec_2003_21_56_51_+0100_bWHoQuPG.IrB4ewd-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 16:02:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24036 for ; Fri, 12 Dec 2003 15:16: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 1AUthi-00065F-OF for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKG2B9023361 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUthi-00064W-90 for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:16: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 PAA23920 for ; Fri, 12 Dec 2003 15:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUthg-00070K-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:16:00 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUthV-0006yt-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:15:49 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUth9-0006d0-K3 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 15:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtgl-0005uK-JK; Fri, 12 Dec 2003 15:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUtg6-0005pl-A2 for mip4@optimus.ietf.org; Fri, 12 Dec 2003 15:14: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 PAA23360 for ; Fri, 12 Dec 2003 15:14:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUtdH-0006fV-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:11:27 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AUtdH-0006fQ-00 for mip4@ietf.org; Fri, 12 Dec 2003 15:11:27 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hBCKASsj010033; Fri, 12 Dec 2003 13:10:30 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hBCKAJD9011812; Fri, 12 Dec 2003 14:10:20 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id EA0B12EC95; Fri, 12 Dec 2003 21:10:35 +0100 (CET) Message-ID: <3FDA20BB.90905@nal.motlabs.com> Date: Fri, 12 Dec 2003 21:10:35 +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: Henrik Levkowetz Cc: Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <20031212190503.7ad1a4a2.henrik@levkowetz.com> In-Reply-To: <20031212190503.7ad1a4a2.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 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: > The HA's would be situated physically close, but with different > routes to the internet, to provide a greater redundancy than what you > could get with a pure VRRP or CARP solution. I don't think that CARP requires the HA's to have same unique route to the Internet. In my understanding it's just required the two hosts to have a common link such that ARP works on that common link. Alex -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 16:02:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26441 for ; Fri, 12 Dec 2003 16:02: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 1AUuQF-0008FX-J3 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 16:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCL23qZ031705 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 16: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 1AUuQF-0008FI-0D for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 16: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 QAA26424 for ; Fri, 12 Dec 2003 16:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuQD-0000hC-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 16:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUuQD-0000h9-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 16:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuQD-0008Ey-TG; Fri, 12 Dec 2003 16: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 1AUuPi-0008EQ-4k for mip4@optimus.ietf.org; Fri, 12 Dec 2003 16:01:30 -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 QAA26413 for ; Fri, 12 Dec 2003 16:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuPg-0000gh-00 for mip4@ietf.org; Fri, 12 Dec 2003 16:01:28 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AUuPg-0000ge-00 for mip4@ietf.org; Fri, 12 Dec 2003 16:01:28 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AUuLo-0000F6-00; Fri, 12 Dec 2003 21:57:28 +0100 Date: Fri, 12 Dec 2003 21:57:24 +0100 From: Henrik Levkowetz To: Pete McCann Cc: Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt Message-Id: <20031212215724.65429ce1.henrik@levkowetz.com> In-Reply-To: <16346.3911.779505.772357@gargle.gargle.HOWL> References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <16346.3911.779505.772357@gargle.gargle.HOWL> 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 12 December 2003, Pete wrote: > Load balancing/failover (within the same location/administrative > domain) might be a better motivation for redirecting an in-progress > session. However, it is possible to solve at least some aspects of > this problem without any new protocol changes to Mobile IP, see, e.g.: > > http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z Yes, this is an implementation with the same characteristics as the VRRP / CARP based solutions I was talking about earlier. I didn't know of this particular reference, but have looked at HARP earlier. Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Dec 12 16:17:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26770 for ; Fri, 12 Dec 2003 16:17: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 1AUuek-0000Vo-P4 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 16:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCLH2uF001962 for mip4-archive@odin.ietf.org; Fri, 12 Dec 2003 16:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuek-0000VZ-Ju for mip4-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 16:17: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 QAA26751 for ; Fri, 12 Dec 2003 16:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuei-00015H-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 16:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUuei-00015E-00 for mip4-web-archive@ietf.org; Fri, 12 Dec 2003 16:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuej-0000VE-GI; Fri, 12 Dec 2003 16:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUueL-0000T1-Ih for mip4@optimus.ietf.org; Fri, 12 Dec 2003 16:16: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 QAA26747 for ; Fri, 12 Dec 2003 16:16:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUueJ-00014a-00 for mip4@ietf.org; Fri, 12 Dec 2003 16:16:35 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AUueJ-00014R-00 for mip4@ietf.org; Fri, 12 Dec 2003 16:16:35 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hBCLGIWF028271; Fri, 12 Dec 2003 14:16:24 -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 hBCLGAn1012329; Fri, 12 Dec 2003 15:16:11 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 47D642EC95; Fri, 12 Dec 2003 22:16:14 +0100 (CET) Message-ID: <3FDA301D.50900@nal.motlabs.com> Date: Fri, 12 Dec 2003 22:16:13 +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: Henrik Levkowetz Cc: Pete McCann , Tsirtsis George , "'Alpesh'" , "'Kent Leung'" , mip4@ietf.org Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-assignment-02.txt References: <9E3BA3946476AD4EB94672712B12A85F03AA82@ftmail.lab.flarion.com> <16346.3911.779505.772357@gargle.gargle.HOWL> <3FDA19F5.4020505@nal.motlabs.com> <20031212214556.54176f54.henrik@levkowetz.com> In-Reply-To: <20031212214556.54176f54.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 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: > Friday 12 December 2003, Alexandru wrote: > >>> Load balancing/failover (within the same location/administrative >>> domain) might be a better motivation for redirecting an >>> in-progress session. However, it is possible to solve at least >>> some aspects of this problem without any new protocol changes to >>> Mobile IP, see, e.g.: >>> >>> http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z >> >> Thanks for the reference. >> >> I think it is also possible to achieve a certain degree of load >> balancing by assigning two HA's on the same link the same IP >> address, at least with CARP. I do not think there is any problem >> in achieving load balancing for HA in this way. > > Not a problem, but remember you still have to arrange to have > registration requests to be forwarded between the two HA's, but only > replied to by one of them. Ah yes, that is right. I only thought about fault tolerance in fact, where if one HA goes down (so not sending any more replies) there will be one other HA staying up. The way those two HA's have their data synchronized is by "disk mirroring" I've seen. With HA off-loading an MH to another HA, it is indeed different and new registrations would be needed. Alex -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Dec 14 19:27:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03657 for ; Sun, 14 Dec 2003 19:27: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 1AVgZj-0000qN-Po for mip4-archive@odin.ietf.org; Sun, 14 Dec 2003 19:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF0R3lZ003235 for mip4-archive@odin.ietf.org; Sun, 14 Dec 2003 19:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgZi-0000pn-Ez for mip4-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 19:27: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 TAA03624 for ; Sun, 14 Dec 2003 19:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgZg-00073m-00 for mip4-web-archive@ietf.org; Sun, 14 Dec 2003 19:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVgZg-00073i-00 for mip4-web-archive@ietf.org; Sun, 14 Dec 2003 19:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgZh-0000pO-3G; Sun, 14 Dec 2003 19: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 1AVgZ5-0000p7-5k for mip4@optimus.ietf.org; Sun, 14 Dec 2003 19:26: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 TAA03599; Sun, 14 Dec 2003 19:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgZ3-00073Q-00; Sun, 14 Dec 2003 19:26:21 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AVgZ2-00073N-00; Sun, 14 Dec 2003 19:26:20 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBF0QJY9001503; Mon, 15 Dec 2003 09:26:19 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBF0QJv2021336; Mon, 15 Dec 2003 09:26:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA21335 ; Mon, 15 Dec 2003 09:26:19 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA11042; Mon, 15 Dec 2003 09:26:18 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp id JAA26953; Mon, 15 Dec 2003 09:26:17 +0900 (JST) Received: from localhost (inoue@flowerpark [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id hBF0QH126060; Mon, 15 Dec 2003 09:26:17 +0900 (JST) To: mipshop@ietf.org, mip4@ietf.org In-Reply-To: Your message of "Mon, 15 Dec 2003 09:17:43 +0900" <20031215091743J.inoue@isl.rdc.toshiba.co.jp> References: <20031215091743J.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031215092616I.inoue@isl.rdc.toshiba.co.jp> Date: Mon, 15 Dec 2003 09:26:16 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 127 Content-Transfer-Encoding: 7bit Subject: [Mip4] Call for participation: ICMU2004 Jan.8-9 at Yokosuka Japan 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 (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Dec 14 19:31:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03782 for ; Sun, 14 Dec 2003 19:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgde-00011L-7H for mip4-archive@odin.ietf.org; Sun, 14 Dec 2003 19:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF0V5t9003906 for mip4-archive@odin.ietf.org; Sun, 14 Dec 2003 19: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 1AVgdd-00010R-5L for mip4-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 19:31: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 TAA03755 for ; Sun, 14 Dec 2003 19:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgdb-00077F-00 for mip4-web-archive@ietf.org; Sun, 14 Dec 2003 19:31:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVgdb-00077C-00 for mip4-web-archive@ietf.org; Sun, 14 Dec 2003 19:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgdb-0000zb-DI; Sun, 14 Dec 2003 19:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgQo-0000T1-EK for mip4@optimus.ietf.org; Sun, 14 Dec 2003 19:17:50 -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 TAA03264; Sun, 14 Dec 2003 19:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t5-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t0-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBF0HjY9024113; Mon, 15 Dec 2003 09:17:46 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBF0HjiE010065; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA10062 ; Mon, 15 Dec 2003 09:17:45 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03597; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp id JAA03834; Mon, 15 Dec 2003 09:17:44 +0900 (JST) Received: from localhost (inoue@flowerpark [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id hBF0Hh125636; Mon, 15 Dec 2003 09:17:43 +0900 (JST) To: nemo@ietf.org, mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org, pana@ietf.org In-Reply-To: Your message of "Sat, 13 Dec 2003 10:55:08 +0900" <20031213105508E.inoue@isl.rdc.toshiba.co.jp> References: <20031213105508E.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031215091743J.inoue@isl.rdc.toshiba.co.jp> Date: Mon, 15 Dec 2003 09:17:43 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 126 Content-Transfer-Encoding: 7bit Subject: [Mip4] Call for participation: ICMU2004 Jan.8-9 at Yokosuka Japan 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 (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Dec 15 21:55:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13432 for ; Mon, 15 Dec 2003 21:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW5MX-0002vF-Ik for mip4-archive@odin.ietf.org; Mon, 15 Dec 2003 21:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG2t5HZ011230 for mip4-archive@odin.ietf.org; Mon, 15 Dec 2003 21: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 1AW5MX-0002v3-DI for mip4-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 21:55: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 VAA13429 for ; Mon, 15 Dec 2003 21:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW5MU-0004zy-00 for mip4-web-archive@ietf.org; Mon, 15 Dec 2003 21:55:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW5MT-0004zr-00 for mip4-web-archive@ietf.org; Mon, 15 Dec 2003 21:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW5MT-0004zm-00 for mip4-web-archive@ietf.org; Mon, 15 Dec 2003 21: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 1AW5MU-0002uQ-Eh; Mon, 15 Dec 2003 21: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 1AW5Lz-0002tI-NK for mip4@optimus.ietf.org; Mon, 15 Dec 2003 21:54: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 VAA13418 for ; Mon, 15 Dec 2003 21:54:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW5Lw-0004yk-00 for mip4@ietf.org; Mon, 15 Dec 2003 21:54:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW5Lv-0004yQ-00 for mip4@ietf.org; Mon, 15 Dec 2003 21:54:28 -0500 Received: from bay2-f134.bay2.hotmail.com ([65.54.247.134] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AW5Lu-0004wm-00 for mip4@ietf.org; Mon, 15 Dec 2003 21:54:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Dec 2003 18:53:56 -0800 Received: from 203.200.198.9 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 16 Dec 2003 02:53:56 GMT X-Originating-IP: [203.200.198.9] X-Originating-Email: [sakib@hotmail.com] X-Sender: sakib@hotmail.com From: "sakib mondal" To: mip4@ietf.org Date: Tue, 16 Dec 2003 02:53:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Dec 2003 02:53:56.0385 (UTC) FILETIME=[D8E7F910:01C3C37F] Subject: [Mip4] Book Announcement 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I thought the members of this mailing list would be interested in the following book. For more information, please visit http://www.wkap.nl/prod/b/0-306-47874-9. Best Regards, Sakib Mobile IP: Present State and Future Abdul Sakib Mondal Mobile IP: Present State and Future is an up-to-date introduction to the rapidly evolving field of mobile IP. In addition to detailed coverage of motivation behind mobile IP and fundamental concepts of mobile IP like agent advertisement and discovery, registration and tunneling, the book provides a comprehensive treatment of various associated technical issues such as security, TCP performance, multicasting and integration with wireless. The book has been written to serve as a text for network professionals who are yearning to acquire a clear understanding of this interesting field. It also covers ongoing research on possible ways to mitigate the challenges and issues associated with mobile IP. This makes the book a good reference for advanced readers as well as researchers in the field. Network system developers and administrators will find this book useful due to discussions on applications of mobile IP in the real world, and management of mobile IP. Last but not least, the book delineates possible future directions of mobile IP, a topic that will be of interest to a large section of network professionals and researchers. The book contains a large number of examples, illustrations and notes to make the presentation simple and interesting. The book should be relevant for courses on advanced networking, mobile computing and similar topics. _________________________________________________________________ Marriage? http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Join BharatMatrimony.com for free. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 16 16:03:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04393 for ; Tue, 16 Dec 2003 16:03: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 1AWMLQ-00058i-UO for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 16:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGL34f0019750 for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 16:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMLQ-00058T-QO for mip4-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:03: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 QAA04294 for ; Tue, 16 Dec 2003 16:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMLP-0002Rl-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMLO-0002Rd-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMLN-0002Ra-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMLN-00056z-W8; Tue, 16 Dec 2003 16: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 1AWMKg-00055v-Oa for mip4@optimus.ietf.org; Tue, 16 Dec 2003 16:02:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04189; Tue, 16 Dec 2003 16:02:15 -0500 (EST) Message-Id: <200312162102.QAA04189@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 16 Dec 2003 16:02:15 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-nai-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for AAA Network Access Identifiers Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mip4-aaa-nai-02.txt Pages : 10 Date : 2003-12-16 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple Authentication Authorization and Accounting (AAA) servers the reauthentication request may not be received by the same Home AAA server as previous authentication requests. In order for the new Home AAA server to be able to forward the request to the correct Home Agent it has to know the identity of the Home Agent. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-nai-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-aaa-nai-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-aaa-nai-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-16154226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-aaa-nai-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-aaa-nai-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-16154226.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 16 16:50:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09783 for ; Tue, 16 Dec 2003 16:50: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 1AWN4w-0007sR-Nk for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 16:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGLo6TO030279 for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 16:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWN4w-0007sI-Ja for mip4-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:50: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 QAA09780 for ; Tue, 16 Dec 2003 16:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWN4u-0006hm-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWN4t-0006hf-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:50:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWN4t-0006hc-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 16:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWN4s-0007ru-Ck; Tue, 16 Dec 2003 16:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWN3v-0007rE-8G for mip4@optimus.ietf.org; Tue, 16 Dec 2003 16:49: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 QAA09759 for ; Tue, 16 Dec 2003 16:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWN3t-0006hK-00 for mip4@ietf.org; Tue, 16 Dec 2003 16:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWN3s-0006hD-00 for mip4@ietf.org; Tue, 16 Dec 2003 16:49:00 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AWN3r-0006gw-00 for mip4@ietf.org; Tue, 16 Dec 2003 16:49:00 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 16:48:22 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F03AA99@ftmail.lab.flarion.com> From: Tsirtsis George To: mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-nai-02.txt Date: Tue, 16 Dec 2003 16:48:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-7" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I am a bit confused about the intention of this document. Could someone give me an example of how it can be used? I apologize in advance if this has been discussed recently. Thanks George -----Original Message----- From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, December 16, 2003 4:02 PM Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-nai-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for AAA Network Access Identifiers Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mip4-aaa-nai-02.txt Pages : 10 Date : 2003-12-16 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple Authentication Authorization and Accounting (AAA) servers the reauthentication request may not be received by the same Home AAA server as previous authentication requests. In order for the new Home AAA server to be able to forward the request to the correct Home Agent it has to know the identity of the Home Agent. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-nai-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-aaa-nai-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-aaa-nai-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 16 17:16:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10729 for ; Tue, 16 Dec 2003 17:16: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 1AWNU4-0000iJ-DK for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 17:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMG4bw002743 for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 17:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNU4-0000iA-40 for mip4-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:16: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 RAA10726 for ; Tue, 16 Dec 2003 17:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNU1-0007Ty-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNU1-0007Tr-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:16:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNU0-0007To-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNU1-0000hY-MV; Tue, 16 Dec 2003 17:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNTC-0000gp-AV for mip4@optimus.ietf.org; Tue, 16 Dec 2003 17:15: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 RAA10715 for ; Tue, 16 Dec 2003 17:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNTA-0007Ss-00 for mip4@ietf.org; Tue, 16 Dec 2003 17:15:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNT9-0007Sk-00 for mip4@ietf.org; Tue, 16 Dec 2003 17:15:07 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AWNT9-0007Sh-00 for mip4@ietf.org; Tue, 16 Dec 2003 17:15:07 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.levkowetz.com) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AWNT7-0000Gm-00; Tue, 16 Dec 2003 23:15:05 +0100 Date: Tue, 16 Dec 2003 23:15:02 +0100 From: Henrik Levkowetz To: Tsirtsis George Cc: mip4@ietf.org Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-nai-02.txt Message-Id: <20031216231502.6a05e13b.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F03AA99@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F03AA99@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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi George, Tuesday 16 December 2003, Tsirtsis George wrote: > I am a bit confused about the intention of this document. Could someone give > me an example of how it can be used? > I apologize in advance if this has been discussed recently. The original motivation for this document was that the extension and sub-types it defined was needed for the diameter mobile-ip application; it is referenced by the diameter mobile-ip draft and needed to complete it. (It would also be possible to use this extension to provide HA and AAAH NAIs for use with vendor-specific RADIUS AVPs.) In response to feedback at the time of WG last call, the specification was generalised so that it is not strictly limiting to be an AAA-NAI carrying extension. Does this answer your question? Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Dec 16 17:28:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11332 for ; Tue, 16 Dec 2003 17:28: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 1AWNfh-0001D4-KF for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 17:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMS5Ip004644 for mip4-archive@odin.ietf.org; Tue, 16 Dec 2003 17:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNfh-0001Cp-Fk for mip4-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:28: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 RAA11204 for ; Tue, 16 Dec 2003 17:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNff-00009w-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNfb-00009G-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:28:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNfb-000097-00 for mip4-web-archive@ietf.org; Tue, 16 Dec 2003 17:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNfc-00019l-I4; Tue, 16 Dec 2003 17: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 1AWNev-0000zJ-Rh for mip4@optimus.ietf.org; Tue, 16 Dec 2003 17:27: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 RAA11042 for ; Tue, 16 Dec 2003 17:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNet-000019-00 for mip4@iesg.org; Tue, 16 Dec 2003 17:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNep-00000Q-00 for mip4@iesg.org; Tue, 16 Dec 2003 17:27:14 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AWNeo-000004-00 for mip4@iesg.org; Tue, 16 Dec 2003 17:27:10 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.levkowetz.com) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AWNec-0000I4-00 for ; Tue, 16 Dec 2003 23:26:58 +0100 Date: Tue, 16 Dec 2003 23:26:57 +0100 From: Henrik Levkowetz To: mip4@iesg.org Message-Id: <20031216232657.70eabc5f.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=_Tue__16_Dec_2003_23_26_57_+0100_djqZ5C0Y8eScSeZC" Subject: [Mip4] Runthrough of issues raised on 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Signature=_Tue__16_Dec_2003_23_26_57_+0100_djqZ5C0Y8eScSeZC Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, I've gone through the comments given on this draft as a result of the WG last call. The issues have been recorded in an issue tracker at http://www.mip4.org/issues/tracker/mip4/ , and the proposed resolution for each of the issues raised can be seen in the working documents I maintain at http://ietf.levkowetz.com/drafts/dhc/mipadvert/ , as well as in the issue tracker. I'd much appreciate feedback on the proposed resolutions. See the list below for the individual issues, and link to proposed text. The full text of the current incarnation of the working document, with all the proposed fixes applied, is at: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.n.txt Henrik --- Issue Details 28 Title: How does the DHCP server know about agent load? From: Kuntal Chowdhury Issue: http://www.mip4.org/issues/tracker/mip4/issue28 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.a-from-01.diff.html 29 Title: 'B' bit may not always be valid From: Kuntal Chowdhury Issue: http://www.mip4.org/issues/tracker/mip4/issue29 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.b-from-02.a.diff.html 30 Title: Precise rules for sending and receiving these options needed. From: Ralph Droms , Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue30 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.c-from-02.b.diff.html 31 Title: Handling of sequence number field From: Naveen Paulkandasamy , Thomas Narten and others Issue: http://www.mip4.org/issues/tracker/mip4/issue31 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.d-from-02.c.diff.html 32 Title: Zero-length suboptions From: Kim Kinnear , Bernie Volz , Ted Lemon , Eric.Luce@nominum.com Issue: http://www.mip4.org/issues/tracker/mip4/issue32 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.e-from-02.d.diff.html 33 Title: Add request to IANA to maintain registry for sub-options From: Ralph Droms , Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue33 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.f-from-02.e.diff.html 34 Title: AD comments, with bearing on issues 29, 30, 33, plus nits From: Thomas Narten Issue: http://www.mip4.org/issues/tracker/mip4/issue34 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.g-from-02.f.diff.html 36 Title: Duplication of 3344 advertisement format specification & 1 nit From: Sami Vaarala , Espen Klovning Issue: http://www.mip4.org/issues/tracker/mip4/issue36 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.h-from-02.g.diff.html 37 Title: How should MN use this option? From: Espen Klovning" Issue: http://www.mip4.org/issues/tracker/mip4/issue37 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.i-from-02.h.diff.html 38 Title: Must the Agents be on-link? From: Pete McCann Issue: http://www.mip4.org/issues/tracker/mip4/issue38 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.j-from-02.i.diff.html 39 Title: Nits From: Ralph Droms Issue: http://www.mip4.org/issues/tracker/mip4/issue39 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.k-from-02.j.diff.html 40 Title: How to select the individual agent assignments From: Alpesh Patel , Naveen Paulkandasamy , Issue: http://www.mip4.org/issues/tracker/mip4/issue40 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.l-from-02.k.diff.html 41 Title: How does this option tie into authentication of DHCP messages From: Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue41 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.m-from-02.l.diff.html 42 Title: Tying NAI and ciaddr fields together From: Alpesh Patel Issue: http://www.mip4.org/issues/tracker/mip4/issue42 Fix: http://ietf.levkowetz.com/drafts/dhc/mipadvert/draft-ietf-dhc-mipadvert-opt-02.n-from-02.m.diff.html --Signature=_Tue__16_Dec_2003_23_26_57_+0100_djqZ5C0Y8eScSeZC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/34axeVhrtTJkXCMRAujqAKCo/Kv4j/4L33GqrczSM+et9fZ5gwCgjZJ/ /uWlNjF6hnVkksyYXTolo+8= =eJ2O -----END PGP SIGNATURE----- --Signature=_Tue__16_Dec_2003_23_26_57_+0100_djqZ5C0Y8eScSeZC-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Dec 18 02:48:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09807 for ; Thu, 18 Dec 2003 02:48: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 1AWstC-0004Sa-8h for mip4-archive@odin.ietf.org; Thu, 18 Dec 2003 02:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI7m6cY017140 for mip4-archive@odin.ietf.org; Thu, 18 Dec 2003 02:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWstB-0004SK-Ta for mip4-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 02:48: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 CAA09798 for ; Thu, 18 Dec 2003 02:48:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWst8-0004Z2-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWst5-0004Yp-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02:48:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWst5-0004Yi-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02: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 1AWst7-0004RW-4E; Thu, 18 Dec 2003 02: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 1AWo1j-0001dO-GJ for mip4@optimus.ietf.org; Wed, 17 Dec 2003 21:36: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 VAA18892 for ; Wed, 17 Dec 2003 21:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWo1g-00052e-00 for mip4@ietf.org; Wed, 17 Dec 2003 21:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWo1e-00052M-00 for mip4@ietf.org; Wed, 17 Dec 2003 21:36:32 -0500 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]) by ietf-mx with esmtp (Exim 4.12) id 1AWo1d-00052H-00 for mip4@ietf.org; Wed, 17 Dec 2003 21:36:29 -0500 Received: from parkslope (12-221-100-79.client.insightBB.com [12.221.100.79]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.10/8.12.10) with ESMTP id hBI2aSjI019167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 17 Dec 2003 20:36:29 -0600 (CST) Message-ID: <027501c3c50f$be412eb0$6501a8c0@parkslope> From: "Robin Kravets" To: Date: Wed, 17 Dec 2003 20:36:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Mip4] ACM MobiCom 2004 - Preliminary 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- PRELIMINARY ANNOUNCEMENT AND CALL FOR PAPERS MobiCom 2004 The Tenth Annual International Conference on Mobile Computing and Networking September 26 - October 1, 2004 Philadelphia, PA, USA (dates and location are subject to final approval) http://www.sigmobile.org/mobicom/2004/ Sponsored by ACM SIGMOBILE IMPORTANT DATES: Paper registrations due: March 8, 2004 Paper submissions due: March 15, 2004 Notification of acceptance: June 21, 2004 Camera-ready versions due: July 25, 2004 ACM MobiCom 2004, the Tenth Annual International Conference on Mobile Computing and Networking, is the tenth in the series of annual conferences sponsored by ACM SIGMOBILE and dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. The MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. PAPERS: Authors are invited to submit full papers presenting new research related to the theory or practice of mobile computing and networking. All submissions must describe original research that is not published or currently under review by another conference or journal. Areas of interest include, but are not limited to: - Applications and computing services supporting mobile users - Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity - Database and data management issues in mobile computing - Operating system and middleware support for mobile computing and networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks - Performance of mobile and wireless networks and systems - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Selected papers will appear in a special issue of the ACM/Kluwer Wireless Networks (WINET) journal. CHALLENGES PAPERS: The conference also solicits short papers (maximum of 8 pages) that challenge the mobile computing community with revolutionary new approaches, new technologies, or visionary applications. Such papers should provide stimulating ideas or grand visions that may open up exciting avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the normal submission procedure. The title of such papers must start with the word "Challenges," i.e., "Challenges: ... `rest of the title'." SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PDF or a PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), font size not smaller than 10 points, and must fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions for the paper submission procedure and format will be available on the conference web pages. The deadline for registering the title and the abstract of the paper with our electronic submission system is March 8, 2004 and the deadline for submitting the actual paper is March 15, 2004. All deadlines are 11:59PM EST. All submitted papers will be judged based on their quality through double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Samir Das and Ravi Jain at mobicom_pcchairs@acm.org. TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs, Andrew Campbell (campbell@ee.columbia.edu) and Taieb Znati (tznati@nsf.gov). The deadline for tutorial proposals is April 05, 2004. PANELS: Panel proposals are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-Chairs, Prathima Agrawal (pagrawal@eng.auburn.edu) and Tao Zhang (tao@research.telcordia.com). The deadline for panel proposals is April 26, 2004. RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment to be used. Send proposals to the Research Demo Chair, Elizabeth Belding-Royer (ebelding@cs.ucsb.edu). The deadline for demo proposals is July 12, 2004. We are also planning an Expo featuring exhibits of the latest mobile computing products and services. STUDENT POSTER SESSION: Student posters are solicited that present recent and on-going research by students on mobile computing and mobile and wireless networking topics. Student posters should not exceed 2 pages and should include a description of the student's research. See above for paper formatting requirements. Accepted posters will be put on the conference web page; however, they will not be printed in the conference proceedings. Send poster submissions to the Student Poster Co-Chairs, Chiara Petrioli (petrioli@di.uniroma1.it) and Stefano Basagni (basagni@ece.neu.edu). The deadline for student posters is July 12, 2004. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will be considered for the Best Student Paper Award, with a cash award of 1000 USD. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. GENERAL CHAIR Zygmunt Haas Cornell University PROGRAM CO-CHAIRS Samir R. Das Stony Brook University, SUNY Ravi Jain DoCoMo USA Labs STEERING COMMITTEE CHAIR Imrich Chlamtac University of Texas at Dallas ACM PROGRAM DIRECTOR Ginger Ignatoff Additional committee members will be announced on the conference web page. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Dec 18 02:48:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09824 for ; Thu, 18 Dec 2003 02:48:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWstC-0004SU-6r for mip4-archive@odin.ietf.org; Thu, 18 Dec 2003 02:48:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI7m6QW017133 for mip4-archive@odin.ietf.org; Thu, 18 Dec 2003 02:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWstB-0004SF-R5 for mip4-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 02:48: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 CAA09796 for ; Thu, 18 Dec 2003 02:48:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWst7-0004Yz-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWst5-0004Yl-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02:48:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWst5-0004Yh-00 for mip4-web-archive@ietf.org; Thu, 18 Dec 2003 02: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 1AWst7-0004Re-Js; Thu, 18 Dec 2003 02: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 1AWpN1-0004Uy-Sm for mip4@optimus.ietf.org; Wed, 17 Dec 2003 23:02: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 XAA21436 for ; Wed, 17 Dec 2003 23:02:35 -0500 (EST) From: dru.lundeng@icst.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWpMy-0007F9-00 for mip4@ietf.org; Wed, 17 Dec 2003 23:02:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWpMx-0007F2-00 for mip4@ietf.org; Wed, 17 Dec 2003 23:02:35 -0500 Received: from [66.246.27.66] (helo=fox.dnsvelocity.com) by ietf-mx with esmtp (Exim 4.12) id 1AWpMw-0007Dz-00 for mip4@ietf.org; Wed, 17 Dec 2003 23:02:34 -0500 Received: from cpanel by fox.dnsvelocity.com with local (Exim 4.24) id 1AWpLk-0005M7-BL; Thu, 18 Dec 2003 04:01:20 +0000 Received: from cache01.lax.untd.com (cache01.lax.untd.com [64.136.26.225]) by www.icst.org (IMP) with HTTP for ; Thu, 18 Dec 2003 04:01:20 +0000 Message-ID: <1071720080.3fe1269027185@www.icst.org> Date: Thu, 18 Dec 2003 04:01:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 64.136.26.225 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - fox.dnsvelocity.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [502 503] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org Content-Transfer-Encoding: 8bit Subject: [Mip4] MobiQuitous 2004 - Call for Papers 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=LINES_OF_YELLING,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit We apologize if you receive multiple copies of this Call for Papers *********************************************************************** PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS MobiQuitous 2004 http://www.mobiquitous.org The First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services August 22-25, 2004 Boston, Massachusetts, USA (ACM sponsorship pending) *********************************************************************** The combination of mobile and ubiquitous computing is emerging as a promising new paradigm with the goal to provide computing and communication services all the time, everywhere, transparently and invisibly to the user, using devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they interact, or both may be mobile. The implementation of such a paradigm requires advances in wireless network technologies and devices, development of infrastructures supporting cognitive environments, and discovery and identification of ubiquitous computing applications and services. The first ACM Annual International Conference on Mobile and Ubiquitous Systems: networking and services (Mobiquitous 04) will cover all these aspects, representing a forum where practitioners and researchers coming from the many areas involved in ubiquitous solutions design and deployment will be able to interact exchanging the cross-layer experiences needed to build the overall ubiquitous systems. Areas addressed by the conference include: applications, service-oriented computing, middleware, networking, agents, knowledge management and databases. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. The conference is interested in contributions addressing all the areas associated with mobile and ubiquitous architectures, infrastructure and services. Technical works clearly identifying how the specific contributions fit to an overall working solution are particularly of interest. Topics include, but are not limited to, the following feature topics: * Ubiquitous architectures and systems * Wearable computing and personal area network * Wireless technologies for mobile and ubiquitous communications (Bluetooth, ZigBee, 802.15.x, WiFi) * Wireless Internet access in ubiquitous systems * Reconfigurability and personalization of wireless network * Service discovery mechanisms, knowledge discovery, matching and composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer knowledge management * Emerging industrial/business scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Smart spaces * Ad hoc and sensor networking * Localization and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, and mobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * User interfaces * Toolkits, development environments, and languages for ubiquitous computing * Ontologies for mobile and ubiquitous computing SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare a Portable Document Format (PDF) or postscript version of their full paper. Papers must not exceed 8 pages double column (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. PUBLICATION: All submitted papers will be rigorously reviewed by technical program committee members. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks journal. TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair by March 1, 2004. DEMOS: Proposals for research and industrial demos are solicited. A maximum of 3 pages should be submitted which include a description of the demo and needed equipment. Proposals should be submitted to the Demo Chair, which will be announced shortly. *********************************************************************** IMPORTANT DATES *********************************************************************** Paper submission due: FEBRUARY 1 2004 Notification of acceptance: APRIL 30 2004 Camera-ready version due: MAY 15 2004 ********************************************************************** *** ORGANIZING COMMITTEE * General Co-Chairs Imrich Chlamtac University of Texas at Dallas, U.S.A. chlamtac@utdallas.edu Fausto Giunchiglia Universita` di Trento, Italy fausto@dit.unitn.it * General Vice Co-Chairs Michele Zorzi Universita` di Padova, Italy zorzi@dei.unipd.it Valentina Tamma University of Liverpool, U.K. valli@csc.liv.ac.uk * Program Co-Chairs * Networking Tom La Porta Penn State University, U.S.A. tlp@cse.psu.edu Chiara Petrioli Universita` di Roma "La Sapienza," Italy petrioli@dsi.uniroma1.it * Knowledge management Tim Finin Univ. of Maryland Baltimore County, U.S.A. finin@cs.umbc.edu Chiara Ghidini ITC-IRST, Trento, Italy ghidini@itc.it * Tutorial Chair Mani Srivastava Univ. of California Los Angeles, U.S.A. * Publicity Co-Chairs Stefano Basagni Northeastern University, U.S.A. Ilya Zaihrayeu Universita` di Trento, Italy * Registration Chair Robin Kravets Univ. of Illinois Urbana-Champaign, U.S.A. * Demo Chair Yannis Labrou Fujitsu Labs of America, U.S.A. * Local Arrangements Chair Prithwish Basu BBN Technologies, U.S.A. * Publication Chair Roger Whitaker Cardiff University, U.K. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4