From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 01 00:46:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoDQ0-0005a8-4s for dna-archive@megatron.ietf.org; Fri, 01 Jul 2005 00:46:24 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12929 for ; Fri, 1 Jul 2005 00:46:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ44ZPSE2Y99N4G4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 01 Jul 2005 14:45:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F8FFAB548; Fri, 01 Jul 2005 14:45:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 27AD44FB09; Fri, 01 Jul 2005 14:45:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j614jPh02122 for dna-list; Fri, 01 Jul 2005 14:45:25 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j614jPw02118 for ; Fri, 01 Jul 2005 14:45:25 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ44YZYJEQ9AOV3R@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 01 Jul 2005 14:45:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BC0FAB543 for ; Fri, 01 Jul 2005 14:45:09 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id AEAAD4FB07 for ; Fri, 01 Jul 2005 14:45:08 +1000 (EST) Date: Fri, 01 Jul 2005 14:45:02 +1000 From: Greg Daley Subject: [DNA] [Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France] Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C4CA4E.6010406@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, Please be aware of the following cut-off dates for draft submission before the Paris session. Greg -------- Original Message -------- Date: Fri, 01 Jul 2005 00:00:01 -0400 From: ietf-secretariat@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Sender: ietf-announce-bounces@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 63rd IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, July 11th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Tuesday, July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, August 1st at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or revised Internet-Draft after their respective cutoff deadlines, then your document will be retained and posted when Internet-Draft processing resumes. You will no longer be required to resubmit the document. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 01 01:21:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoDyF-0006rq-1f for dna-archive@megatron.ietf.org; Fri, 01 Jul 2005 01:21:47 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15490 for ; Fri, 1 Jul 2005 01:21:45 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ46910RA89AOVQ1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 01 Jul 2005 15:21:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B23EDAB544; Fri, 01 Jul 2005 15:21:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6AAFD4FB08; Fri, 01 Jul 2005 15:21:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j615LG702520 for dna-list; Fri, 01 Jul 2005 15:21:16 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j615LGw02516 for ; Fri, 01 Jul 2005 15:21:16 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ468JW1M09AOF4S@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 01 Jul 2005 15:21:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B4539AB546 for ; Fri, 01 Jul 2005 15:21:05 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 95D634FB05 for ; Fri, 01 Jul 2005 15:21:05 +1000 (EST) Date: Fri, 01 Jul 2005 15:21:00 +1000 From: Greg Daley Subject: [DNA] Any drafts to approve for draft-ietf-dna-? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42C4D2BC.7090702@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, Please remind me if there are any drafts you think should be approved for draft-ietf-dna-yyyyyy-00 before Tuesday. as far as I can recall, there's one document pending. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 04 09:31:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpR2t-0007e1-Kj for dna-archive@megatron.ietf.org; Mon, 04 Jul 2005 09:31:35 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14109 for ; Mon, 4 Jul 2005 09:31:33 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQ8U7NOLNI94VXPZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 04 Jul 2005 23:31:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 355CD8000E; Mon, 04 Jul 2005 23:30:44 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id F07233C00C; Mon, 04 Jul 2005 23:30:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j64DTEH11766 for dna-list; Mon, 04 Jul 2005 23:29:14 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j64DTEw11762 for ; Mon, 04 Jul 2005 23:29:14 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQ8U5RNS9I9AOZLO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 04 Jul 2005 23:29:13 +1000 Received: by localhost (Postfix, from userid 510) id E05C08000E; Mon, 04 Jul 2005 23:29:12 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id 285F93C003; Mon, 04 Jul 2005 23:29:10 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j64DT88t015595; Mon, 04 Jul 2005 07:29:09 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j64DT2sp225982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 04 Jul 2005 06:29:06 -0700 (PDT) Date: Mon, 04 Jul 2005 06:29:38 -0700 From: Erik Nordmark Subject: Re: [DNA] DNA and TSLLAO In-reply-to: <42BF9465.1020707@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, Pekka Nikander Message-id: <42C939C2.5050608@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF9465.1020707@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Do people think it would be useful for this technology to > be standardized? Yes, I think it is necessary for a performant DNA solution. > If so, where should it go: > > a) within the DNA solution > > b) as a separate document within DNA > > c) ask IPv6 (or another suggested WG) to work on it? Either b) or c) would be fine with me; depends on how the ADs and WG chairs want to organize things. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 05 15:57:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptXS-0004fB-To for dna-archive@megatron.ietf.org; Tue, 05 Jul 2005 15:57:03 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15203 for ; Tue, 5 Jul 2005 15:56:59 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQALY5II5U97HW7T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 06 Jul 2005 05:56:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C043AB54A; Wed, 06 Jul 2005 05:56:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id DF1AA4FB05; Wed, 06 Jul 2005 05:56:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j65JoKv31951 for dna-list; Wed, 06 Jul 2005 05:50:20 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j65JoJw31947 for ; Wed, 06 Jul 2005 05:50:19 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQALQDJPJA94W2RH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 06 Jul 2005 05:50:06 +1000 Received: by localhost (Postfix, from userid 510) id 63B8CAB543; Wed, 06 Jul 2005 05:50:06 +1000 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 4C52B4FB06 for ; Wed, 06 Jul 2005 05:50:04 +1000 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DptQf-00037N-GE; Tue, 05 Jul 2005 15:50:01 -0400 Date: Tue, 05 Jul 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-routers-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_YcoU6CyCaPTzZhzkj+PbmA)" X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) --Boundary_(ID_YcoU6CyCaPTzZhzkj+PbmA) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 - Best Current Practices for Routers Author(s) : S. Narayanan, et al. Filename : draft-ietf-dna-routers-00.txt Pages : 22 Date : 2005-7-5 Hosts experiencing rapid link-layer changes may require to do configuration change detection procedures more frequently than traditional fixed hosts. This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-routers-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-routers-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-dna-routers-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. --Boundary_(ID_YcoU6CyCaPTzZhzkj+PbmA) Content-type: multipart/alternative; boundary="Boundary_(ID_W7+WhBXoAu3IU1FBdevgvA)" --Boundary_(ID_W7+WhBXoAu3IU1FBdevgvA) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-5131634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-routers-00.txt --Boundary_(ID_W7+WhBXoAu3IU1FBdevgvA) Content-type: Message/External-body; name=draft-ietf-dna-routers-00.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-routers-00.txt Content-Type: text/plain Content-ID: <2005-7-5131634.I-D@ietf.org> --Boundary_(ID_W7+WhBXoAu3IU1FBdevgvA)-- --Boundary_(ID_YcoU6CyCaPTzZhzkj+PbmA)-- From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 06 18:06:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqI2h-0003Ei-RV for dna-archive@megatron.ietf.org; Wed, 06 Jul 2005 18:06:56 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03075 for ; Wed, 6 Jul 2005 18:06:50 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQC4SJHEQ497H04G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 07 Jul 2005 08:06:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C0ACE8000E; Thu, 07 Jul 2005 08:06:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7635A3C00D; Thu, 07 Jul 2005 08:06:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j66M2YY16453 for dna-list; Thu, 07 Jul 2005 08:02:34 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j66M2Ww16449 for ; Thu, 07 Jul 2005 08:02:32 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQC4NV7JOM9AP1J9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 07 Jul 2005 08:02:30 +1000 Received: by localhost (Postfix, from userid 510) id D0058AB542; Thu, 07 Jul 2005 08:02:30 +1000 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id BBB6A4FB06; Thu, 07 Jul 2005 08:02:26 +1000 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j66LxD7S008440; Thu, 07 Jul 2005 00:59:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 07 Jul 2005 01:02:17 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 06 Jul 2005 17:02:13 -0500 Date: Wed, 06 Jul 2005 15:02:12 -0700 From: Michael.G.Williams@nokia.com Subject: [DNA] Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com, gabriel_montenegro_2000@yahoo.com Message-id: <8A76136424391244A5CF0165337085375F4815@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWBscTY+GcB1EDLSGqEYlGAwjIGvgABVtUgAB/eFKAADCyF8AAAKZzAAAEz5iAAAbbesAAAJfow Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 06 Jul 2005 22:02:13.0544 (UTC) FILETIME=[5D722280:01C58276] Content-Transfer-Encoding: 7BIT Colleagues, The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting. There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. Drafts of interest include but are not limited to : "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21." "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 06 18:18:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIDq-00051Y-QB for dna-archive@megatron.ietf.org; Wed, 06 Jul 2005 18:18:26 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04763 for ; Wed, 6 Jul 2005 18:18:23 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQC56MG4FE94X0QZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 07 Jul 2005 08:18:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BCE47AB544; Thu, 07 Jul 2005 08:17:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6998C4FB02; Thu, 07 Jul 2005 08:17:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j66MHT616634 for dna-list; Thu, 07 Jul 2005 08:17:29 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j66MHSw16630 for ; Thu, 07 Jul 2005 08:17:28 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQC56CNRD49AP1CX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 07 Jul 2005 08:17:25 +1000 Received: by localhost (Postfix, from userid 510) id E7FF9AB545; Thu, 07 Jul 2005 08:17:24 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id C55034FB05; Thu, 07 Jul 2005 08:17:23 +1000 (EST) Date: Wed, 06 Jul 2005 15:18:43 -0700 From: James Kempf Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: Michael.G.Williams@nokia.com, mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com, gabriel_montenegro_2000@yahoo.com Message-id: <0b1b01c58278$ab6ad980$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <8A76136424391244A5CF0165337085375F4815@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Mike, Would you like to get a BAR BOF-style meeting at IETF set up to discuss this? With the help of an AD or IAB member, I think we could get a room reserved for that purpose. jak ----- Original Message ----- From: To: ; ; Cc: ; ; ; ; ; Sent: Wednesday, July 06, 2005 3:02 PM Subject: Interest in protocols for IEEE 802.21 IS, CS, ES Colleagues, The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting. There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. Drafts of interest include but are not limited to : "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21." "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 06 19:11:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqJ3S-00048W-Nz for dna-archive@megatron.ietf.org; Wed, 06 Jul 2005 19:11:46 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13408 for ; Wed, 6 Jul 2005 19:11:42 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQC71XNDWI94WYXL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 07 Jul 2005 09:11:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1FB6E8000F; Thu, 07 Jul 2005 09:11:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id AB1D03C003; Thu, 07 Jul 2005 09:11:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j66NAgM17220 for dna-list; Thu, 07 Jul 2005 09:10:42 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j66NAfw17216 for ; Thu, 07 Jul 2005 09:10:41 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQC71256Q094WU60@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 07 Jul 2005 09:10:25 +1000 Received: by localhost (Postfix, from userid 510) id F3BB8AB54B; Thu, 07 Jul 2005 09:10:24 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id CDFD54FB09; Thu, 07 Jul 2005 09:10:20 +1000 (EST) Date: Wed, 06 Jul 2005 16:11:40 -0700 From: James Kempf Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: gabriel montenegro , Michael.G.Williams@nokia.com, mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Message-id: <0b4801c58280$112fd7a0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <20050706222637.29798.qmail@web81912.mail.mud.yahoo.com> Content-Transfer-Encoding: 7BIT Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 06 23:45:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNKi-0007d3-Gf for dna-archive@megatron.ietf.org; Wed, 06 Jul 2005 23:45:52 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00491 for ; Wed, 6 Jul 2005 23:45:49 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQCGMX1Y229AOO71@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 07 Jul 2005 13:45:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9EA5F8000F; Thu, 07 Jul 2005 13:45:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 429C83C00D; Thu, 07 Jul 2005 13:45:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j673ifT20207 for dna-list; Thu, 07 Jul 2005 13:44:41 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j673ifw20203 for ; Thu, 07 Jul 2005 13:44:41 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQCGLS1XO89AP2EY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 07 Jul 2005 13:44:25 +1000 Received: by localhost (Postfix, from userid 510) id B1398AB542; Thu, 07 Jul 2005 13:44:25 +1000 (EST) Received: from thingmagic.com (unknown [204.9.221.21]) by curly.its.monash.edu.au (Postfix) with ESMTP id AA09A4FB06 for ; Thu, 07 Jul 2005 13:44:23 +1000 (EST) Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Date: Wed, 06 Jul 2005 23:41:45 -0400 From: Margaret Wasserman Subject: [DNA] NEW!! Internet Area Mailing List Sender: owner-dna@ecselists.eng.monash.edu.au To: int-area@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 07 11:06:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXxF-0002EO-6R for dna-archive@megatron.ietf.org; Thu, 07 Jul 2005 11:06:21 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15760 for ; Thu, 7 Jul 2005 11:06:15 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQD4E80OHW94SK0F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Jul 2005 01:05:48 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ACF888000E; Fri, 08 Jul 2005 01:05:31 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1A6AB3C00C; Fri, 08 Jul 2005 01:05:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j67F4lC27486 for dna-list; Fri, 08 Jul 2005 01:04:47 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j67F4gw27482 for ; Fri, 08 Jul 2005 01:04:42 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQD4D4Z99S94WX7S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Jul 2005 01:04:39 +1000 Received: by localhost (Postfix, from userid 510) id 499B580010; Fri, 08 Jul 2005 01:04:39 +1000 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id B37163C00C; Fri, 08 Jul 2005 01:04:34 +1000 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j67F1H3d031900; Thu, 07 Jul 2005 18:01:20 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 07 Jul 2005 18:04:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 07 Jul 2005 10:04:23 -0500 Date: Thu, 07 Jul 2005 10:04:17 -0500 From: stefano.faccin@nokia.com Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: kempf@docomolabs-usa.com, gabriel_montenegro_2000@yahoo.com, Michael.G.Williams@nokia.com, mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Message-id: <33B0AB1B4BA65042831AE04C0836E2038DC878@daebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWCgFmtyOn6QW7xRvOWeVNDsk32nwAhA1Rw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 07 Jul 2005 15:04:23.0927 (UTC) FILETIME=[2933E870:01C58305] Content-Transfer-Encoding: 7BIT James, I guess the reference to triggers may have been a bit misleading. They are relevant from the point of view that the drafts refer to some of the technical aspects that the MIH services cover, but the focus here is not specifically on the triggers between L2 and L3. If the MIHEP BOF is approved, and if we coordinate the discussion with MIPSHOP, I believe we will be able to cover the various aspects without requiring any other BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 07 12:38:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZNy-0000LF-G2 for dna-archive@megatron.ietf.org; Thu, 07 Jul 2005 12:38:02 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23915 for ; Thu, 7 Jul 2005 12:37:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQD7KWKFMK99NWCN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Jul 2005 02:37:15 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EFDDAB545; Fri, 08 Jul 2005 02:37:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D71E54FB08; Fri, 08 Jul 2005 02:37:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j67GaoR28472 for dna-list; Fri, 08 Jul 2005 02:36:50 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j67Gamw28468 for ; Fri, 08 Jul 2005 02:36:48 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQD7K1ORK894WTK6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Jul 2005 02:36:31 +1000 Received: by localhost (Postfix, from userid 510) id F27ECAB543; Fri, 08 Jul 2005 02:36:30 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id CD7A94FB05; Fri, 08 Jul 2005 02:36:26 +1000 (EST) Date: Thu, 07 Jul 2005 09:37:46 -0700 From: James Kempf Subject: Re: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: stefano.faccin@nokia.com, gabriel_montenegro_2000@yahoo.com, Michael.G.Williams@nokia.com, mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Message-id: <0e4601c58312$34d17780$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <33B0AB1B4BA65042831AE04C0836E2038DC878@daebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Stefano, There is also Yoshi Obha's draft on media-independent pre-authentication. Having read a draft of the 802.21 spec, I don't recall anything specifically in this area, but from Mike's email, it sounds as if they are interested in it. Was the intent of MIHEP to cover that too? jak ----- Original Message ----- From: To: ; ; ; ; ; Cc: ; ; ; Sent: Thursday, July 07, 2005 8:04 AM Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES James, I guess the reference to triggers may have been a bit misleading. They are relevant from the point of view that the drafts refer to some of the technical aspects that the MIH services cover, but the focus here is not specifically on the triggers between L2 and L3. If the MIHEP BOF is approved, and if we coordinate the discussion with MIPSHOP, I believe we will be able to cover the various aspects without requiring any other BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 07 13:13:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZvt-0004DX-OT for dna-archive@megatron.ietf.org; Thu, 07 Jul 2005 13:13:07 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26616 for ; Thu, 7 Jul 2005 13:13:01 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQD8TSUCIW99NS2V@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Jul 2005 03:12:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C88480011; Fri, 08 Jul 2005 03:12:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B7B403C00D; Fri, 08 Jul 2005 03:12:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j67HCLx28928 for dna-list; Fri, 08 Jul 2005 03:12:21 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j67HCLw28924 for ; Fri, 08 Jul 2005 03:12:21 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQD8T639FK94X1JU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Jul 2005 03:12:07 +1000 Received: by localhost (Postfix, from userid 510) id CA3018000D; Fri, 08 Jul 2005 03:12:06 +1000 (EST) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id DDFA93C00B; Fri, 08 Jul 2005 03:12:03 +1000 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j67H6uCg012972; Thu, 07 Jul 2005 20:06:57 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 07 Jul 2005 20:11:51 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 07 Jul 2005 12:11:49 -0500 Date: Thu, 07 Jul 2005 12:11:48 -0500 From: stefano.faccin@nokia.com Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: kempf@docomolabs-usa.com, gabriel_montenegro_2000@yahoo.com, Michael.G.Williams@nokia.com, mipshop@ietf.org, mobopts@irtf.org, dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au, margaret@thingmagic.com, rajeev@iprg.nokia.com, Basavaraj.Patil@nokia.com Message-id: <33B0AB1B4BA65042831AE04C0836E2033BBAA4@daebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Thread-Index: AcWDEjXbcycTYGhBRB673gIRPcnENQABEpaw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 07 Jul 2005 17:11:49.0436 (UTC) FILETIME=[F647FFC0:01C58316] Content-Transfer-Encoding: 7BIT James, thanks for bringing this up. Yoshi's work is definitely interesting and relevant to the area of 802.21, as Michael says. So far 802.21 has not been working on security aspects, but I do not rule out the group may work on them in the future. Therefore, as far as the present relevance of Yoshi's material with 802.21 work and requirements, that would be a whole separate discussion by itself. Again, I think it is relevant, but I'm afraid if we pull this into the MIHEP discussion now (without having had a similar discussion in 802.21) we may just stir up more mud and divert the discussion from the main topic. Stefano -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, July 07, 2005 11:38 To: Faccin Stefano (Nokia-NRC/Dallas); gabriel_montenegro_2000@yahoo.com; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: Re: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Stefano, There is also Yoshi Obha's draft on media-independent pre-authentication. Having read a draft of the 802.21 spec, I don't recall anything specifically in this area, but from Mike's email, it sounds as if they are interested in it. Was the intent of MIHEP to cover that too? jak ----- Original Message ----- From: To: ; ; ; ; ; Cc: ; ; ; Sent: Thursday, July 07, 2005 8:04 AM Subject: RE: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES James, I guess the reference to triggers may have been a bit misleading. They are relevant from the point of view that the drafts refer to some of the technical aspects that the MIH services cover, but the focus here is not specifically on the triggers between L2 and L3. If the MIHEP BOF is approved, and if we coordinate the discussion with MIPSHOP, I believe we will be able to cover the various aspects without requiring any other BOFs. Stefano -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of ext James Kempf Sent: Wednesday, July 06, 2005 18:12 To: gabriel montenegro; Williams Michael.G (Nokia-ES/MtView); mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: Greg.Daley@eng.monash.edu.au; margaret@thingmagic.com; rajeev@iprg.nokia.com; Patil Basavaraj (Nokia-NET/Dallas) Subject: [DNA] Re: Interest in protocols for IEEE 802.21 IS, CS, ES Some of the things on Mike's list, like link triggers, are DNA items. We had discussed doing the InfoElements work in Mipshop prior to the MIHEP BOF discussion coming up. So now I'm completely confused what is happening, which is why I suggested the BAR BOF. Margaret, can you help us figure this out? Has the MIHEP BOF been approved? jak ----- Original Message ----- From: "gabriel montenegro" To: "James Kempf" ; ; ; ; Cc: ; ; ; Sent: Wednesday, July 06, 2005 3:26 PM Subject: Re: Interest in protocols for IEEE 802.21 IS, CS, ES > > Isn't this the subject for the proposed MIHEP BoF? What's the latest word, > is it being scheduled? Some of this discussion is quite relevant to > the MIPSHOP meeting, and the 802.21 folks are already on that agenda. > > But I agree that this is an important discussion. If the MIHEP BoF does not get > scheduled, we should have a bar BoF on the subject. > > -gabriel > > --- James Kempf wrote: > > > Mike, > > > > Would you like to get a BAR BOF-style meeting at IETF set up to discuss > > this? With the help of an AD or IAB member, I think we could get a room > > reserved for that purpose. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Cc: ; ; > > ; ; > > ; > > Sent: Wednesday, July 06, 2005 3:02 PM > > Subject: Interest in protocols for IEEE 802.21 IS, CS, ES > > > > > > Colleagues, > > > > The IEEE 802.21 working group is developing services for facilitating IP > > address mobility and service mobility, especially handoff across a > > variety of media. The group is interested in working with the relevant > > IETF/IRTF working groups to develop methods of carrying these services > > across the network. It would be ideal to discuss this at the next IETF > > meeting. > > > > There are multiple drafts currently issued or in development that are > > interesting and could serve as the basis for starting the work. > > > > Drafts of interest include but are not limited to : > > > > "Neighborhood Information Elements Discovery (NED) > > (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic > > protocol for carrying information elements of interest to IEEE 802.21." > > > > "Some Requirements for a Media Independent Handover Information Service" > > (draft-faccin-mih-infoserv-00.txt, > > http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt > > ). > > > > "Architectural Implications of Link Indications" > > http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt > > > > > > > > "Unified L2 Abstractions for L3-Driven Fast Handover" > > http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 > > 2.txt > > > > "A Framework of Media-Independent Pre-Authentication (MPA)" > > http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. > > txt > > > > Best Regards, > > Michael G. Williams > > IEEE 802.21 Working Group Vice Chair > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 11 15:53:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds4L7-0006sI-Mm for dna-archive@megatron.ietf.org; Mon, 11 Jul 2005 15:53:17 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16086 for ; Mon, 11 Jul 2005 15:53:14 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQIZK39XS694XGCM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Jul 2005 05:52:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F02C4AB543; Tue, 12 Jul 2005 05:52:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B03CD4FB03; Tue, 12 Jul 2005 05:52:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6BJoHG30904 for dna-list; Tue, 12 Jul 2005 05:50:17 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6BJoHw30900 for ; Tue, 12 Jul 2005 05:50:17 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQIZHH0C2G99O1JV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Jul 2005 05:50:07 +1000 Received: by localhost (Postfix, from userid 510) id B7BF1AB542; Tue, 12 Jul 2005 05:50:07 +1000 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id DB2764FB06 for ; Tue, 12 Jul 2005 05:50:04 +1000 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ds4Hy-0001Sn-7u; Mon, 11 Jul 2005 15:50:02 -0400 Date: Mon, 11 Jul 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-hosts-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_fuPNnWzAY8tut8RzZvohtg)" X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) --Boundary_(ID_fuPNnWzAY8tut8RzZvohtg) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 - Best Current Practices for hosts. Author(s) : S. Narayanan, et al. Filename : draft-ietf-dna-hosts-01.txt Pages : 25 Date : 2005-7-11 Hosts experiencing rapid link-layer changes may require efficient IP configuration change detection procedures than traditional fixed hosts. DNA is defined as the process by which a host collects appropriate information and detects the identity of its currently attached link to ascertains the validity of its IP configuration. This document details best current practice for Detecting Network Attachment in IPv6 hosts using existing Neighbor Discovery procedures. Since there is no explicit link identification mechanism in the existing Neighbor Discovery for IP Version 6, the document describes implicit mechanisms for identifying the current link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-hosts-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-hosts-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-dna-hosts-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. --Boundary_(ID_fuPNnWzAY8tut8RzZvohtg) Content-type: multipart/alternative; boundary="Boundary_(ID_9T7NmZKUZa0oszud9Jh6JA)" --Boundary_(ID_9T7NmZKUZa0oszud9Jh6JA) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-11130858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-hosts-01.txt --Boundary_(ID_9T7NmZKUZa0oszud9Jh6JA) Content-type: Message/External-body; name=draft-ietf-dna-hosts-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-hosts-01.txt Content-Type: text/plain Content-ID: <2005-7-11130858.I-D@ietf.org> --Boundary_(ID_9T7NmZKUZa0oszud9Jh6JA)-- --Boundary_(ID_fuPNnWzAY8tut8RzZvohtg)-- From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 03:06:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsEqs-0006Ol-Db for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 03:06:46 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24760 for ; Tue, 12 Jul 2005 03:06:44 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQJN3YDOWY99OAK9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Jul 2005 17:06:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67FB58000F; Tue, 12 Jul 2005 17:06:25 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0EFEF3C00C; Tue, 12 Jul 2005 17:06:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6C75a905676 for dna-list; Tue, 12 Jul 2005 17:05:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6C75Zw05672 for ; Tue, 12 Jul 2005 17:05:35 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQJN2LB12S94XO32@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Jul 2005 17:05:19 +1000 Received: by localhost (Postfix, from userid 510) id 90CED8000E; Tue, 12 Jul 2005 17:05:19 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 84FF43C011 for ; Tue, 12 Jul 2005 17:05:17 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI00L3J6CRW1@mailout1.samsung.com> for dna@eng.monash.edu.au; Tue, 12 Jul 2005 16:05:15 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJI00CT06CHRN@mmp1.samsung.com> for dna@eng.monash.edu.au; Tue, 12 Jul 2005 16:05:15 +0900 (KST) Date: Tue, 12 Jul 2005 12:31:39 +0530 From: Syam Madanapalli Subject: [DNA] Linkid Draft Implementation and Test Results Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: JinHyeock Choi , Subba Reddy Message-id: <020301c586af$938c9570$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Dear DNA WG, We have implemented the following Linkid draft DNA Solution: Link Identifier based approach http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-01.txt and set up a test bed to conducted a few experiments. We are glad to say that everything worked fine and you can find the result in http://www.diffeo.com/test/Linkid_Implementation.ppt In brief, the code is not so complex to write (390 line for a router and 160 lines for a host.) and our testbed consists of 2 links having 3 router interfaces respectively (as described in slide 3). We have tested the cases of "Initialization", "Linkid change (Linkid prefix addition & deletion)" and "Link change" and the results were as expected. Routers agreed on the same linkid in a second and a host correctly checked for the link change. - When a linkid is changed without link change, the host simply changed its linkid prefix without falsely assuming a link change. - When the host moved to a different link, the host correctly detected a link change and changed its linkid prefix. Your feedback will be appreciated. Regards, Syam From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 03:36:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFJO-0008Ri-7O for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 03:36:14 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27365 for ; Tue, 12 Jul 2005 03:36:12 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQJO4EDKIM94WVPT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Jul 2005 17:35:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A4EF8000F; Tue, 12 Jul 2005 17:35:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D0F433C003; Tue, 12 Jul 2005 17:35:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6C7YpD06001 for dna-list; Tue, 12 Jul 2005 17:34:51 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6C7Yow05997 for ; Tue, 12 Jul 2005 17:34:50 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQJO43RZQU9AP76D@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Jul 2005 17:34:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 46B8BAB542; Tue, 12 Jul 2005 17:34:47 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 2300E4FB0E; Tue, 12 Jul 2005 17:34:47 +1000 (EST) Date: Tue, 12 Jul 2005 17:34:46 +1000 From: Brett Pentland Subject: Re: [DNA] Linkid Draft Implementation and Test Results In-reply-to: <020301c586af$938c9570$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: dna@eng.monash.edu.au, JinHyeock Choi , Subba Reddy , Greg Daley Message-id: <42D37296.4090003@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <020301c586af$938c9570$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Good work! It's nice to see some real-world results. I just have a few quick questions about your test setup. Is it possible to add any imparements? It's excellent to see it all working properly, but it would be good to also be able to see what happens in some less common situations like when packet loss occurs, or when handover takes place during a renumbering event. It might be tricky to coordinate a handover to happen during a renumbering event, but packet loss mightn't be too hard. Also, what does your host do with it's address configuration, neighbour cache, etc. when it does detect change? Greg has been working here on an implementation of landmark-based link identification, and I believe that so far the DNA process is able to make decisions correctly, but at this point it doesn't actually modify the address configuration (correct me if I'm wrong Greg). Have you managed to tie it all together? One last question: how are the RAs received by the host? Are they solicited or unsolicited? Cheers, Brett. Syam Madanapalli wrote: > Dear DNA WG, > > We have implemented the following Linkid draft > DNA Solution: Link Identifier based approach > http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-01.txt > > and set up a test bed to conducted a few experiments. > We are glad to say that everything worked fine and you can find the > result in > http://www.diffeo.com/test/Linkid_Implementation.ppt > > In brief, the code is not so complex to write (390 line for a router and > 160 lines for a host.) and our testbed consists of 2 links having 3 > router interfaces respectively (as described in slide 3). > We have tested the cases of "Initialization", "Linkid change (Linkid > prefix addition & deletion)" and "Link change" and the results were > as expected. Routers agreed on the same linkid in a second and a host > correctly checked for the link change. - When a linkid is changed > without link change, the host simply changed its linkid prefix without > falsely assuming a link change. - When the host moved to a different > link, the host correctly detected a link change and changed its linkid > prefix. > Your feedback will be appreciated. > Regards, > Syam From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 04:22:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsG2E-0005cY-Jr for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 04:22:34 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00393 for ; Tue, 12 Jul 2005 04:22:32 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQJPQFYWS497JBR1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Jul 2005 18:22:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3254DAB546; Tue, 12 Jul 2005 18:21:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B03594FB07; Tue, 12 Jul 2005 18:21:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6C8LHg06521 for dna-list; Tue, 12 Jul 2005 18:21:17 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6C8LGw06517 for ; Tue, 12 Jul 2005 18:21:16 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQJPPGL7IA97JBR1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Jul 2005 18:21:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B5BC8AB543; Tue, 12 Jul 2005 18:21:01 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 978D64FB07; Tue, 12 Jul 2005 18:21:01 +1000 (EST) Date: Tue, 12 Jul 2005 18:21:01 +1000 From: Brett Pentland Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <42D37D6D.8080706@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) Content-Transfer-Encoding: 7BIT Hi folks, I have been updating the landmark-based DNA proposal to reflect earlier discussion on this list and just wanted to check something. There was a query about the router behaviour during startup. The draft says that a router should send out router solicitations on startup so that it can quickly learn about the other routers/prefixes active on the link. The draft is mute about how it should behave during this period. My thought is that the router should basically behave like a non-DNA router during this bootstrapping phase so that it can make its own prefixes known, but won't make assumptions about its own knowledge of the other routers/prefixes on the link. A possible optimization would be to allow router to answer landmark questions if the answer is yes (since the router knows it's right about that regardless of what other routers are doing), but for a few seconds around startup, it's probably not worth doing. Any comments? Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 05:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsH1a-0007rD-FT for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:25:58 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04523 for ; Tue, 12 Jul 2005 05:25:55 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQJRYLE3Z09AP2QN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Jul 2005 19:25:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A00BAB543; Tue, 12 Jul 2005 19:25:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 211E94FB09; Tue, 12 Jul 2005 19:25:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6C9P7G07227 for dna-list; Tue, 12 Jul 2005 19:25:07 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6C9P6w07223 for ; Tue, 12 Jul 2005 19:25:06 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQJRXPS5NW9AP8NU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Jul 2005 19:24:57 +1000 Received: by localhost (Postfix, from userid 510) id 1E61DAB54A; Tue, 12 Jul 2005 19:24:57 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id AF32B4FB03; Tue, 12 Jul 2005 19:24:54 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI00ISACTFU9@mailout2.samsung.com>; Tue, 12 Jul 2005 18:24:52 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJI00GIMCT9W6@mmp1.samsung.com>; Tue, 12 Jul 2005 18:24:51 +0900 (KST) Date: Tue, 12 Jul 2005 14:51:21 +0530 From: Syam Madanapalli Subject: Re: [DNA] Linkid Draft Implementation and Test Results Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au, JinHyeock Choi , Subba Reddy , Greg Daley Message-id: <026501c586c3$15877230$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <020301c586af$938c9570$59476c6b@sisodomain.com> <42D37296.4090003@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, > Hi Syam, > > Good work! It's nice to see some real-world results. I just > have a few quick questions about your test setup. Is it possible > to add any imparements? It's excellent to see it all working > properly, but it would be good to also be able to see what > happens in some less common situations like when packet loss > occurs, or when handover takes place during a renumbering > event. It might be tricky to coordinate a handover to happen > during a renumbering event, but packet loss mightn't be too > hard. We did not simulate any packet loss in our testbed. Also we have not tested with flash renumbering. We tested with graceful renumbering without any problems. > > Also, what does your host do with it's address configuration, > neighbour cache, etc. when it does detect change? Greg has > been working here on an implementation of landmark-based link > identification, and I believe that so far the DNA process is able > to make decisions correctly, but at this point it doesn't > actually modify the address configuration (correct me if I'm > wrong Greg). Our status is almost same. We were just testing the behavior of linkid based approach under various cirumstances. Currently, in case of link change we are just deleting the existing addresses and NC, and configuring new address using new prefix on the new link. > Have you managed to tie it all together? > > One last question: how are the RAs received by the host? Are > they solicited or unsolicited? We are using the unsolicited RAs. so hosts don't have to send an RS to check for link change but it may delay the link change decision if we do not get quick RA. But depending on unsolicited RAs may be good for host that do not support L2 hint. We are also thinking to implement L2 hint to trigger RS. > > Cheers, > Brett. > > Syam Madanapalli wrote: >> Dear DNA WG, >> >> We have implemented the following Linkid draft DNA Solution: Link >> Identifier based approach >> http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-01.txt >> >> and set up a test bed to conducted a few experiments. >> We are glad to say that everything worked fine and you can find the >> result in >> http://www.diffeo.com/test/Linkid_Implementation.ppt >> >> In brief, the code is not so complex to write (390 line for a router and >> 160 lines for a host.) and our testbed consists of 2 links having 3 >> router interfaces respectively (as described in slide 3). >> We have tested the cases of "Initialization", "Linkid change (Linkid >> prefix addition & deletion)" and "Link change" and the results were >> as expected. Routers agreed on the same linkid in a second and a host >> correctly checked for the link change. - When a linkid is changed without >> link change, the host simply changed its linkid prefix without falsely >> assuming a link change. - When the host moved to a different link, the >> host correctly detected a link change and changed its linkid prefix. >> Your feedback will be appreciated. >> Regards, >> Syam > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 13:28:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsOYZ-0003Wn-5L for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 13:28:31 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17999 for ; Tue, 12 Jul 2005 13:28:27 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQK8TIYMO29AP7LZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 03:28:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B756DAB545; Wed, 13 Jul 2005 03:27:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6C92C4FB08; Wed, 13 Jul 2005 03:27:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6CHRHs12412 for dna-list; Wed, 13 Jul 2005 03:27:17 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6CHRGw12408 for ; Wed, 13 Jul 2005 03:27:16 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LQK8SHV0XK99O8XU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 03:27:07 +1000 Received: by localhost (Postfix, from userid 510) id ED872AB543; Wed, 13 Jul 2005 03:27:06 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id C03224FB05; Wed, 13 Jul 2005 03:27:05 +1000 (EST) Date: Tue, 12 Jul 2005 10:27:00 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Dna Message-id: <04c201c58706$e9888900$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42D37D6D.8080706@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, Actually, I think that a DNA router should refrain from answering any RSs until the bootstrap phase is complete. This phase is likely to be relatively transient, and, in addition, it is possible the hosts will be starting up too. Thus, in addition to the router not having complete information on the link, the router could possibly fail over into the multicast with a higher probability. So why not just limit any RAs during the bootstrap phase to multicast? Does 2461 say anthing about this? jak ----- Original Message ----- From: "Brett Pentland" To: "Dna" Sent: Tuesday, July 12, 2005 1:21 AM Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal > Hi folks, > > I have been updating the landmark-based DNA proposal to reflect earlier > discussion on this list and just wanted to check something. > > There was a query about the router behaviour during startup. The draft > says that a router should send out router solicitations on startup so > that it can quickly learn about the other routers/prefixes active on the > link. The draft is mute about how it should behave during this period. > > My thought is that the router should basically behave like a non-DNA > router during this bootstrapping phase so that it can make its own > prefixes known, but won't make assumptions about its own knowledge of > the other routers/prefixes on the link. > > A possible optimization would be to allow router to answer landmark > questions if the answer is yes (since the router knows it's right about > that regardless of what other routers are doing), but for a few seconds > around startup, it's probably not worth doing. > > Any comments? > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 22:08:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWg4-0002vj-Td for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 22:08:51 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16943 for ; Tue, 12 Jul 2005 22:08:45 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQKQZOZ2R49AP9GL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 12:08:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A72AAAB54B; Wed, 13 Jul 2005 12:08:18 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 396124FB0D; Wed, 13 Jul 2005 12:08:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6D276k18144 for dna-list; Wed, 13 Jul 2005 12:07:06 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6D275w18140 for ; Wed, 13 Jul 2005 12:07:05 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQKQXYTKYE97J6DG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 12:06:56 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4746AAB543; Wed, 13 Jul 2005 12:06:55 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 111CE4FB10; Wed, 13 Jul 2005 12:06:55 +1000 (EST) Date: Wed, 13 Jul 2005 12:06:54 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <04c201c58706$e9888900$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Dna Message-id: <42D4773E.5010409@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <42D37D6D.8080706@eng.monash.edu.au> <04c201c58706$e9888900$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi Jim, If DNA routers refrain from answering RSs altogether, then the bootstapping process will achieve nothing when all the routers on a link startup together since they'll just ignore each others' RSs. Regarding RFC 2461, the only bit I could find on this is section 6.2.1 which deals with becoming an advertising interface. It doesn't have any bootstrapping period; it just says that the interface should respond to Router Solicitations sent to the all-routers multicast address and that it should verify the consistancy of RAs sent by neighbouring routers. So I don't think it matters whether responses are unicast or multicast but I think routers should respond with RAs that have no DNA-specific options included. Brett. James Kempf wrote: > Brett, > > Actually, I think that a DNA router should refrain from answering any RSs > until the bootstrap phase is complete. This phase is likely to be relatively > transient, and, in addition, it is possible the hosts will be starting up > too. Thus, in addition to the router not having complete information on the > link, the router could possibly fail over into the multicast with a higher > probability. So why not just limit any RAs during the bootstrap phase to > multicast? > > Does 2461 say anthing about this? > > jak > > ----- Original Message ----- > From: "Brett Pentland" > To: "Dna" > Sent: Tuesday, July 12, 2005 1:21 AM > Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA > proposal > > > >>Hi folks, >> >>I have been updating the landmark-based DNA proposal to reflect earlier >>discussion on this list and just wanted to check something. >> >>There was a query about the router behaviour during startup. The draft >>says that a router should send out router solicitations on startup so >>that it can quickly learn about the other routers/prefixes active on the >>link. The draft is mute about how it should behave during this period. >> >>My thought is that the router should basically behave like a non-DNA >>router during this bootstrapping phase so that it can make its own >>prefixes known, but won't make assumptions about its own knowledge of >>the other routers/prefixes on the link. >> >>A possible optimization would be to allow router to answer landmark >>questions if the answer is yes (since the router knows it's right about >>that regardless of what other routers are doing), but for a few seconds >>around startup, it's probably not worth doing. >> >>Any comments? >>Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 12 23:02:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXW2-0007dX-Gw for dna-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:02:30 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19802 for ; Tue, 12 Jul 2005 23:02:27 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQKSVK962Q99O6N4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 13:02:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D04F4AB54C; Wed, 13 Jul 2005 13:02:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 882AB4FB02; Wed, 13 Jul 2005 13:02:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6D323418821 for dna-list; Wed, 13 Jul 2005 13:02:03 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6D322w18817 for ; Wed, 13 Jul 2005 13:02:02 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQKSUZCZG494YGX8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 13:01:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DE393AB543; Wed, 13 Jul 2005 13:01:46 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id C702A4FB0D; Wed, 13 Jul 2005 13:01:46 +1000 (EST) Received: from [211.28.22.10] by mail-store-2.its.monash.edu.au (mshttpd); Wed, 13 Jul 2005 13:01:46 +1000 Date: Wed, 13 Jul 2005 13:01:46 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: James Kempf , Dna Message-id: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Brett and Jim, ----- Original Message ----- From: Brett Pentland Date: Wednesday, July 13, 2005 12:06 pm Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal > Hi Jim, > > If DNA routers refrain from answering RSs altogether, then the > bootstapping process will achieve nothing when all the routers > on a link startup together since they'll just ignore each others' > RSs. Chicken or Egg? We've seen similar problems with this before, where no-one advertises. > Regarding RFC 2461, the only bit I could find on this is section > 6.2.1 which deals with becoming an advertising interface. It doesn't > have any bootstrapping period; it just says that the interface > should respond to Router Solicitations sent to the all-routers > multicast address and that it should verify the consistancy of > RAs sent by neighbouring routers. > > So I don't think it matters whether responses are unicast or > multicast but I think routers should respond with RAs that have > no DNA-specific options included. I think that for landmarks, the presence of the separate Yes/No flags in the existing Landmark Option format allow the router to say "I saw RS's Landmark Option", but leave both flags unset if it is unable to say that the landmark is present, while it is still bootstrapping knowledge This is how I've implemented. I provide about 15 seconds for knowledge to be 'incomplete' in a similar way to CPL. Routers advertise as described above. Hosts rely on CPL logic if there's no authoritative landmark (which is always a decent fallback). This also works when there are too many landmarks to track (for example if someone is spoofing prefixes to make it difficult to store all seen prefixes). Prefixes which are seen, stored and known can be answered yes, but other prefixes can be answered "I saw the RS's Landmark Option" with flags unset. This provides knowledge that the state of the routers is incomplete for the link. This information is useful to hosts which wish to be aware of unusual circumstances. With regard to advertisements, it's vitally important to immediately advertise your FastRA capability though, even though you may not be able to do FastRA for a few seconds. This means that fast RA delays won't be available for 1/N of the RS's received in the bootstrap period, but those devices should receive 50ms delayed RSs. The reason for advertising FastRA immediately (even before you send) is to ensure that RAs don't collide when you finally turn on the capability. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 00:01:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYR5-0004MR-39 for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 00:01:27 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23485 for ; Wed, 13 Jul 2005 00:01:23 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQKUXAKJCY99OF3Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 14:00:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6E42AAB542; Wed, 13 Jul 2005 14:00:54 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2EE684FB0F; Wed, 13 Jul 2005 14:00:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6D40Qj19471 for dna-list; Wed, 13 Jul 2005 14:00:26 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6D40Pw19464 for ; Wed, 13 Jul 2005 14:00:25 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQKUWOU22S99OF3Q@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 14:00:25 +1000 Received: by localhost (Postfix, from userid 510) id E9929AB545; Wed, 13 Jul 2005 14:00:24 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9C0C84FB06; Wed, 13 Jul 2005 14:00:23 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJJ002W0SGLFJ@mailout2.samsung.com>; Wed, 13 Jul 2005 13:00:21 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJJ00LZUSGFVG@mmp2.samsung.com>; Wed, 13 Jul 2005 13:00:21 +0900 (KST) Date: Wed, 13 Jul 2005 09:26:48 +0530 From: Subba Reddy Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , James Kempf Cc: Dna Message-id: <00c501c5875e$e81f5410$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42D37D6D.8080706@eng.monash.edu.au> <04c201c58706$e9888900$016115ac@dcml.docomolabsusa.com> <42D4773E.5010409@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett and James, > > If DNA routers refrain from answering RSs altogether, then the > bootstapping process will achieve nothing when all the routers > on a link startup together since they'll just ignore each others' > RSs. > I think routers should advertise RAs atleast for non DNA RSs. For landmark queries, if the prefix advertised by the router (not learned prefix) and the landmark prefix matches, then it may be better to send "Yes". Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 04:35:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsciX-00056l-A4 for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 04:35:45 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15175 for ; Wed, 13 Jul 2005 04:35:42 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQL4I9HSCA94YF7T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 18:35:25 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4E9ECAB542; Wed, 13 Jul 2005 18:35:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EB23B4FB0A; Wed, 13 Jul 2005 18:35:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6D8WIi22401 for dna-list; Wed, 13 Jul 2005 18:32:18 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6D8WHw22397 for ; Wed, 13 Jul 2005 18:32:18 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQL4EEX1QG99O491@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 18:32:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4930FAB54A; Wed, 13 Jul 2005 18:32:01 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id F297C4FB08; Wed, 13 Jul 2005 18:32:00 +1000 (EST) Date: Wed, 13 Jul 2005 18:32:00 +1000 From: Brett Pentland Subject: [DNA] Token bucket for limiting responses to RSs in landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <42D4D180.3070405@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) Content-Transfer-Encoding: 7BIT Hi folks, A while back on the design team list we had a discussion about the proposed token bucket scheme for rate limiting routers' responses to RSs. The discussion started somewhere around http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00316.html and continued around http://www.ctie.monash.edu.au/warchive/dna-dt/2005-05/msg00016.html There was a proposal to use a random drop model triggered by measured rate of RS arrival. Sathya did some simulations to compare performance. The first of these can be found at http://www.ctie.monash.edu.au/warchive/dna-dt/2005-05/msg00018.html and later ones in subsequent emails on that thread. The outcome was that the random drop algorithm performed better, but that with a small modification to the token bucket - doing away with the unicast and multicast sender states, and just allowing a fast unicast response whenever there is a token in the bucket (which is actually what we started out with way back) - performs similarly, but with less complexity. I think we were just about convinced that this modification to the token bucket was the way to go, but didn't quite close out the issue before the date we had set ourselves to post the -00 draft. Does anyone (DT members included) have any comment on this? Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 07:24:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsfLy-0004Rr-U0 for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 07:24:39 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27185 for ; Wed, 13 Jul 2005 07:24:37 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLAF3Y0789AP85I@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 13 Jul 2005 21:24:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F8548000F; Wed, 13 Jul 2005 21:24:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5070A3C013; Wed, 13 Jul 2005 21:24:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DBNhP24254 for dna-list; Wed, 13 Jul 2005 21:23:43 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DBNgw24250 for ; Wed, 13 Jul 2005 21:23:42 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLAE6V4KM97J9ZZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 13 Jul 2005 21:23:38 +1000 Received: by localhost (Postfix, from userid 510) id 73FA6AB543; Wed, 13 Jul 2005 21:23:38 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6EECC4FB08; Wed, 13 Jul 2005 21:23:36 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6DBNWKg029372; Wed, 13 Jul 2005 04:23:32 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6DBKmTS643637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Jul 2005 04:21:43 -0700 (PDT) Date: Wed, 13 Jul 2005 04:21:10 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Brett Pentland , James Kempf , Dna Message-id: <42D4F926.6090708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: Greg, overall your suggestions sound like a very useful strategy for both hosts and routers. Some nits below. > I think that for landmarks, the presence of the separate > Yes/No flags in the existing Landmark Option format allow > the router to say "I saw RS's Landmark Option", but leave > both flags unset if it is unable to say that the landmark > is present, while it is still bootstrapping knowledge I'm not sure it needs to say "I saw the landmark" - what would a host do when it receives this? The host would fall back to CPL in any case. And while bootstrapping the router would now about the prefixes it has been configured to advertise, thus it can provide "yes" answers for those. > This is how I've implemented. I provide about 15 seconds > for knowledge to be 'incomplete' in a similar way to CPL. > Routers advertise as described above. Hosts rely on CPL > logic if there's no authoritative landmark (which is always > a decent fallback). > > This also works when there are too many landmarks to track > (for example if someone is spoofing prefixes to make it difficult > to store all seen prefixes). Prefixes which are seen, stored and > known can be answered yes, but other prefixes can be answered > "I saw the RS's Landmark Option" with flags unset. > > This provides knowledge that the state of the routers is incomplete > for the link. > > This information is useful to hosts which wish to be aware of > unusual circumstances. > > With regard to advertisements, it's vitally important to immediately > advertise your FastRA capability though, even though you may not be able > to do FastRA for a few seconds. This means that fast RA delays won't be > available for 1/N of the RS's received in the bootstrap period, but > those > devices should receive 50ms delayed RSs. > > The reason for advertising FastRA immediately (even before you send) is > to > ensure that RAs don't collide when you finally turn on the capability. So is it for the fastRA that you need a "I saw the landmark" response? Perhaps there should be a "I'm a fastRA router" in the RA. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 12:18:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsjw8-0002dD-Hc for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:18:16 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29988 for ; Wed, 13 Jul 2005 12:18:12 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLKNWSZ3899OF68@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 02:17:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BE332AB543; Thu, 14 Jul 2005 02:17:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6BD914FB07; Thu, 14 Jul 2005 02:17:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DGGuA27541 for dna-list; Thu, 14 Jul 2005 02:16:56 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DGGuw27537 for ; Thu, 14 Jul 2005 02:16:56 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLKMGPPA697ISRQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 02:16:38 +1000 Received: by localhost (Postfix, from userid 510) id 89EA18000D; Thu, 14 Jul 2005 02:16:38 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 606283C010; Thu, 14 Jul 2005 02:16:37 +1000 (EST) Date: Wed, 13 Jul 2005 09:16:39 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: <08b601c587c6$40263f90$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42D37D6D.8080706@eng.monash.edu.au> <04c201c58706$e9888900$016115ac@dcml.docomolabsusa.com> <42D4773E.5010409@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, RFC 2461 seems to be a little thin on describing how a link (as opposed to a single router) bootstraps. I can see two possibilities; 1) The routers multicast RSs to All_Routers_Multicast, and receive unicast nonDNA RAs in reply. To accommodate drops, the routers would have to multicast a sequence of RSs at exponentially increasing intervals up to some limit. 2) The routers multicast nonDNA RAs to All_Routers_Multicast at exponentially increasing intervals until a limit. This technique was used in SLP for bootstrapping a network of Service Agents. The advantage of the first is that routers receive replies to their queries. The disadvantage of the first is that hosts too can send out queries during the bootstrap phase. The host will not learn anything different in the first than the second, since the multicast nonDNA RAs in the second will provide the same information as the unicast in the first, but an attacker could utilize this to disrupt the bootstrapping phase by causing the routers to roll over to multicast (which is actually what the second technique does anyway). Regarding the amount of traffic, there should be exactly as much multicast traffic for the first as the second, but less unicast traffic on the second because there is no unicast reply. jak ----- Original Message ----- From: "Brett Pentland" To: "James Kempf" Cc: "Dna" Sent: Tuesday, July 12, 2005 7:06 PM Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal > Hi Jim, > > If DNA routers refrain from answering RSs altogether, then the > bootstapping process will achieve nothing when all the routers > on a link startup together since they'll just ignore each others' > RSs. > > Regarding RFC 2461, the only bit I could find on this is section > 6.2.1 which deals with becoming an advertising interface. It doesn't > have any bootstrapping period; it just says that the interface > should respond to Router Solicitations sent to the all-routers > multicast address and that it should verify the consistancy of > RAs sent by neighbouring routers. > > So I don't think it matters whether responses are unicast or > multicast but I think routers should respond with RAs that have > no DNA-specific options included. > > Brett. > > James Kempf wrote: > > Brett, > > > > Actually, I think that a DNA router should refrain from answering any RSs > > until the bootstrap phase is complete. This phase is likely to be relatively > > transient, and, in addition, it is possible the hosts will be starting up > > too. Thus, in addition to the router not having complete information on the > > link, the router could possibly fail over into the multicast with a higher > > probability. So why not just limit any RAs during the bootstrap phase to > > multicast? > > > > Does 2461 say anthing about this? > > > > jak > > > > ----- Original Message ----- > > From: "Brett Pentland" > > To: "Dna" > > Sent: Tuesday, July 12, 2005 1:21 AM > > Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA > > proposal > > > > > > > >>Hi folks, > >> > >>I have been updating the landmark-based DNA proposal to reflect earlier > >>discussion on this list and just wanted to check something. > >> > >>There was a query about the router behaviour during startup. The draft > >>says that a router should send out router solicitations on startup so > >>that it can quickly learn about the other routers/prefixes active on the > >>link. The draft is mute about how it should behave during this period. > >> > >>My thought is that the router should basically behave like a non-DNA > >>router during this bootstrapping phase so that it can make its own > >>prefixes known, but won't make assumptions about its own knowledge of > >>the other routers/prefixes on the link. > >> > >>A possible optimization would be to allow router to answer landmark > >>questions if the answer is yes (since the router knows it's right about > >>that regardless of what other routers are doing), but for a few seconds > >>around startup, it's probably not worth doing. > >> > >>Any comments? > >>Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 12:21:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsjyo-000461-8w for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:21:02 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00191 for ; Wed, 13 Jul 2005 12:20:58 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLKRMCY0Q99N1T9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 02:20:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DE17B8000D; Thu, 14 Jul 2005 02:20:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 932BF3C005; Thu, 14 Jul 2005 02:20:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DGKix27605 for dna-list; Thu, 14 Jul 2005 02:20:44 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DGKhw27601 for ; Thu, 14 Jul 2005 02:20:43 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLKR74KA094XZIQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 02:20:27 +1000 Received: by localhost (Postfix, from userid 510) id 842128000D; Thu, 14 Jul 2005 02:20:27 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1031A3C005 for ; Thu, 14 Jul 2005 02:20:26 +1000 (EST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK00CW1QPZMI@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 14 Jul 2005 01:20:23 +0900 (KST) Received: from ep_spt02 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK00H80QPZWA@ms3.samsung.com> for dna@eng.monash.edu.au; Thu, 14 Jul 2005 01:20:23 +0900 (KST) Content-return: prohibited Date: Wed, 13 Jul 2005 16:20:21 +0000 (GMT) From: =?euc-kr?B?udq89sir?= Subject: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: Singh Ajoy-ASINGH1 Cc: "'Michael.G.Williams@nokia.com'" , "'mipshop@ietf.org'" , "'mobopts@irtf.org'" , "'dna@eng.monash.edu.au'" , "'kempf@docomolabs-usa.com'" , "'Marco Liebsch'" , "'rajeev@iprg.nokia.com'" , "'margaret@thingmagic.com'" , "'gabriel_montenegro_2000@yahoo.com'" , "'Basavaraj.Patil@nokia.com'" Reply-to: soohong.park@samsung.com Message-id: <0IJK00H81QPZWA@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050713162001656@soohong.park X-MTR: 20050713162001656@soohong.park X-EPLocale: en_US.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** Content-Transfer-Encoding: 7BIT

CARD is an IETF stuff. 802.21 framework runs under IP layer.

That's all.

In terms of protocol aspect, CARD is still an experimental track

and further, I don't agree CARD might be a standard track.

 

 

Regards,

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics




------- Original Message -------
Sender : Singh Ajoy-ASINGH1<ASINGH1@motorola.com>
Date : Jul 13, 2005 13:07
Title : [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES
Hi Michael, 

I do not see any mention of CARD protocol here. I think CARD is more appropriate candidate for IEEE 802.21 information service protocol. CARD is now published as experimental RFC. So, I would request that we should focus to advance CARD protocol to standard track and then use CARD for information service unless we can really find good reason to define a new protocol. 
Perhaps you might remember that I have mentioned use of CARD protocol in one of earlier IEEE 802.21 meetings but I could not continue to participate in subsequent IEEE meeting due to personal reason.

Regards,
Ajoy 



-----Original Message-----
From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of Michael.G.Williams@nokia.com
Sent: Wednesday, July 06, 2005 5:02 PM
To: mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au
Cc: kempf@docomolabs-usa.com; gabriel_montenegro_2000@yahoo.com; rajeev@iprg.nokia.com; margaret@thingmagic.com; Basavaraj.Patil@nokia.com
Subject: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES

Colleagues,
 
The IEEE 802.21 working group is developing services for facilitating IP
address mobility and service mobility, especially handoff across a
variety of media. The group is interested in working with the relevant
IETF/IRTF working groups to develop methods of  carrying  these services
across the network.  It would be ideal to discuss this at the next IETF
meeting. 
 
There are multiple drafts currently issued or in development that are
interesting and could serve as the basis for starting the work.
  
Drafts of interest include but are not limited to :
 
"Neighborhood Information Elements Discovery (NED)
(draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic
protocol for carrying information elements of interest to IEEE 802.21." 
 
"Some Requirements for a Media Independent Handover Information Service"
(draft-faccin-mih-infoserv-00.txt,
http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt
<http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt> ).
 
"Architectural Implications of Link Indications"
http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt
<http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt>

 
"Unified L2 Abstractions for L3-Driven Fast Handover"
http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0
2.txt
 
"A Framework of Media-Independent Pre-Authentication (MPA)"
http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00.
txt 
 
Best Regards,
Michael G. Williams
IEEE 802.21 Working Group Vice Chair

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop




 

 

 

 

 

Regards

 

 

 

 


From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 12:30:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsk7l-0000g9-6e for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:30:17 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01086 for ; Wed, 13 Jul 2005 12:30:13 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLL2P44VA94YALX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 02:29:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D675AB542; Thu, 14 Jul 2005 02:29:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4C9694FB03; Thu, 14 Jul 2005 02:29:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DGTal27724 for dna-list; Thu, 14 Jul 2005 02:29:36 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DGTZw27720 for ; Thu, 14 Jul 2005 02:29:35 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLL27TLKO9AP7DT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 02:29:20 +1000 Received: by localhost (Postfix, from userid 510) id 8F56D8000D; Thu, 14 Jul 2005 02:29:20 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id B2BA93C00B; Thu, 14 Jul 2005 02:29:19 +1000 (EST) Date: Wed, 13 Jul 2005 09:29:22 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Brett Pentland Cc: Dna Message-id: <08db01c587c8$06e66aa0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg, > I think that for landmarks, the presence of the separate > Yes/No flags in the existing Landmark Option format allow > the router to say "I saw RS's Landmark Option", but leave > both flags unset if it is unable to say that the landmark > is present, while it is still bootstrapping knowledge > I'm not sure what this really buys us. During a link bootstrap, I wouldn't expect any requests for landmarks from hosts anyway, since they will be coming up on the link too. And, as you say below, if someone hands over during that period, they can always use CPL. > > This is how I've implemented. I provide about 15 seconds > for knowledge to be 'incomplete' in a similar way to CPL. > Routers advertise as described above. Hosts rely on CPL > logic if there's no authoritative landmark (which is always > a decent fallback). > 15 seconds sounds like a good default link configuration time. I'm not sure, though, how that would work on a TRILL link. If there are a lot of Rbridges, it might take longer. But as long as it is configurable, there should not be a problem. > This also works when there are too many landmarks to track > (for example if someone is spoofing prefixes to make it difficult > to store all seen prefixes). Prefixes which are seen, stored and > known can be answered yes, but other prefixes can be answered > "I saw the RS's Landmark Option" with flags unset. > > This provides knowledge that the state of the routers is incomplete > for the link. > > This information is useful to hosts which wish to be aware of > unusual circumstances. > I don't know, it seems to be a bit of an additional refinement that I feel probably wouldn't get used often, but seems like it would introduce additional complexity. > With regard to advertisements, it's vitally important to immediately > advertise your FastRA capability though, even though you may not be able > to do FastRA for a few seconds. This means that fast RA delays won't be > available for 1/N of the RS's received in the bootstrap period, but > those > devices should receive 50ms delayed RSs. > > The reason for advertising FastRA immediately (even before you send) is > to > ensure that RAs don't collide when you finally turn on the capability. > I don't understand this particular point. If a host just happens to need a link attachment confirmation during bootstrap, then why is this important? Seems like it could get the same from nonDNA RAs. jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 12:58:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskYi-0000U6-5h for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 12:58:12 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03241 for ; Wed, 13 Jul 2005 12:58:04 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLM2HQ61M9AP0VJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 02:57:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 545D18000E; Thu, 14 Jul 2005 02:57:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 12B4B3C010; Thu, 14 Jul 2005 02:57:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DGvcE28132 for dna-list; Thu, 14 Jul 2005 02:57:38 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DGvcw28128 for ; Thu, 14 Jul 2005 02:57:38 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLM1YFDSW97JJRJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 02:57:22 +1000 Received: by localhost (Postfix, from userid 510) id 748378000D; Thu, 14 Jul 2005 02:57:22 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8DBB93C010; Thu, 14 Jul 2005 02:57:20 +1000 (EST) Date: Wed, 13 Jul 2005 09:57:15 -0700 From: James Kempf Subject: Re: [DNA] Token bucket for limiting responses to RSs in landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Dna Message-id: <093d01c587cb$ec113a30$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42D4D180.3070405@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT I agree that we should go with the modified token bucket algorithm. I'd especially like to thank Sathya for his good work on this item. jak ----- Original Message ----- From: "Brett Pentland" To: "Dna" Sent: Wednesday, July 13, 2005 1:32 AM Subject: [DNA] Token bucket for limiting responses to RSs in landmark-based DNA proposal > Hi folks, > > A while back on the design team list we had a discussion about > the proposed token bucket scheme for rate limiting routers' responses > to RSs. The discussion started somewhere around > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00316.html > > and continued around > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-05/msg00016.html > > There was a proposal to use a random drop model triggered by > measured rate of RS arrival. Sathya did some simulations to > compare performance. The first of these can be found at > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-05/msg00018.html > > and later ones in subsequent emails on that thread. > > The outcome was that the random drop algorithm performed better, but > that with a small modification to the token bucket - doing away with > the unicast and multicast sender states, and just allowing a fast > unicast response whenever there is a token in the bucket (which is > actually what we started out with way back) - performs similarly, > but with less complexity. > > I think we were just about convinced that this modification to the > token bucket was the way to go, but didn't quite close out the > issue before the date we had set ourselves to post the -00 draft. > > Does anyone (DT members included) have any comment on this? > Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 13:07:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskhM-000670-TQ for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 13:07:05 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04275 for ; Wed, 13 Jul 2005 13:07:01 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQLMD1IG4K94YB38@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 03:06:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76C128000E; Thu, 14 Jul 2005 03:06:18 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2DD633C00C; Thu, 14 Jul 2005 03:06:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6DH6DE28264 for dna-list; Thu, 14 Jul 2005 03:06:13 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6DH6Cw28260 for ; Thu, 14 Jul 2005 03:06:12 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQLMCUQN209AP7ZS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 03:06:09 +1000 Received: by localhost (Postfix, from userid 510) id 9077EAB544; Thu, 14 Jul 2005 03:06:09 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5E5A24FB07 for ; Thu, 14 Jul 2005 03:06:07 +1000 (EST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK00MXLSU5LC@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 14 Jul 2005 02:06:05 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJK0059YSU50D@ms3.samsung.com> for dna@eng.monash.edu.au; Thu, 14 Jul 2005 02:06:05 +0900 (KST) Content-return: prohibited Date: Wed, 13 Jul 2005 17:04:50 +0000 (GMT) From: =?euc-kr?B?udq89sir?= Subject: [DNA] Re: RE: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: Singh Ajoy-ASINGH1 Cc: "'Michael.G.Williams@nokia.com'" , "'mipshop@ietf.org'" , "'mobopts@irtf.org'" , "'dna@eng.monash.edu.au'" , "'kempf@docomolabs-usa.com'" , "'Marco Liebsch'" , "'rajeev@iprg.nokia.com'" , "'margaret@thingmagic.com'" , "'gabriel_montenegro_2000@yahoo.com'" , "'Basavaraj.Patil@nokia.com'" Reply-to: soohong.park@samsung.com Message-id: <8420773.1121274343580.JavaMail.weblogic@ep_ml10> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050713170543576@soohong.park X-MTR: 20050713170543576@soohong.park X-EPLocale: en_US.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: * Content-Transfer-Encoding: 7BIT >However, I do not think that using IP transport is ruled out >by existing IEEE 802.21 spec. If we use IP transport then why >can't CARD be used. Singh, I didn't say *ruled out by 802.21*. Please remind that layer 3 and higher layer protocol are beyond scope of 802.21 specification. 802.21 is to define a media independent handover architecture on the layer 2.5. (21-05-0240-01-0000-Joint_Harmonized_MIH_Proposal_Draft_Text) I am not sure but MIHEN is able to be an available place to discuss what you concern. Regards, Daniel (SoohongDaniel Park) Mobile PlatformLaboratory. SAMSUNG Electronics ------- Original Message ------- Sender : SinghAjoy-ASINGH1 Date : Jul 13, 2005 13:07 Title : [Mipshop] RE: [Mobopts]Interest in protocols for IEEE 802.21 IS, CS, ES Hi Michael, I do not see any mention of CARD protocol here. I think CARD is more appropriate candidate for IEEE 802.21 information service protocol. CARD is now published as experimental RFC. So, I would request that we should focus to advance CARD protocol to standard track and then use CARD for information service unless we can really find good reason to define a new protocol. Perhaps you might remember that I have mentioned use of CARD protocol in one of earlier IEEE 802.21 meetings but I could not continue to participate in subsequent IEEE meeting due to personal reason. Regards, Ajoy -----Original Message----- From: mobopts-bounces@irtf.org [mailto:mobopts-bounces@irtf.org] On Behalf Of Michael.G.Williams@nokia.com Sent: Wednesday, July 06, 2005 5:02 PM To: mipshop@ietf.org; mobopts@irtf.org; dna@eng.monash.edu.au Cc: kempf@docomolabs-usa.com; gabriel_montenegro_2000@yahoo.com; rajeev@iprg.nokia.com; margaret@thingmagic.com; Basavaraj.Patil@nokia.com Subject: [Mobopts] Interest in protocols for IEEE 802.21 IS, CS, ES Colleagues, The IEEE 802.21 working group is developing services for facilitating IP address mobility and service mobility, especially handoff across a variety of media. The group is interested in working with the relevant IETF/IRTF working groups to develop methods of carrying these services across the network. It would be ideal to discuss this at the next IETF meeting. There are multiple drafts currently issued or in development that are interesting and could serve as the basis for starting the work. Drafts of interest include but are not limited to : "Neighborhood Information Elements Discovery (NED) (draft-kempf-mobopts-nhood-discovery-00.txt), which provides a generic protocol for carrying information elements of interest to IEEE 802.21." "Some Requirements for a Media Independent Handover Information Service" (draft-faccin-mih-infoserv-00.txt, http://www.ctie.monash.edu.au/dna/draft-faccin-mih-infoserv-00.txt ). "Architectural Implications of Link Indications" http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt "Unified L2 Abstractions for L3-Driven Fast Handover" http://www.ietf.org/internet-drafts/draft-koki-mobopts-l2-abstractions-0 2.txt "A Framework of Media-Independent Pre-Authentication (MPA)" http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-00. txt Best Regards, Michael G. Williams IEEE 802.21 Working Group Vice Chair _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop Regards Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 21:39:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dssh4-0006bb-Pd for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 21:39:18 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01178 for ; Wed, 13 Jul 2005 21:39:16 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQM49GPLSW99OAMZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 11:38:54 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EF8E80015; Thu, 14 Jul 2005 11:38:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E60033C012; Thu, 14 Jul 2005 11:38:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6E1cB901654 for dna-list; Thu, 14 Jul 2005 11:38:11 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6E1cAw01650 for ; Thu, 14 Jul 2005 11:38:10 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQM488P3SW97K9RN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 11:37:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3943AAB543; Thu, 14 Jul 2005 11:37:50 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 177BA4FB09; Thu, 14 Jul 2005 11:37:50 +1000 (EST) Date: Thu, 14 Jul 2005 11:37:44 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42D4F926.6090708@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D5C1E8.5060406@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Sorry about my lack of clarity. Erik Nordmark wrote: > Greg Daley wrote: > Greg, > > overall your suggestions sound like a very useful strategy for both > hosts and routers. Some nits below. > >> I think that for landmarks, the presence of the separate >> Yes/No flags in the existing Landmark Option format allow >> the router to say "I saw RS's Landmark Option", but leave >> both flags unset if it is unable to say that the landmark >> is present, while it is still bootstrapping knowledge > > > I'm not sure it needs to say "I saw the landmark" - what would a host do > when it receives this? The host would fall back to CPL in any case. Any response containing a landmark option is the "I saw the landmark" I mentioned. It admittedly doesn't buy much for the receiver if it receives the landmark option except to say that the DNA advertisor hasn't seen the prefix itself. Some information is conceivably better than none? > And while bootstrapping the router would now about the prefixes it has > been configured to advertise, thus it can provide "yes" answers for those. Definitely, Just as it can advertise RAs but not know that it has a completeRA. [cut] >> >> The reason for advertising FastRA immediately (even before you send) >> is to ensure that RAs don't collide when you finally turn on the >> capability. > > > So is it for the fastRA that you need a "I saw the landmark" response? > Perhaps there should be a "I'm a fastRA router" in the RA. I think the two are separate. The DNA flag provides the "I'm a fastRA router" capability. It can be switched on even before the router needs it though. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 13 21:44:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsslg-0000u9-Ui for dna-archive@megatron.ietf.org; Wed, 13 Jul 2005 21:44:05 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01363 for ; Wed, 13 Jul 2005 21:44:02 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQM4FN8VKG99ODLQ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 11:43:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 46C6C8000F; Thu, 14 Jul 2005 11:43:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D0A513C00C; Thu, 14 Jul 2005 11:43:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6E1hhb01760 for dna-list; Thu, 14 Jul 2005 11:43:43 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6E1hgw01756 for ; Thu, 14 Jul 2005 11:43:42 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQM4FHLBWA99ODLQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 11:43:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B445480011; Thu, 14 Jul 2005 11:43:40 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 924793C014; Thu, 14 Jul 2005 11:43:40 +1000 (EST) Date: Thu, 14 Jul 2005 11:43:34 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <08db01c587c8$06e66aa0$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D5C346.9000707@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <08db01c587c8$06e66aa0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, I think you're thinking of what happens after power failure. While that's important, valid (and fast) configuration when other routers are already in operation is also needed. James Kempf wrote: > Greg, > > >>I think that for landmarks, the presence of the separate >>Yes/No flags in the existing Landmark Option format allow >>the router to say "I saw RS's Landmark Option", but leave >>both flags unset if it is unable to say that the landmark >>is present, while it is still bootstrapping knowledge >> > > > I'm not sure what this really buys us. During a link bootstrap, I wouldn't > expect any requests for landmarks from hosts anyway, since they will be > coming up on the link too. And, as you say below, if someone hands over > during that period, they can always use CPL. There are often other devices which will be already running, so the router can be present, and tell hosts and routers about its presence (for example setting the DNA flag), whilst not countermanding existing DNA state. >>This is how I've implemented. I provide about 15 seconds >>for knowledge to be 'incomplete' in a similar way to CPL. >>Routers advertise as described above. Hosts rely on CPL >>logic if there's no authoritative landmark (which is always >>a decent fallback). >> > > > 15 seconds sounds like a good default link configuration time. I'm not sure, > though, how that would work on a TRILL link. If there are a lot of Rbridges, > it might take longer. But as long as it is configurable, there should not be > a problem. If the period is much more than 15 seconds, it really matters that the routers have some partial DNA capability enabled in order to provide protection from poor environments (where it would be possible to drop into and out of configuration). More than 15 seconds is fine, but STP calculation is 30 seconds so I wouldn't go more than 45 seconds on startup. If the idea is OK, then we can fine-tune the time. >>This also works when there are too many landmarks to track >>(for example if someone is spoofing prefixes to make it difficult >>to store all seen prefixes). Prefixes which are seen, stored and >>known can be answered yes, but other prefixes can be answered >>"I saw the RS's Landmark Option" with flags unset. >> >>This provides knowledge that the state of the routers is incomplete >>for the link. >> >>This information is useful to hosts which wish to be aware of >>unusual circumstances. >> > > > I don't know, it seems to be a bit of an additional refinement that I feel > probably wouldn't get used often, but seems like it would introduce > additional complexity. Not much! I've just got a hold down timer which if it hasn't expired, you cannot answer "no" authoritatively in the Landmark option (or call the RA a CompleteRA). It's called the OverFlow timer for when there are too many prefixes to track. DNA will need some sort of protection for that case too. I just default the timer to exipre 15 seconds after startup. >>With regard to advertisements, it's vitally important to immediately >>advertise your FastRA capability though, even though you may not be able >>to do FastRA for a few seconds. This means that fast RA delays won't be >>available for 1/N of the RS's received in the bootstrap period, but >>those >>devices should receive 50ms delayed RSs. >> >>The reason for advertising FastRA immediately (even before you send) is >>to >>ensure that RAs don't collide when you finally turn on the capability. >> > > > I don't understand this particular point. If a host just happens to need a > link attachment confirmation during bootstrap, then why is this important? > Seems like it could get the same from nonDNA RAs. It's not the host's startup. Hosts are battery powered, and may just arrive while one of the routers is starting. If none of the routers are bootstrapped, then the responses from the routers will be nonDNA (non fast) RAs. If any of the routers are already bootstrapped, then they will be able to provide fastRA response. Since any number of the other routers may already be advertising, they only need to adjust their position for the joining router (actually I think the adjustment is 20ms (RASeparation) in the draft). This will only affect the responses for the advertisements where the router would have advertised fastest anyway (based on the hashing method). Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 07:47:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2BX-0000rF-R6 for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 07:47:23 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01676 for ; Thu, 14 Jul 2005 07:47:20 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQMPH8FW049AP8XJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Jul 2005 21:46:51 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 45CF28000D; Thu, 14 Jul 2005 21:46:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id ED13A3C00E; Thu, 14 Jul 2005 21:46:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6EBjGE09009 for dna-list; Thu, 14 Jul 2005 21:45:16 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6EBjGw09005 for ; Thu, 14 Jul 2005 21:45:16 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQMPEZZUNC94YACD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 14 Jul 2005 21:44:58 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4003BAB543 for ; Thu, 14 Jul 2005 21:44:58 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id AE7674FB0B for ; Thu, 14 Jul 2005 21:44:57 +1000 (EST) Date: Thu, 14 Jul 2005 21:44:57 +1000 From: Greg Daley Subject: [DNA] Code for implementations of draft-pentland-dna-protocol-00.txt, and draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D65039.7000309@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear DNA WG, I've just finished basic testing of the following two pieces of code, which comprise a complete implementation of one of the DNA protocol proposals, as well as the DNA with unmodified routers document: draft-ietf-dna-cpl-00. As you're aware protocol-00 contains RS processing and FastRA delivery/rate limiting mechanisms, and also describes link idenfitication using prefix landmarking and CompleteRA. This is all included. host code (protocol-00 + CPL): http://www.ctie.monash.edu.au/dna/eventrs0.02.tgz router (radvd) code (protocol-00): http://www.ctie.monash.edu.au/dna/radvddna0.02-0.7.3.patch Router Support: --------------- Here's the build instructions. download and extract a tgz of radvd-0.7.3. From the expanded directory radvd-0.7.3: patch -p1 --dry-run < ../radvddna0.02-0.7.3.patch patch -p1 < ../radvddna0.02-0.7.3.patch chmod 0755 ./auto ./auto; ./configure --sysconfdir=/etc ; make Before running radvd, you need a radvd.conf file which supports DNA: setting: DNASupport on; Should probably be sufficient to start DNA on an Interface. Also the settings: RecvSourceLLAddress on; RecvTentativeLLAddress on; May be used to provide unicast responses without requiring Neighbour Discovery exchanges. Limits with the implementation (+kernel) mean that this doesn't work well on links with many neighbours/hosts. This radvd implements "variant 1" DNA option sizing, as discussed on the DNA list. Host Support: ------------- extract the tar, it will create a subdirectory eventrs: in this directory run: make This should build the dna clients. There are: stand-alone RS senders - sendrsnew stand-alone RS sender/RA receiver - sendrsmatch link-layer event driven RS sending - eventrs link-layer event driven RS sending/matching and CPL generation - dnadaem dnadaem represents the furthest developed of these tools. It provides DNA support using RS's with prefix landmarks and TSLLAOs, and monitors inbound link-layer events, and RA reception. It can infer whether link-change has occurred from Complete Prefix Lists using unmodified routers, DNA compliant routers, or combination DNA and legacy routers. It prints out a message when link change occurs, but takes no other actions. Importantly, it doesn't modify the kernel's perception of configuration state (please feel free), or configure global addresses. It has been tested with airo_cs (Cisco 350) on a Linux 2.4.9 kernel. Kernel driver support for wireless events is required, but available in the abovementioned kernel for airo_cs. Some elementary support for other devices is available, but this is expected to improve with further testing. read the file README.txt for licensing and instructions on how to use these tools. Experimenting with the simple 'eventrs' tool is encouraged, while event bugs are being diagnosed. Please contact me with questions (on-list is OK, so long as the issues are protocol not code specific), but I'm not immediately ready to perform deep technical support for this (I.e. think of it as experimental, and I'll answer questions as to how it works/doesn't work but I'm not looking at fixing coredumps for you). I hope that's OK. Please have a look, see if you can get it compiled and installed, and see if it has the same results for you which it did for me in my testbed. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 14:03:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt83q-0003ub-TN for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 14:03:51 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05186 for ; Thu, 14 Jul 2005 14:03:48 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQN2N2QSOY99OHAP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 04:03:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5793280067; Fri, 15 Jul 2005 04:02:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D693B3C016; Fri, 15 Jul 2005 04:02:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6EI21Y13704 for dna-list; Fri, 15 Jul 2005 04:02:01 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6EI1xw13689 for ; Fri, 15 Jul 2005 04:01:59 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQN2L4KGEI99OHAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 04:01:46 +1000 Received: by localhost (Postfix, from userid 510) id 3BC07AB552; Fri, 15 Jul 2005 04:01:44 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4FB5D4FB0C for ; Fri, 15 Jul 2005 04:01:42 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6EI1PIO025989; Thu, 14 Jul 2005 14:01:25 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id E87A51E922D; Thu, 14 Jul 2005 13:52:17 -0400 (EDT) Received: from [150.169.1.201] (alpha.Research.Panasonic.COM [150.169.1.201]) by redwood.research.panasonic.com (Postfix) with ESMTP id D16221E922B; Thu, 14 Jul 2005 13:52:17 -0400 (EDT) Date: Thu, 14 Jul 2005 14:01:27 -0400 From: Eunsoo Shim Subject: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE 802.21IS, CS, ES In-reply-to: <0IJK00H81QPZWA@ms3.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: soohong.park@samsung.com Cc: Singh Ajoy-ASINGH1 , "'margaret@thingmagic.com'" , "'mipshop@ietf.org'" , "'kempf@docomolabs-usa.com'" , "'Marco Liebsch'" , "'rajeev@iprg.nokia.com'" , "'dna@eng.monash.edu.au'" , "'gabriel_montenegro_2000@yahoo.com'" , "'Basavaraj.Patil@nokia.com'" , "'mobopts@irtf.org'" Message-id: <42D6A877.1000108@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=EUC-KR Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:80.84530 C:13 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <0IJK00H81QPZWA@ms3.samsung.com> Content-Transfer-Encoding: 7BIT Hi, Soohong, Please let me add a comment in this discussion. > CARD is an IETF stuff. 802.21 framework runs under IP layer. > This is generally the case. But the requirement of 802.21 IS (Information Service) "to be Media Indepent" makes a different case. If the contact point for a mobile talking 802.21 IS is a function separated from (or independent of) any specific L2 entity or L2 technology, then it should be IP transport. If L2 protocol entities such as the Access Point talk 802.21 IS, this adds a lot of overhead to each L2 protocol and its entity such as Access Points, in particular if they have to learn about the environment (maybe beyond the scope of its own technology?) such as IP layer information. It would be a long and open-ended process to modify/extend every single L2 to adopt 802.21 IS. To be "Media Independent", using IP as transport is a logical and quickest way. So I'd say 802.21 framework will be designed in IEEE 802.21 but the protocol for 802.21 IS should come from IETF. If a protocol comes from IETF, CARD is the primary candidate because it was designed for the functions IEEE 802.21 IS is meant to do. What do you think? Regards, Eunsoo From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 15:01:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8xi-0007I2-H4 for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 15:01:34 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09526 for ; Thu, 14 Jul 2005 15:01:31 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQN4NRVWGS97H38D@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 05:01:25 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D234AB545; Fri, 15 Jul 2005 05:01:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9DF734FB03; Fri, 15 Jul 2005 05:01:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6EJ0qM14661 for dna-list; Fri, 15 Jul 2005 05:00:52 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6EJ0ow14657 for ; Fri, 15 Jul 2005 05:00:50 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQN4N2515S99OO6T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 05:00:34 +1000 Received: by localhost (Postfix, from userid 510) id 864E78000D; Fri, 15 Jul 2005 05:00:34 +1000 (EST) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 661FB3C019 for ; Fri, 15 Jul 2005 05:00:32 +1000 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6EJ0LFW009630; Thu, 14 Jul 2005 22:00:21 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 22:00:20 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 14:00:15 -0500 Date: Thu, 14 Jul 2005 12:00:13 -0700 From: Michael.G.Williams@nokia.com Subject: RE: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE802.21IS, CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: eunsoo@research.panasonic.com, soohong.park@samsung.com Cc: ASINGH1@motorola.com, margaret@thingmagic.com, mipshop@ietf.org, kempf@docomolabs-usa.com, marco.liebsch@netlab.nec.de, rajeev@iprg.nokia.com, dna@eng.monash.edu.au, gabriel_montenegro_2000@yahoo.com, Basavaraj.Patil@nokia.com, mobopts@irtf.org Message-id: <8A76136424391244A5CF0165337085375F4F46@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE802.21IS, CS, ES Thread-Index: AcWIpPBtZuR/pdDLRCKY/zhQf2CXngAAGB+g Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 14 Jul 2005 19:00:15.0622 (UTC) FILETIME=[45297260:01C588A6] Content-Transfer-Encoding: 7BIT Hi Eunsoo, Despite the opinion that it will be a long and open-ended process to modify IEEE 802 MAC layers to adopt IEEE 802.21, that is the plan (well, not that it will be necessarily long and open ended ;^). Within the IEEE 802.11 and 802.16 working groups there are already groups assigned to this task. Even so, there is still the need for the MIH IS (and potentially ES and CS) to be available between entities that cannot communicate directly via MAC services. Best Regards, Michael -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Eunsoo Shim Sent: Thursday, July 14, 2005 11:01 AM To: soohong.park@samsung.com Cc: Singh Ajoy-ASINGH1; 'margaret@thingmagic.com'; 'mipshop@ietf.org'; 'kempf@docomolabs-usa.com'; 'Marco Liebsch'; 'rajeev@iprg.nokia.com'; 'dna@eng.monash.edu.au'; 'gabriel_montenegro_2000@yahoo.com'; Patil Basavaraj (Nokia-NET/Dallas); 'mobopts@irtf.org' Subject: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE802.21IS, CS, ES Hi, Soohong, Please let me add a comment in this discussion. > CARD is an IETF stuff. 802.21 framework runs under IP layer. > This is generally the case. But the requirement of 802.21 IS (Information Service) "to be Media Indepent" makes a different case. If the contact point for a mobile talking 802.21 IS is a function separated from (or independent of) any specific L2 entity or L2 technology, then it should be IP transport. If L2 protocol entities such as the Access Point talk 802.21 IS, this adds a lot of overhead to each L2 protocol and its entity such as Access Points, in particular if they have to learn about the environment (maybe beyond the scope of its own technology?) such as IP layer information. It would be a long and open-ended process to modify/extend every single L2 to adopt 802.21 IS. To be "Media Independent", using IP as transport is a logical and quickest way. So I'd say 802.21 framework will be designed in IEEE 802.21 but the protocol for 802.21 IS should come from IETF. If a protocol comes from IETF, CARD is the primary candidate because it was designed for the functions IEEE 802.21 IS is meant to do. What do you think? Regards, Eunsoo From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 15:16:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9CX-0006U7-1U for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 15:16:53 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11328 for ; Thu, 14 Jul 2005 15:16:49 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQN5666A3A94YTEC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 05:16:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9347AB543; Fri, 15 Jul 2005 05:15:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 94D1A4FB08; Fri, 15 Jul 2005 05:15:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6EJFd814853 for dna-list; Fri, 15 Jul 2005 05:15:39 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6EJFaw14849 for ; Fri, 15 Jul 2005 05:15:36 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQN55BVUN697KEKP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 05:15:18 +1000 Received: by localhost (Postfix, from userid 510) id 4C1CCAB542; Fri, 15 Jul 2005 05:15:18 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3DA154FB0A for ; Fri, 15 Jul 2005 05:15:16 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6EJF24K028865; Thu, 14 Jul 2005 15:15:02 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id F24211E922F; Thu, 14 Jul 2005 15:05:40 -0400 (EDT) Received: from [150.169.1.201] (alpha.Research.Panasonic.COM [150.169.1.201]) by redwood.research.panasonic.com (Postfix) with ESMTP id DFC7C1E922E; Thu, 14 Jul 2005 15:05:40 -0400 (EDT) Date: Thu, 14 Jul 2005 15:14:50 -0400 From: Eunsoo Shim Subject: Re: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for IEEE802.21IS,CS, ES In-reply-to: <8A76136424391244A5CF0165337085375F4F46@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Michael.G.Williams@nokia.com Cc: soohong.park@samsung.com, ASINGH1@motorola.com, margaret@thingmagic.com, mipshop@ietf.org, kempf@docomolabs-usa.com, marco.liebsch@netlab.nec.de, rajeev@iprg.nokia.com, dna@eng.monash.edu.au, gabriel_montenegro_2000@yahoo.com, Basavaraj.Patil@nokia.com, mobopts@irtf.org Message-id: <42D6B9AA.2040904@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <8A76136424391244A5CF0165337085375F4F46@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Hi, Michael, If there is a IP-based protocol, it will solve the problem at once for all L2 technologies. Nowadays, all wireless network technologies are moving forward to IP. In particular, 802.11 and 802.16 support IP from the beginning. Furthermore, if you want to allow any location of the information service entity in the network side, there is no other choice but to take IP as transport. If 802.21 WG develops MAC-specific protocols in parallel with an IP-based protocol, there will be lots duplicate and unnecessary effort. From the implementation point of view, a mobile node might have to contain multiple protocol entities for the same function (eg. IS over 802.11 MAC, IS over 802.16 MAC and IS over IP). Why do you want to do that? Regards, Eunsoo Michael.G.Williams@nokia.com wrote: > >Hi Eunsoo, > >Despite the opinion that it will be a long and open-ended process to >modify IEEE 802 MAC layers to adopt IEEE 802.21, that is the plan (well, >not that it will be necessarily long and open ended ;^). Within the IEEE >802.11 and 802.16 working groups there are already groups assigned to >this task. > >Even so, there is still the need for the MIH IS (and potentially ES and >CS) to be available between entities that cannot communicate directly >via MAC services. > >Best Regards, >Michael > >-----Original Message----- >From: owner-dna@ecselists.eng.monash.edu.au >[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Eunsoo >Shim >Sent: Thursday, July 14, 2005 11:01 AM >To: soohong.park@samsung.com >Cc: Singh Ajoy-ASINGH1; 'margaret@thingmagic.com'; 'mipshop@ietf.org'; >'kempf@docomolabs-usa.com'; 'Marco Liebsch'; 'rajeev@iprg.nokia.com'; >'dna@eng.monash.edu.au'; 'gabriel_montenegro_2000@yahoo.com'; Patil >Basavaraj (Nokia-NET/Dallas); 'mobopts@irtf.org' >Subject: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for >IEEE802.21IS, CS, ES > >Hi, Soohong, > >Please let me add a comment in this discussion. > > > > >>CARD is an IETF stuff. 802.21 framework runs under IP layer. >> >> >> >This is generally the case. But the requirement of 802.21 IS >(Information Service) "to be Media Indepent" makes a different case. >If the contact point for a mobile talking 802.21 IS is a function >separated from (or independent of) any specific L2 entity or L2 >technology, then it should be IP transport. If L2 protocol entities such >as the Access Point talk 802.21 IS, this adds a lot of overhead to each >L2 protocol and its entity such as Access Points, in particular if they >have to learn about the environment (maybe beyond the scope of its own >technology?) such as IP layer information. > >It would be a long and open-ended process to modify/extend every single >L2 to adopt 802.21 IS. To be "Media Independent", using IP as transport >is a logical and quickest way. So I'd say 802.21 framework will be >designed in IEEE 802.21 but the protocol for 802.21 IS should come from >IETF. If a protocol comes from IETF, CARD is the primary candidate >because it was designed for the functions IEEE 802.21 IS is meant to do. >What do you think? > >Regards, > >Eunsoo > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 17:31:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBIS-0007Ss-QT for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 17:31:08 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25585 for ; Thu, 14 Jul 2005 17:31:04 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQN9VG2KN89AP8WT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 07:30:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CE3C8000F; Fri, 15 Jul 2005 07:30:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3BE0A3C003; Fri, 15 Jul 2005 07:30:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6ELUK916459 for dna-list; Fri, 15 Jul 2005 07:30:20 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6ELUKw16455 for ; Fri, 15 Jul 2005 07:30:20 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQN9UGXMBI94YWHW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 07:30:06 +1000 Received: by localhost (Postfix, from userid 510) id 72BECAB543; Fri, 15 Jul 2005 07:30:06 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6A3774FB0A; Fri, 15 Jul 2005 07:30:05 +1000 (EST) Date: Thu, 14 Jul 2005 14:30:01 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , Dna Message-id: <0e0601c588bb$30eb8350$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <08db01c587c8$06e66aa0$016115ac@dcml.docomolabsusa.com> <42D5C346.9000707@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > I think you're thinking of what happens after power failure. > While that's important, valid (and fast) configuration when > other routers are already in operation is also needed. > You're thinking of a new router coming up when the link is already boostrapped, yes, that's true. > There are often other devices which will be already running, > so the router can be present, and tell hosts and routers about > its presence (for example setting the DNA flag), whilst not > countermanding existing DNA state. > OK, so I have no objection if the DNA flag is set during link bootstrap. > I've just got a hold down timer which if it hasn't expired, you cannot > answer "no" authoritatively in the Landmark option (or call the RA a > CompleteRA). > > It's called the OverFlow timer for when there are too many prefixes to > track. DNA will need some sort of protection for that case too. > I just default the timer to exipre 15 seconds after startup. > So how many timers are there total in your implementation? > >>With regard to advertisements, it's vitally important to immediately > >>advertise your FastRA capability though, even though you may not be able > >>to do FastRA for a few seconds. This means that fast RA delays won't be > >>available for 1/N of the RS's received in the bootstrap period, but > >>those > >>devices should receive 50ms delayed RSs. > >> > >>The reason for advertising FastRA immediately (even before you send) is > >>to > >>ensure that RAs don't collide when you finally turn on the capability. > >> > > > > > > I don't understand this particular point. If a host just happens to need a > > link attachment confirmation during bootstrap, then why is this important? > > Seems like it could get the same from nonDNA RAs. > > It's not the host's startup. Hosts are battery powered, and may just > arrive while one of the routers is starting. > > If none of the routers are bootstrapped, then the responses from the > routers will be nonDNA (non fast) RAs. > > If any of the routers are already bootstrapped, then they will be able > to provide fastRA response. > > Since any number of the other routers may already be advertising, they > only need to adjust their position for the joining router (actually I > think the adjustment is 20ms (RASeparation) in the draft). > > This will only affect the responses for the advertisements where the > router would have advertised fastest anyway (based on the hashing > method). > OK, this sounds fine. jak From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 19:54:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtDWi-00062H-Lr for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 19:54:00 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22003 for ; Thu, 14 Jul 2005 19:53:55 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNETSHSV294Y8V1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 09:52:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DA68980012; Fri, 15 Jul 2005 09:52:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9C8693C003; Fri, 15 Jul 2005 09:52:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6ENpls18208 for dna-list; Fri, 15 Jul 2005 09:51:47 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6ENpkw18204 for ; Fri, 15 Jul 2005 09:51:46 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNESXCNOQ99OOZ9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 09:51:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35F1C8000F; Fri, 15 Jul 2005 09:51:38 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 17C8A3C00D; Fri, 15 Jul 2005 09:51:38 +1000 (EST) Date: Fri, 15 Jul 2005 09:51:37 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <0e0601c588bb$30eb8350$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D6FA89.3090102@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <08db01c587c8$06e66aa0$016115ac@dcml.docomolabsusa.com> <42D5C346.9000707@eng.monash.edu.au> <0e0601c588bb$30eb8350$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>I think you're thinking of what happens after power failure. >>While that's important, valid (and fast) configuration when >>other routers are already in operation is also needed. >> > > > You're thinking of a new router coming up when the link is already > boostrapped, yes, that's true. > > >>There are often other devices which will be already running, >>so the router can be present, and tell hosts and routers about >>its presence (for example setting the DNA flag), whilst not >>countermanding existing DNA state. >> > > > OK, so I have no objection if the DNA flag is set during link bootstrap. > > >>I've just got a hold down timer which if it hasn't expired, you cannot >>answer "no" authoritatively in the Landmark option (or call the RA a >>CompleteRA). >> >>It's called the OverFlow timer for when there are too many prefixes to >>track. DNA will need some sort of protection for that case too. >>I just default the timer to exipre 15 seconds after startup. >> > > > > So how many timers are there total in your implementation? There's one timer for the gathered prefixes (this doesn't have an expiry callback, but is checked when the list is used or updated). This is used as the overflow timer. There's a timer per interface for fastRA token buckets (this doesn't have an expiry callback, as it's checked when an RS is received). There's a set of timers with callback expiries for scheduling delayed unicast RAs (Added in my version of Radvd in order to provide parallel responses). These have callback expiry timers, free pools etc. There's a multicast RA timer per interface. This already existed in RADVD. The first two sets require updating with gettimeofday() operations, and have a comparison operation, but these are only called when the data structure would otherwise be used or updated, so don't have their own scheduling mechanisms. The code's out now (not the most simple version, but inspectable). Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 21:03:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEbf-0003Jt-K1 for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 21:03:11 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26182 for ; Thu, 14 Jul 2005 21:03:08 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNHAECCYS9APA2X@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 11:03:04 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D5B5B80012; Fri, 15 Jul 2005 11:02:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5FED23C00D; Fri, 15 Jul 2005 11:02:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F12W819036 for dna-list; Fri, 15 Jul 2005 11:02:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F12Vw19032 for ; Fri, 15 Jul 2005 11:02:31 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNH9S9HM899ODAT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 11:02:29 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADFE9AB542 for ; Fri, 15 Jul 2005 11:02:29 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 927254FB04 for ; Fri, 15 Jul 2005 11:02:29 +1000 (EST) Date: Fri, 15 Jul 2005 11:02:28 +1000 From: Greg Daley Subject: [DNA] Flash renumbering and CompleteRA/CPL maintenance Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D70B24.5030704@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, When discussing changes to the advertised prefix lists with Brett we determined that there's insufficient guidance in protocol-00 regarding the lifetimes of received Prefixes in the DNA Option, for nodes arriving after a prefix stops being advertised on a link. For the normal case, a prefix which is to stop being advertised will have a advertised reduced lifetime (down to 0), and then the prefix can be reassigned after the original valid lifetime had expired (decrements in real-time on hosts as per RFC2461). Hosts which For nodes arriving after their only knowledge of the validity of the prefixes comes from their being advertised in DNA options. The DNA option doesn't contain explicit lifetime information. This (I guess) means that by default DNA options are assumed to be valid for 1800 seconds (the maximum MaxRtrAdvInterval :- 3 times the default MaxRtrAdvInterval). This means that while these prefixes are readvertised in DNAO, up to the end of the prefix's valid lifetime, they can have 30 minutes extra life beyond the actual lifetime of the prefix on the link. This is problematic for example, if the prefixes are delegated using DHCP, and there is strong demand for prefixes. This could lead to reassignment of prefixes to new links immediately after their validity expires. In order to limit the exposure of hosts to this issue (believing a prefix is still on-link when it is not), the following measures may be reasonable: Firstly, a lifetime in a PIO cannot be overridden by a received DNA Option. This means that any host receiving a PIO containing a valid lifetime will believe that in preference to subsequently received DNAOs. These valid lifetimes will be decremented in real-time (as per RFC2461), leading to a perceived lifetime which cannot exceed the lifetime of the prefix on-link. This doesn't help hosts which never saw the PIO in the first place, and only has the prefix configured due to DNAO reception. Secondly, a completeRA received always updates the list of prefixes on the link, even by removing existing prefixes before the host would expire them. This means that the next RA from another router received after the prefix expires will remove the prefix from the CPL on the host. This has security implications, but can be secured with SEND. By using these mechanisms, a prefix which ceases being on-link can only be kept by hosts as long as no updating RA information arrives. I've implemented these mechanisms in the released code for dnadaem (host inference module for DNA). An alternative would be to contain a minimum lifetime for the objects in the DNAO, I think this would be wasteful of space, and could cause cascades of configuration as a partcular prefix timed out (out of the set of advertised prefixes in the DNAO). From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 14 23:42:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtH60-0001zn-Rw for dna-archive@megatron.ietf.org; Thu, 14 Jul 2005 23:42:40 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04567 for ; Thu, 14 Jul 2005 23:42:37 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNMUTYNZM9APASN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 13:42:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D15BAB54B; Fri, 15 Jul 2005 13:42:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id DEBF94FB07; Fri, 15 Jul 2005 13:42:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F3fe320940 for dna-list; Fri, 15 Jul 2005 13:41:40 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F3fdw20936 for ; Fri, 15 Jul 2005 13:41:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNMTTI5TQ99OL9X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 13:41:25 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 49D51AB54C for ; Fri, 15 Jul 2005 13:41:25 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id BE9FD4FB03 for ; Fri, 15 Jul 2005 13:41:24 +1000 (EST) Date: Fri, 15 Jul 2005 13:41:24 +1000 From: Greg Daley Subject: [DNA] update to DNAdaem code (v0.03) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D73064.3040209@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, I've just uploaded a new version of the DNA daemon code, which fixes a small but embarrassing bug in the prefix lifetime code (thanks Brett). This is now available for download at: http://www.ctie.monash.edu.au/dna/eventrs0.03.tgz Greg Daley From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 01:43:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIym-0001to-Hk for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 01:43:21 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11773 for ; Fri, 15 Jul 2005 01:43:18 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNR20Y8UE94Y9SE@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 15:42:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2F409AB543; Fri, 15 Jul 2005 15:42:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B066B4FB0B; Fri, 15 Jul 2005 15:42:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F5g6022308 for dna-list; Fri, 15 Jul 2005 15:42:06 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F5g5w22304 for ; Fri, 15 Jul 2005 15:42:05 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNR15LAGW97GG1E@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 15:41:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1F321AB543 for ; Fri, 15 Jul 2005 15:41:52 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id F34F24FB02 for ; Fri, 15 Jul 2005 15:41:51 +1000 (EST) Date: Fri, 15 Jul 2005 15:41:51 +1000 From: Greg Daley Subject: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42D74C9F.7030600@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear WG, At the moment, there are two documents aimed at providing input to the DNA solutions process: draft-pentland-dna-protocol-00.txt draft-jinchoi-dna-protocol2-00.txt It seems that the primary focus of difference between these two proposals is in Link Identification. Therefore, I'd like to look into the existing proposals to extract what are the agreed components which the WG believes are necessary regardless of the solution. In this way I hope to build most of the solution, in a way which allows a "drop in" of the agreed Link Identification solution, when agreement is reached on that issue. Does that sound reasonable? Here are a list of steps which I guess may be agreeable for the WG as components of the general DNA solution. Requirement Levels and message contents are ignored unless explicitly stated. Please tell me if you agree that this is a reasonable set of general components required for DNA, without exploring Link Identification. Please indicate if there are components which you think are missing from the general DNA solution, or items present in the list which you don't agree with: 1. Link-Layer indications on hosts Use of "Link-Up" indications as in draft-ietf-dna-link-information, in order to start DNA operations 2. RS transmission upon Link-Up indication Transmission of an RS with an Optimistic Source Address when a Link-Layer indication is received. 3. Unicast Solicited RA Delivery Delivery of Solicited RAs to unicast addresses by default, in order to avoid MinDelayBetweenRAs (or MIN_DELAY_BETWEEN_RAS) timers. 4. TSLLAO in RSs with Optimistic Addresses Where an RS is sent from an Optimistic Address, Tentative Source Link-Layer Address Options are used in order to allow for unicast response from the router without using Neighbour Discovery (NS/NA exchange). 5. Hash Ordered FastRA delivery When unicast solicited RAs are scheduled, ordering is worked out amongst DNA routers to ensure one responds immediately, and other routers do not collide with the scheduling 6. Token Bucket Rate Limiting of FastRAs Rate limitation of RA delivery is undertaken in order to prevent overload of wireless media. A token bucket is used to allow no more than TOKEN_RATE FastRAs to occur per interval, and limit the burst size. 7. Where received RAs do not provide explicit Link Identification, Complete Prefix Lists (draft-ietf-dna-cpl-00) are used. Regardless of the DNA solution's LinkID choice, it is likely that DNA hosts will encounter networks without DNA routers. Where a host is present on a non-DNA network, existing CPL rules should be applicable. ---------------- This leaves the role of Link Identification, which may interact with the above measures, but is still for discussion. Please provide feedback regarding this list, it would be good to know what we agreed was needed in a general DNA solution. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 02:33:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJlM-0006UX-VO for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 02:33:33 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05807 for ; Fri, 15 Jul 2005 02:33:30 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNSTQRTCQ97JE3T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 16:33:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7434E80010; Fri, 15 Jul 2005 16:33:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0CEBC3C013; Fri, 15 Jul 2005 16:33:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F6Woh22914 for dna-list; Fri, 15 Jul 2005 16:32:50 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F6Wow22910 for ; Fri, 15 Jul 2005 16:32:50 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNST1B8MQ9APA6C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 16:32:35 +1000 Received: by localhost (Postfix, from userid 510) id 68702AB543; Fri, 15 Jul 2005 16:32:35 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 19C3C4FB02; Fri, 15 Jul 2005 16:32:34 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJN006AUOU77A@mailout1.samsung.com>; Fri, 15 Jul 2005 15:32:31 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJN00IOIOU2XO@mmp1.samsung.com>; Fri, 15 Jul 2005 15:32:31 +0900 (KST) Date: Fri, 15 Jul 2005 11:58:55 +0530 From: Syam Madanapalli Subject: Re: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <00b201c58906$7cbdcdb0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42D74C9F.7030600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > > Dear WG, > > At the moment, there are two documents aimed at providing input > to the DNA solutions process: > > draft-pentland-dna-protocol-00.txt > draft-jinchoi-dna-protocol2-00.txt > > It seems that the primary focus of difference between these > two proposals is in Link Identification. The later draft is just focuses on the link identification method which can be taken into the former document if WG chooses. > > > Therefore, I'd like to look into the existing proposals to > extract what are the agreed components which the WG believes > are necessary regardless of the solution. > > In this way I hope to build most of the solution, in a way > which allows a "drop in" of the agreed Link Identification > solution, when agreement is reached on that issue. > > Does that sound reasonable? Yes, this looks reasonable. > > Here are a list of steps which I guess may be agreeable for > the WG as components of the general DNA solution. > > Requirement Levels and message contents are ignored unless explicitly > stated. > > Please tell me if you agree that this is a reasonable set of > general components required for DNA, without exploring Link > Identification. > > Please indicate if there are components which you think are missing > from the general DNA solution, or items present in the list which > you don't agree with: > > > 1. Link-Layer indications on hosts > > Use of "Link-Up" indications as in draft-ietf-dna-link-information, > in order to start DNA operations Link Up indication may not be available with all implementations. A host should also be able to start DNA if it has any other indication. However I agree that we should use LinkUp when available. Rest of the list looks goo to me. -Syam From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 03:20:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKUx-0008Tk-7K for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 03:20:39 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09641 for ; Fri, 15 Jul 2005 03:20:33 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNUGRVT4G97KLR3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 17:20:19 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1480BAB545; Fri, 15 Jul 2005 17:19:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C68FF4FB0A; Fri, 15 Jul 2005 17:19:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F7JWx23543 for dna-list; Fri, 15 Jul 2005 17:19:32 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F7JSw23539 for ; Fri, 15 Jul 2005 17:19:28 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNUFT10BM94YDMJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 17:19:11 +1000 Received: by localhost (Postfix, from userid 510) id 61B74AB542; Fri, 15 Jul 2005 17:19:11 +1000 (EST) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 276044FB04 for ; Fri, 15 Jul 2005 17:19:09 +1000 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6F7J1KI018892; Fri, 15 Jul 2005 10:19:01 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 10:19:00 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 02:18:48 -0500 Date: Fri, 15 Jul 2005 00:18:46 -0700 From: Michael.G.Williams@nokia.com Subject: RE: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols forIEEE802.21IS,CS, ES Sender: owner-dna@ecselists.eng.monash.edu.au To: eunsoo@research.panasonic.com Cc: soohong.park@samsung.com, ASINGH1@motorola.com, margaret@thingmagic.com, mipshop@ietf.org, kempf@docomolabs-usa.com, marco.liebsch@netlab.nec.de, rajeev@iprg.nokia.com, dna@eng.monash.edu.au, gabriel_montenegro_2000@yahoo.com, Basavaraj.Patil@nokia.com, mobopts@irtf.org Message-id: <8A76136424391244A5CF0165337085375F5047@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols forIEEE802.21IS,CS, ES Thread-Index: AcWIqtcFo7TXxUKnR8erYgwgWv7WeAAX/Hzg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 15 Jul 2005 07:18:48.0317 (UTC) FILETIME=[71961AD0:01C5890D] Content-Transfer-Encoding: 7BIT Eunsoo, IEEE 802.21 WG has been considering use cases where a mobile node could use the MI Information Service via an unsecure port via L2 before IP is allowed. Now that we have a brand new working document with IEEE line numbers (available in the July 2005 folder for now on the IEEE 802.21 website), I can refer to it for help in discussion ;^) See 5.4.3, around line 14. Would this use case be possible via IP? Please don't get me wrong, for many reasons, L3 or above are needed to deliver the services being designed. I was reminded by Stefano that rapid deployment is possible with an IP approach, another important reason. BR, Michael -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Eunsoo Shim Sent: Thursday, July 14, 2005 12:15 PM To: Williams Michael.G (Nokia-ES/MtView) Cc: soohong.park@samsung.com; ASINGH1@motorola.com; margaret@thingmagic.com; mipshop@ietf.org; kempf@docomolabs-usa.com; marco.liebsch@netlab.nec.de; rajeev@iprg.nokia.com; dna@eng.monash.edu.au; gabriel_montenegro_2000@yahoo.com; Patil Basavaraj (Nokia-NET/Dallas); mobopts@irtf.org Subject: Re: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols forIEEE802.21IS,CS, ES Hi, Michael, If there is a IP-based protocol, it will solve the problem at once for all L2 technologies. Nowadays, all wireless network technologies are moving forward to IP. In particular, 802.11 and 802.16 support IP from the beginning. Furthermore, if you want to allow any location of the information service entity in the network side, there is no other choice but to take IP as transport. If 802.21 WG develops MAC-specific protocols in parallel with an IP-based protocol, there will be lots duplicate and unnecessary effort. From the implementation point of view, a mobile node might have to contain multiple protocol entities for the same function (eg. IS over 802.11 MAC, IS over 802.16 MAC and IS over IP). Why do you want to do that? Regards, Eunsoo Michael.G.Williams@nokia.com wrote: > >Hi Eunsoo, > >Despite the opinion that it will be a long and open-ended process to >modify IEEE 802 MAC layers to adopt IEEE 802.21, that is the plan >(well, not that it will be necessarily long and open ended ;^). Within >the IEEE >802.11 and 802.16 working groups there are already groups assigned to >this task. > >Even so, there is still the need for the MIH IS (and potentially ES and >CS) to be available between entities that cannot communicate directly >via MAC services. > >Best Regards, >Michael > >-----Original Message----- >From: owner-dna@ecselists.eng.monash.edu.au >[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Eunsoo >Shim >Sent: Thursday, July 14, 2005 11:01 AM >To: soohong.park@samsung.com >Cc: Singh Ajoy-ASINGH1; 'margaret@thingmagic.com'; 'mipshop@ietf.org'; >'kempf@docomolabs-usa.com'; 'Marco Liebsch'; 'rajeev@iprg.nokia.com'; >'dna@eng.monash.edu.au'; 'gabriel_montenegro_2000@yahoo.com'; Patil >Basavaraj (Nokia-NET/Dallas); 'mobopts@irtf.org' >Subject: [DNA] Re: [Mipshop] RE: [Mobopts] Interest in protocols for >IEEE802.21IS, CS, ES > >Hi, Soohong, > >Please let me add a comment in this discussion. > > > > >>CARD is an IETF stuff. 802.21 framework runs under IP layer. >> >> >> >This is generally the case. But the requirement of 802.21 IS >(Information Service) "to be Media Indepent" makes a different case. >If the contact point for a mobile talking 802.21 IS is a function >separated from (or independent of) any specific L2 entity or L2 >technology, then it should be IP transport. If L2 protocol entities >such as the Access Point talk 802.21 IS, this adds a lot of overhead to >each >L2 protocol and its entity such as Access Points, in particular if they >have to learn about the environment (maybe beyond the scope of its own >technology?) such as IP layer information. > >It would be a long and open-ended process to modify/extend every single >L2 to adopt 802.21 IS. To be "Media Independent", using IP as transport >is a logical and quickest way. So I'd say 802.21 framework will be >designed in IEEE 802.21 but the protocol for 802.21 IS should come from >IETF. If a protocol comes from IETF, CARD is the primary candidate >because it was designed for the functions IEEE 802.21 IS is meant to do. >What do you think? > >Regards, > >Eunsoo > > > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 04:48:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLsB-0008Mp-06 for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 04:48:43 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15494 for ; Fri, 15 Jul 2005 04:48:39 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQNXJ9ZX9K9AP9PY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 18:48:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8E99D8000F; Fri, 15 Jul 2005 18:48:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 46B373C014; Fri, 15 Jul 2005 18:48:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F8llP24633 for dna-list; Fri, 15 Jul 2005 18:47:47 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F8llw24629 for ; Fri, 15 Jul 2005 18:47:47 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQNXIBCOJ697KG5C@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 18:47:30 +1000 Received: by localhost (Postfix, from userid 510) id 1EF87AB543; Fri, 15 Jul 2005 18:47:30 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0AA414FB0D; Fri, 15 Jul 2005 18:47:27 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6F8lNvU022378; Fri, 15 Jul 2005 02:47:24 -0600 (MDT) Received: from [129.157.211.70] (dhcp-gnb07-211-70.France.Sun.COM [129.157.211.70]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6F8lK0p137547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2005 01:47:22 -0700 (PDT) Date: Thu, 14 Jul 2005 14:12:28 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42D5C1E8.5060406@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Message-id: <42D6D53C.6050607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Any response containing a landmark option is the "I saw the landmark" I > mentioned. I understood that part. > It admittedly doesn't buy much for the receiver if it receives the > landmark option except to say that the DNA advertisor hasn't seen the > prefix itself. Some information is conceivably better than none? Information that the receiver isn't interested in isn't useful. That's why I asked what you intended the receiver to do with this piece of information. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 05:59:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtMyY-0007W6-J3 for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 05:59:22 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19876 for ; Fri, 15 Jul 2005 05:59:18 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQO011Y68Y9AP8KL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Jul 2005 19:59:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98425AB543; Fri, 15 Jul 2005 19:59:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 570654FB07; Fri, 15 Jul 2005 19:59:05 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6F9wYd25452 for dna-list; Fri, 15 Jul 2005 19:58:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6F9wYw25447 for ; Fri, 15 Jul 2005 19:58:34 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQO003ABCY94XTYH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Jul 2005 19:58:19 +1000 Received: by localhost (Postfix, from userid 510) id 1857A8000F; Fri, 15 Jul 2005 19:58:19 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3E31E3C012; Fri, 15 Jul 2005 19:58:17 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6F9wF3t013914; Fri, 15 Jul 2005 02:58:15 -0700 (PDT) Received: from [129.157.211.70] (dhcp-gnb07-211-70.France.Sun.COM [129.157.211.70]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6F9wD7i147107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2005 02:58:14 -0700 (PDT) Date: Fri, 15 Jul 2005 02:58:50 -0700 From: Erik Nordmark Subject: Re: [DNA] Flash renumbering and CompleteRA/CPL maintenance In-reply-to: <42D70B24.5030704@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42D788DA.90701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42D70B24.5030704@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Hi, > > > When discussing changes to the advertised prefix lists with Brett > we determined that there's insufficient guidance in protocol-00 > regarding the lifetimes of received Prefixes in the DNA Option, > for nodes arriving after a prefix stops being advertised > on a link. Greg, I guess I don't understand the problem you are trying to solve. In my view, the only use of the prefixes in the DNAO is for the host to be able to answer the landmark question itself, in the case when the router couldn't answer it (because the router had to multicast an RA in response to multiple RSes for instance). In that view, the prefixes in the DNAO would never have any effect on the Prefix List which the host maintains; the Prefix List would be maintained by the host based on the PIOs that the host receives. > This doesn't help hosts which never saw the PIO in the first place, > and only has the prefix configured due to DNAO reception. Why would the host want to configure the prefix based on only seeing it in a DNAO? And if it does, how does the host know whether the A, O, or R flags should be associated with those prefixes? If we need to do that, the only sane thing IMHO, would be to extend DNAO to contain the lifetimes and the flags that are carried in the PIO; thus this would be the same size as a PIO. But as I said, I don't see any need for this, because when the host sends an RS it will receive a response from every router, thus it will quite quickly receive all the PIOs. The Landmark option and DNAO serves as a way to ensure that the host can always detect whether or not it has moved to a different link based on the first received RA, which is a useful optimization compared to CPL. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 11:34:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSCv-0008Hu-IC for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 11:34:33 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19181 for ; Fri, 15 Jul 2005 11:34:29 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQOBOUQ9FI97KB3C@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 16 Jul 2005 01:34:10 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 26A7A80010; Sat, 16 Jul 2005 01:33:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id ACD763C010; Sat, 16 Jul 2005 01:33:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6FFWEU29420 for dna-list; Sat, 16 Jul 2005 01:32:14 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6FFWDw29416 for ; Sat, 16 Jul 2005 01:32:13 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQOBMYUFDK99OOSY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 16 Jul 2005 01:32:07 +1000 Received: by localhost (Postfix, from userid 510) id 00041AB545; Sat, 16 Jul 2005 01:32:06 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id EF2224FB0C; Sat, 16 Jul 2005 01:32:05 +1000 (EST) Date: Fri, 15 Jul 2005 08:32:05 -0700 From: James Kempf Subject: Re: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <0f5301c58952$5aba75a0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42D74C9F.7030600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > At the moment, there are two documents aimed at providing input > to the DNA solutions process: > > draft-pentland-dna-protocol-00.txt > draft-jinchoi-dna-protocol2-00.txt > > It seems that the primary focus of difference between these > two proposals is in Link Identification. > > > Therefore, I'd like to look into the existing proposals to > extract what are the agreed components which the WG believes > are necessary regardless of the solution. > > In this way I hope to build most of the solution, in a way > which allows a "drop in" of the agreed Link Identification > solution, when agreement is reached on that issue. > > Does that sound reasonable? > Sorry, but no. I think we ought to do a concensus call on which of the two the WG wants and make a decision. There's little point in delaying any longer. jak From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 15 15:51:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWDA-00069V-AW for dna-archive@megatron.ietf.org; Fri, 15 Jul 2005 15:51:04 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11103 for ; Fri, 15 Jul 2005 15:51:00 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQOKORDMLW99OSOF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 16 Jul 2005 05:50:54 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 099D5AB543; Sat, 16 Jul 2005 05:50:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AFF414FB02; Sat, 16 Jul 2005 05:50:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6FJoEk00333 for dna-list; Sat, 16 Jul 2005 05:50:14 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6FJoEw00328 for ; Sat, 16 Jul 2005 05:50:14 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQOKNTWTCS94Z5F0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 16 Jul 2005 05:50:07 +1000 Received: by localhost (Postfix, from userid 510) id 3F670AB543; Sat, 16 Jul 2005 05:50:07 +1000 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id CB1A24FB09 for ; Sat, 16 Jul 2005 05:50:04 +1000 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWCA-0001tV-8u; Fri, 15 Jul 2005 15:50:02 -0400 Date: Fri, 15 Jul 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-cpl-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ndaf+qiZuozk6Zo/85fnXg)" X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) --Boundary_(ID_ndaf+qiZuozk6Zo/85fnXg) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : DNA with unmodified routers: Prefix list based approach Author(s) : E. Nordmark, J. Choi Filename : draft-ietf-dna-cpl-01.txt Pages : 32 Date : 2005-7-15 Upon establishing a new link-layer connection, a host determines whether a link change has occurred, that is, whether or not it has moved at layer 3 and therefor needs new IP configuration. This draft presents a way to robustly check for link change without assuming any changes to the routers. We choose to uniquely identify each link by the set of prefixes assigned to it. We propose that, at each attached link, the host generates the complete prefix list, that is, a prefix list containing all the valid prefixes on the link, and when it receives a hint that indicates a possible link change, it detects the identity of the currently attached link by consulting the existing prefix list. This memo describes how to generate the complete prefix list and to robustly detect the link identity even in the presence of packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-cpl-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-cpl-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-dna-cpl-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. --Boundary_(ID_ndaf+qiZuozk6Zo/85fnXg) Content-type: multipart/alternative; boundary="Boundary_(ID_M0zBZ5gIp8zNlBxeHbD/gg)" --Boundary_(ID_M0zBZ5gIp8zNlBxeHbD/gg) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15131745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-cpl-01.txt --Boundary_(ID_M0zBZ5gIp8zNlBxeHbD/gg) Content-type: Message/External-body; name=draft-ietf-dna-cpl-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-cpl-01.txt Content-Type: text/plain Content-ID: <2005-7-15131745.I-D@ietf.org> --Boundary_(ID_M0zBZ5gIp8zNlBxeHbD/gg)-- --Boundary_(ID_ndaf+qiZuozk6Zo/85fnXg)-- From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 16 07:06:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtkVP-0004Hb-0K for dna-archive@megatron.ietf.org; Sat, 16 Jul 2005 07:06:51 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08450 for ; Sat, 16 Jul 2005 07:06:47 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQPGNU5MCI94YVOG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 16 Jul 2005 21:06:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DEEE8000E; Sat, 16 Jul 2005 21:06:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3D2B33C005; Sat, 16 Jul 2005 21:06:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6GB2GG10950 for dna-list; Sat, 16 Jul 2005 21:02:16 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6GB2Gw10946 for ; Sat, 16 Jul 2005 21:02:16 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQPGIF69US97KVXL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 16 Jul 2005 21:02:01 +1000 Received: by localhost (Postfix, from userid 510) id 2BE3DAB542; Sat, 16 Jul 2005 21:02:01 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5DFA94FB06 for ; Sat, 16 Jul 2005 21:01:58 +1000 (EST) Received: by rproxy.gmail.com with SMTP id b11so891107rne for ; Sat, 16 Jul 2005 04:01:57 -0700 (PDT) Received: by 10.38.76.80 with SMTP id y80mr342416rna; Sat, 16 Jul 2005 04:01:57 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Sat, 16 Jul 2005 04:01:57 -0700 (PDT) Date: Sat, 16 Jul 2005 16:31:57 +0530 From: Syam Madanapalli Subject: [DNA] draft-koodli-dna-fmip-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Rajeev Koodli Reply-to: Syam Madanapalli Message-id: <10e14db2050716040123ccb38@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=qsSq4O+iPLztMi3kj5M1OVFBpKjLyqjbyrneH6/B4C991fLk0OljP5e40yZJaO/OTRYUEWlAgDXOiQ39YXeOjJ2/sLg6tHkz7rmBxKEA/hw/7EPop8iwww1WqozSw60sw0OmYErjdCceUnfIwPXHcQLuvnCQ9eslQmadqUVt3BU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Dear DNA WG, We have published a new draft on FMIPv6 Usage with DNA Protocol. Title : FMIPv6 Usage with DNA Protocol Author(s) : R. Koodli, S. Madanapalli Filename : draft-koodli-dna-fmip-00.txt Pages : 7 Date : 2005-7-15 In this document, we describe how the Fast Mobile IPv6 Handovers (FMIPv6) protocol can work where DNA protocol support is available, but the neighborhood information, which is part of the FMIPv6 operation, is not available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt Please provide your comments. Thank you, Syam From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 16 09:42:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtmvY-0001Eq-As for dna-archive@megatron.ietf.org; Sat, 16 Jul 2005 09:42:00 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14570 for ; Sat, 16 Jul 2005 09:41:57 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQPM26C6YO94YTBD@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 16 Jul 2005 23:41:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 183618000F; Sat, 16 Jul 2005 23:40:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id ADE543C010; Sat, 16 Jul 2005 23:40:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6GDeEr12789 for dna-list; Sat, 16 Jul 2005 23:40:14 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6GDeCw12785 for ; Sat, 16 Jul 2005 23:40:13 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQPM17XVDW94YTBD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 16 Jul 2005 23:39:57 +1000 Received: by localhost (Postfix, from userid 510) id 0AAC98000D; Sat, 16 Jul 2005 23:39:56 +1000 (EST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by larry.its.monash.edu.au (Postfix) with ESMTP id 294163C00E for ; Sat, 16 Jul 2005 23:39:53 +1000 (EST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sat, 16 Jul 2005 22:40:53 +0900 Date: Sat, 16 Jul 2005 22:40:53 +0900 From: Junghoon Jee Subject: RE: [DNA] draft-koodli-dna-fmip-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: smadanapalli@gmail.com, dna@eng.monash.edu.au Cc: rajeev@iprg.nokia.com Reply-to: Junghoon Jee Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Mailer: Microsoft CDO for Exchange 2000 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: normal Thread-Topic: [DNA] draft-koodli-dna-fmip-00.txt thread-index: AcWKC/x7/cc0oSITT3eu0JrsYxjJjQ== Comment: GQ19@|@ZEk=E?,18?x, @L5?Ek=E G%AX?,18F@, 4c4g Content-Class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 16 Jul 2005 13:40:53.0718 (UTC) FILETIME=[FC9A6F60:01C58A0B] Content-Transfer-Encoding: 7BIT Hi Syam, It's an interesting work. After reviewing this I-D, I've come up with a following question. About the role of HI/HACK in this reactive FMIPv6-DNA : I thought that these messages are required to confirm the MN's prospective NCoA in predictive mode. In the FMIPv6-DNA, MN configures the NCoA by optimistic DAD in the reactive mode, so why do those messages needed to be transferred and what's their roles ? Just to prepare for future optional behavior the same as specified in the draft-ietf-mipshop-fast-mipv6-03 ? I guess that my question may also apply to the reactive mode of draft-ietf-mipshop-fast-mipv6-03. Regards, Junghoon > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > Syam Madanapalli > Sent: Saturday, July 16, 2005 8:02 PM > To: dna@eng.monash.edu.au > Cc: Rajeev Koodli > Subject: [DNA] draft-koodli-dna-fmip-00.txt > > > Dear DNA WG, > > We have published a new draft on FMIPv6 Usage with DNA Protocol. > > Title : FMIPv6 Usage with DNA Protocol > Author(s) : R. Koodli, S. Madanapalli > Filename : draft-koodli-dna-fmip-00.txt > Pages : 7 > Date : 2005-7-15 > > In this document, we describe how the Fast Mobile IPv6 Handovers > (FMIPv6) protocol can work where DNA protocol support is available, > but the neighborhood information, which is part of the FMIPv6 > operation, is not available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt > > Please provide your comments. > > Thank you, > Syam From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 17 05:12:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du5Cc-0006l7-8D for dna-archive@megatron.ietf.org; Sun, 17 Jul 2005 05:12:50 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21425 for ; Sun, 17 Jul 2005 05:12:46 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQQQYS876497KVWZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 17 Jul 2005 19:12:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0080CAB545; Sun, 17 Jul 2005 19:12:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id AC5AB4FB02; Sun, 17 Jul 2005 19:12:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6H9B3b30120 for dna-list; Sun, 17 Jul 2005 19:11:03 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6H9B2w30116 for ; Sun, 17 Jul 2005 19:11:02 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQQQWV1W0S9APAJP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 17 Jul 2005 19:10:47 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D660AB543; Sun, 17 Jul 2005 19:10:47 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 9749C4FB03; Sun, 17 Jul 2005 19:10:46 +1000 (EST) Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du5AX-0000gj-FF; Sun, 17 Jul 2005 11:10:43 +0200 Date: Sun, 17 Jul 2005 11:10:40 +0200 From: Christian Vogt Subject: [DNA] Presentation Slot Request for DNA in Paris Sender: owner-dna@ecselists.eng.monash.edu.au To: Gregory Daley Cc: DNA Message-id: <42DA2090.8090800@tm.uka.de> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig38E6EFCBBFFFDD98D7776C3C X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -2.6 (--) X-Spam-Status: No This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38E6EFCBBFFFDD98D7776C3C Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Greg, I'd like to present draft-vogt-dna-relocation-00.txt in the DNA session in Paris. The draft talks about MLD-related attachment delays of up to 1 second. Those are part of the IPv6 auto-configuration procedure, but somewhat hidden in the specifications. I intend to present a problem statement (describing the different problematic situations mentioned in the draft) and conclude with two solution proposals. 10 minutes will be sufficient to also provide room for a discussion. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enig38E6EFCBBFFFDD98D7776C3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2iCQwstEk8gl2rURAkWPAJ4sTW3qINiF0/N4DB4GYjLLweKEewCfZRqC UHLY2SkUJoJM4ZNFtbpDgf8= =+Cb8 -----END PGP SIGNATURE----- --------------enig38E6EFCBBFFFDD98D7776C3C-- From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 17 21:43:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuKfL-0001VP-S6 for dna-archive@megatron.ietf.org; Sun, 17 Jul 2005 21:43:31 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10350 for ; Sun, 17 Jul 2005 21:43:28 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRPKA0PT899OS6A@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 11:43:18 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DA498AB54E; Mon, 18 Jul 2005 11:43:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9581C4FB05; Mon, 18 Jul 2005 11:43:10 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I1fo109317 for dna-list; Mon, 18 Jul 2005 11:41:50 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I1fnw09313 for ; Mon, 18 Jul 2005 11:41:49 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQRPIHENEI94Z0N3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 11:41:48 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 47F0B80012; Mon, 18 Jul 2005 11:41:44 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 24F8C3C014; Mon, 18 Jul 2005 11:41:44 +1000 (EST) Date: Mon, 18 Jul 2005 11:41:42 +1000 From: Greg Daley Subject: Re: [DNA] Flash renumbering and CompleteRA/CPL maintenance In-reply-to: <42D788DA.90701@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DB08D6.5030202@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42D70B24.5030704@eng.monash.edu.au> <42D788DA.90701@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Hi, >> >> >> When discussing changes to the advertised prefix lists with Brett >> we determined that there's insufficient guidance in protocol-00 >> regarding the lifetimes of received Prefixes in the DNA Option, >> for nodes arriving after a prefix stops being advertised >> on a link. > > > Greg, > > I guess I don't understand the problem you are trying to solve. > > In my view, the only use of the prefixes in the DNAO is for the host to > be able to answer the landmark question itself, in the case when the > router couldn't answer it (because the router had to multicast an RA in > response to multiple RSes for instance). > > In that view, the prefixes in the DNAO would never have any effect on > the Prefix List which the host maintains; the Prefix List would be > maintained by the host based on the PIOs that the host receives. Actually, the benefits of the DNAO (in fact the CompleteRA generally), seem to me to be most useful when they are able to be used to construct the CPL immediately (for example on an unsolicited RA, or on a Landmark "No" answer). This means that even rapid subsequent transition to a non-DNA network (or DNA network) can be identified as link-change, so long as the existing reception of RA information can be identified as complete. While in general, it's possible to construct the Prefix List just from PIOs (and they contain more information about timers), any single received CompleteRA (even containing the DNAO) is sufficient to identify the prefixes on the link for CPL generation, at the time of the advertisement. PIOs can be used to update this information, as they are received. They won't always be received before the information is needed though. >> This doesn't help hosts which never saw the PIO in the first place, >> and only has the prefix configured due to DNAO reception. > > > Why would the host want to configure the prefix based on only seeing it > in a DNAO? And if it does, how does the host know whether the A, O, or R > flags should be associated with those prefixes? Hang on a minute, I'm not saying that the addresses are to be used for autoconf. I'm saying that the prefixes should be able to be used for Prefix List management (just as CPL uses them). > If we need to do that, the only sane thing IMHO, would be to extend DNAO > to contain the lifetimes and the flags that are carried in the PIO; > thus this would be the same size as a PIO. That's an option, but as you see, it's certainly not my aim to use prefixes which haven't been received in PIOs for autoconf. If the prefixes are only used to identify the link (which I guessed was the purpose of CompleteRA anyway), it makes sense for them to be stored as part of the PL. As an aside (but not to get sidetracked), even if it was necessary to have lifetime information in the DNAO, a single 16-bit field would be sufficient to identify the shortest lifetime (less than 1800 seconds) of any of the learned prefixes. It's clearly not necessary to bloat the entire DNAO to 16(prefix)+1(plen)+4(lifetime) octets/prefix. > But as I said, I don't see any need for this, because when the host > sends an RS it will receive a response from every router, thus it will > quite quickly receive all the PIOs. The Landmark option and DNAO serves > as a way to ensure that the host can always detect whether or not it has > moved to a different link based on the first received RA, which is a > useful optimization compared to CPL. Timing is quite important here. The duration required to receive all of the prefixes on a link using CPL is RS_TRANSMISSIONS * 4 seconds (where RS_TRANSMISSIONS >= 1). If there's a transition off-link within that period, then the host's notion of the Prefix List is that it is incomplete. Using indications of completeness in the received RAs is valuable, since it doesn't require drawn out delays before allowing transition outside a link to be known deterministic. The question is: Do hosts keep information learned from DNAO? If they do, how long do they keep it for? The measures proposed are aimed at either: * limiting the effect of changes to this list of prefixes (based on better knowledge from routers) * Allowing PIOs to supercede this information with more accurate timing. If the answer to the question is actually different (in that hosts shouldn't keep the DNAO contents), we really have to re-evaluate what the CompleteRA is for. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 17 22:43:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuLbQ-0003OY-DY for dna-archive@megatron.ietf.org; Sun, 17 Jul 2005 22:43:32 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12451 for ; Sun, 17 Jul 2005 22:43:29 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRRND6R4299OYAC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 12:43:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4DF70AB54A; Mon, 18 Jul 2005 12:42:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 04EAA4FB06; Mon, 18 Jul 2005 12:42:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I2gbs10111 for dna-list; Mon, 18 Jul 2005 12:42:37 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I2gbw10107 for ; Mon, 18 Jul 2005 12:42:37 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRRMN0D7E99OXVD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 12:42:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 741CEAB545; Mon, 18 Jul 2005 12:42:21 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 55BCE4FB06; Mon, 18 Jul 2005 12:42:21 +1000 (EST) Date: Mon, 18 Jul 2005 12:42:20 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42D6D53C.6050607@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DB170C.7090900@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Any response containing a landmark option is the "I saw the landmark" I >> mentioned. > > > I understood that part. > >> It admittedly doesn't buy much for the receiver if it receives the >> landmark option except to say that the DNA advertisor hasn't seen the >> prefix itself. Some information is conceivably better than none? > > > Information that the receiver isn't interested in isn't useful. > That's why I asked what you intended the receiver to do with this piece > of information. OK. I find myself compelled to agree with you (even) by my own logic. So if we recommend that the router incapable of answering either Yes or No doesn't send a Landmark, do we need to specify that hosts discard landmark options with neither Yes or No received in an RA? Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 17 23:06:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuLxq-0007Fg-OM for dna-archive@megatron.ietf.org; Sun, 17 Jul 2005 23:06:42 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13245 for ; Sun, 17 Jul 2005 23:06:38 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQRSH9OWC497KVN7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 13:06:29 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C746580010; Mon, 18 Jul 2005 13:06:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8027B3C00D; Mon, 18 Jul 2005 13:06:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I361v10439 for dna-list; Mon, 18 Jul 2005 13:06:01 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I360w10435 for ; Mon, 18 Jul 2005 13:06:01 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRSGRW96M9APES4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 13:05:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 582D8AB543; Mon, 18 Jul 2005 13:05:52 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3BC144FB06; Mon, 18 Jul 2005 13:05:52 +1000 (EST) Date: Mon, 18 Jul 2005 13:05:51 +1000 From: Greg Daley Subject: Re: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? In-reply-to: <0f5301c58952$5aba75a0$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DB1C8F.4010609@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42D74C9F.7030600@eng.monash.edu.au> <0f5301c58952$5aba75a0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>At the moment, there are two documents aimed at providing input >>to the DNA solutions process: >> >>draft-pentland-dna-protocol-00.txt >>draft-jinchoi-dna-protocol2-00.txt >> >>It seems that the primary focus of difference between these >>two proposals is in Link Identification. >> >> >>Therefore, I'd like to look into the existing proposals to >>extract what are the agreed components which the WG believes >>are necessary regardless of the solution. >> >>In this way I hope to build most of the solution, in a way >>which allows a "drop in" of the agreed Link Identification >>solution, when agreement is reached on that issue. >> >>Does that sound reasonable? >> > > > Sorry, but no. I think we ought to do a concensus call on which of the two > the WG wants and make a decision. There's little point in delaying any > longer. I guess you think that the other parts don't require discussion (as they are agreeable...???) I'm not really interested in delaying determination of the solution either, and want to see if there's consensus before the meeting. That means that we need to see what people understand about the solution (even outside those who have been so active in the design area). If you'd like to start an on-list discussion about the Link Identification, it would be possible to start a consensus call. We'd need two weeks to conduct the consensus call (as per RFC2418 section 3.3). Given the time left until the IETF meeting (and our projected Thursday session) it would be possible to either run the consensus call to end before the session, or after it: July/August: S M T W T F S 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 I'd prefer that a consensus call allows presentation of ideas in the session, if there's not a strong consensus position apparent beforehand. At the session, we could redirect people to the ML in order to participate in the call to ensure that their input isn't lost. I'll take input on this today and tomorrow, in order to allow some flexibility in the choice of solution (to discuss whether people think the consensus call should end before or after the session). WG: Please start discussion of Link Identification solutions ASAP, so as to assist building consensus. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 01:55:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuObS-0001Gu-MI for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 01:55:51 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20970 for ; Mon, 18 Jul 2005 01:55:45 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRYDAPEPG99OV2A@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 15:55:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D9CEBAB542; Mon, 18 Jul 2005 15:54:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7FC934FB0E; Mon, 18 Jul 2005 15:54:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I5sJt12357 for dna-list; Mon, 18 Jul 2005 15:54:19 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I5sIw12353 for ; Mon, 18 Jul 2005 15:54:18 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQRYCHYZSM94YGK9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 15:54:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6739FAB54A; Mon, 18 Jul 2005 15:54:13 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 234B24FB03; Mon, 18 Jul 2005 15:54:13 +1000 (EST) Date: Mon, 18 Jul 2005 15:54:12 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DB170C.7090900@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , James Kempf , Dna Message-id: <42DB4404.6040303@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT So attempting to summarise, during bootstrap a router needs to: - Solicit for RAs to fill its DNAPrefixList and DNARouterList (It can't rely on unsolicited RAs since it might be the only one bootstrapping at that instant and doesn't know how frequent other routers are advertising, if at all) - Respond to solicitations (otherwise the bootstrapping won't achieve anything if all routers are bootstrapping at the same time) - Not include a Landmark Option in responses if the answer is NO (though there does seem to be support for allowing responses if the answer is YES - probably as a MAY) - Include the DNA flag in any RAs so that other routers can learn that they need to include this router in calculations relating to Fast RA transmission. - Though I don't think it has come up in the discussion to date, I think that a bootstrapping router should probably multicast a few unsolicited RAs to announce its presence on the link to any already-bootstrapped routers. In general, RAs won't have any DNA-specific parts except for the DNA flag. Timings would be as specified in RFC2461. The other exception to this would be if an RS with a Landmark Option is received and the answer to the question posed in it would be a yes, in which case a DNA-style Landmark Option reply MAY be used instead. Does that sound about right? Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 01:58:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuOdd-0001cY-FD for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 01:58:01 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21102 for ; Mon, 18 Jul 2005 01:57:59 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRYGTIRZK9APEIX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 15:57:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 39DDE8000F; Mon, 18 Jul 2005 15:57:42 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E126D3C01A; Mon, 18 Jul 2005 15:57:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I5vc312417 for dna-list; Mon, 18 Jul 2005 15:57:38 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I5vcw12413 for ; Mon, 18 Jul 2005 15:57:38 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQRYGE4VCE99NN7L@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 15:57:22 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD894AB544; Mon, 18 Jul 2005 15:57:21 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9F8764FB02; Mon, 18 Jul 2005 15:57:21 +1000 (EST) Date: Mon, 18 Jul 2005 15:57:21 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DB4404.6040303@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DB44C1.5000606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Fine with me (opinions may change with further conversation). Greg Brett Pentland wrote: > So attempting to summarise, during bootstrap a router needs to: > > - Solicit for RAs to fill its DNAPrefixList and DNARouterList > (It can't rely on unsolicited RAs since it might be the > only one bootstrapping at that instant and doesn't know > how frequent other routers are advertising, if at all) > > - Respond to solicitations (otherwise the bootstrapping won't > achieve anything if all routers are bootstrapping at the > same time) > > - Not include a Landmark Option in responses if the answer is > NO (though there does seem to be support for allowing > responses if the answer is YES - probably as a MAY) > > - Include the DNA flag in any RAs so that other routers can > learn that they need to include this router in calculations > relating to Fast RA transmission. > > - Though I don't think it has come up in the discussion to date, > I think that a bootstrapping router should probably > multicast a few unsolicited RAs to announce its presence > on the link to any already-bootstrapped routers. > > In general, RAs won't have any DNA-specific parts except for the > DNA flag. Timings would be as specified in RFC2461. The other > exception to this would be if an RS with a Landmark Option is > received and the answer to the question posed in it would be a > yes, in which case a DNA-style Landmark Option reply MAY be used > instead. > > Does that sound about right? > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 04:28:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQz6-0005nr-5P for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 04:28:20 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21948 for ; Mon, 18 Jul 2005 04:28:17 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQS3OUKYJE99OUOC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 18:27:47 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3423CAB545; Mon, 18 Jul 2005 18:27:44 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id EB4134FB08; Mon, 18 Jul 2005 18:27:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I8RJX14105 for dna-list; Mon, 18 Jul 2005 18:27:19 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I8RIw14101 for ; Mon, 18 Jul 2005 18:27:18 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQS3NX26F097KFZH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 18:27:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 16B208000E; Mon, 18 Jul 2005 18:26:59 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id C367D3C016; Mon, 18 Jul 2005 18:26:58 +1000 (EST) Date: Mon, 18 Jul 2005 18:26:58 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DB44C1.5000606@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , James Kempf , Dna Message-id: <42DB67D2.1040502@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <42DB44C1.5000606@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT >> - Not include a Landmark Option in responses if the answer is >> NO (though there does seem to be support for allowing >> responses if the answer is YES - probably as a MAY) I was putting this bootstrapping stuff into draft -01 and have just submitted it, but I've had to leave out the optional YES response for now because I came across an issue with it. How would the timing go for one of these yes responses during bootstrap? I think it's probably not a great idea to give a fast response yet because during bootstrap we can't be sure that we know all of the other routers on the link. It may be possible to go fast as the consequence of choosing the same time slot as another router is just a higher probability of a collision, not a guarantee of it. If we choose not to allow the fast response, then is it worth having the yes answer at all rather than just doing the RFC 2461 style response and letting the host fall back on CPL? Anyone have any thoughts on this? Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 04:38:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuR9A-0007sX-2j for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 04:38:44 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22637 for ; Mon, 18 Jul 2005 04:38:41 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQS425MNDG97KC3I@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 18:38:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DC9A880010; Mon, 18 Jul 2005 18:37:40 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 84C3F3C014; Mon, 18 Jul 2005 18:37:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6I8bYn14241 for dna-list; Mon, 18 Jul 2005 18:37:34 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6I8bXw14237 for ; Mon, 18 Jul 2005 18:37:33 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQS41ZHJ1K99OZ9W@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 18:37:33 +1000 Received: by localhost (Postfix, from userid 510) id D5253AB543; Mon, 18 Jul 2005 18:37:32 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id BC4324FB08 for ; Mon, 18 Jul 2005 18:37:31 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJT0005XEM6DJ@mailout3.samsung.com> for dna@eng.monash.edu.au; Mon, 18 Jul 2005 17:37:18 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJT006OSELXEI@mmp2.samsung.com> for dna@eng.monash.edu.au; Mon, 18 Jul 2005 17:37:18 +0900 (KST) Date: Mon, 18 Jul 2005 14:03:32 +0530 From: Syam Madanapalli Subject: Re: [DNA] draft-koodli-dna-fmip-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Junghoon Jee , dna@eng.monash.edu.au Cc: rajeev@iprg.nokia.com, smadanapalli@gmail.com Message-id: <026a01c58b73$671b4ef0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Hello Junghoon, Thanks for reviewing the draft. > > Hi Syam, > It's an interesting work. > After reviewing this I-D, I've come up with a following question. > > About the role of HI/HACK in this reactive FMIPv6-DNA : > I thought that these messages are required to confirm the MN's prospective > NCoA in predictive mode. > In the FMIPv6-DNA, MN configures the NCoA by optimistic DAD in the > reactive mode, > so why do those messages needed to be transferred and what's their roles ? > Just to prepare for future optional behavior the same as specified in the > draft-ietf-mipshop-fast-mipv6-03 ? > I guess that my question may also apply to the reactive mode of > draft-ietf-mipshop-fast-mipv6-03. As you mentioned, currently there is no new use of HI/HACK other than what is mentioned in FMIPv6 RFC. That is, NAR can make use of the knowledge that its trusted peer (i.e., PAR) has a trust relationship with the MN. > > Regards, > Junghoon > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 07:41:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuU03-0003tl-53 for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 07:41:31 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02489 for ; Mon, 18 Jul 2005 07:41:26 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSAG9AFCM97KVMV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 21:41:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E89AAB542; Mon, 18 Jul 2005 21:40:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B116B4FB03; Mon, 18 Jul 2005 21:40:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6IBdUi16261 for dna-list; Mon, 18 Jul 2005 21:39:30 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6IBdUw16257 for ; Mon, 18 Jul 2005 21:39:30 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSAE8S4SE9APETE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 21:39:14 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A7A418000D; Mon, 18 Jul 2005 21:39:13 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 90AD83C00C; Mon, 18 Jul 2005 21:39:13 +1000 (EST) Received: from [211.28.77.184] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 18 Jul 2005 21:39:13 +1000 Date: Mon, 18 Jul 2005 21:39:13 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , James Kempf , Dna Message-id: <4085c740b414.40b4144085c7@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Brett, ----- Original Message ----- From: Brett Pentland Date: Monday, July 18, 2005 6:26 pm Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal > > >> - Not include a Landmark Option in responses if the answer is > >> NO (though there does seem to be support for allowing > >> responses if the answer is YES - probably as a MAY) > > I was putting this bootstrapping stuff into draft -01 and have > just submitted it, but I've had to leave out the optional YES > response for now because I came across an issue with it. > > How would the timing go for one of these yes responses during > bootstrap? I think it's probably not a great idea to give a > fast response yet because during bootstrap we can't be sure > that we know all of the other routers on the link. It may be > possible to go fast as the consequence of choosing the same > time slot as another router is just a higher probability of a > collision, not a guarantee of it. > > If we choose not to allow the fast response, then is it worth > having the yes answer at all rather than just doing the RFC 2461 > style response and letting the host fall back on CPL? > > Anyone have any thoughts on this? > Brett. I'll have to admit that I don't think in my RADVD hack, my checking of the DNA Fast Routers list is as strong as the timers for link identification (so I'm not sure I've seen the issue). Given that the host is actually asking about a known landmark though, and the router is capable of correctly answering it, answering "Yes" is a legitimate thing to do, regardless of the time required to do so. In this case, it may not be something that you encourage, but saying something against it is just going to take text (unless there's a blanket "behave like 2461" statement). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 08:44:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuUyh-0000oS-5I for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 08:44:14 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06850 for ; Mon, 18 Jul 2005 08:44:08 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSCMS2K9W99OXY5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 18 Jul 2005 22:43:35 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F149AB54B; Mon, 18 Jul 2005 22:43:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 12D2E4FB05; Mon, 18 Jul 2005 22:43:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6ICgov16990 for dna-list; Mon, 18 Jul 2005 22:42:50 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6ICgow16986 for ; Mon, 18 Jul 2005 22:42:50 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSCLRMJ3097KKV2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 18 Jul 2005 22:42:34 +1000 Received: by localhost (Postfix, from userid 510) id 88FDBAB542; Mon, 18 Jul 2005 22:42:33 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 111C64FB05; Mon, 18 Jul 2005 22:42:31 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6ICgTr3005750; Mon, 18 Jul 2005 06:42:30 -0600 (MDT) Received: from [129.157.211.70] (dhcp-gnb07-211-70.France.Sun.COM [129.157.211.70]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6ICgNaX794354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2005 05:42:25 -0700 (PDT) Date: Mon, 18 Jul 2005 01:31:11 -0700 From: Erik Nordmark Subject: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <42DB68CF.4060104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Dear Erik and JinHyeock, > > I've recently read through CPL, and am pleased with how it is > shaping up. > > While reading through, I noticed some minor issues which > may need to be considered: Thanks for your careful read - We've tried to fold in improvements on all of these points in the new version of the draft. > Second Last paragraph on Page 6 (Section 2.3): > > "... > Otherwise, to make matters certain, the host may need at least to > wait for more than the first RAs, or additionally, perform multiple > RS/ RA exchanges after the hint. The first level of trying harder is > to, after the RS transmission, wait for all RAs that would have been > triggered by the RS. The second level of trying harder is to send > multiple RSs (and waiting for the resulting RAs). > ..." > > I think that this paragraph needs to be more direct: > > Suggest: > > "... > Otherwise, to make matters certain, the host may need to attempt > further > procedures. A first step to clarify link identity is to wait for > all RAs > which would have been sent in response to the RS. A further step > is to send > multiple RSs (and wait for the resulting RAs). > ..." I think your suggested text makes things more clear. > Section 4.4: > > After the last paragraph, it is not clear if the link-layer > indications reset the number of router solicitations for > MAX_RTR_SOLICITATIONS comparison. > > I'd consider adding the following paragraph. > > "... > > Note that if link-layer indications are reliable, a host can > reset the number of sent Router Solicitations to 0, while still > maintaining RTR_SOLICITATION_INTERVAL between RSs. > Makes sense. > Page 15 Paragraph 2, Section 4.5: > > "... > It is possible that the above comparison will result in matching > multiple Candidate Link objects. For example, if the RA contains the > prefixes P1 and P2, and there is one Candidate Link object with P1 > and P3 and other Candidate Link object with P2 and P4. This should > not happen during normal operation, but if links have been renumbered > or physically separate links have been made into one link (before the > lifetimes in the Candidate Link objects expired), then the host could > observe this. The most sensible action would be for the host to > merge all such matching Candidate Link objects together with the > information in the receive RA and make this the new CCL. Doing this > merging correctly probably requires that each Candidate Link object > contains the time it was last updated by a RA, so that more recent > information can override older information. Note that this case is > one reason one needs to be concerned about security issues when > Candidate Link objects are shared across multiple interfaces > ..." > > * "The most sensible action would be for " is actually debatable, since > this may lead to false detection in the case that existing CCLs hold > out-of-date information (if a no-longer present prefix is retained). > > s/The most sensible action would be for/One possible action would be > for/ I don't mind using your suggested change (and 01 already does) but I'd like to understand more about the case where this would cause a problem. The draft recommends that a Candidate Link object not be retained for more than 90 minutes, thus as long as a prefix isn't removed from one link and added/assigned to another link in less than 90 minutes then this shouldn't be a problem, right? (That's what we call the flash renumbering and reassignment case.) If the prefix is allowed to expire (lifetimes dropping to zero) before it is removed and reassigned to another link, there should never be any confusion. > * There's a sentence at the bottom of the paragraph: > "Note that this case is one reason ...multiple interfaces" > > This is inappropriate given the location, and the fact that sharing > between interfaces has already been prohibited due to security > reasons (which override the later consideration). The sentence > should be deleted to ensure that people don't get distracted > from the main content. Good catch. The document had become internally inconsistent on this point. > Page 15 Paragraph 4+5, Section 4.5: > > [...] > > The first paragraph is incorrect since it forgets (or misstates) when > the > CCL is complete that any received RA should be treated as from a > separate link if there are no prefixes in common with the CCL. > > Suggested Text (including paragraph boundary movement): > > "... > When the first RA afte a link UP notification contains prefixes > which > are disjoint from those in the CCL, it may not be immediately obvious > whether the host has moved or not. Where the CCL is believed to be > complete, though, any advertisement which arrives that does not > contain > common prefixes with the CCL can be assumed to be a link change in > accordance with section 4.6. Otherwise, the host needs to create a > new CCL with the new router's advertisement. This CCL should not > yet be treated as if it belongs to a new link though, and the > operations defined in 4.6 should not yet occur. Instead, the host > waits a minimum it waits for 4 seconds, and RAs that are received > during > that time interval are processed as specified above. > > This processing might result in finding a prefix in common between a > Candidate Link object and the CCL, in which case the host knows > whether and to which link it has moved. But should the 4 seconds > expire without any common prefix, then it will conclude that it has > moved to a new link and inform the rest of the host of the movement > (Section 4.6.) Note that the arrival of a new link UP notification > during the 4 second timer must prevent the timer from firing. In > this case the host might yet again have moved so it is necessary to > restart the process of inspecting the RAs. > ..." I edited your suggested text and created a hybrid of it and the old text, so that we capture the case when the host views its prefix list as complete. [The 01 draft also has a RS_RA_count conceptual variable which is used to determine when the prefix list is viewed as complete.] > Page 16 Last paragrpah of section 4.5: > > > "... > Subject to local policy, and perhaps also the host's knowledge of the > packet loss characteristics of the interface or type of L2 > technology, the host can try harder than just waiting for 4 seconds. > It is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS > messages spaced RTR_SOLICITATION_INTERVAL apart. In the most > conservative approach this means a 12 second delay until the host > will declare that is has moved to a new link. Just as above, this > process should be terminated should a new link UP notification arrive > during the 12 seconds. > ..." > > This text needs to be made more direct: > > s/can try harder than just waiting for 4 seconds./can send Router > Solicitations in > order to gather information./ ok Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 11:53:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXwG-0007B1-BO for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 11:53:52 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23383 for ; Mon, 18 Jul 2005 11:53:48 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSJ9MM7UC99OU4U@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 01:53:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B55B6AB54A; Tue, 19 Jul 2005 01:53:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 704B04FB06; Tue, 19 Jul 2005 01:53:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6IFqsZ19362 for dna-list; Tue, 19 Jul 2005 01:52:54 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6IFqsw19358 for ; Tue, 19 Jul 2005 01:52:54 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSJ8GVWFQ99OU4U@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 01:52:39 +1000 Received: by localhost (Postfix, from userid 510) id B233FAB542; Tue, 19 Jul 2005 01:52:39 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id B02484FB04; Tue, 19 Jul 2005 01:52:38 +1000 (EST) Date: Mon, 18 Jul 2005 08:52:35 -0700 From: James Kempf Subject: Re: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <01aa01c58bb0$b73c8970$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42D74C9F.7030600@eng.monash.edu.au> <0f5301c58952$5aba75a0$016115ac@dcml.docomolabsusa.com> <42DB1C8F.4010609@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > I guess you think that the other parts don't require discussion > (as they are agreeable...???) > I'm in favor of discussion of issues. DNA has an issue list, I think an email on each individual issue should be sent out, a time limit sent for discussion, and, at the close of discussion, consensus should be called on the issue. In other WGs, the draft editor or a WG chair manages issue resolution. > I'm not really interested in delaying determination of the solution > either, and want to see if there's consensus before the meeting. > > That means that we need to see what people understand about the solution > (even outside those who have been so active in the design area). > > If you'd like to start an on-list discussion about the Link > Identification, it would be possible to start a consensus call. > We'd need two weeks to conduct the consensus call (as per RFC2418 > section 3.3). > I'll be offline until the meeting starting on Sat. BTW, I think the consensus call in RFC 2418 means for the entire draft, not individual issues. WG chairs and editors are free to set their own time limit there, > Given the time left until the IETF meeting (and our projected Thursday > session) it would be possible to either run the consensus call to end > before the session, or after it: > > July/August: > S M T W T F S > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > 31 1 2 3 4 5 6 > > I'd prefer that a consensus call allows presentation of ideas in the > session, if there's not a strong consensus position apparent beforehand. > At the session, we could redirect people to the ML in order to > participate in the call to ensure that their input isn't lost. > > I'll take input on this today and tomorrow, in order to allow some > flexibility in the choice of solution (to discuss whether people think > the consensus call should end before or after the session). > > WG: Please start discussion of Link Identification solutions ASAP, so as > to assist building consensus. > OK. I think it would help to have this as an issue in the issues list, and on the issues Web page. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 12:09:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYBZ-0002uE-S0 for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 12:09:41 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24920 for ; Mon, 18 Jul 2005 12:09:38 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSJT2O0UK94ZGAN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 02:09:25 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4AE34AB545; Tue, 19 Jul 2005 02:09:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id F29414FB05; Tue, 19 Jul 2005 02:09:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6IG92g19556 for dna-list; Tue, 19 Jul 2005 02:09:02 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6IG91w19552 for ; Tue, 19 Jul 2005 02:09:01 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSJSPQ0BQ99OO94@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 02:08:59 +1000 Received: by localhost (Postfix, from userid 510) id 0F165AB543; Tue, 19 Jul 2005 02:08:58 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0EF874FB08; Tue, 19 Jul 2005 02:08:57 +1000 (EST) Date: Mon, 18 Jul 2005 09:08:55 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , greg.daley@eng.monash.edu.au Cc: Erik Nordmark , Dna Message-id: <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, As I believe I mentioned in an email on Fri., the alternative to the RS technique described below is the following. When an interface comes up, a router: - Multicasts RAs on the interface for a period of DNAInterfaceBootstrapTime seconds (15 default), with exponentially increasing times between multicast. The RAs are simple RAs with complete prefix and other information on the router, including setting the DNA flag so that other routers can learn that they need to include this router in calculations relating to Fast RA transmission. - Listen on the interface for RAs from other routers and record prefix information and DNA status of discovered routers (a router must do this all the time, actually, in case a router comes up while the link is operating). - Drop any RSs received during DNAInterfaceBootstrapTime. Comparisons are: 1) RA technique has somewhat less traffic. Both techniques require repeated multicasts (the RS technique to compensate for possible losses, the RA technique to advertise), the RA technique has somewhat less traffic because it does not require the unicast return RA and the RS technique requires additional RA beacons, which the RA technique doesn't (beacons are built in). 2) The RS technique is subject to interference from hosts that solicit during this time period. The interference might be unintential or intentional (i.e. a DoS attack). It is possible if the traffic volume of RSs is heavy enough, that the router's token bucket algorithm would roll over to multicast anyway, so using the RA multicast technique is a way to ensure that all routers get a response (the token bucket roll over algorithm has no provision for repeated multicast). How about we generate an Issue in the issues list and put this out for discussion? jak ----- Original Message ----- From: "Brett Pentland" To: Cc: "Erik Nordmark" ; "James Kempf" ; "Dna" Sent: Sunday, July 17, 2005 10:54 PM Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal > So attempting to summarise, during bootstrap a router needs to: > > - Solicit for RAs to fill its DNAPrefixList and DNARouterList > (It can't rely on unsolicited RAs since it might be the > only one bootstrapping at that instant and doesn't know > how frequent other routers are advertising, if at all) > > - Respond to solicitations (otherwise the bootstrapping won't > achieve anything if all routers are bootstrapping at the > same time) > > - Not include a Landmark Option in responses if the answer is > NO (though there does seem to be support for allowing > responses if the answer is YES - probably as a MAY) > > - Include the DNA flag in any RAs so that other routers can > learn that they need to include this router in calculations > relating to Fast RA transmission. > > - Though I don't think it has come up in the discussion to date, > I think that a bootstrapping router should probably > multicast a few unsolicited RAs to announce its presence > on the link to any already-bootstrapped routers. > > In general, RAs won't have any DNA-specific parts except for the > DNA flag. Timings would be as specified in RFC2461. The other > exception to this would be if an RS with a Landmark Option is > received and the answer to the question posed in it would be a > yes, in which case a DNA-style Landmark Option reply MAY be used > instead. > > Does that sound about right? > Brett. > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 12:11:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYDc-0004w8-5s for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 12:11:48 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25179 for ; Mon, 18 Jul 2005 12:11:43 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSJTSO03694ZGAO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 02:09:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 37A588000F; Tue, 19 Jul 2005 02:09:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id A4DAE3C011; Tue, 19 Jul 2005 02:09:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6IG9nt19585 for dna-list; Tue, 19 Jul 2005 02:09:49 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6IG9mw19581 for ; Tue, 19 Jul 2005 02:09:48 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSJTP44K29APF0T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 02:09:46 +1000 Received: by localhost (Postfix, from userid 510) id 95D36AB543; Tue, 19 Jul 2005 02:09:46 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id ABCF64FB05; Tue, 19 Jul 2005 02:09:44 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6IG9fr3017979; Mon, 18 Jul 2005 10:09:41 -0600 (MDT) Received: from [129.157.211.70] (dhcp-gnb07-211-70.France.Sun.COM [129.157.211.70]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6IG9c90836548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2005 09:09:40 -0700 (PDT) Date: Mon, 18 Jul 2005 09:10:16 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DB4404.6040303@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42DBD468.7030103@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett Pentland wrote: > - Though I don't think it has come up in the discussion to date, > I think that a bootstrapping router should probably > multicast a few unsolicited RAs to announce its presence > on the link to any already-bootstrapped routers. That's already covered in RFC 2461, but it doesn't hurt to spell it out explicitly in the DNA specification. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 15:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuauZ-0004lb-Lr for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 15:04:20 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06329 for ; Mon, 18 Jul 2005 15:04:17 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSPWWG2U099P0T5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 05:04:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6548EAB542; Tue, 19 Jul 2005 05:04:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 270FD4FB03; Tue, 19 Jul 2005 05:04:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6IJ3ZW21834 for dna-list; Tue, 19 Jul 2005 05:03:35 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6IJ3Zw21830 for ; Tue, 19 Jul 2005 05:03:35 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSPVYHJMO9AP875@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 05:03:23 +1000 Received: by localhost (Postfix, from userid 510) id D22058000D; Tue, 19 Jul 2005 05:03:23 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id A3E373C012 for ; Tue, 19 Jul 2005 05:03:21 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJU0063U7LJLM@mailout1.samsung.com> for dna@eng.monash.edu.au; Tue, 19 Jul 2005 04:03:19 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJU00IQC7LHSJ@mmp1.samsung.com> for dna@eng.monash.edu.au; Tue, 19 Jul 2005 04:03:19 +0900 (KST) Date: Mon, 18 Jul 2005 12:03:17 -0700 From: Alper Yegin Subject: [DNA] Revised dna-link-info I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Folks, I've had submitted the revised version of the dna-link-info I-D 10 days ago, but it hasn't showed up on the IETF repository yet. For that, please see a copy of the I-D at the following location: http://yegin.org/IETF/draft-ietf-dna-link-information-02.txt The major changes in this revision include: - New text for IEEE 802.3. - Handling multiple 3GPP PDP Contexts. I'd like to take your attention to the changes we needed to make in order to accommodate nondeterministic L2 events on Ethernet (e.g., link is up but the host the network may block data transmission). Please read Section 2 and the entire 2.4 to see the details. Please review and comment before the Paris meeting. Alper From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 17:34:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DudG4-0006Wm-CG for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 17:34:42 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00741 for ; Mon, 18 Jul 2005 17:34:36 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSV5UDCOC97LKF0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 07:34:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72B268000F; Tue, 19 Jul 2005 07:34:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 26D0E3C00D; Tue, 19 Jul 2005 07:34:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6ILXcS23486 for dna-list; Tue, 19 Jul 2005 07:33:38 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6ILXcw23482 for ; Tue, 19 Jul 2005 07:33:38 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSV4YNPZ69APDN9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 07:33:26 +1000 Received: by localhost (Postfix, from userid 510) id EBD148000D; Tue, 19 Jul 2005 07:33:25 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id EE7063C00D for ; Tue, 19 Jul 2005 07:33:24 +1000 (EST) Date: Mon, 18 Jul 2005 14:33:53 -0700 From: James Kempf Subject: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** Content-Transfer-Encoding: 7BIT I am in favor of Landmark Prefix and not LinkID. I could go through a list of problems I have with draft-jinchoi but I'm sure JinHyeock could up with reasonable responses, and I'm not interested in getting into a long email conversation about specific details of LinkID, because it would only result in more text getting added to the draft to handle problems and special cases with the protocol. My basic objection is that LinkID is considerably more more complex than Landmark Prefix. draft-jinchoi requires 22 pages just to describe the link identification protocol, whereas the latest draft of draft-pentland covers link identification, fast RA delivery, link configuration, address state machine management, and more in 25 pages. Essentially, the draft to describe the entire DNA protocol using Landmark Prefix is only 3 pages more than the draft to describe just the link identification part using LinkID. Page count is a kind of crude measure of complexity, but I think this analysis would hold up if one went through in more detail. There's a lot of special case language, extra timers, and extra data structures in LinkID that aren't needed for Landmark Prefix. I support selecting Landmark Prefix for the WG draft for DNA. jak From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 19:17:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuerK-0006g1-Au for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 19:17:15 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15460 for ; Mon, 18 Jul 2005 19:17:10 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSYR2EW8699OT78@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 09:16:48 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A40788000F; Tue, 19 Jul 2005 09:16:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3341A3C00C; Tue, 19 Jul 2005 09:16:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6INGED24736 for dna-list; Tue, 19 Jul 2005 09:16:14 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6INGDw24732 for ; Tue, 19 Jul 2005 09:16:13 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSYQ9MJP897L3U2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 09:16:07 +1000 Received: by localhost (Postfix, from userid 510) id 0DBC28000D; Tue, 19 Jul 2005 09:16:06 +1000 (EST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by larry.its.monash.edu.au (Postfix) with ESMTP id 20D1B3C00C for ; Tue, 19 Jul 2005 09:16:04 +1000 (EST) Received: from FLY ([192.168.250.2]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 08:17:26 +0900 Date: Mon, 18 Jul 2005 16:16:03 -0700 From: Junghoon Jee Subject: RE: [DNA] draft-koodli-dna-fmip-00.txt In-reply-to: <42DBEB1A.3050204@iprg.nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Rajeev Koodli'" , "'Syam Madanapalli'" Cc: dna@eng.monash.edu.au, smadanapalli@gmail.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: AcWLwPKYTnxnTJ/wSDSCgV7ba0YuWwALYigg X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 18 Jul 2005 23:17:26.0504 (UTC) FILETIME=[DC562E80:01C58BEE] Content-Transfer-Encoding: 7BIT Rajeev, > For both predictive and reactive modes, HI/HAck can be useful > for access control. NAR can forward packets for the MN > without forcing access control, through HI/HAck. Are you saying about context transfer by HI/HAck ? Regards, Junghoon > (If it is not clear, FMIP-DNA is applicable when DNA+oDAD is > available, > and no neighborhood information is available for FMIP) > > -Rajeev > > > > Syam Madanapalli wrote: > > > Hello Junghoon, > > > > Thanks for reviewing the draft. > > > >> > >> Hi Syam, > >> It's an interesting work. > >> After reviewing this I-D, I've come up with a following question. > >> > >> About the role of HI/HACK in this reactive FMIPv6-DNA : > >> I thought that these messages are required to confirm the MN's > >> prospective NCoA in predictive mode. > >> In the FMIPv6-DNA, MN configures the NCoA by optimistic DAD in the > >> reactive mode, so why do those messages needed to be > transferred and > >> what's their roles ? > >> Just to prepare for future optional behavior the same as > specified in > >> the draft-ietf-mipshop-fast-mipv6-03 ? > >> I guess that my question may also apply to the reactive mode of > >> draft-ietf-mipshop-fast-mipv6-03. > > > > > > As you mentioned, currently there is no new use of HI/HACK > other than > > what is mentioned in FMIPv6 RFC. That is, NAR can make use of the > > knowledge that its trusted peer (i.e., PAR) has a trust > relationship > > with the > > MN. > > > > > >> > >> Regards, > >> Junghoon > >> > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 19:53:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufQI-0000fR-QT for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 19:53:27 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00335 for ; Mon, 18 Jul 2005 19:53:18 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQSZXWIOME97KFWW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 09:52:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D4BBAB545; Tue, 19 Jul 2005 09:51:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 51B054FB02; Tue, 19 Jul 2005 09:51:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6INp2Q25206 for dna-list; Tue, 19 Jul 2005 09:51:02 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6INp2w25202 for ; Tue, 19 Jul 2005 09:51:02 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQSZXK65PK99OPXM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 09:51:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22EE3AB54E; Tue, 19 Jul 2005 09:51:01 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id CE0FE4FB06; Tue, 19 Jul 2005 09:51:00 +1000 (EST) Date: Tue, 19 Jul 2005 09:50:55 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <42DC405F.5040501@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi Jim, > When an interface comes up, a router: > > - Multicasts RAs on the interface for a period of DNAInterfaceBootstrapTime > seconds (15 default), with exponentially increasing times between multicast. > The RAs are simple RAs with complete prefix and other information on the > router, including setting the DNA flag so that other routers can learn that > they need to include this router in calculations relating to Fast RA > transmission. > > - Listen on the interface for RAs from other routers and record prefix > information and DNA status of discovered routers (a router must do this all > the time, actually, in case a router comes up while the link is operating). > > - Drop any RSs received during DNAInterfaceBootstrapTime. Yes, if that covered all cases it would be simpler not to need RSs, but there is no guarantee that there will be any unsolicited RAs from the other routers on the link before the 15 sec expiry. If that doesn't happen, then the router will start behaving as a full DNA router before it has complete information and may thus answser requests incorrectly. I can't see how we can avoid RSs if we want to be confident of complete information before we start behaving as a DNA router. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 20:01:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufXi-0004QZ-2x for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 20:01:02 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00920 for ; Mon, 18 Jul 2005 20:00:58 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQT06XVJ0G97KU6B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 09:58:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04CF9AB54C; Tue, 19 Jul 2005 09:57:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B23814FB08; Tue, 19 Jul 2005 09:57:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6INvf525325 for dna-list; Tue, 19 Jul 2005 09:57:41 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6INvfw25321 for ; Tue, 19 Jul 2005 09:57:41 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQT06JAJSM97IYYU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 09:57:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 69662AB548; Tue, 19 Jul 2005 09:57:28 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 460994FB02; Tue, 19 Jul 2005 09:57:28 +1000 (EST) Date: Tue, 19 Jul 2005 09:57:27 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DBD468.7030103@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42DC41E7.2020605@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <42DBD468.7030103@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Brett Pentland wrote: > >> - Though I don't think it has come up in the discussion to date, >> I think that a bootstrapping router should probably >> multicast a few unsolicited RAs to announce its presence >> on the link to any already-bootstrapped routers. > > > That's already covered in RFC 2461, but it doesn't hurt to spell it out > explicitly in the DNA specification. Yes I noted in the text for -01, that a few RAs should be sent and why, and pointed at section 6.2.4 of RFC 2461. Brett. Note that I have posted draft -01 but it hasn't shown up in the repository yet. For a preview see: http://www.ctie.monash.edu.au/dna/draft-pentland-dna-protocol-01.txt Changes from -00 can be viewed at: http://www.ctie.monash.edu.au/dna/draft-pentland-dna-protocol-01-from-00.diff.html From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 21:13:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DugfX-00040r-Rf for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 21:13:12 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06384 for ; Mon, 18 Jul 2005 21:13:09 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQT2RVRCVS94Z96A@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 11:12:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98E3080011; Tue, 19 Jul 2005 11:11:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 41BD33C00C; Tue, 19 Jul 2005 11:11:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J1BSt26220 for dna-list; Tue, 19 Jul 2005 11:11:28 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J1BSw26216 for ; Tue, 19 Jul 2005 11:11:28 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQT2QYETX099OZU9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 11:11:12 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 259E280010; Tue, 19 Jul 2005 11:11:12 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id F04893C003; Tue, 19 Jul 2005 11:11:11 +1000 (EST) Date: Tue, 19 Jul 2005 11:11:06 +1000 From: Greg Daley Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DB68CF.4060104@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DC532A.6040103@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42DB68CF.4060104@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Thanks for your work in getting -01 out. It looks good. Below I've gone into further detail about my confusion about flash renumbering and the 90 minute window. Erik Nordmark wrote: [cut] >> Page 15 Paragraph 2, Section 4.5: >> >> "... >> It is possible that the above comparison will result in matching >> multiple Candidate Link objects. For example, if the RA contains the >> prefixes P1 and P2, and there is one Candidate Link object with P1 >> and P3 and other Candidate Link object with P2 and P4. This should >> not happen during normal operation, but if links have been renumbered >> or physically separate links have been made into one link (before the >> lifetimes in the Candidate Link objects expired), then the host could >> observe this. The most sensible action would be for the host to >> merge all such matching Candidate Link objects together with the >> information in the receive RA and make this the new CCL. Doing this >> merging correctly probably requires that each Candidate Link object >> contains the time it was last updated by a RA, so that more recent >> information can override older information. Note that this case is >> one reason one needs to be concerned about security issues when >> Candidate Link objects are shared across multiple interfaces >> ..." >> >> * "The most sensible action would be for " is actually debatable, since >> this may lead to false detection in the case that existing CCLs hold >> out-of-date information (if a no-longer present prefix is retained). > > > > >> s/The most sensible action would be for/One possible action would be for/ > > > I don't mind using your suggested change (and 01 already does) but I'd > like to understand more about the case where this would cause a problem. > The draft recommends that a Candidate Link object not be retained for > more than 90 minutes, thus as long as a prefix isn't removed from one > link and added/assigned to another link in less than 90 minutes then > this shouldn't be a problem, right? (That's what we call the flash > renumbering and reassignment case.) If the prefix is allowed to expire > (lifetimes dropping to zero) before it is removed and reassigned to > another link, there should never be any confusion. I've been thinking about this more recently since looking at the implementation of cpl-00 (I've not got the 90 minutes timers though). I think you're right about the lifetimes counting down to zero (based on the real time counters from Section 4.1). These should supercede the 90 minute cache time, where a prefix is withdrawn from a link. For example with DHCPv6 PD, the advertised lifetimes of prefixes in RAs decrement as the DHCP lease time reduces, so that the prefix can't be configured beyond it lifetime. As soon as the prefix is not valid any longer on a link, it can be immediately allocated to another link (with no overlap time, since the prefixes are expired on the old link). I guess this could become a fairly common case. If you're only using PIOs for prefix lifetimes, then the lifetimes should count down to zero at approximately the same time, without any problems. Only if a prefix is assigned to a new link before the expiry of the prefix on the old link, would the 90 minute timer come into use. So is flash renumbering really about allocating a prefix to another link before expiring the lifetime on the existing link's routers? In that case, the 90 minutes are sufficient only if deployers can be made to comply with that period of non use (or non redeployment) for the prefix. I think the flash renumbering concept needs to be well defined (possibly separately), and discussed in order to gain a wider consensus that it's a problem we need to solve, and if the 90 minute hold-down before reallocation is the right way to solve it. At this stage, I've only seen flash renumbering described in a DNA context, so it would be good to figure out if any other WGs are likely to have the same interest or problems. Your references would be helpful here. [cut] >> Page 15 Paragraph 4+5, Section 4.5: >> > > [...] > >> >> The first paragraph is incorrect since it forgets (or misstates) >> when the >> CCL is complete that any received RA should be treated as from a >> separate link if there are no prefixes in common with the CCL. >> >> Suggested Text (including paragraph boundary movement): >> >> "... >> When the first RA afte a link UP notification contains prefixes >> which are disjoint from those in the CCL, it may not be immediately >> obvious >> whether the host has moved or not. Where the CCL is believed to be >> complete, though, any advertisement which arrives that does not >> contain >> common prefixes with the CCL can be assumed to be a link change in >> accordance with section 4.6. Otherwise, the host needs to create a >> new CCL with the new router's advertisement. This CCL should not >> yet be treated as if it belongs to a new link though, and the >> operations defined in 4.6 should not yet occur. Instead, the host >> waits a minimum it waits for 4 seconds, and RAs that are received >> during >> that time interval are processed as specified above. >> >> This processing might result in finding a prefix in common between a >> Candidate Link object and the CCL, in which case the host knows >> whether and to which link it has moved. But should the 4 seconds >> expire without any common prefix, then it will conclude that it has >> moved to a new link and inform the rest of the host of the movement >> (Section 4.6.) Note that the arrival of a new link UP notification >> during the 4 second timer must prevent the timer from firing. In >> this case the host might yet again have moved so it is necessary to >> restart the process of inspecting the RAs. >> ..." > > > I edited your suggested text and created a hybrid of it and the old > text, so that we capture the case when the host views its prefix list as > complete. > [The 01 draft also has a RS_RA_count conceptual variable which is used > to determine when the prefix list is viewed as complete.] > > [cut] I think the text in -01 is good. Thanks, Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 18 21:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DugiU-000537-ME for dna-archive@megatron.ietf.org; Mon, 18 Jul 2005 21:16:14 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06510 for ; Mon, 18 Jul 2005 21:16:12 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQT2W9ZYZI97KQ52@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 11:15:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8D5DAAB546; Tue, 19 Jul 2005 11:15:29 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4542C4FB06; Tue, 19 Jul 2005 11:15:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J1FQT26297 for dna-list; Tue, 19 Jul 2005 11:15:26 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J1FPw26291 for ; Tue, 19 Jul 2005 11:15:25 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQT2W4LTNO94ZION@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 11:15:22 +1000 Received: by localhost (Postfix, from userid 510) id 20319AB54D; Tue, 19 Jul 2005 11:15:22 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by moe.its.monash.edu.au (Postfix) with ESMTP id 360EE4FB07 for ; Tue, 19 Jul 2005 11:15:20 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so279050nzd for ; Mon, 18 Jul 2005 18:15:19 -0700 (PDT) Received: by 10.36.57.11 with SMTP id f11mr4582846nza; Mon, 18 Jul 2005 18:14:54 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 18 Jul 2005 18:14:54 -0700 (PDT) Date: Tue, 19 Jul 2005 10:14:54 +0900 From: JinHyeock Choi Subject: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0507181814d7f98bf@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ErEC4aEOpaDbp4rhumS2fAswLtbf3ImemMQ94ZxiLkcUgsADMBVtnTRaeS97ZlTn1dXr/PJMfQxWAW/RO07kV/Y2dyPMI3dxJGKEgL2Mba3awIs8kZt/UpZweimSHNMfTIagVGopmtK0fo1CjM2Aig5BsHNc3/Y8ibLzHP6bdDg= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Dear DNA WG We have updated FRD (Fast Router Discovery) I-D and submitted it. This draft presents a quick RA acquisition scheme with the support of a link-layer entity, PoA (Point of Attachment). PoA is either 802.11 AP or 802.16 BS. Upon a new network attachment, a PoA can either trigger a router to immediately send an unicast RA ("RA Triggering") or deliver such an RA for itself ("RA Proxying"). We may put 'RA Triggering' or 'RA Proxying' functionality on a PoA to get the optimized result. Main changes from the previous versions are - We expanded the result to other wireless-link technologies. We added IEEE 802.16. part. - We added RA Triggering part so the scheme doesn't depend solely on "RA Caching" any longer. - We incorporated the IEEE 802.21 (Media Independent Handover) results to realize "RA Triggering" and "RA Proxying" The draft doesn't show up on the repository yet but is available at http://www.diffeo.com/drafts/draft-jinchoi-dna-frd-01.txt Your feedback will be appreciated. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi p.s. We implemented a scheme in 802.11 AP and measured DNA delay. Roughly it takes 1-2 ms for a host to get an RA after L2 association is made. More detailed report later. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 02:18:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DulRO-0006NE-32 for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 02:18:54 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09327 for ; Tue, 19 Jul 2005 02:18:52 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTDFQYUKO99OXDC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 16:17:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4E1B6AB543; Tue, 19 Jul 2005 16:17:31 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0D76A4FB05; Tue, 19 Jul 2005 16:17:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J6EsH29726 for dna-list; Tue, 19 Jul 2005 16:14:54 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J6Esw29721 for ; Tue, 19 Jul 2005 16:14:54 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTDC5MWUI99OANG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 16:14:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C0538000E; Tue, 19 Jul 2005 16:14:37 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 1CC153C00E; Tue, 19 Jul 2005 16:14:37 +1000 (EST) Date: Tue, 19 Jul 2005 16:14:36 +1000 From: Brett Pentland Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <92e919fb0507181814d7f98bf@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , dna@eng.monash.edu.au Message-id: <42DC9A4C.9010601@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, I just read over your update and have a few observations. I see you now have triggering as well as caching. Triggering seems to make good sense when the AR and Point of Attachment (PoA) are co-located, but when they are not it seems that you are just reinventing RS/RA. Compared to the host initiating the RS, you save one store-and-forward time in the PoA, but that doesn't seem like much of a saving for a new protocol. For RA Proxying you have a new option for getting the cached RA, but what do you do if there's more than one router on the link? Should the PoA cache and forward multiple RAs? If not, then the host may have incomplete information. It may not have all of the prefixes available on the link, and it won't have a complete list of potential default routers. To get this additional information it will need to send an RS in order to receive the RAs from all of the routers on the link. You end up adding an RA to the overall process though admittedly you get that first RA very quickly. Cheers, Brett. JinHyeock Choi wrote: > Dear DNA WG > > We have updated FRD (Fast Router Discovery) I-D and submitted it. > > This draft presents a quick RA acquisition scheme with the support > of a link-layer entity, PoA (Point of Attachment). PoA is either > 802.11 AP or 802.16 BS. > > Upon a new network attachment, a PoA can either trigger a router > to immediately send an unicast RA ("RA Triggering") or deliver > such an RA for itself ("RA Proxying"). > > We may put 'RA Triggering' or 'RA Proxying' functionality on > a PoA to get the optimized result. > > Main changes from the previous versions are > - We expanded the result to other wireless-link technologies. > We added IEEE 802.16. part. > - We added RA Triggering part so the scheme doesn't depend > solely on "RA Caching" any longer. > - We incorporated the IEEE 802.21 (Media Independent Handover) > results to realize "RA Triggering" and "RA Proxying" > > The draft doesn't show up on the repository yet but is available at > > http://www.diffeo.com/drafts/draft-jinchoi-dna-frd-01.txt > > Your feedback will be appreciated. > > Thanks in advance for your kind consideration. > > Best Regards > > JinHyeock Choi > > p.s. > We implemented a scheme in 802.11 AP and measured DNA delay. > Roughly it takes 1-2 ms for a host to get an RA after L2 association > is made. More detailed report later. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 03:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DumEA-0001m8-PQ for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 03:09:18 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15467 for ; Tue, 19 Jul 2005 03:09:16 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTF8HZ49299OZ3L@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 17:09:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 94242AB544; Tue, 19 Jul 2005 17:08:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4704E4FB0F; Tue, 19 Jul 2005 17:08:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J78iX30363 for dna-list; Tue, 19 Jul 2005 17:08:44 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J78iw30359 for ; Tue, 19 Jul 2005 17:08:44 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTF80K8ZQ97KU10@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 17:08:34 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EA5EAB543; Tue, 19 Jul 2005 17:08:33 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 145684FB03; Tue, 19 Jul 2005 17:08:33 +1000 (EST) Date: Tue, 19 Jul 2005 17:08:32 +1000 From: Brett Pentland Subject: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Dna Message-id: <42DCA6F0.1030302@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT I created an issue page for this topic. See: http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue019 I'm also in favour of the landmark approach. Amongst other things, I think it integrates more easily with non-DNA devices. A host that comes from a non-DNA link to a DNA link gets a positive confirmation of link change. I don't think this is the case with LinkID which relies on detecting change in the LinkID (which there won't be on a non-DNA link). Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 03:32:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DumaC-0007Xa-4N for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 03:32:04 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16639 for ; Tue, 19 Jul 2005 03:32:01 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTG1VJT8K99OXKG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 17:31:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B91ABAB545; Tue, 19 Jul 2005 17:31:50 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6E1314FB03; Tue, 19 Jul 2005 17:31:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J7VUF30632 for dna-list; Tue, 19 Jul 2005 17:31:30 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J7VUw30628 for ; Tue, 19 Jul 2005 17:31:30 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTG15OLAC97LSX4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 17:31:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AEE2AAB543; Tue, 19 Jul 2005 17:31:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8C8674FB04; Tue, 19 Jul 2005 17:31:15 +1000 (EST) Date: Tue, 19 Jul 2005 17:31:15 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DCA6F0.1030302@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DCAC43.2030602@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Thanks for creating the issue. I'm taking my hat off for this e-mail. Brett Pentland wrote: > I created an issue page for this topic. See: > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue019 > > I'm also in favour of the landmark approach. > > Amongst other things, I think it integrates more easily with non-DNA > devices. A host that comes from a non-DNA link to a DNA link gets a > positive confirmation of link change. I don't think this is the case > with LinkID which relies on detecting change in the LinkID (which there > won't be on a non-DNA link). I'd like to point out that protocol-00/protocol-01 have two Link Identification mechanisms which interact. The draft has the prefix landmark scheme (Request in RS, Response in RA) which is able to answer questions regardless of which link a prefix was previously on. It also contains a specification of CompleteRA, which contains an augmented RA (like Prefix LinkID) in even unsolicited RAs. Rightly, comparisons should initially be made between CompleteRA and Prefix LinkID, rather than between Prefix LinkID and Prefix Landmarks, since the augmented RA schemes have so much in common. I'd guess that the desirable solution for me is either: Prefix Landmark + CompleteRA Prefix Landmark + Prefix LinkID rather than argument for removal of prefix landmarks (which serve a purpose wherever RSs are required for DNA). This below represents my current (personal) leanings: Personally, while the cost of CompleteRA is potentially higher if the prefixes advertised by routers aren't the same, I still believe that it has strong advantages in being able to immediately help construct a complete list of prefixes on the link, which can be used in RA matching if a link-hint is received again (even if the host moves to a non-DNA link). CompleteRA and Prefix Landmarks also both work well even if they share a link with RFC 2461 (non-DNA) routers. In either case, the DNA router is able to answer questions about the prefixes in use by the legacy routers (CompleteRA readvertises these in the DNAO, and a Landmark query can be answered easily, regardless of the original advertisor's DNA status). Prefix LinkIDs cannot agree easily with existing non-DNA routers on the link's identity. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 04:11:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunCf-0008Kd-Oi for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 04:11:49 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18791 for ; Tue, 19 Jul 2005 04:11:46 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTHECH4LC94YGK0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 18:11:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F37E8000F; Tue, 19 Jul 2005 18:10:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E05F23C00E; Tue, 19 Jul 2005 18:10:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J8AeU31129 for dna-list; Tue, 19 Jul 2005 18:10:40 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J8Adw31125 for ; Tue, 19 Jul 2005 18:10:39 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTHDU7X209APETY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 18:10:31 +1000 Received: by localhost (Postfix, from userid 510) id 0A6428000E; Tue, 19 Jul 2005 18:10:30 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id 107AB3C005; Tue, 19 Jul 2005 18:10:29 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6J8AR3t003150; Tue, 19 Jul 2005 01:10:28 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6J8ALCc223244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2005 01:10:24 -0700 (PDT) Date: Tue, 19 Jul 2005 01:11:00 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DC532A.6040103@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <42DCB594.1010105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Hi Erik, > > Thanks for your work in getting -01 out. It looks good. Thank Brett! > I think you're right about the lifetimes counting down to zero (based > on the real time counters from Section 4.1). These should supercede > the 90 minute cache time, where a prefix is withdrawn from a link. Yes, it should be the min of the 90 minutes and the advertised valid lifetime. > [...] > > Only if a prefix is assigned to a new link before the expiry of the > prefix on the old link, would the 90 minute timer come into use. Yes. > So is flash renumbering really about allocating a prefix to another > link before expiring the lifetime on the existing link's routers? The loose definition I've been using for "flash renumbering" (as opposed to more gentle forms of renumbering) is where the prefix is suddenly withdrawn i.e. the valid lifetime suddenly drops from a large value (could be 30 days, or a few hours) down to zero. More gentle forms of (planned) renumbering would be when the preferred and valid lifetimes are allowed to decrement in realtime i.e. with an initial valid lifetime of X days, it is known X days in advance that the prefix will be removed. The problematic case shows up when there is flash renumbering followed by (more or less) immediate reassignment of the removed prefix to another link. One could argue that folks shouldn't do that, but it would still be nice to have some safety so that, should it be done, a DNA host isn't in some confused state for a long time (e.g., 30 days with the default RFC 2461 timers). > In that case, the 90 minutes are sufficient only if deployers > can be made to comply with that period of non use (or non redeployment) > for the prefix. Yep. > I think the flash renumbering concept needs to be well defined > (possibly separately), and discussed in order to gain a wider > consensus that it's a problem we need to solve, and if the > 90 minute hold-down before reallocation is the right way to solve it. FWIW I think this might be one reason that Keith Moore was concerned about using prefixes for DNAs purpose. > At this stage, I've only seen flash renumbering described in a > DNA context, so it would be good to figure out if any other WGs > are likely to have the same interest or problems. There hasn't been another place it has come up, because there hasn't been another thorough effort to handle movement. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 04:18:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunJ6-0002kn-12 for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 04:18:28 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19406 for ; Tue, 19 Jul 2005 04:18:25 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTHJOLZGQ97LYLT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 18:15:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B22D8000E; Tue, 19 Jul 2005 18:15:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 379923C00C; Tue, 19 Jul 2005 18:15:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J8FAb31206 for dna-list; Tue, 19 Jul 2005 18:15:10 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J8FAw31202 for ; Tue, 19 Jul 2005 18:15:10 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTHJES9O89APETY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 18:15:01 +1000 Received: by localhost (Postfix, from userid 510) id 820C8AB543; Tue, 19 Jul 2005 18:15:00 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0E6CA4FB02 for ; Tue, 19 Jul 2005 18:14:54 +1000 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7412A1019; Tue, 19 Jul 2005 10:14:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 10:14:51 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 10:14:51 +0200 Date: Tue, 19 Jul 2005 10:14:50 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised dna-link-info I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j6J8FAw31203 Content-type: text/plain; charset=iso-8859-1 Thread-Topic: [DNA] Revised dna-link-info I-D Thread-index: AcWLy4cAsdJNzAZJQei+qiLtRtZzfQAbAGgA Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 19 Jul 2005 08:14:51.0886 (UTC) FILETIME=[F01500E0:01C58C39] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA19406 Hi Alper, This has already been discussed on the mailing list, but I wanted to brin= g it up again anyway. I feel that it's worth noting in the draft (maybe in Section 2.: "Among t= hese two event the first one...) that certain link technologies (I only k= now of 802.11) don't necessarily produce a link-down event prior a link-u= p event when the node re-associates with a new AP. If such a link-down ev= ent is desirable, it must be generated from the host's stack because I do= n't think it is realistic to assume that already existing hardware will b= e updated to produce such events. -- Tero=20 -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.e= ng.monash.edu.au] On Behalf Of Alper Yegin Sent: 18. hein=E4kuuta 2005 22:03 To: dna@eng.monash.edu.au Subject: [DNA] Revised dna-link-info I-D Folks, I've had submitted the revised version of the dna-link-info I-D 10 days ago, but it hasn't showed up on the IETF repository yet. For that, please see a copy of the I-D at the following location: http://yegin.org/IETF/draft-ietf-dna-link-information-02.txt The major changes in this revision include: - New text for IEEE 802.3. - Handling multiple 3GPP PDP Contexts. I'd like to take your attention to the changes we needed to make in order to accommodate nondeterministic L2 events on Ethernet (e.g., link is up but the host the network may block data transmission). Please read Section 2 and the entire 2.4 to see the details. Please review and comment before the Paris meeting. Alper From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 04:55:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuntC-0004H1-Av for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 04:55:46 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21517 for ; Tue, 19 Jul 2005 04:55:43 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTIY6ZI9499P4J8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 18:55:27 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E6CBAB545; Tue, 19 Jul 2005 18:55:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AF1874FB03; Tue, 19 Jul 2005 18:55:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J8sai31746 for dna-list; Tue, 19 Jul 2005 18:54:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J8saw31740 for ; Tue, 19 Jul 2005 18:54:36 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTIXG2BKU94ZXMP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 18:54:34 +1000 Received: by localhost (Postfix, from userid 510) id 0C7DC8000D; Tue, 19 Jul 2005 18:54:34 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3B2D53C00B; Tue, 19 Jul 2005 18:54:32 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6J8sVvU013247; Tue, 19 Jul 2005 02:54:31 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6J8sMoJ228582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2005 01:54:26 -0700 (PDT) Date: Tue, 19 Jul 2005 01:25:56 -0700 From: Erik Nordmark Subject: Re: [DNA] Flash renumbering and CompleteRA/CPL maintenance In-reply-to: <42DB08D6.5030202@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42DCB914.2040300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42D70B24.5030704@eng.monash.edu.au> <42D788DA.90701@sun.com> <42DB08D6.5030202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Actually, the benefits of the DNAO (in fact the CompleteRA generally), > seem to me to be most useful when they are able to be used to > construct the CPL immediately (for example on an unsolicited RA, or > on a Landmark "No" answer). > > This means that even rapid subsequent transition to a non-DNA > network (or DNA network) can be identified as link-change, so long > as the existing reception of RA information can be identified as > complete. Now that I understand the problem you are trying to solve ... The current draft isn't written with this in mind, but it doesn't seem hard to extend it to be able to do this as well. (And as I was reading your email I came up with the idea that a single DNAO lifetime, which is the min of all the valid lifetimes of the includes prefixes, could be included; then I saw you had the same idea already expressed in your email :-) I had initially thought that all routers on the link would either be new DNA capable routers, or all be old RFC 2461 routers, but then I realized that such a constraint is hard if not impossible to enforce (it would at least add complications to the protocol). If this was the case though, then movement between DNA and non-DNA links would be easy to detect since the DNA bit in the RAs would differ. But assuming we want to handle a mix of DNA and non-DNA routers on the same link, then the hosts need to be able to track the complete prefix list all the time, and the landmark option (and DNAO in multicast RAs) merely become an optimization for detecting movement with a single RA. So I agree with you that DNAO can be useful for quickly constructing the CPL. Adding the single "minimum valid lifetime" is needed to do this. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 04:56:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuntV-0004IN-Ac for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 04:56:05 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21546 for ; Tue, 19 Jul 2005 04:56:02 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTIY0SAFS97KZYZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 18:55:29 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C20D28000F; Tue, 19 Jul 2005 18:55:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 79B803C00B; Tue, 19 Jul 2005 18:55:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J8saO31743 for dna-list; Tue, 19 Jul 2005 18:54:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J8sZw31736 for ; Tue, 19 Jul 2005 18:54:35 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTIXA9RW697KZYZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 18:54:26 +1000 Received: by localhost (Postfix, from userid 510) id 42A86AB543; Tue, 19 Jul 2005 18:54:26 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4966C4FB08; Tue, 19 Jul 2005 18:54:24 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6J8sKr3005037; Tue, 19 Jul 2005 02:54:20 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6J8sDj8228523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2005 01:54:17 -0700 (PDT) Date: Tue, 19 Jul 2005 01:16:07 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DB170C.7090900@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Message-id: <42DCB6C7.2000506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > So if we recommend that the router incapable of answering either Yes > or No doesn't send a Landmark, do we need to specify that hosts > discard landmark options with neither Yes or No received in an RA? We should clarify that such landmark options are a no-op, i.e. that they don't change any state on the receiver (since they have no semantic value). Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 05:02:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo07-0006hg-Li for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 05:02:55 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22076 for ; Tue, 19 Jul 2005 05:02:52 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTJ7DWUB69APFNU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 19:02:39 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BCCB2AB546; Tue, 19 Jul 2005 19:02:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7D0B74FB07; Tue, 19 Jul 2005 19:02:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J92Ux31880 for dna-list; Tue, 19 Jul 2005 19:02:30 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J92Tw31876 for ; Tue, 19 Jul 2005 19:02:29 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTJ72HPD097KU3A@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 19:02:20 +1000 Received: by localhost (Postfix, from userid 510) id 6E0A4AB545; Tue, 19 Jul 2005 19:02:19 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 800144FB0E; Tue, 19 Jul 2005 19:02:17 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6J92Gcn009379; Tue, 19 Jul 2005 02:02:16 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6J927OI229487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2005 02:02:11 -0700 (PDT) Date: Tue, 19 Jul 2005 02:02:46 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DCB594.1010105@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <42DCC1B6.4060002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Greg Daley wrote: > >> Hi Erik, >> >> Thanks for your work in getting -01 out. It looks good. > > > Thank Brett! Sigh - too many drafts and common issues. AFAIK Brett didn't help editing the CPL draft, but he did for the draft-pentland-dna-protocol draft. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 05:05:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duo2v-0007sz-6J for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 05:05:49 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22361 for ; Tue, 19 Jul 2005 05:05:46 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTJB4WFQG9APFNU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 19:05:41 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1398AAB543; Tue, 19 Jul 2005 19:05:36 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C67374FB05; Tue, 19 Jul 2005 19:05:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6J95V731939 for dna-list; Tue, 19 Jul 2005 19:05:31 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6J95Uw31935 for ; Tue, 19 Jul 2005 19:05:30 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTJAUUWH299P6WF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 19:05:22 +1000 Received: by localhost (Postfix, from userid 510) id BD818AB542; Tue, 19 Jul 2005 19:05:22 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by curly.its.monash.edu.au (Postfix) with ESMTP id E8F0E4FB03 for ; Tue, 19 Jul 2005 19:05:21 +1000 (EST) Received: by zproxy.gmail.com with SMTP id p8so1098367nzb for ; Tue, 19 Jul 2005 02:05:20 -0700 (PDT) Received: by 10.36.55.7 with SMTP id d7mr508364nza; Tue, 19 Jul 2005 02:04:53 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 02:04:53 -0700 (PDT) Date: Tue, 19 Jul 2005 18:04:53 +0900 From: JinHyeock Choi Subject: Re: [DNA] Building upon agreement: Which bits of DNA solution do we have consensus for? In-reply-to: <42D74C9F.7030600@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05071902044fc335de@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=njdST5TZuNuQXDBfORWrjoXJB3M908DmLqewFOk3wUqW1Yo6nORNLCVLJK3NRlIIlBbdymu1QN4TYswp3MY68mr03/dvqO22rn6zuc6ga5Ybsmxqrhak8qlC2WWga/4ElDgJ677FsUCX/tAHkxuNAe835Jb+379dVHDDkaVtyRo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42D74C9F.7030600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg Thanks for your trouble advancing DNA solution. I think that there are a few missing components in your list. Framework draft presents the solution components as below, 3.1 Solution components 1. RA message optimized for DNA, which 1) properly indicate link change and 2) carries necessary information for a new IP configuration. 2. A way to quickly deliver an RA to a host upon a new link-layer connection. 3. Optimistic DAD [17] and TSLLAO [18] that is being specified in the IPv6 WG. 4. A procedure to apply DAD during the DNA procedure that is both efficient and safe should there be a duplicate. 5. A procedure for MLD so that the multicast groups are reported on a new link. 6. A procedure that handles DHCPv6 address (and other) configuration for those cases when stateless address autoconfiguration is not used. Though your list properly deals with 2, 3 and link identification, it doesn't include 1, 4, 5, 6. Especially I'd like to mention 1, RA optimized for DNA. In case a host is attached to a different link, it would be useful for the first RA message to include the necessary information to initiate a new IP configuration. I think we need to consider what kind of information the RA should include. We think that the RA should include 1) The information to indicate link change 2) Router address (to select new default router, in case of a link change) 3) Prefix(es) (to form a new IP address, in case of a link change) 4) Link-layer address of a router (to immediately send a packet) and the RA would better include 1') A global IP address of a router 2') All prefixes that the router advertises I'd like WG look this over to reach an agreement. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 07:40:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqSi-0001GV-AT for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 07:40:36 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04493 for ; Tue, 19 Jul 2005 07:40:34 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTOP9XPG497LMN6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 21:40:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9CE36AB545; Tue, 19 Jul 2005 21:39:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 537DB4FB0E; Tue, 19 Jul 2005 21:39:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JBdAL01360 for dna-list; Tue, 19 Jul 2005 21:39:10 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JBdAw01356 for ; Tue, 19 Jul 2005 21:39:10 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTOO70FUU94ZL30@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 21:38:54 +1000 Received: by localhost (Postfix, from userid 510) id 6FA65AB543; Tue, 19 Jul 2005 21:38:54 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5D7A34FB03; Tue, 19 Jul 2005 21:38:48 +1000 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F99A12B4; Tue, 19 Jul 2005 13:38:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 13:38:45 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 13:38:25 +0200 Date: Tue, 19 Jul 2005 13:38:24 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Greg Daley Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised FRD (Fast Router Discovery) I-D Thread-index: AcWL/2crmvHzGA8uS5KFcvksfF0LqgAUWlNA Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 19 Jul 2005 11:38:25.0434 (UTC) FILETIME=[5FEC87A0:01C58C56] Content-Transfer-Encoding: 7BIT Hi JinHyeock, Just a couple of quick questions... Should entries in the cache suppose to have the lifetime stated in an RA? I guess PoA uses sending router's source address to index entries in the cache, i.e. if a router sends an updated RA, PoA finds the old entry by using the source address (or source link layer address in the option field). -- Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 08:36:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurKe-0001GA-7x for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 08:36:20 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09199 for ; Tue, 19 Jul 2005 08:36:18 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTQNQKB6C99OUA7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Jul 2005 22:36:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DCE05AB544; Tue, 19 Jul 2005 22:35:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8EC8C4FB06; Tue, 19 Jul 2005 22:35:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JCZ4t02010 for dna-list; Tue, 19 Jul 2005 22:35:04 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JCZ4w02006 for ; Tue, 19 Jul 2005 22:35:04 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTQMJR18Y94YZHC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Jul 2005 22:34:50 +1000 Received: by localhost (Postfix, from userid 510) id C4F13AB542; Tue, 19 Jul 2005 22:34:50 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2E7714FB05; Tue, 19 Jul 2005 22:34:45 +1000 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84DA4A18; Tue, 19 Jul 2005 14:34:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 14:34:42 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 14:34:42 +0200 Date: Tue, 19 Jul 2005 14:34:41 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , JinHyeock Choi , Greg Daley Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised FRD (Fast Router Discovery) I-D Thread-index: AcWL/2crmvHzGA8uS5KFcvksfF0LqgAUWlNAAAKYPCA= Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 19 Jul 2005 12:34:42.0437 (UTC) FILETIME=[3CC64B50:01C58C5E] Content-Transfer-Encoding: 7BIT Hi again, I also started wondering how the solution works with SEND and especially when the timestamp and nonce options are present. In addition what if the router(s) is/are configured to send RAs relatively seldom, say once every 60 minutes, would it be required that the PoA decreases prefix lifetimes in the cached entries? Just wondering... /Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 11:12:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dutle-0002ca-OX for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 11:12:22 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27702 for ; Tue, 19 Jul 2005 11:12:18 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTW4JPLBQ99P4ZA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 01:12:10 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B07A5AB543; Wed, 20 Jul 2005 01:12:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 739024FB04; Wed, 20 Jul 2005 01:12:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JFBTt03913 for dna-list; Wed, 20 Jul 2005 01:11:29 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JFBRw03909 for ; Wed, 20 Jul 2005 01:11:28 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTW3CYPW697KXZ8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 01:11:10 +1000 Received: by localhost (Postfix, from userid 510) id 7F1B2AB542; Wed, 20 Jul 2005 01:11:10 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8F50B4FB06; Wed, 20 Jul 2005 01:11:07 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6JFAp4R022132; Tue, 19 Jul 2005 11:10:51 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id CB2E71E8181; Tue, 19 Jul 2005 11:01:37 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id B30CA1E8168; Tue, 19 Jul 2005 11:01:37 -0400 (EDT) Date: Tue, 19 Jul 2005 11:10:25 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DCAC43.2030602@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Message-id: <42DD17E1.9090903@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:79.38847 C:14 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg - I agree with your preference: I too prefer Prefix Landmark + CompleteRA , among other things, CompleteRA helps with building of the CPL if the host moves out to a non-DNA link. Prefix Landmark provides a way for the router to know whether the host with the 'landmark question' has changed link or not and build its (unicast-)RA accordingly, which I think will be very efficient in terms of bandwidth utilization as 'no link change' is more likely than not. I quote from "-01.txt" "In the case when the host is still attached to the same link, which might occur when the host has changed from using one layer 2 access point to another, but the access points are on the same link, the Router Advertisement(s) it receives will contain a "yes, that prefix is on this link" answer, and no other information. Thus, such RA messages are quite small. In the case when the landmark prefix is unknown to the responding router, the host will receive a "No" answer to its landmark question, and also the information it needs to configure itself for the new link. The routers try to include as much information as possible in such messages, so that the host can be informed of all the prefixes assigned to the new link as soon as possible." - Sathya > Hi Brett, > > Thanks for creating the issue. > > I'm taking my hat off for this e-mail. > > Brett Pentland wrote: > >> I created an issue page for this topic. See: >> >> http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue019 >> >> I'm also in favour of the landmark approach. >> >> Amongst other things, I think it integrates more easily with non-DNA >> devices. A host that comes from a non-DNA link to a DNA link gets a >> positive confirmation of link change. I don't think this is the case >> with LinkID which relies on detecting change in the LinkID (which there >> won't be on a non-DNA link). > > > > I'd like to point out that protocol-00/protocol-01 have two Link > Identification mechanisms which interact. > > The draft has the prefix landmark scheme (Request in RS, Response in RA) > which is able to answer questions regardless of which link a prefix was > previously on. > > It also contains a specification of CompleteRA, which contains an > augmented RA (like Prefix LinkID) in even unsolicited RAs. > Rightly, comparisons should initially be made between CompleteRA > and Prefix LinkID, rather than between Prefix LinkID and > Prefix Landmarks, since the augmented RA schemes have so much in common. > > I'd guess that the desirable solution for me is either: > > Prefix Landmark + CompleteRA > > Prefix Landmark + Prefix LinkID > > rather than argument for removal of prefix landmarks (which serve a > purpose wherever RSs are required for DNA). > > This below represents my current (personal) leanings: > > Personally, while the cost of CompleteRA is potentially higher if the > prefixes advertised by routers aren't the same, I still believe that it > has strong advantages in being able to immediately help construct a > complete list of prefixes on the link, which can be used in RA matching > if a link-hint is received again (even if the host moves to a non-DNA > link). > > CompleteRA and Prefix Landmarks also both work well even if they share > a link with RFC 2461 (non-DNA) routers. In either case, the DNA > router is able to answer questions about the prefixes in use by the > legacy routers (CompleteRA readvertises these in the DNAO, and a > Landmark query can be answered easily, regardless of the original > advertisor's DNA status). > > Prefix LinkIDs cannot agree easily with existing non-DNA routers on the > link's identity. > > Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:32:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duv0r-0005X6-Gt for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:32:09 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11759 for ; Tue, 19 Jul 2005 12:32:05 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTYVRVVMK94ZPTZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:31:32 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C72CCAB54A; Wed, 20 Jul 2005 02:31:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 777DA4FB05; Wed, 20 Jul 2005 02:31:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGUqu04864 for dna-list; Wed, 20 Jul 2005 02:30:52 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGUpw04859 for ; Wed, 20 Jul 2005 02:30:51 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTYUW6QN89APE8F@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:30:38 +1000 Received: by localhost (Postfix, from userid 510) id 5D467AB543; Wed, 20 Jul 2005 02:30:38 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2B7334FB08; Wed, 20 Jul 2005 02:30:37 +1000 (EST) Date: Tue, 19 Jul 2005 09:30:34 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, Brett Pentland Cc: Dna Message-id: <00d501c58c7f$2fcac400$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg, I agree that CompleteRA is preferable to PrefixID, for the reasons you've stated. jak ----- Original Message ----- From: "Greg Daley" To: "Brett Pentland" Cc: "James Kempf" ; "Dna" Sent: Tuesday, July 19, 2005 12:31 AM Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Hi Brett, > > Thanks for creating the issue. > > I'm taking my hat off for this e-mail. > > Brett Pentland wrote: > > I created an issue page for this topic. See: > > > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue019 > > > > I'm also in favour of the landmark approach. > > > > Amongst other things, I think it integrates more easily with non-DNA > > devices. A host that comes from a non-DNA link to a DNA link gets a > > positive confirmation of link change. I don't think this is the case > > with LinkID which relies on detecting change in the LinkID (which there > > won't be on a non-DNA link). > > > I'd like to point out that protocol-00/protocol-01 have two Link > Identification mechanisms which interact. > > The draft has the prefix landmark scheme (Request in RS, Response in RA) > which is able to answer questions regardless of which link a prefix was > previously on. > > It also contains a specification of CompleteRA, which contains an > augmented RA (like Prefix LinkID) in even unsolicited RAs. > Rightly, comparisons should initially be made between CompleteRA > and Prefix LinkID, rather than between Prefix LinkID and > Prefix Landmarks, since the augmented RA schemes have so much in common. > > I'd guess that the desirable solution for me is either: > > Prefix Landmark + CompleteRA > > Prefix Landmark + Prefix LinkID > > rather than argument for removal of prefix landmarks (which serve a > purpose wherever RSs are required for DNA). > > This below represents my current (personal) leanings: > > Personally, while the cost of CompleteRA is potentially higher if the > prefixes advertised by routers aren't the same, I still believe that it > has strong advantages in being able to immediately help construct a > complete list of prefixes on the link, which can be used in RA matching > if a link-hint is received again (even if the host moves to a non-DNA > link). > > CompleteRA and Prefix Landmarks also both work well even if they share > a link with RFC 2461 (non-DNA) routers. In either case, the DNA > router is able to answer questions about the prefixes in use by the > legacy routers (CompleteRA readvertises these in the DNAO, and a > Landmark query can be answered easily, regardless of the original > advertisor's DNA status). > > Prefix LinkIDs cannot agree easily with existing non-DNA routers on the > link's identity. > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:35:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duv4J-0006iG-RK for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:35:44 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11918 for ; Tue, 19 Jul 2005 12:35:40 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZ0VEW0I9APE8F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:35:29 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 732FFAB544; Wed, 20 Jul 2005 02:35:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 16E974FB06; Wed, 20 Jul 2005 02:35:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGZN104947 for dna-list; Wed, 20 Jul 2005 02:35:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGZNw04943 for ; Wed, 20 Jul 2005 02:35:23 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZ0P3YP89APCNF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:35:19 +1000 Received: by localhost (Postfix, from userid 510) id 1DB038000D; Wed, 20 Jul 2005 02:35:19 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5AB313C005; Wed, 20 Jul 2005 02:35:18 +1000 (EST) Date: Tue, 19 Jul 2005 09:35:15 -0700 From: James Kempf Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , greg.daley@eng.monash.edu.au Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <00e301c58c7f$d7bd2680$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> Content-Transfer-Encoding: 7BIT > > At this stage, I've only seen flash renumbering described in a > > DNA context, so it would be good to figure out if any other WGs > > are likely to have the same interest or problems. > > There hasn't been another place it has come up, because there hasn't > been another thorough effort to handle movement. > In fact, AFICT, RFC 2894 has not received a lot of operational testing. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:52:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvK6-0004r8-7U for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:52:06 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13056 for ; Tue, 19 Jul 2005 12:51:58 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZL5TJEA9APGMA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:51:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F422AB545; Wed, 20 Jul 2005 02:51:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 31C324FB09; Wed, 20 Jul 2005 02:51:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGpbn05227 for dna-list; Wed, 20 Jul 2005 02:51:37 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGpaw05219 for ; Wed, 20 Jul 2005 02:51:36 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZKLKPYG99P0PA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:51:21 +1000 Received: by localhost (Postfix, from userid 510) id C1C0E8000D; Wed, 20 Jul 2005 02:51:21 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by larry.its.monash.edu.au (Postfix) with ESMTP id B1BF83C005 for ; Wed, 20 Jul 2005 02:51:19 +1000 (EST) Received: by zproxy.gmail.com with SMTP id p8so1178577nzb for ; Tue, 19 Jul 2005 09:51:18 -0700 (PDT) Received: by 10.36.147.2 with SMTP id u2mr5231388nzd; Tue, 19 Jul 2005 09:50:47 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 09:50:46 -0700 (PDT) Date: Wed, 20 Jul 2005 01:50:46 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05071909502f4fa258@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Levbs1Lg+v/8tKBc39aSajfb36SkrzOWCrGWIVHLEuEvBg1rboYmUor/h5ledHmNe9B+aQ2nH9mMvvLHd8ZxGgrVwLX1d3cDhuRxXnMcMSlqLkxr4mepxHGTpZWZiezM9zH/0SH1EHkZK8VlnHM+LwanIYhzpGZ5eb9+0Y3zxbo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Dear Jak Thanks for your detailed comments. > I am in favor of Landmark Prefix and not LinkID. I could go through a list > of problems I have with draft-jinchoi but I'm sure JinHyeock could up with > reasonable responses, > and I'm not interested in getting into a long email > conversation about specific details of LinkID, because it would only result > in more text getting added to the draft to handle problems and special cases > with the protocol. I think you may overestimate me. I am prepared to yield to the case which LinkId can't handle reasonably. > My basic objection is that LinkID is considerably more more complex than > Landmark Prefix. We are in disagreement here. draft-pentland relies not only landmark but also CompleteRA. (I guess Landmark/ CompleteRA may be the more proper term.) I think CompleteRA by itself is more complex than LinkID. (That's why I switched to Linkid. As you may know, I've played with CompleteRA quite long in DT) > draft-jinchoi requires 22 pages just to describe the link > identification protocol, whereas the latest draft of draft-pentland covers > link identification, fast RA delivery, link configuration, address state > machine management, and more in 25 pages. Essentially, the draft to describe > the entire DNA protocol using Landmark Prefix is only 3 pages more than the > draft to describe just the link identification part using LinkID. Page count > is a kind of crude measure of complexity, but I think this analysis would > hold up if one went through in more detail. I don't think page count is a proper measure of complexity. It may result from either my poor English composition or more mature protocol specification. Also I point out the scheme is implemented with the code size 390 lines for router & 160 lines for host, which, I think, is not too much complicated. We may count code lines instead. > There's a lot of special case > language, extra timers, and extra data structures in LinkID that aren't > needed for Landmark Prefix. Kindly designate in more detail. Many new notions in LinkID is also needed in Landmark/ CompleteRA (though in different language). For the case of Linkid lifetime, Landmark/ CompleteRA also adopts a similar notion like below. Prefix information entry MUST be removed from the DNAPrefixList when its valid lifetime expires or if the entry has not been refreshed in the last 1.5 hours. Moreover I point out Landmark/ CompleteRA needs more new messages. > I support selecting Landmark Prefix for the WG draft for DNA. Though I am in favor of Linkid, I don't think we have made a proper comparison yet. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:52:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvKa-0004wV-39 for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:52:32 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13097 for ; Tue, 19 Jul 2005 12:52:28 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZLPV5YY9APGMA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:52:21 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BADEAB544; Wed, 20 Jul 2005 02:52:15 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 01AB14FB03; Wed, 20 Jul 2005 02:52:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGqDM05285 for dna-list; Wed, 20 Jul 2005 02:52:13 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGqDw05281 for ; Wed, 20 Jul 2005 02:52:13 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTZLMIVS494ZL5Z@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:52:11 +1000 Received: by localhost (Postfix, from userid 510) id 5D0BB80010; Wed, 20 Jul 2005 02:52:11 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by larry.its.monash.edu.au (Postfix) with ESMTP id 980013C00C for ; Wed, 20 Jul 2005 02:52:10 +1000 (EST) Received: by zproxy.gmail.com with SMTP id m22so1178823nzf for ; Tue, 19 Jul 2005 09:52:09 -0700 (PDT) Received: by 10.36.222.18 with SMTP id u18mr5283944nzg; Tue, 19 Jul 2005 09:51:40 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 09:51:39 -0700 (PDT) Date: Wed, 20 Jul 2005 01:51:39 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DD17E1.9090903@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507190951599a65f7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iSVae+FiaC5U4mJJf+vleKy8pBoqrU0GCQ7+FEI7+T5HSHNk5Y1J2+yWLJn+lVQ48OlP12d+StKXwOXxHn+SGFahkheZDhwh8aSlMVGYYILYidb6uVvYSl+pQpI3MCcbfNzpUZMovzIdlqyG2yDUqwnBa60PV73IiYutmtz82TQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <42DD17E1.9090903@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > I agree with your preference: I too prefer Prefix Landmark + CompleteRA > , among other things, CompleteRA helps with building of the CPL if the > host moves out to a non-DNA link. > > Prefix Landmark provides a way for the router to know whether the host > with the 'landmark question' has changed link or not and build its > (unicast-)RA accordingly, which I think will be very efficient in terms > of bandwidth utilization as 'no link change' is more likely than not. I > quote from "-01.txt" Kindly see the Issue 007 of Linkid-01 draft. With Linkid prefix option for RS message, Linkid can achieve the same bandwidth saving. (But I can't be sure that it's worthwhile.) Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:52:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvKs-00056Q-8U for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:52:50 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13170 for ; Tue, 19 Jul 2005 12:52:46 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTZL8TL4A94ZVF1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:52:18 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D35D1AB543; Wed, 20 Jul 2005 02:51:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 882B54FB05; Wed, 20 Jul 2005 02:51:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGppW05254 for dna-list; Wed, 20 Jul 2005 02:51:51 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGpow05250 for ; Wed, 20 Jul 2005 02:51:50 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTZL5UDGI94ZVF1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:51:49 +1000 Received: by localhost (Postfix, from userid 510) id 04D6DAB54C; Wed, 20 Jul 2005 02:51:48 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0657D4FB07 for ; Wed, 20 Jul 2005 02:51:47 +1000 (EST) Received: by zproxy.gmail.com with SMTP id x3so1176431nzd for ; Tue, 19 Jul 2005 09:51:47 -0700 (PDT) Received: by 10.36.148.7 with SMTP id v7mr5234083nzd; Tue, 19 Jul 2005 09:51:22 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 09:51:22 -0700 (PDT) Date: Wed, 20 Jul 2005 01:51:22 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DCAC43.2030602@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507190951362ec87c@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rpyo9Ip9hk1eD6MMu6qDEnKzY/7LEH2Z6v+VHCoJ67PX564/kMw7SCp26vwr5SGVFySgMEDoaByDvPlpGbqvWnlxlD7KohV+v8wnnj3OFpcgiWHqVtYlK60Rg2od00DP9nx79sVG72lPMzWHwpj4fNMX8tKH9u8Oxnbc6SfZra8= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > I'd like to point out that protocol-00/protocol-01 have two Link > Identification mechanisms which interact. > > The draft has the prefix landmark scheme (Request in RS, Response in RA) > which is able to answer questions regardless of which link a prefix was > previously on. > > It also contains a specification of CompleteRA, which contains an > augmented RA (like Prefix LinkID) in even unsolicited RAs. > Rightly, comparisons should initially be made between CompleteRA > and Prefix LinkID, rather than between Prefix LinkID and > Prefix Landmarks, since the augmented RA schemes have so much in common. > > I'd guess that the desirable solution for me is either: > > Prefix Landmark + CompleteRA > > Prefix Landmark + Prefix LinkID > > rather than argument for removal of prefix landmarks (which serve a > purpose wherever RSs are required for DNA). I don't think the comparison is exactly right. Right now Linkid draft is complete by itself. It doesn't need either landmark or CompleteRA. Whereas Landarmk needs CompleteRA to be able to check for link change with unsolicted RA. I don't rule out the possibility of Linkid + landmark but would like to see the tangible benefits which can match up the added complexity to Linkid alone. I think the comparison would better be as it is. Linkid between Landmark/ CompleteRA > This below represents my current (personal) leanings: > > Personally, while the cost of CompleteRA is potentially higher if the > prefixes advertised by routers aren't the same, I still believe that it > has strong advantages in being able to immediately help construct a > complete list of prefixes on the link, which can be used in RA matching > if a link-hint is received again (even if the host moves to a non-DNA > link). As DT may knows, I worked on Comlete RA for long. But it's more difficult to synchronize, consume more bandwidth and there is a possibility that it can't be made. > CompleteRA and Prefix Landmarks also both work well even if they share > a link with RFC 2461 (non-DNA) routers. In either case, the DNA > router is able to answer questions about the prefixes in use by the > legacy routers (CompleteRA readvertises these in the DNAO, and a > Landmark query can be answered easily, regardless of the original > advertisor's DNA status). > > Prefix LinkIDs cannot agree easily with existing non-DNA routers on the > link's identity. It can. It will simply pick the smallest prefix. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 12:53:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvL2-00056t-5m for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 12:53:00 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13197 for ; Tue, 19 Jul 2005 12:52:56 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQTZLBK40S97KTLG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 02:52:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 87A898000E; Wed, 20 Jul 2005 02:51:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 34CFF3C00C; Wed, 20 Jul 2005 02:51:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JGpbA05229 for dna-list; Wed, 20 Jul 2005 02:51:37 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JGpaw05221 for ; Wed, 20 Jul 2005 02:51:36 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQTZKVFDCG99P0PA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 02:51:35 +1000 Received: by localhost (Postfix, from userid 510) id 0DE7BAB543; Wed, 20 Jul 2005 02:51:35 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by moe.its.monash.edu.au (Postfix) with ESMTP id 305734FB06 for ; Wed, 20 Jul 2005 02:51:32 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 4so1177887nzn for ; Tue, 19 Jul 2005 09:51:30 -0700 (PDT) Received: by 10.36.5.19 with SMTP id 19mr5295649nze; Tue, 19 Jul 2005 09:51:03 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 09:51:02 -0700 (PDT) Date: Wed, 20 Jul 2005 01:51:02 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DCA6F0.1030302@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050719095163dbae27@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rKQncswGkMk+4E0c5NErpRIXQ9MQ8AvXAYTFMZ6XmI8qtu3LnQkS6q960exxmEsYzDD1gofF8NRLo8ZS0IMUTeDDJhXtECgjqT7NeHCwnnsYe5MHsYUSeg+jMFdkzLxbhRtSbkX47TXxfgPtdslwjZMV52ivLyT2Fr04oJMiAVo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > I'm also in favour of the landmark approach. > > Amongst other things, I think it integrates more easily with non-DNA > devices. A host that comes from a non-DNA link to a DNA link gets a > positive confirmation of link change. I don't think this is the case > with LinkID which relies on detecting change in the LinkID (which there > won't be on a non-DNA link). You are right but I think CPL will step in such a case. I think it would help if we write down 'other things' to compare two in whole. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 13:17:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duvib-00069L-6b for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 13:17:25 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15508 for ; Tue, 19 Jul 2005 13:17:17 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU0HENBW099P07G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 03:17:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 62D35AB545; Wed, 20 Jul 2005 03:17:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D251E4FB0D; Wed, 20 Jul 2005 03:17:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JHGhu05646 for dna-list; Wed, 20 Jul 2005 03:16:43 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JHGgw05642 for ; Wed, 20 Jul 2005 03:16:42 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU0GR08KY94ZITT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 03:16:30 +1000 Received: by localhost (Postfix, from userid 510) id 2C507AB542; Wed, 20 Jul 2005 03:16:30 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7FF984FB08; Wed, 20 Jul 2005 03:16:26 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6JHGBfw026849; Tue, 19 Jul 2005 13:16:11 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 6BF6E1E81A0; Tue, 19 Jul 2005 13:06:57 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 591C11E8181; Tue, 19 Jul 2005 13:06:57 -0400 (EDT) Date: Tue, 19 Jul 2005 13:15:45 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <92e919fb0507190951362ec87c@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <42DD3541.3010703@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > > >>This below represents my current (personal) leanings: >> >>Personally, while the cost of CompleteRA is potentially higher if the >>prefixes advertised by routers aren't the same, I still believe that it >>has strong advantages in being able to immediately help construct a >>complete list of prefixes on the link, which can be used in RA matching >>if a link-hint is received again (even if the host moves to a non-DNA >>link). >> >> > >As DT may knows, I worked on Comlete RA for long. But it's more >difficult to synchronize, consume more bandwidth and there is a >possibility that it can't be made. > > I don't think this is accurate in comparison to synchronizing for prefix-LinkID. Prefix LinkID requires the completeRA list to be synchronized in each of the routers so that the least prefix can be selected from the list as LinkID. So the synchronization/bandwidth requirements are the same for both CompleteRA and Prefix LinkID. The difference between LinkID and CompleteRA is only in terms of what is included in the RA messages - i.e. the debate is only what will be the information included in the RA message. I think it is better to include the whole list of prefixes rather one representative - because chosing a representative adds additional requirement of synchronization in terms of the timing when the representative is chosen at each router. - Sathya > > > >>CompleteRA and Prefix Landmarks also both work well even if they share >>a link with RFC 2461 (non-DNA) routers. In either case, the DNA >>router is able to answer questions about the prefixes in use by the >>legacy routers (CompleteRA readvertises these in the DNAO, and a >>Landmark query can be answered easily, regardless of the original >>advertisor's DNA status). >> >>Prefix LinkIDs cannot agree easily with existing non-DNA routers on the >>link's identity. >> >> > >It can. It will simply pick the smallest prefix. > >Thanks in advance for your kind consideration. > >Best Regards > >JinHyeock > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 13:35:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duw0Q-0003p4-NF for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 13:35:46 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16832 for ; Tue, 19 Jul 2005 13:35:42 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU14FL85M9APF9G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 03:35:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8D0B78000F; Wed, 20 Jul 2005 03:35:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 32E9F3C00D; Wed, 20 Jul 2005 03:35:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JHZAQ05901 for dna-list; Wed, 20 Jul 2005 03:35:10 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JHZ9w05897 for ; Wed, 20 Jul 2005 03:35:09 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU13LAWPQ99OYHA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 03:34:55 +1000 Received: by localhost (Postfix, from userid 510) id 18E62AB542; Wed, 20 Jul 2005 03:34:55 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 359634FB06; Wed, 20 Jul 2005 03:34:53 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6JHYoPs027744; Tue, 19 Jul 2005 13:34:50 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 909911E8181; Tue, 19 Jul 2005 13:25:36 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 667001E820B; Tue, 19 Jul 2005 13:25:36 -0400 (EDT) Date: Tue, 19 Jul 2005 13:34:24 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <92e919fb0507190951599a65f7@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <42DD39A0.3040009@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> Content-Transfer-Encoding: 7BIT Dear JinHyeock - >Dear Sathya > > >>I agree with your preference: I too prefer Prefix Landmark + CompleteRA >>, among other things, CompleteRA helps with building of the CPL if the >>host moves out to a non-DNA link. >> >>Prefix Landmark provides a way for the router to know whether the host >>with the 'landmark question' has changed link or not and build its >>(unicast-)RA accordingly, which I think will be very efficient in terms >>of bandwidth utilization as 'no link change' is more likely than not. I >>quote from "-01.txt" >> >> > >Kindly see the Issue 007 of Linkid-01 draft. With Linkid prefix option >for RS message, Linkid can achieve the same bandwidth saving. >(But I can't be sure that it's worthwhile.) > > I am surprised - this issue is basically suggesting the adoption of prefix landmark into the prefix LinkID solution. If this change is made to LinkID, then the second proposal becomes Prefix Landmark + Prefix LinkID, as Greg suggested. But, your response to Greg's email seem to suggest that you don't like that combination. Anyhow, I think the first step is to agree which particular concepts are worth pursuing and then we can worry about which particular solution draft is proposing it. If what is said in Issue 007 of Linkid-01 draft is agreed by you, I think there is consensus to adopt the 'concept of landmark'. Whether the 'prefix-LinkID ' chosen by the routers must be used as landmark by the hosts or whether each host choses its own landmark needs to be resolved - I (obviously ;-) prefer the later. And the second component needing consensus is, as Greg suggested, whether to include the complete list of prefixes (CompleteRA) or a representative for each set (LinkID). As I mentioned in the earlier email, LinkID requires the synchronization of the complete list of prefixes so that it can choose the least prefix - but LinkID needs additional synchronization among the routers as to when they chose the LinkID. All the other components like oDAD, TSLLAO etc., AFAIK, we already have consensus on how to address them. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 14:07:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwVE-00006g-M4 for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 14:07:36 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19473 for ; Tue, 19 Jul 2005 14:07:32 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU27VXR7299OYC9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 04:06:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 322CAAB54A; Wed, 20 Jul 2005 04:06:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E12F94FB02; Wed, 20 Jul 2005 04:06:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JI6L206518 for dna-list; Wed, 20 Jul 2005 04:06:21 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JI6Iw06514 for ; Wed, 20 Jul 2005 04:06:18 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU2752SXC9504Q3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 04:06:01 +1000 Received: by localhost (Postfix, from userid 510) id 4642DAB543; Wed, 20 Jul 2005 04:06:01 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by moe.its.monash.edu.au (Postfix) with ESMTP id 65D794FB02 for ; Wed, 20 Jul 2005 04:06:00 +1000 (EST) Received: by rproxy.gmail.com with SMTP id a41so1671500rng for ; Tue, 19 Jul 2005 11:05:59 -0700 (PDT) Received: by 10.38.59.70 with SMTP id h70mr2053767rna; Tue, 19 Jul 2005 11:05:59 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Tue, 19 Jul 2005 11:05:59 -0700 (PDT) Date: Tue, 19 Jul 2005 23:35:59 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DCAC43.2030602@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Reply-to: Syam Madanapalli Message-id: <10e14db20507191105264e01f7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GbIH2DlHqLfOXotbCECR6zK5krjRv7VBJujZ4in2xkw5W+ZnC2RvPpm2HmhNxqgnOUNqXCXedYUIZmaWSMZaAHeuu2SyLRE+wQvCchkRUvV1FruUzGQkgHxLq4izmxyjjQ19rtiUEqlXZvoYcNZJlhc/swsHODP4PkYrQhNqO9I= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > > I'd like to point out that protocol-00/protocol-01 have two Link > Identification mechanisms which interact. > > The draft has the prefix landmark scheme (Request in RS, Response in RA) > which is able to answer questions regardless of which link a prefix was > previously on. > > It also contains a specification of CompleteRA, which contains an > augmented RA (like Prefix LinkID) in even unsolicited RAs. > Rightly, comparisons should initially be made between CompleteRA > and Prefix LinkID, rather than between Prefix LinkID and > Prefix Landmarks, since the augmented RA schemes have so much in common. > > I'd guess that the desirable solution for me is either: > > Prefix Landmark + CompleteRA > > Prefix Landmark + Prefix LinkID > > rather than argument for removal of prefix landmarks (which serve a > purpose wherever RSs are required for DNA). Linkid scheme also works with RS as well as without RS if the node was on a DNA capable link previously. Definitely I see the advantage of Landmark if the node is moving from non-DNA link. > > This below represents my current (personal) leanings: > > Personally, while the cost of CompleteRA is potentially higher if the > prefixes advertised by routers aren't the same, I still believe that it > has strong advantages in being able to immediately help construct a > complete list of prefixes on the link, which can be used in RA matching > if a link-hint is received again (even if the host moves to a non-DNA > link). As a host can build the complete prefix list on its own without explicit support for complete RA, we may need to carefully evaluate it's benefits against the bandwidth consumption on the link as well as synchronization complexity. A host may need to be at the link for less than a minute to acquire the complete prefix list, the chances of a node moving away from the link within few seconds may be less. > > CompleteRA and Prefix Landmarks also both work well even if they share > a link with RFC 2461 (non-DNA) routers. In either case, the DNA > router is able to answer questions about the prefixes in use by the > legacy routers (CompleteRA readvertises these in the DNAO, and a > Landmark query can be answered easily, regardless of the original > advertisor's DNA status). Did you see any problems with linkid scheme in case non-DNA router present on the link? I think Linkid scheme also works with non-DNA routers. > > Prefix LinkIDs cannot agree easily with existing non-DNA routers on the > link's identity. As we have implemented the linkid scheme, we did not find any such problems. For landmark also all the Routers need know about all other prefixes, otherwie the host may get conflict answers. > > Greg > And I think it is worth to provide the complete comparison list between Landmark and Linkid Schemes, so that the non DT members can uderstand and will be able to participate in the selection process for the link identification method. I hope this is not a burden for the DT as they already know how each schecme works :) Thank you, Syam From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 14:14:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwcD-00033U-Ce for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 14:14:49 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19975 for ; Tue, 19 Jul 2005 14:14:47 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU2HM4ADI9APGNS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 04:14:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC8698000E; Wed, 20 Jul 2005 04:14:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 88FF03C003; Wed, 20 Jul 2005 04:14:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JIELl06655 for dna-list; Wed, 20 Jul 2005 04:14:21 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JIELw06651 for ; Wed, 20 Jul 2005 04:14:21 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU2HGPY9094ZYDT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 04:14:20 +1000 Received: by localhost (Postfix, from userid 510) id AE5698000D; Wed, 20 Jul 2005 04:14:20 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by larry.its.monash.edu.au (Postfix) with ESMTP id E490B3C00C for ; Wed, 20 Jul 2005 04:14:18 +1000 (EST) Received: by rproxy.gmail.com with SMTP id r35so1672956rna for ; Tue, 19 Jul 2005 11:14:17 -0700 (PDT) Received: by 10.38.86.42 with SMTP id j42mr3048916rnb; Tue, 19 Jul 2005 11:14:17 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Tue, 19 Jul 2005 11:14:17 -0700 (PDT) Date: Tue, 19 Jul 2005 23:44:17 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <42DD39A0.3040009@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: Syam Madanapalli Message-id: <10e14db205071911144ebdf04d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OSF5eb3f5ShzSoakwHmmSPAPCnoxBUFo7PWEBvTB/ppwIUF8ntEAvCydt/LRYFKnHgim3WV6TmigM/uueksDRW0OViDh3TkWQPoHZHheGDh8yJ5a3Zb6TCvAgqHeUY4rhZ6PMJdSA26bM17DMPDx/SZizIEjzdo5fpGj9E0yT64= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, > As I mentioned in the earlier > email, LinkID requires the synchronization of the complete list of > prefixes so that it can choose the least prefix - but LinkID needs > additional synchronization among the routers as to when they chose the > LinkID. > To the extent of my knowledge even Landmark method requires the synchronization among routers, otherwise one router may say 'no' and other may say 'yes' for the landmark question. -Syam From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 14:47:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dux7X-0006YQ-UT for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 14:47:16 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22187 for ; Tue, 19 Jul 2005 14:47:09 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU3M1FP169APFHZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 04:47:05 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43C68AB545; Wed, 20 Jul 2005 04:47:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E8D5F4FB05; Wed, 20 Jul 2005 04:47:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JIkdN07134 for dna-list; Wed, 20 Jul 2005 04:46:39 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JIkcw07130 for ; Wed, 20 Jul 2005 04:46:38 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU3L9XO5Y9505NA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 04:46:26 +1000 Received: by localhost (Postfix, from userid 510) id 7539B8000E; Wed, 20 Jul 2005 04:46:26 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id EC5473C011; Wed, 20 Jul 2005 04:46:24 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6JIk9qL030232; Tue, 19 Jul 2005 14:46:09 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id D280E1E8181; Tue, 19 Jul 2005 14:36:55 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id C20591E8168; Tue, 19 Jul 2005 14:36:55 -0400 (EDT) Date: Tue, 19 Jul 2005 14:45:44 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkIDv.s.LandmarkPrefix In-reply-to: <10e14db205071911144ebdf04d@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <42DD4A58.80003@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <10e14db205071911144ebdf04d@mail.gmail.com> Content-Transfer-Encoding: 7BIT Syam - >Hi Sathya, > > > >>As I mentioned in the earlier >>email, LinkID requires the synchronization of the complete list of >>prefixes so that it can choose the least prefix - but LinkID needs >>additional synchronization among the routers as to when they chose the >>LinkID. >> >> >> >To the extent of my knowledge even Landmark method requires the >synchronization among routers, otherwise one router may say 'no' >and other may say 'yes' for the landmark question. > > Yes - I am sorry I wasn't clear - LinkID, CompleteRA and Landmark require the synchronization of the complete list of prefixes by the routers - but LinkID MAY need additional synchronization in terms of the timing when the LinkID is chosen at each routers. What I mean is that, a clear indication that the complete list is collected is needed in the LinkID case before the routers can chose the LinkID, while in Landmark and CompleteRA - 'as far as I know' these are the prefixes will work reasonably well at each router, even when the complete list is a little bit off. Some hosts may get conflicting answers with Landmark, but if two routers chose different LinkIDs all the hosts in the link will receive RA messages with two different LinkIDs and keep changing configuration until the synchronization is complete - i.e. the synchronization requirement is stronger in the case of LinkID, IMHO. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 15:55:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyBq-0004Tk-Os for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 15:55:43 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29132 for ; Tue, 19 Jul 2005 15:55:40 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU60ACEAM94VHVZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 05:55:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BFB3AB542; Wed, 20 Jul 2005 05:55:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 51E9F4FB07; Wed, 20 Jul 2005 05:55:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JJsW207909 for dna-list; Wed, 20 Jul 2005 05:54:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JJsVw07905 for ; Wed, 20 Jul 2005 05:54:31 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU5YHTRXG99OX99@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 05:54:22 +1000 Received: by localhost (Postfix, from userid 510) id E3317AB545; Wed, 20 Jul 2005 05:54:21 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id E65094FB07; Wed, 20 Jul 2005 05:54:20 +1000 (EST) Date: Tue, 19 Jul 2005 12:54:17 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli , greg.daley@eng.monash.edu.au Cc: Brett Pentland , Dna Message-id: <008601c58c9b$a5c35a70$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> Content-Transfer-Encoding: 7BIT And I think it is worth to provide the complete comparison list between Landmark and Linkid Schemes, so that the non DT members can uderstand and will be able to participate in the selection process for the link identification method. I hope this is not a burden for the DT as they already know how each schecme works :) jak>> I've got no objection if someone wants to do this, but I really don't think it is necessary. People just need to read the drafts and decide for themselves which one they like. jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 16:33:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duymh-0002CS-LU for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 16:33:48 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15878 for ; Tue, 19 Jul 2005 16:33:44 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU7BTU5UE97LETQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 06:33:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 47359AB543; Wed, 20 Jul 2005 06:33:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 049E54FB06; Wed, 20 Jul 2005 06:33:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JKX6a08332 for dna-list; Wed, 20 Jul 2005 06:33:06 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JKX5w08328 for ; Wed, 20 Jul 2005 06:33:05 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU7B6WE6897LETQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 06:32:50 +1000 Received: by localhost (Postfix, from userid 510) id 93321AB542; Wed, 20 Jul 2005 06:32:49 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id B34634FB06; Wed, 20 Jul 2005 06:32:47 +1000 (EST) Date: Tue, 19 Jul 2005 13:32:45 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> <42DC405F.5040501@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, > Yes, if that covered all cases it would be simpler not to need RSs, but > there is no guarantee that there will be any unsolicited RAs from the > other routers on the link before the 15 sec expiry. If that doesn't > happen, then the router will start behaving as a full DNA router before > it has complete information and may thus answser requests incorrectly. > I assume you are thinking of nonDNA routers, because if we specify something from DNA routers, then there will be a high probability that something will come through, since the retransmits should ensure it in the face of drops, right? RFC 2461 (and RFC 2461bis) has this to say about boot time sending of unsolicited RAs (Section 6.2.4): For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it becomes an advertising interface, if the randomly chosen interval is greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for the initial advertisements increases the likelihood of a router being discovered quickly when it first becomes available, in the presence of possible packet loss. So, basically, whether or not a nonDNA router does advertisement is configurable. If we decide to use advertisement, then I think we need to specify what these configurable parameters need to be for nonDNA routers (and we probably ought to do that anyway even if we decide to use solicitation, as Eric's note mentioned). > I can't see how we can avoid RSs if we want to be confident of complete > information before we start behaving as a DNA router. I don't see how RSs would provide any more confidence than RAs. In order to make sure that all routers got the RSs in the face of drops, they would need to be multicast retransmitted too. So whether the RAs are multicast retransmitted or the the RSs are doesn't seem to make much difference AFIKT. Can you explain why you think this would make a difference? jak From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 16:37:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyqJ-0004gz-2k for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 16:37:32 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17500 for ; Tue, 19 Jul 2005 16:37:28 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQU7FUII9O9APEZW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 06:36:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A3BF9AB542; Wed, 20 Jul 2005 06:36:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5D7B54FB04; Wed, 20 Jul 2005 06:36:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JKaTP08400 for dna-list; Wed, 20 Jul 2005 06:36:29 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JKaTw08396 for ; Wed, 20 Jul 2005 06:36:29 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQU7FKLRPG97L2ZY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 06:36:22 +1000 Received: by localhost (Postfix, from userid 510) id 87005AB542; Wed, 20 Jul 2005 06:36:22 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 92D5D4FB05; Wed, 20 Jul 2005 06:36:21 +1000 (EST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW0001G6KJSF@mailout1.samsung.com>; Wed, 20 Jul 2005 05:36:19 +0900 (KST) Received: from ep_spt02 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00CW56KJA9@ms3.samsung.com>; Wed, 20 Jul 2005 05:36:19 +0900 (KST) Content-return: prohibited Date: Tue, 19 Jul 2005 20:36:12 +0000 (GMT) From: Daniel Park Subject: Re: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Syam Madanapalli , "greg.daley@eng.monash.edu.au" , Brett Pentland , Dna Reply-to: soohong.park@samsung.com Message-id: <0IJW00CW66KJA9@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050719203618258@soohong.park X-MTR: 20050719203618258@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: ** Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

And I think it is worth to provide the complete comparison list
between Landmark and Linkid Schemes, so that the non DT members can
uderstand and will be able to participate in the selection process for
the link identification method. I hope this is not a
burden for the DT as they already know how each schecme works :)


jak>> I've got no objection if someone wants to do this, but I really don't
think it is necessary. People just need to read the drafts and decide for
themselves which one they like.

 

Daniel> Strongly disagreed, in my understanding, DNA will decide

which one  would be more valuable method and it will be accepted

as WG item, then another one will be dead.  (I don't think we need

both) Rather just reading a draft, specific comparison and evaluation

would be more good effort on adopting any protocols within each WG

if available.  So it is definitely necessary at this stage.

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 18:40:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0kt-0001NN-PK for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 18:40:08 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09221 for ; Tue, 19 Jul 2005 18:39:59 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUBPPUB9E95071W@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 08:39:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2106EAB545; Wed, 20 Jul 2005 08:39:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C86DD4FB03; Wed, 20 Jul 2005 08:39:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JMcWR09857 for dna-list; Wed, 20 Jul 2005 08:38:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JMcUw09853 for ; Wed, 20 Jul 2005 08:38:30 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUBOSIQGW99P0NN@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 08:38:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54AB7AB543; Wed, 20 Jul 2005 08:38:20 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 39C234FB0D; Wed, 20 Jul 2005 08:38:20 +1000 (EST) Date: Wed, 20 Jul 2005 08:38:18 +1000 From: Greg Daley Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DCB6C7.2000506@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DD80DA.5060409@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DCB6C7.2000506@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> So if we recommend that the router incapable of answering either Yes >> or No doesn't send a Landmark, do we need to specify that hosts >> discard landmark options with neither Yes or No received in an RA? > > > We should clarify that such landmark options are a no-op, i.e. that they > don't change any state on the receiver (since they have no semantic value). Yes, and then also tell routers not to send them. Is that the agreement? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 19:03:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv180-0006qZ-1S for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 19:03:56 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11358 for ; Tue, 19 Jul 2005 19:03:51 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUCKLC6A097LBRC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 09:03:25 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE1E1AB544; Wed, 20 Jul 2005 09:03:11 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6B6FE4FB05; Wed, 20 Jul 2005 09:03:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JN31B10180 for dna-list; Wed, 20 Jul 2005 09:03:01 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JN30w10176 for ; Wed, 20 Jul 2005 09:03:00 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUCK5UKLW99P2YF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 09:02:51 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E7D82AB545; Wed, 20 Jul 2005 09:02:50 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id CA11E4FB04; Wed, 20 Jul 2005 09:02:50 +1000 (EST) Date: Wed, 20 Jul 2005 09:02:50 +1000 From: Greg Daley Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DCB594.1010105@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DD869A.8050402@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > [cut] > >> Only if a prefix is assigned to a new link before the expiry of the >> prefix on the old link, would the 90 minute timer come into use. > > > Yes. > >> So is flash renumbering really about allocating a prefix to another >> link before expiring the lifetime on the existing link's routers? > > > The loose definition I've been using for "flash renumbering" (as opposed > to more gentle forms of renumbering) is where the prefix is suddenly > withdrawn i.e. the valid lifetime suddenly drops from a large value > (could be 30 days, or a few hours) down to zero. > > More gentle forms of (planned) renumbering would be when the preferred > and valid lifetimes are allowed to decrement in realtime i.e. with an > initial valid lifetime of X days, it is known X days in advance that the > prefix will be removed. > > The problematic case shows up when there is flash renumbering followed > by (more or less) immediate reassignment of the removed prefix to > another link. > One could argue that folks shouldn't do that, but it would still be nice > to have some safety so that, should it be done, a DNA host isn't in some > confused state for a long time (e.g., 30 days with the default RFC 2461 > timers). I think that the problem in DNA comes (primarily) where there's lingering state in the network: a host or router which hasn't seen the zero lifetime retraction. A zero lifetime retraction is a valid mechanism, but intermittently connected hosts may not receive the notification that the prefix is no longer connected. I'd like to sit and think for a little while and determine if there's a completely safe way to handle knowledge used for CPL (or CompleteRA etc.) without facing the danger that the prefixes will be classified as belonging to one link (when in fact they belong to two, from two different times). This shouldn't hamper progression of CPL at the moment. >> In that case, the 90 minutes are sufficient only if deployers >> can be made to comply with that period of non use (or non redeployment) >> for the prefix. > > > Yep. > >> I think the flash renumbering concept needs to be well defined >> (possibly separately), and discussed in order to gain a wider >> consensus that it's a problem we need to solve, and if the >> 90 minute hold-down before reallocation is the right way to solve it. > > > FWIW I think this might be one reason that Keith Moore was concerned > about using prefixes for DNAs purpose. That's understandable. It would be good later to have his and other operational opinions of how relevant the problem is, and how the solutions may be impacted by it. >> At this stage, I've only seen flash renumbering described in a >> DNA context, so it would be good to figure out if any other WGs >> are likely to have the same interest or problems. > > > There hasn't been another place it has come up, because there hasn't > been another thorough effort to handle movement. I think that this is the right place to explore the issue then (if it's a small enough issue). Do you think we may need a short PS after IETF? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 19:14:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1Hu-0004dc-Cp for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 19:14:10 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12105 for ; Tue, 19 Jul 2005 19:14:06 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUCX924VW94U6P6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 09:14:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EF5A8AB545; Wed, 20 Jul 2005 09:13:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8773B4FB0B; Wed, 20 Jul 2005 09:13:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JNDBT10306 for dna-list; Wed, 20 Jul 2005 09:13:11 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JNDAw10302 for ; Wed, 20 Jul 2005 09:13:10 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUCWM9XEO9AOWJ5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 09:12:54 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B20880010; Wed, 20 Jul 2005 09:12:53 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 696033C005; Wed, 20 Jul 2005 09:12:53 +1000 (EST) Date: Wed, 20 Jul 2005 09:12:52 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb0507190951362ec87c@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DD88F4.40209@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: [cut] >> >>I'd guess that the desirable solution for me is either: >> >>Prefix Landmark + CompleteRA >> >>Prefix Landmark + Prefix LinkID >> >>rather than argument for removal of prefix landmarks (which serve a >>purpose wherever RSs are required for DNA). > > > I don't think the comparison is exactly right. > > Right now Linkid draft is complete by itself. It doesn't need either landmark > or CompleteRA. Whereas Landarmk needs CompleteRA to be able to > check for link change with unsolicted RA. > > I don't rule out the possibility of Linkid + landmark but would like to see > the tangible benefits which can match up the added complexity to > Linkid alone. > > I think the comparison would better be as it is. > > Linkid between Landmark/ CompleteRA OK. That's a fair opinion. [cut] > > > As DT may knows, I worked on Comlete RA for long. But it's more > difficult to synchronize, consume more bandwidth and there is a > possibility that it can't be made. CompleteRA isn't difficult to synchronize at all. All routers immediately update their DNAPrefixList with a prefix as soon as it is seen. The next RAs all contain the prefix. The prefix lifetime timers (and last seen timers) count down in real-time on the routers (exactly like CPL). The (re-)advertised prefixes are only advertised so long as their original prefixes are valid. This is available in the distributed source code. >>CompleteRA and Prefix Landmarks also both work well even if they share >>a link with RFC 2461 (non-DNA) routers. In either case, the DNA >>router is able to answer questions about the prefixes in use by the >>legacy routers (CompleteRA readvertises these in the DNAO, and a >>Landmark query can be answered easily, regardless of the original >>advertisor's DNA status). >> >>Prefix LinkIDs cannot agree easily with existing non-DNA routers on the >>link's identity. > > > It can. It will simply pick the smallest prefix. Except if the non-DNA routers do not have the smallest prefix configured (which was my point). The RAs received from non-DNA routers aren't guaranteed to have any prefixes in common with the DNA (LinkID) routers. CompleteRA has this at potentially greater prefix advertisement cost. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 19:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1lG-00025V-FR for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 19:44:32 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14205 for ; Tue, 19 Jul 2005 19:44:26 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUE02NP0A99P4MT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 09:43:59 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4A38BAB54C; Wed, 20 Jul 2005 09:43:54 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id F25D54FB03; Wed, 20 Jul 2005 09:43:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JNhR110685 for dna-list; Wed, 20 Jul 2005 09:43:27 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JNhPw10679 for ; Wed, 20 Jul 2005 09:43:25 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUDY3DOWE97KR21@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 09:43:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 456578000E; Wed, 20 Jul 2005 09:43:06 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 20A3A3C013; Wed, 20 Jul 2005 09:43:06 +1000 (EST) Date: Wed, 20 Jul 2005 09:43:05 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <10e14db20507191105264e01f7@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DD9009.8060108@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi Syam, Once again, I'm expressing personal opionions only. Syam Madanapalli wrote: [cut] > > > Linkid scheme also works with RS as well as without RS if the node > was on a DNA capable link previously. Definitely I see the advantage > of Landmark if the node is moving from non-DNA link. The same can be said of CompleteRA (which has [provably] exactly the same properties as LinkID of being able to detect link change with DNA routers). The omission of RS only works in constrained environments where one already has the right link information (FMIPv6 predictive handover), or the Network infrastructure can be known beforehand to provide RA information (conceivably FastRD in a constrained environment). Neither of these scenarios is under consideration for the main DNA solution (FMIPv6 because it works without RA, FastRD because it isn't generally applicable), which needs to work correctly and quickly in generic IPv6 environments. So I don't think we can champion one particular technology based on the fact that it works (slowly in general) with unsolicited RA. >>This below represents my current (personal) leanings: >> >>Personally, while the cost of CompleteRA is potentially higher if the >>prefixes advertised by routers aren't the same, I still believe that it >>has strong advantages in being able to immediately help construct a >>complete list of prefixes on the link, which can be used in RA matching >>if a link-hint is received again (even if the host moves to a non-DNA >>link). > > > As a host can build the complete prefix list on its own without explicit > support for complete RA, we may need to carefully evaluate it's benefits > against the bandwidth consumption on the link as well as synchronization > complexity. A host may need to be at the link for less than a minute to > acquire the complete prefix list, the chances of a node moving away from > the link within few seconds may be less. But we already have CPL, and we know what its limitations are. The time to build sufficient information to Detect change is the critical issue: Otherwise we wouldn't have any link identification mechanism in the DNA solution. CPL is good enough if you've got the time and energy to probe for RAs. If we want to support (potentially) rapidly changing attachment, the state on the host needs to be as up to date as possible, whether using a landmark, a link-id or CompleteRA. CompleteRA has the potential to create a CPL immediately, which is better for the "movement to non-DNA" link case. >>CompleteRA and Prefix Landmarks also both work well even if they share >>a link with RFC 2461 (non-DNA) routers. In either case, the DNA >>router is able to answer questions about the prefixes in use by the >>legacy routers (CompleteRA readvertises these in the DNAO, and a >>Landmark query can be answered easily, regardless of the original >>advertisor's DNA status). > > > Did you see any problems with linkid scheme in case non-DNA router > present on the link? I think Linkid scheme also works with non-DNA routers. Except if the non-DNA routers don't happen to advertise the lowest numeric prefix... >>Prefix LinkIDs cannot agree easily with existing non-DNA routers on the >>link's identity. > > > As we have implemented the linkid scheme, we did not find any such problems. > For landmark also all the Routers need know about all other prefixes, otherwie > the host may get conflict answers. It doesn't need to know all the prefixes (as described in a previous thread). It needs to know what prefixes it definitely has locally. In that case, it can answer "Yes" immediately. Answering "No" takes definitive knowledge and synchronization. A prefix which answers "Yes" will supercede a "No" if it is received first. The chance that a router will answer "No" when another answers "Yes" is the chance that a prefix's advertisement has not been received on the "No" router before the RS with a landmark query is sent. This is bounded by the delay of the original RA to cross the network, and any robustness factors affecting delivery between pairs of routers. As the solicitor would have to have received the landmark prefix in an RA before it can send the landmark RS, the chances are really quite small that any remaining router would be not be updated before answering the landmark query. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 19:49:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1q5-00050I-HM for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 19:49:29 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14502 for ; Tue, 19 Jul 2005 19:49:25 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUE6FBQAU99OWC6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 09:49:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A2ABAB545; Wed, 20 Jul 2005 09:49:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0C1664FB04; Wed, 20 Jul 2005 09:49:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6JNmvr10799 for dna-list; Wed, 20 Jul 2005 09:48:57 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6JNmvw10795 for ; Wed, 20 Jul 2005 09:48:57 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUE633EMU97M2GZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 09:48:48 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04D5F80012; Wed, 20 Jul 2005 09:48:45 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id CA89C3C005; Wed, 20 Jul 2005 09:48:45 +1000 (EST) Date: Wed, 20 Jul 2005 09:48:45 +1000 From: Greg Daley Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <00e301c58c7f$d7bd2680$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DD915D.1090004@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <00e301c58c7f$d7bd2680$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: >>>At this stage, I've only seen flash renumbering described in a >>>DNA context, so it would be good to figure out if any other WGs >>>are likely to have the same interest or problems. >> >>There hasn't been another place it has come up, because there hasn't >>been another thorough effort to handle movement. >> > > > > In fact, AFICT, RFC 2894 has not received a lot of operational testing. I think I know what you mean, although there has been some work as part of the 6net project: http://www.6net.org/publications/deliverables/D3.6.2.pdf I've yet to read it thoroughly but came across it the other day. Greg. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 21:06:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv32o-0000YZ-0s for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 21:06:43 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23837 for ; Tue, 19 Jul 2005 21:06:39 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUGTLHBQK9APG7E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 11:05:04 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 295188000F; Wed, 20 Jul 2005 11:04:59 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DB3CE3C011; Wed, 20 Jul 2005 11:04:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K10Ek11672 for dna-list; Wed, 20 Jul 2005 11:00:14 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K10Bw11660 for ; Wed, 20 Jul 2005 11:00:11 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUGNF8B7C9APEMB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 11:00:01 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9094FAB545; Wed, 20 Jul 2005 11:00:00 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 607944FB05; Wed, 20 Jul 2005 11:00:00 +1000 (EST) Date: Wed, 20 Jul 2005 10:59:59 +1000 From: Greg Daley Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05071909502f4fa258@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDA20F.2080400@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> Content-Transfer-Encoding: 7BIT Dear JinHyeock, JinHyeock Choi wrote: > Dear Jak > > Thanks for your detailed comments. > > >>I am in favor of Landmark Prefix and not LinkID. I could go through a list >>of problems I have with draft-jinchoi but I'm sure JinHyeock could up with >>reasonable responses, >>and I'm not interested in getting into a long email >>conversation about specific details of LinkID, because it would only result >>in more text getting added to the draft to handle problems and special cases >>with the protocol. > > > I think you may overestimate me. I am prepared to yield to the case > which LinkId can't handle reasonably. > > >>My basic objection is that LinkID is considerably more more complex than >>Landmark Prefix. > > > We are in disagreement here. > > draft-pentland relies not only landmark but also CompleteRA. (I guess > Landmark/ CompleteRA may be the more proper term.) > > I think CompleteRA by itself is more complex than LinkID. (That's > why I switched to Linkid. As you may know, I've played with CompleteRA > quite long in DT) CompleteRA is not significantly more difficult. The only difference between storage of information in either CompleteRA or LinkID is that routers have to keep (at least) the two smallest Prefixes with LinkID, and that CompleteRA has to keep all prefixes (on the router side). The storage and comparison requirements are quite similar, especially on the host, where the CPL (+CCL) must be kept anyway. In fact, the Landmark and CompleteRA have exactly the same state requirements, and share space and implementation code in my RADVD patch. So overall, the cost of storage for the combined Landmark+CompleteRA solution is comparable to the LinkID solution. >>draft-jinchoi requires 22 pages just to describe the link >>identification protocol, whereas the latest draft of draft-pentland covers >>link identification, fast RA delivery, link configuration, address state >>machine management, and more in 25 pages. Essentially, the draft to describe >>the entire DNA protocol using Landmark Prefix is only 3 pages more than the >>draft to describe just the link identification part using LinkID. Page count >>is a kind of crude measure of complexity, but I think this analysis would >>hold up if one went through in more detail. > > > I don't think page count is a proper measure of complexity. It may > result from either my poor English composition or more mature > protocol specification. > > Also I point out the scheme is implemented with the code size > 390 lines for router & 160 lines for host, which, I think, is not > too much complicated. We may count code lines instead. Please don't count code lines, I've not got the time to program succinctly :) Please also be aware that my code contains CPL (on the host side - the most complicated part), event processing, router solicitation etc... On the router side, I've implemented FastRA, CompleteRA+Landmarks, token bucket schemes, new scheduling algorithms for RAs. It's not an apples-to-apples comparison (although you're free to peruse the code). If the text length isn't valid for comparison, and the code lines aren't either, we'll have to work on the properties exhibited by the proposals. >>There's a lot of special case >>language, extra timers, and extra data structures in LinkID that aren't >>needed for Landmark Prefix. > > > Kindly designate in more detail. Many new notions in LinkID is also > needed in Landmark/ CompleteRA (though in different language). > For the case of Linkid lifetime, Landmark/ CompleteRA also adopts > a similar notion like below. > > Prefix information entry MUST be removed from the DNAPrefixList when > its valid lifetime expires or if the entry has not been refreshed in > the last 1.5 hours. > > Moreover I point out Landmark/ CompleteRA needs more new > messages. Neither needs more messages. Both define new options and flags. Protocol-01 only needs an additional option for landmarking. I've previously described an alternative to the protocol-00, which used the same option format for DNAO and Landmark option. This was discussed on the ML and rejected since it unnecessarily overloaded the function of the DNA and Landmark options. So while there is an additional option, the agreement on-list was that things were made simpler by having separate options. Now having implemented this, I tend to agree (there wasn't significant additional cost with 2 options - and I'd implemented both ways). It's worth mentioning that protocol2-01's issue 007 recommends adding a LinkID prefix option, anyway. The DNAO is equivalent to the LPIO, since all native (not learned) prefixes in PrefixLinkID and CompleteRA are sent in their original PIO (with a flag for LinkID). The only difference between LPIO and DNAO is that it is possible to have up to two fixed sized LPIOs in LinkID, and up to one variable sized DNAO (only for learned prefixes). Neither scheme advertises LPIO or DNAO if the RA already contains all relevant prefixes. Arguing that one is more complicated than the other is likely to be inaccurate, as you're able to ascertain yourself from the published code. >>I support selecting Landmark Prefix for the WG draft for DNA. > > > Though I am in favor of Linkid, I don't think we have made > a proper comparison yet. Fair enough. I think we've got some time to process this still. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 21:11:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv37M-0002jY-9b for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 21:11:24 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24422 for ; Tue, 19 Jul 2005 21:11:21 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUH19F2II9APG7E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 11:11:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AEA14AB54F; Wed, 20 Jul 2005 11:11:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6EC484FB02; Wed, 20 Jul 2005 11:11:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K1B3d11809 for dna-list; Wed, 20 Jul 2005 11:11:03 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K1B3w11803 for ; Wed, 20 Jul 2005 11:11:03 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUH0ZLTPW97CULG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 11:10:57 +1000 Received: by localhost (Postfix, from userid 510) id D4587AB549; Wed, 20 Jul 2005 11:10:56 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6ECF04FB04 for ; Wed, 20 Jul 2005 11:10:54 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00DWIJA40P@mailout1.samsung.com> for dna@eng.monash.edu.au; Wed, 20 Jul 2005 10:10:52 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJW00M49JA2VX@mmp1.samsung.com> for dna@eng.monash.edu.au; Wed, 20 Jul 2005 10:10:52 +0900 (KST) Date: Tue, 19 Jul 2005 18:10:50 -0700 From: Alper Yegin Subject: RE: [DNA] Revised dna-link-info I-D In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Tero Kauppinen (JO/LMF)'" , dna@eng.monash.edu.au Message-id: <073701c58cc7$df789790$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j6K1B3w11804 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA24422 Hi Tero, How about if we add one more sentence to the end of this paragraph: Among these two events the first one to take place after an interface becomes enabled MUST be a link up event. During the time a network interface is enabled, it may go through a series of link up and down events. Each time the interface changes its point of attachment, a link down event with the previous attachment point MUST be followed by a link up event with the new one. Finally, when the network interface is disabled, this MUST generate a link down event. Each one of these events MUST generate a notification in the order they occur. Note that, a link down notification MAY NOT be generated if an optional tear-down protocol exchange or mechanism is skipped prior to performing a handover. Alper > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: Tuesday, July 19, 2005 1:15 AM > To: Alper Yegin; dna@eng.monash.edu.au > Subject: RE: [DNA] Revised dna-link-info I-D >=20 > Hi Alper, >=20 > This has already been discussed on the mailing list, but I wanted to bring > it up again anyway. >=20 > I feel that it's worth noting in the draft (maybe in Section 2.: "Among > these two event the first one...) that certain link technologies (I only > know of 802.11) don't necessarily produce a link-down event prior a link- > up event when the node re-associates with a new AP. If such a link-down > event is desirable, it must be generated from the host's stack because I > don't think it is realistic to assume that already existing hardware will > be updated to produce such events. >=20 > -- > Tero >=20 > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of Alper Yegin > Sent: 18. hein=E4kuuta 2005 22:03 > To: dna@eng.monash.edu.au > Subject: [DNA] Revised dna-link-info I-D >=20 >=20 > Folks, >=20 > I've had submitted the revised version of the dna-link-info I-D 10 days > ago, but it hasn't showed up on the IETF repository yet. For that, > please see a copy of the I-D at the following location: >=20 > http://yegin.org/IETF/draft-ietf-dna-link-information-02.txt >=20 > The major changes in this revision include: >=20 > - New text for IEEE 802.3. > - Handling multiple 3GPP PDP Contexts. >=20 > I'd like to take your attention to the changes we needed to make in > order to accommodate nondeterministic L2 events on Ethernet (e.g., link > is up but the host the network may block data transmission). Please read > Section 2 and the entire 2.4 to see the details. >=20 > Please review and comment before the Paris meeting. >=20 > Alper >=20 >=20 From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 21:25:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv3Kx-00017G-Qj for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 21:25:27 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26081 for ; Tue, 19 Jul 2005 21:25:25 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUHIBPNJC9APFTR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 11:24:59 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 715D2AB54A; Wed, 20 Jul 2005 11:24:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E8A9D4FB02; Wed, 20 Jul 2005 11:24:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K1OUm11996 for dna-list; Wed, 20 Jul 2005 11:24:30 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K1OUw11992 for ; Wed, 20 Jul 2005 11:24:30 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUHHLJN6U97L649@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 11:24:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3FF44AB545 for ; Wed, 20 Jul 2005 11:24:20 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 219B44FB02 for ; Wed, 20 Jul 2005 11:24:20 +1000 (EST) Date: Wed, 20 Jul 2005 11:24:19 +1000 From: Greg Daley Subject: [DNA] Paris Session update Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDA7C3.1090304@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear DNA WG, I'm working on the session agenda for Paris. It will be mainly aimed at getting the charter items progressed. In the mean time, here is the Date and Time for the DNA session at IETF 63, based on the current draft agenda: THURSDAY, August 4, 2005 1400-1630 Afternoon Session I APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT dna Detecting Network Attachment WG OPS mboned MBONE Deployment WG RTG manet Mobile Ad-hoc Networks WG SEC saag Open Security Area Directorate TSV dccp Datagram Congestion Control Protocol WG TSV voipeer VoIP Peering and Interconnect BOF Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 22:16:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv48J-0001nR-Ho for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 22:16:27 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05117 for ; Tue, 19 Jul 2005 22:16:22 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUJAPYG0Y9API1M@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 12:16:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F3C38000D; Wed, 20 Jul 2005 12:16:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 361073C013; Wed, 20 Jul 2005 12:16:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K2FZS12718 for dna-list; Wed, 20 Jul 2005 12:15:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K2FYw12714 for ; Wed, 20 Jul 2005 12:15:34 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUJ9SHVYC94ZDRZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 12:15:18 +1000 Received: by localhost (Postfix, from userid 510) id B792BAB544; Wed, 20 Jul 2005 12:15:18 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by curly.its.monash.edu.au (Postfix) with ESMTP id C47C04FB09 for ; Wed, 20 Jul 2005 12:15:16 +1000 (EST) Received: by zproxy.gmail.com with SMTP id f1so1131179nzc for ; Tue, 19 Jul 2005 19:15:15 -0700 (PDT) Received: by 10.36.60.13 with SMTP id i13mr219309nza; Tue, 19 Jul 2005 19:14:58 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 19:14:55 -0700 (PDT) Date: Wed, 20 Jul 2005 11:14:55 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <42DC9A4C.9010601@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0507191914308de355@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WZVinSJW9hXwJEuRamwmFLdFefKDJBD2uinyTGpKhIgzUrQ0BrXgrGdwErCN3w0jGXmP+fCXrCo/PpDdU/Yrwr0/lNznIqKb4M4ba4xgZICL3tkwO1s70VH6QoDVxLmUhSDtIaKNCQ5ESyqw0Eqes5XQSA1riPKXPA7+uyYjLyE= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett Thanks for your comments. > I just read over your update and have a few observations. > > I see you now have triggering as well as caching. Triggering seems > to make good sense when the AR and Point of Attachment (PoA) are > co-located, but when they are not it seems that you are just > reinventing RS/RA. Compared to the host initiating the RS, you > save one store-and-forward time in the PoA, but that doesn't seem > like much of a saving for a new protocol. Triggering is mostly aimed for the case of AR & PoA in one box. In that case, I see few reason for PoA to proxy an RA. But I think that "Triggering" can be even of help in the other case. Right now, we're contemplating a scheme which I will present when completed. > For RA Proxying you have a new option for getting the cached RA, > but what do you do if there's more than one router on the link? > Should the PoA cache and forward multiple RAs? If not, then the > host may have incomplete information. It may not have all of the > prefixes available on the link, and it won't have a complete list > of potential default routers. To get this additional information > it will need to send an RS in order to receive the RAs from all > of the routers on the link. You end up adding an RA to the overall > process though admittedly you get that first RA very quickly. I don't understand your point. DNA solution is supposed to do its job with a single RA message. Allow me to quote from DNA design team document, It was felt that by crafting the information in the solicitation and advertisement, a single RS/RA exchange should be sufficient for DNA. So in DNA point of view, I see no problem sending just one RA (optimized for DNA). Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 23:09:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv4xo-0004NF-DI for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 23:09:40 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10466 for ; Tue, 19 Jul 2005 23:09:36 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUL5PIQW29APCR5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 13:09:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D2BBAB54C; Wed, 20 Jul 2005 13:09:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A53DE4FB0C; Wed, 20 Jul 2005 13:09:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K38sL13369 for dna-list; Wed, 20 Jul 2005 13:08:54 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K38sw13364 for ; Wed, 20 Jul 2005 13:08:54 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUL4XGVCG9APF4J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 13:08:39 +1000 Received: by localhost (Postfix, from userid 510) id 88071AB542; Wed, 20 Jul 2005 13:08:39 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by curly.its.monash.edu.au (Postfix) with ESMTP id A30844FB0B for ; Wed, 20 Jul 2005 13:08:35 +1000 (EST) Received: by zproxy.gmail.com with SMTP id x3so1306206nzd for ; Tue, 19 Jul 2005 20:08:34 -0700 (PDT) Received: by 10.36.157.2 with SMTP id f2mr5659223nze; Tue, 19 Jul 2005 20:08:05 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 20:08:05 -0700 (PDT) Date: Wed, 20 Jul 2005 12:08:05 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0507192008382d856c@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JoefJZPugZS3yNR7kbN4rke4ixAANh7G4DTGf6XDJFQRIVswPSNswlTl8llJRAMdC9i68QP8UUEhe5k6NriS9FwHojIXtxF8olM/ab2Nwe1u4dr9YfIIZliri1Gv2WAHFIxuxN/uc0282xTpJ3rpnhsG+wMgIQsMJUCx4Ln+nBU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Dear Tero Thanks for comments. FRD is actually a schema, a collection of schemes. With the combination of various sub-components, we can implement it in different ways. I assume your question concern mostly about RA Proxying with Scanning. Am I right? > Just a couple of quick questions... > > Should entries in the cache suppose to have the lifetime stated in an > RA? No. We don't think it's desirable for PoA to modify an RA, unless it gets permission from AR. > I guess PoA uses sending router's source address to index entries in the > cache, i.e. if a router sends an updated RA, PoA finds the old entry by > using the source address (or source link layer address in the option > field). Right now, we design the scheme in the simplest way and PoA doesn't manage index entries. Assume there are two routers on a link, AR1 and AR2. First AR1 sends RA1 and PoA caches it. Afterwards AR2 sends RA2, then PoA substitutes its cached RA with RA2. This doesn't affect DNA performance as long as both RA1 and RA2 can properly indicate link identity, i.e. RA optimized for DNA. Also we implemented FRD with with 802.11 AP and it works as below. 1. We implemented FRD module on drives modules of netgear AP. 2. FRD module caches a multicast RA (multicast in IP point of view) 3. When an MN is attached, FRD module extracts the MN's MAC address from the L2 association request message. 4. FRD module combines the MN's MAC address with the cached RA to make an unicast L2 frame. (But the L2 frame contains a multicast RA.) 5. FRD module sends the unicast L2 frame (with the cached multicast RA) to the MN. 6. The MN receives the cached RA (in the unicast L2 frame). in average 1.3 ms. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 19 23:48:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv5Zj-0006vR-Ls for dna-archive@megatron.ietf.org; Tue, 19 Jul 2005 23:48:52 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13924 for ; Tue, 19 Jul 2005 23:48:48 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUMI8Q2IO97LIMM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 13:48:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9EDC980012; Wed, 20 Jul 2005 13:47:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 465E33C005; Wed, 20 Jul 2005 13:47:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K3kQY13834 for dna-list; Wed, 20 Jul 2005 13:46:26 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K3kJw13826 for ; Wed, 20 Jul 2005 13:46:19 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUMGEWSWA99OVMX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 13:46:09 +1000 Received: by localhost (Postfix, from userid 510) id 9C971AB542; Wed, 20 Jul 2005 13:46:09 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 641544FB0E; Wed, 20 Jul 2005 13:46:08 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW008PSQGUPB@mailout3.samsung.com>; Wed, 20 Jul 2005 12:46:06 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJW00ACVQGOS2@mmp1.samsung.com>; Wed, 20 Jul 2005 12:46:06 +0900 (KST) Date: Wed, 20 Jul 2005 09:12:20 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , Syam Madanapalli Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <060c01c58cdd$0bdc5fa0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <10e14db205071911144ebdf04d@mail.gmail.com> <42DD4A58.80003@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, >> >> >>>As I mentioned in the earlier >>>email, LinkID requires the synchronization of the complete list of >>>prefixes so that it can choose the least prefix - but LinkID needs >>>additional synchronization among the routers as to when they chose the >>>LinkID. >>> >>> >>> >>To the extent of my knowledge even Landmark method requires the >>synchronization among routers, otherwise one router may say 'no' >>and other may say 'yes' for the landmark question. >> >> > Yes - I am sorry I wasn't clear - LinkID, CompleteRA and Landmark > require the synchronization of the complete list of prefixes by the > routers - but LinkID MAY need additional synchronization in terms of the > timing when the LinkID is chosen at each routers. What I mean is that, a > clear indication that the complete list is collected is needed in the > LinkID case before the routers can chose the LinkID, while in Landmark > and CompleteRA - 'as far as I know' these are the prefixes will work > reasonably well at each router, even when the complete list is a little > bit off. Some hosts may get conflicting answers with Landmark, but if > two routers chose different LinkIDs all the hosts in the link will > receive RA messages with two different LinkIDs and keep changing > configuration until the synchronization is complete - i.e. the > synchronization requirement is stronger in the case of LinkID, IMHO. This is incorrect. The linkid works perfectly with the scenario you described. In the linkid, the host maintains the list of previous linkids which will be used to check if any of one of these was a linkid on the link. So change in linkid does not mean that the host requires reconfiguration. My current understanding is that the landmark need to synchronize all the time. Also linkid does not really require the synchronization all the time if router agree to have same linkid as long as possible. e.g. Router can pick one with longer valid life time and can continue to have the same linkid till the life time expires. If the prefix lifetime is not renewed then router can start synchronization to select new linkid. However, I am not saying the linkid is the only perfect solution, rather we may need to define criteria for the evaluation and then compare the two schemes against the defined criteria and we need to pick the best solution. - Syam From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 00:41:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6OP-0006sP-Ny for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 00:41:14 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18319 for ; Wed, 20 Jul 2005 00:41:09 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOC0X4BC97L9E4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 14:40:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22868AB548; Wed, 20 Jul 2005 14:39:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B3BD54FB0F; Wed, 20 Jul 2005 14:39:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K4dAk14412 for dna-list; Wed, 20 Jul 2005 14:39:10 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K4d9w14408 for ; Wed, 20 Jul 2005 14:39:09 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOAVHSAC9503XB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 14:38:58 +1000 Received: by localhost (Postfix, from userid 510) id 8CAEBAB543; Wed, 20 Jul 2005 14:38:57 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5A3E54FB0A; Wed, 20 Jul 2005 14:38:56 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00MVVSWQVI@mailout2.samsung.com>; Wed, 20 Jul 2005 13:38:50 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJW002EYSWINQ@mmp2.samsung.com>; Wed, 20 Jul 2005 13:38:50 +0900 (KST) Date: Wed, 20 Jul 2005 10:05:02 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, JinHyeock Choi Cc: Brett Pentland , James Kempf , Dna Message-id: <02c501c58ce4$69191210$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > >>CompleteRA and Prefix Landmarks also both work well even if they share > >>a link with RFC 2461 (non-DNA) routers. In either case, the DNA > >>router is able to answer questions about the prefixes in use by the > >>legacy routers (CompleteRA readvertises these in the DNAO, and a > >>Landmark query can be answered easily, regardless of the original > >>advertisor's DNA status). > >> > >>Prefix LinkIDs cannot agree easily with existing non-DNA routers on the > >>link's identity. > > > > > > It can. It will simply pick the smallest prefix. > > Except if the non-DNA routers do not have the smallest prefix > configured (which was my point). I think, this is not a problem in linkid scheme. Because hosts will not consider the RAs sent by non-DNA routers in finding the link change (if they are using linkid scheme). Such RAs will not contain linkid option. > > The RAs received from non-DNA routers aren't guaranteed to have > any prefixes in common with the DNA (LinkID) routers. > CompleteRA has this at potentially greater prefix advertisement cost. > > Greg > > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 00:44:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6RN-000714-Qd for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 00:44:23 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18631 for ; Wed, 20 Jul 2005 00:44:13 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUOH3CV7E9APFMO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 14:44:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1D88680012; Wed, 20 Jul 2005 14:43:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id CA6A43C00B; Wed, 20 Jul 2005 14:43:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K4hkR14505 for dna-list; Wed, 20 Jul 2005 14:43:46 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K4hkw14501 for ; Wed, 20 Jul 2005 14:43:46 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUOGIWZE699OWDN@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 14:43:31 +1000 Received: by localhost (Postfix, from userid 510) id E6800AB544; Wed, 20 Jul 2005 14:43:30 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id E49234FB09; Wed, 20 Jul 2005 14:43:26 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00MSET4DT9@mailout2.samsung.com>; Wed, 20 Jul 2005 13:43:25 +0900 (KST) Received: from Alperyegin ([105.253.155.13]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJW00KOJT4A7E@mmp2.samsung.com>; Wed, 20 Jul 2005 13:43:25 +0900 (KST) Date: Tue, 19 Jul 2005 21:43:17 -0700 From: Alper Yegin Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <92e919fb0507181814d7f98bf@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'JinHyeock Choi'" , "'Greg Daley'" Cc: dna@eng.monash.edu.au Message-id: <074901c58ce5$907e4180$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Hi JinHyeock, Here are couple of comments and questions on the FRD scheme... - "Triggered RA" has dependency on an additional protocol between the AP and AR. I see now that there are some discussions around that, stemming from the IEEE 802.21 work. I had a draft on such a protocol a while back (http://www.watersprings.org/pub/id/draft-yegin-l2-triggers-01.txt) FYI... - Have you analyzed what happens when you bypass the "random delay" mechanisms? They are there for congestion avoidance. Thanks, Alper > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of JinHyeock Choi > Sent: Monday, July 18, 2005 6:15 PM > To: Greg Daley > Cc: dna@eng.monash.edu.au > Subject: [DNA] Revised FRD (Fast Router Discovery) I-D > > Dear DNA WG > > We have updated FRD (Fast Router Discovery) I-D and submitted it. > > This draft presents a quick RA acquisition scheme with the support > of a link-layer entity, PoA (Point of Attachment). PoA is either > 802.11 AP or 802.16 BS. > > Upon a new network attachment, a PoA can either trigger a router > to immediately send an unicast RA ("RA Triggering") or deliver > such an RA for itself ("RA Proxying"). > > We may put 'RA Triggering' or 'RA Proxying' functionality on > a PoA to get the optimized result. > > Main changes from the previous versions are > - We expanded the result to other wireless-link technologies. > We added IEEE 802.16. part. > - We added RA Triggering part so the scheme doesn't depend > solely on "RA Caching" any longer. > - We incorporated the IEEE 802.21 (Media Independent Handover) > results to realize "RA Triggering" and "RA Proxying" > > The draft doesn't show up on the repository yet but is available at > > http://www.diffeo.com/drafts/draft-jinchoi-dna-frd-01.txt > > Your feedback will be appreciated. > > Thanks in advance for your kind consideration. > > Best Regards > > JinHyeock Choi > > p.s. > We implemented a scheme in 802.11 AP and measured DNA delay. > Roughly it takes 1-2 ms for a host to get an RA after L2 association > is made. More detailed report later. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 00:45:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6SX-0007I5-60 for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 00:45:29 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18727 for ; Wed, 20 Jul 2005 00:45:24 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOHD72CG94YM8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 14:44:56 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67BF7AB552; Wed, 20 Jul 2005 14:44:11 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id F065D4FB06; Wed, 20 Jul 2005 14:44:10 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K4i9114530 for dna-list; Wed, 20 Jul 2005 14:44:09 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K4i4w14526 for ; Wed, 20 Jul 2005 14:44:04 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUOH0AOY49APFMO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 14:43:54 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35F2880015; Wed, 20 Jul 2005 14:43:54 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 189193C013; Wed, 20 Jul 2005 14:43:54 +1000 (EST) Date: Wed, 20 Jul 2005 14:43:53 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <02c501c58ce4$69191210$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDD689.5030807@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Subba, Subba Reddy wrote: [cut] > > I think, this is not a problem in linkid scheme. Because hosts will not > consider the RAs > sent by non-DNA routers in finding the link change (if they are using linkid > scheme). > Such RAs will not contain linkid option. If the first RA received after link up is a non DNA router, false change detection will occur. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 00:49:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6Wk-00037v-UC for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 00:49:51 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19076 for ; Wed, 20 Jul 2005 00:49:46 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOM9VKZ294YM8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 14:49:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B168C80012; Wed, 20 Jul 2005 14:48:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 02D073C011; Wed, 20 Jul 2005 14:48:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K4luM14635 for dna-list; Wed, 20 Jul 2005 14:47:56 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K4lpw14630 for ; Wed, 20 Jul 2005 14:47:51 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOLP9NX894YM8B@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 14:47:41 +1000 Received: by localhost (Postfix, from userid 510) id 50011AB54C; Wed, 20 Jul 2005 14:47:41 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id 254C94FB0E; Wed, 20 Jul 2005 14:47:40 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00MX1T9VT9@mailout2.samsung.com>; Wed, 20 Jul 2005 13:46:43 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJW00LZTT9OFR@mmp1.samsung.com>; Wed, 20 Jul 2005 13:46:43 +0900 (KST) Date: Wed, 20 Jul 2005 10:12:56 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Message-id: <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > Subba Reddy wrote: > [cut] > > > > I think, this is not a problem in linkid scheme. Because hosts will not > > consider the RAs > > sent by non-DNA routers in finding the link change (if they are using linkid > > scheme). > > Such RAs will not contain linkid option. > > If the first RA received after link up is a non DNA router, > false change detection will occur. > Such RA will not contain linkid option. So host will not make any decision based on that RA (in linkid scheme). > Greg > > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 00:56:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6cq-0006OQ-V6 for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 00:56:09 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19927 for ; Wed, 20 Jul 2005 00:56:05 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOV4X52W94YM8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 14:55:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A292C8000D; Wed, 20 Jul 2005 14:55:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5D26E3C005; Wed, 20 Jul 2005 14:55:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K4snw14755 for dna-list; Wed, 20 Jul 2005 14:54:49 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K4siw14751 for ; Wed, 20 Jul 2005 14:54:44 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUOUCWBKW97LSWT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 14:54:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 12D72AB542; Wed, 20 Jul 2005 14:54:40 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id E9DE14FB02; Wed, 20 Jul 2005 14:54:39 +1000 (EST) Date: Wed, 20 Jul 2005 14:54:39 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDD90F.2090505@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Subba, These are some fairly fast exchanges, but may be getting somewhere... Please excuse my terseness. Subba Reddy wrote: > Hi Greg, > > >>Subba Reddy wrote: >>[cut] >> >>>I think, this is not a problem in linkid scheme. Because hosts will not >>>consider the RAs >>>sent by non-DNA routers in finding the link change (if they are using > > linkid > >>>scheme). >>>Such RAs will not contain linkid option. >> >>If the first RA received after link up is a non DNA router, >>false change detection will occur. >> > > > Such RA will not contain linkid option. So host will not make any decision > based on that RA (in linkid scheme). So how does LinkID work when transiting to networks with non-DNA routers? Does it rely on building CPL in the period where the host remained on the previous link? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 01:16:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6w2-0007Tv-Q4 for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 01:16:01 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22481 for ; Wed, 20 Jul 2005 01:15:56 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUPKMEQR899P0LW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 15:15:54 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 68347AB544; Wed, 20 Jul 2005 15:15:50 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1FA064FB04; Wed, 20 Jul 2005 15:15:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K5FEq15015 for dna-list; Wed, 20 Jul 2005 15:15:14 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K5F8w15011 for ; Wed, 20 Jul 2005 15:15:08 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUPJM0OUK99P6R2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 15:15:01 +1000 Received: by localhost (Postfix, from userid 510) id AB9888000F; Wed, 20 Jul 2005 15:15:01 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7A61D3C00C for ; Wed, 20 Jul 2005 15:14:54 +1000 (EST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD8E353E; Wed, 20 Jul 2005 07:14:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 07:14:50 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 07:14:49 +0200 Date: Wed, 20 Jul 2005 07:14:48 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised dna-link-info I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j6K5F9w15012 Content-type: text/plain; charset=iso-8859-1 Thread-Topic: [DNA] Revised dna-link-info I-D Thread-index: AcWMx+P8devHzIPrTWutsWpB5XaRRQAIVBnQ Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 20 Jul 2005 05:14:49.0922 (UTC) FILETIME=[F405DA20:01C58CE9] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA22481 Hi Alper, >Hi Tero, > >How about if we add one more sentence to the end of this paragraph: > > Among these two events the first one to take place after an interface > becomes enabled MUST be a link up event. During the time a network > interface is enabled, it may go through a series of link up and down > events. Each time the interface changes its point of attachment, a > link down event with the previous attachment point MUST be followed > by a link up event with the new one. Finally, when the network > interface is disabled, this MUST generate a link down event. Each > one of these events MUST generate a notification in the order they > occur. Note that, a link down notification MAY NOT be generated > if an optional tear-down protocol exchange or mechanism is skipped > prior to performing a handover. Yep, that's perfect. /Tero >Alper > > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: Tuesday, July 19, 2005 1:15 AM > To: Alper Yegin; dna@eng.monash.edu.au > Subject: RE: [DNA] Revised dna-link-info I-D >=20 > Hi Alper, >=20 > This has already been discussed on the mailing list, but I wanted to bring > it up again anyway. >=20 > I feel that it's worth noting in the draft (maybe in Section 2.: "Among > these two event the first one...) that certain link technologies (I only > know of 802.11) don't necessarily produce a link-down event prior a link- > up event when the node re-associates with a new AP. If such a link-down > event is desirable, it must be generated from the host's stack because I > don't think it is realistic to assume that already existing hardware will > be updated to produce such events. >=20 > -- > Tero >=20 > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of Alper Yegin > Sent: 18. hein=E4kuuta 2005 22:03 > To: dna@eng.monash.edu.au > Subject: [DNA] Revised dna-link-info I-D >=20 >=20 > Folks, >=20 > I've had submitted the revised version of the dna-link-info I-D 10 days > ago, but it hasn't showed up on the IETF repository yet. For that, > please see a copy of the I-D at the following location: >=20 > http://yegin.org/IETF/draft-ietf-dna-link-information-02.txt >=20 > The major changes in this revision include: >=20 > - New text for IEEE 802.3. > - Handling multiple 3GPP PDP Contexts. >=20 > I'd like to take your attention to the changes we needed to make in > order to accommodate nondeterministic L2 events on Ethernet (e.g., link > is up but the host the network may block data transmission). Please read > Section 2 and the entire 2.4 to see the details. >=20 > Please review and comment before the Paris meeting. >=20 > Alper >=20 >=20 From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 01:38:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7Hu-0001me-OK for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 01:38:36 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24837 for ; Wed, 20 Jul 2005 01:38:32 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUQCDN7YY94ZSAX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 15:37:55 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3FE568000E; Wed, 20 Jul 2005 15:37:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DBA293C003; Wed, 20 Jul 2005 15:37:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K5asM15300 for dna-list; Wed, 20 Jul 2005 15:36:54 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K5aqw15296 for ; Wed, 20 Jul 2005 15:36:52 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUQBHH6QM97LOD4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 15:36:45 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 064E9AB543; Wed, 20 Jul 2005 15:36:43 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id CD5194FB02; Wed, 20 Jul 2005 15:36:42 +1000 (EST) Date: Wed, 20 Jul 2005 15:36:42 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <42DDE2EA.9000100@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> <42DC405F.5040501@eng.monash.edu.au> <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT >>Yes, if that covered all cases it would be simpler not to need RSs, but >>there is no guarantee that there will be any unsolicited RAs from the >>other routers on the link before the 15 sec expiry. If that doesn't >>happen, then the router will start behaving as a full DNA router before >>it has complete information and may thus answser requests incorrectly. >> > > > I assume you are thinking of nonDNA routers, because if we specify something > from DNA routers, then there will be a high probability that something will > come through, since the retransmits should ensure it in the face of drops, > right? Sorry, I guess I didn't explain the scenario I was thinking of well enough. If a DNA router bootstraps on a link that already has fully bootstrapped DNA routers on it, there is no guarantee that the existing routers will send any RAs during the new router's bootstrap period. Unsolicited RAs might be minutes apart. The only way that they can tell that there is a new router is by the RAs it sends. I guess we could use those to trigger the sending of RAs, but the existing router discovery method for soliciting RAs is with an RS. Does that make sense? Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 01:55:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7YT-0007cT-Iw for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 01:55:41 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26603 for ; Wed, 20 Jul 2005 01:55:39 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUQXX1ZA297ITOY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 15:55:11 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D0E3AB54B; Wed, 20 Jul 2005 15:54:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A46844FB09; Wed, 20 Jul 2005 15:54:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K5s4915611 for dna-list; Wed, 20 Jul 2005 15:54:04 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K5s3w15602 for ; Wed, 20 Jul 2005 15:54:03 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUQWYF4AW99OUZ3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 15:54:01 +1000 Received: by localhost (Postfix, from userid 510) id AC78AAB54C; Wed, 20 Jul 2005 15:54:01 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id AB7654FB06; Wed, 20 Jul 2005 15:54:00 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW00MB9WDXT9@mailout2.samsung.com>; Wed, 20 Jul 2005 14:53:57 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJW00K6OWDR7L@mmp1.samsung.com>; Wed, 20 Jul 2005 14:53:57 +0900 (KST) Date: Wed, 20 Jul 2005 11:20:10 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Message-id: <02f001c58cee$e7fd4f10$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> <42DDD90F.2090505@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > > These are some fairly fast exchanges, but may be getting somewhere... > Please excuse my terseness. I can understand. No problem. > > Subba Reddy wrote: > > Hi Greg, > > > > > >>Subba Reddy wrote: > >>[cut] > >> > >>>I think, this is not a problem in linkid scheme. Because hosts will not > >>>consider the RAs > >>>sent by non-DNA routers in finding the link change (if they are using > > > > linkid > > > >>>scheme). > >>>Such RAs will not contain linkid option. > >> > >>If the first RA received after link up is a non DNA router, > >>false change detection will occur. > >> > > > > > > Such RA will not contain linkid option. So host will not make any decision > > based on that RA (in linkid scheme). > > So how does LinkID work when transiting to networks with non-DNA > routers? Does it rely on building CPL in the period where > the host remained on the previous link? > Yes. Section 4.2 of the linkid draft (version 00/01) says "... After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no RA with a linkid prefix arrives, the host assumes it is at a non DNA link and falls back on CPL [9]. ..." > Greg > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 01:55:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7YU-0007ez-Jv for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 01:55:42 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26602 for ; Wed, 20 Jul 2005 01:55:37 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUQXQPK2I97L7UZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 15:54:58 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A7F60AB542; Wed, 20 Jul 2005 15:54:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5966F4FB0A; Wed, 20 Jul 2005 15:54:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K5rXj15591 for dna-list; Wed, 20 Jul 2005 15:53:33 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K5rWw15587 for ; Wed, 20 Jul 2005 15:53:32 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUQW1LB6U97L7UZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 15:53:18 +1000 Received: by localhost (Postfix, from userid 510) id 81DFF8000D; Wed, 20 Jul 2005 15:53:17 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by larry.its.monash.edu.au (Postfix) with ESMTP id BACA93C005 for ; Wed, 20 Jul 2005 15:53:16 +1000 (EST) Received: by zproxy.gmail.com with SMTP id p8so1336471nzb for ; Tue, 19 Jul 2005 22:53:15 -0700 (PDT) Received: by 10.36.60.13 with SMTP id i13mr374803nza; Tue, 19 Jul 2005 22:52:45 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Tue, 19 Jul 2005 22:52:45 -0700 (PDT) Date: Wed, 20 Jul 2005 14:52:45 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05071922521eaebcd3@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D3v9dQgkXYVZMdWqg9WctxshjRCQezf1zgVn3kgvm1ssiELWpQG9Hvf3qDAaUOLzZM9FhSLUUhn46feWxunDSXJoV9FWby5lOhwEroiLjtuFQCAWUnk+Rio1lToUOzWIw7rP4C8a+jh5IocSLa62QC6ukgU21CfbNjQwAMQrvV8= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Tero > I also started wondering how the solution works with SEND and especially > when the timestamp and nonce options are present. > > In addition what if the router(s) is/are configured to send RAs > relatively seldom, say once every 60 minutes, would it be required that > the PoA decreases prefix lifetimes in the cached entries? Just > wondering... Good point. This is tricky part but, we think, isn't insurmountable. Our line of thoughts are as below. First, we checked with people who run IPv6 router and heard that usually RA information is static. Once configured, the same RA is sent over and over again. Usually RA doens't change its information. So I think for the most case the scheme is ok. Second, for the case RA having a kind of timer value, we can use the following trick. PoA may keep checking the validity of the cached RA and before timer expires, send an RS to refresh the cached RA. But this seems complicated and the simplest & safest solution may be to establish a kind of secure path between AR and PoA wish a kind of scheme described in MICS section. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 01:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7bq-0002ZT-5X for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 01:59:14 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26815 for ; Wed, 20 Jul 2005 01:59:08 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUR0NHCV099OZQP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 15:57:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 70EE7AB544; Wed, 20 Jul 2005 15:57:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D99294FB07; Wed, 20 Jul 2005 15:56:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K5uq615677 for dna-list; Wed, 20 Jul 2005 15:56:52 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K5uqw15670 for ; Wed, 20 Jul 2005 15:56:52 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR04740U97LO3J@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 15:56:35 +1000 Received: by localhost (Postfix, from userid 510) id 8775680012; Wed, 20 Jul 2005 15:56:34 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by larry.its.monash.edu.au (Postfix) with ESMTP id AA9563C012; Wed, 20 Jul 2005 15:56:28 +1000 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6DBD7CA7; Wed, 20 Jul 2005 07:56:27 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 07:56:26 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 07:56:26 +0200 Date: Wed, 20 Jul 2005 07:56:25 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised FRD (Fast Router Discovery) I-D Thread-index: AcWM2FH0o1GSG95XQtGFN7NJ1L6OlwAE6Hjw Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 20 Jul 2005 05:56:26.0416 (UTC) FILETIME=[C40C9B00:01C58CEF] Content-Transfer-Encoding: 7BIT Hello JinHyeock, Thanks for the answers. There is an additional question below. >I assume your question concern mostly about RA Proxying with >Scanning. Am I right? Correct. > > Just a couple of quick questions... > > > > Should entries in the cache suppose to have the lifetime stated in an > > RA? > > No. We don't think it's desirable for PoA to modify an RA, unless > it gets permission from AR. Ok. I was just thinking how long PoA should keep an entry in the cache. Unlike it the second mail sent later, at this point I was not wondering should the lifetime in the cached entry also be decreased. > > > I guess PoA uses sending router's source address to index entries in the > > cache, i.e. if a router sends an updated RA, PoA finds the old entry by > > using the source address (or source link layer address in the option > > field). > > Right now, we design the scheme in the simplest way and PoA doesn't > manage index entries. > > Assume there are two routers on a link, AR1 and AR2. First AR1 > sends RA1 and PoA caches it. Afterwards AR2 sends RA2, then > PoA substitutes its cached RA with RA2. This doesn't affect DNA > performance as long as both RA1 and RA2 can properly indicate > link identity, i.e. RA optimized for DNA. Oh, I see. There is only one cached entry instead of multiple entries (i.e. RAs from different APs). /Tero From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 02:03:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7gS-00055o-3i for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 02:03:56 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00884 for ; Wed, 20 Jul 2005 02:03:54 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR7XAH7G9507QX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 16:03:12 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10FF8AB54C; Wed, 20 Jul 2005 16:02:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C3EB54FB04; Wed, 20 Jul 2005 16:02:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K62o415820 for dna-list; Wed, 20 Jul 2005 16:02:50 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K62ow15816 for ; Wed, 20 Jul 2005 16:02:50 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR7HGW3697L4D2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 16:02:33 +1000 Received: by localhost (Postfix, from userid 510) id D5D38AB54A; Wed, 20 Jul 2005 16:02:30 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id CC2564FB03; Wed, 20 Jul 2005 16:02:29 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJW007CJWQMIH@mailout3.samsung.com>; Wed, 20 Jul 2005 15:01:34 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJW002XFWQJNQ@mmp2.samsung.com>; Wed, 20 Jul 2005 15:01:34 +0900 (KST) Date: Wed, 20 Jul 2005 11:27:51 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, Subba Reddy Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Message-id: <065d01c58cef$f8a03b10$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> <42DDD90F.2090505@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Greg Daley" To: "Subba Reddy" Cc: "JinHyeock Choi" ; "Brett Pentland" ; "James Kempf" ; "Dna" Sent: Wednesday, July 20, 2005 10:24 AM Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Hi Subba, > > These are some fairly fast exchanges, but may be getting somewhere... > Please excuse my terseness. > > Subba Reddy wrote: >> Hi Greg, >> >> >>>Subba Reddy wrote: >>>[cut] >>> >>>>I think, this is not a problem in linkid scheme. Because hosts will not >>>>consider the RAs >>>>sent by non-DNA routers in finding the link change (if they are using >> >> linkid >> >>>>scheme). >>>>Such RAs will not contain linkid option. >>> >>>If the first RA received after link up is a non DNA router, >>>false change detection will occur. >>> >> >> >> Such RA will not contain linkid option. So host will not make any >> decision >> based on that RA (in linkid scheme). > > So how does LinkID work when transiting to networks with non-DNA > routers? Does it rely on building CPL in the period where > the host remained on the previous link? Yes, it has to fall back to CPL if it is a non-DNA link without any DNA routers. I think this is also true with the Landmark approach. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 02:03:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7gV-0005BE-7S for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 02:03:59 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00844 for ; Wed, 20 Jul 2005 02:03:51 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR71LCA897M3HB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 16:02:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 785318000F; Wed, 20 Jul 2005 16:02:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 291403C012; Wed, 20 Jul 2005 16:02:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K61ts15768 for dna-list; Wed, 20 Jul 2005 16:01:55 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K61tw15764 for ; Wed, 20 Jul 2005 16:01:55 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR6COUGO97M3HB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 16:01:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0B79DAB543; Wed, 20 Jul 2005 16:01:36 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id E19DD4FB02; Wed, 20 Jul 2005 16:01:35 +1000 (EST) Date: Wed, 20 Jul 2005 16:01:35 +1000 From: Greg Daley Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: JinHyeock Choi , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDE8BF.7010404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 7BIT Hi Tero, Tero Kauppinen (JO/LMF) wrote: > Hi again, > > I also started wondering how the solution works with SEND and especially > when the timestamp and nonce options are present. > > In addition what if the router(s) is/are configured to send RAs > relatively seldom, say once every 60 minutes, would it be required that > the PoA decreases prefix lifetimes in the cached entries? Just > wondering... I've done an analysis on this (which may yet have flaws) and there are some tricky issues with the caching and SEND. With SEND, the options cannot be modified by an intervening device (as it doesn't have the CGA private key), so all RA contents remain the same, including lifetime and SEND Timestamp options. With the existing SEND specification, differences in clocks between a host and a router are accounted for by allowing the first RA to arrive with an allowed window. This defaults to +-300 seconds (from section 5.3.4.2/10.2 of RFC3971). Therefore the cache cannot last beyond 5 minutes (without even accounting for different clocks) by default. The Receiver's timelog - RDlast (and the received timestamp TSlast) of the first RA message are then stored for comparison, and new RAs are tested against the following inequality (the newly received timestamp option containing TSnew, and the reception time on the host being RDnew), only those new RAs conforming to the following inequality are acceptable as fresh SEND RAs (sec 5.4.3.2): TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz The drift and fuzz factors being defined as the maximum rate of clock drift, and the maximum (absolute) value variation in reception of individual packets across a link, respectively. Using the defaults from section 10.2 (in seconds): TSnew - TSlast > 0.99x(RDnew - RDlast) - 2 Upon the first reception of a non-cached RA (after the cached RA), TSnew - TSlast will be greater than RDnew - RDlast, since (assuming minimal clock skew over the period): RDnew - RDlast = delta_t TSnew - TSlast = delta_t + t_cache This then is an accepted RA, as the inequality holds. Such an RA updates the RDlast and TSlast timers with the fresh RA's information (as described in 5.3.4.2 of SEND). Where either the first received RA was non-cached, and had an up-to-date timestamp, or a later uncached RA updated the RDlast and TSlast parameters as described above, the situation is not as clear cut. Any subsequently received cached RA will be delayed by t_cache'. Therefore, in this case: RDnew' - RDlast' = delta_t' TSnew' - TSlast' = delta_t' - t_cache' Using the inequality above (again assuming no significant skew) delta_t' - t_cache' > 0.99 x delta_t' -2 which implies: t_cache' <= 0.01 x delta_t' + 2 So the cache time has to be less than 2 seconds plus 1% of the interval between received RAs in order to be accepted as a fresh RA by the SEND host. This affects subsequent RA reception when transiting to the new PoAs within the same link. It also affects the return of a node to a previously visited link for which it has previously received SEND messages (with parameters and Timestamps). As described in sections 5.3.4, 9.2.5 (and Appendix B) of SEND, hosts are likely to keep such information beyond the lifetime of a particular neighbour cache entry in order to prevent replay attacks. So long as the SEND timer information is kept, return to a link will ignore a Cached RA (if the cache duration is outside the boundaries of the skew and fuzz factors for SEND). I'm still not quite sure about this analysis, so I'd appreciate feedback on the issue. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 02:04:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7gb-0005If-GV for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 02:04:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01060 for ; Wed, 20 Jul 2005 02:04:03 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUR7FFXAM97L4D2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 16:03:32 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 421C2AB545; Wed, 20 Jul 2005 16:02:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E988F4FB07; Wed, 20 Jul 2005 16:02:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K62Qr15800 for dna-list; Wed, 20 Jul 2005 16:02:26 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K62Pw15793 for ; Wed, 20 Jul 2005 16:02:26 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQUR7BOW2K9AOWXD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 16:02:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4015480012; Wed, 20 Jul 2005 16:02:23 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0B4433C016; Wed, 20 Jul 2005 16:02:22 +1000 (EST) Date: Wed, 20 Jul 2005 16:02:22 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <02f001c58cee$e7fd4f10$39476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: JinHyeock Choi , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDE8EE.3070907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> <42DDD90F.2090505@eng.monash.edu.au> <02f001c58cee$e7fd4f10$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Subba, Subba Reddy wrote: [cut] >> >>So how does LinkID work when transiting to networks with non-DNA >>routers? Does it rely on building CPL in the period where >>the host remained on the previous link? >> > > > Yes. > > Section 4.2 of the linkid draft (version 00/01) says > > "... > After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no > RA with a linkid prefix arrives, the host assumes it is at a non DNA > link and falls back on CPL [9]. > ..." > Thanks, Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 02:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7kO-0006gA-88 for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 02:08:00 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04813 for ; Wed, 20 Jul 2005 02:07:53 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQURDJ596G99OW15@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 16:07:29 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5D244AB544; Wed, 20 Jul 2005 16:07:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1AB804FB04; Wed, 20 Jul 2005 16:07:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K67CF15916 for dna-list; Wed, 20 Jul 2005 16:07:12 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K67Cw15912 for ; Wed, 20 Jul 2005 16:07:12 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQURD14SO297LO3J@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 16:06:59 +1000 Received: by localhost (Postfix, from userid 510) id 541888000F; Wed, 20 Jul 2005 16:06:59 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by larry.its.monash.edu.au (Postfix) with ESMTP id 598633C012; Wed, 20 Jul 2005 16:06:53 +1000 (EST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CAB6CBE; Wed, 20 Jul 2005 08:06:52 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 08:06:51 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 08:06:50 +0200 Date: Wed, 20 Jul 2005 08:06:50 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised FRD (Fast Router Discovery) I-D Thread-index: AcWM8IRd0/B7GNABSo2dA3mAnJrdpwAADxUQ Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 20 Jul 2005 06:06:50.0620 (UTC) FILETIME=[381A93C0:01C58CF1] Content-Transfer-Encoding: 7BIT Hi Greg, > Hi Tero, > > Tero Kauppinen (JO/LMF) wrote: > > Hi again, > > > > I also started wondering how the solution works with SEND and especially > > when the timestamp and nonce options are present. > > > > In addition what if the router(s) is/are configured to send RAs > > relatively seldom, say once every 60 minutes, would it be required that > > the PoA decreases prefix lifetimes in the cached entries? Just > > wondering... > > > I've done an analysis on this (which may yet have flaws) and there > are some tricky issues with the caching and SEND. > > With SEND, the options cannot be modified by an intervening device > (as it doesn't have the CGA private key), so all RA contents remain > the same, including lifetime and SEND Timestamp options. True. The later question was actually meant for the case when SEND is not applied / available. I should have stated that in the sentence, though. :( Thanks for the detailed description. Tero > > With the existing SEND specification, differences in clocks between > a host and a router are accounted for by allowing the first RA > to arrive with an allowed window. This defaults to +-300 seconds > (from section 5.3.4.2/10.2 of RFC3971). > > Therefore the cache cannot last beyond 5 minutes (without even > accounting for different clocks) by default. > > The Receiver's timelog - RDlast (and the received timestamp TSlast) of > the first RA message are then stored for comparison, and new RAs > are tested against the following inequality (the newly received > timestamp option containing TSnew, and the reception time on the > host being RDnew), only those new RAs conforming to the following > inequality are acceptable as fresh SEND RAs (sec 5.4.3.2): > > > TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz > > > The drift and fuzz factors being defined as the maximum rate of > clock drift, and the maximum (absolute) value variation in > reception of individual packets across a link, respectively. > > Using the defaults from section 10.2 (in seconds): > > TSnew - TSlast > 0.99x(RDnew - RDlast) - 2 > > Upon the first reception of a non-cached RA (after the cached RA), > TSnew - TSlast will be greater than RDnew - RDlast, since > (assuming minimal clock skew over the period): > > RDnew - RDlast = delta_t > TSnew - TSlast = delta_t + t_cache > > This then is an accepted RA, as the inequality holds. Such an RA > updates the RDlast and TSlast timers with the fresh RA's information > (as described in 5.3.4.2 of SEND). > > Where either the first received RA was non-cached, and had an up-to-date > timestamp, or a later uncached RA updated the RDlast and TSlast > parameters as described above, the situation is not as clear cut. > > Any subsequently received cached RA will be delayed by t_cache'. > > Therefore, in this case: > > RDnew' - RDlast' = delta_t' > TSnew' - TSlast' = delta_t' - t_cache' > > Using the inequality above (again assuming no significant skew) > > delta_t' - t_cache' > 0.99 x delta_t' -2 > > which implies: > > t_cache' <= 0.01 x delta_t' + 2 > > So the cache time has to be less than 2 seconds plus 1% of the > interval between received RAs in order to be accepted as a fresh > RA by the SEND host. > > This affects subsequent RA reception when transiting to the > new PoAs within the same link. > > It also affects the return of a node to a previously visited > link for which it has previously received SEND messages > (with parameters and Timestamps). As described in sections > 5.3.4, 9.2.5 (and Appendix B) of SEND, hosts are likely to > keep such information beyond the lifetime of a particular > neighbour cache entry in order to prevent replay attacks. > > So long as the SEND timer information is kept, return to > a link will ignore a Cached RA (if the cache duration is > outside the boundaries of the skew and fuzz factors for SEND). > > I'm still not quite sure about this analysis, so I'd appreciate > feedback on the issue. > > Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 02:12:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7oT-0001cl-NO for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 02:12:15 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08965 for ; Wed, 20 Jul 2005 02:12:11 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQURIS3EA299OZ7R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 16:11:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57D0BAB546; Wed, 20 Jul 2005 16:11:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id F279A4FB07; Wed, 20 Jul 2005 16:11:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K6BPG15993 for dna-list; Wed, 20 Jul 2005 16:11:25 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K6BJw15987 for ; Wed, 20 Jul 2005 16:11:20 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQURI20UXY99P6IU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 16:11:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5271AAB542; Wed, 20 Jul 2005 16:11:02 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2DCC44FB0D; Wed, 20 Jul 2005 16:11:02 +1000 (EST) Date: Wed, 20 Jul 2005 16:11:01 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <065d01c58cef$f8a03b10$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Subba Reddy , JinHyeock Choi , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DDEAF5.2070208@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <02c501c58ce4$69191210$39476c6b@sisodomain.com> <42DDD689.5030807@eng.monash.edu.au> <02df01c58ce5$835f7dc0$39476c6b@sisodomain.com> <42DDD90F.2090505@eng.monash.edu.au> <065d01c58cef$f8a03b10$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: [cut] > > > Yes, it has to fall back to CPL if it is a non-DNA link without > any DNA routers. I think this is also true with the Landmark > approach. But only if the original landmark system didn't include a CompleteRA, which was the point of my comparison. (I've been mainly been comparing CompleteRA and LinkID because of their similar properties). Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 03:47:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9Ix-0006HY-HN for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 03:47:47 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13344 for ; Wed, 20 Jul 2005 03:47:45 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUU2VTLQI97H435@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 17:25:10 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E2307AB54E; Wed, 20 Jul 2005 17:24:18 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 930E24FB06; Wed, 20 Jul 2005 17:24:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K7NII16907 for dna-list; Wed, 20 Jul 2005 17:23:18 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K7NIw16903 for ; Wed, 20 Jul 2005 17:23:18 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUU18L3RC94ZESA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 17:23:00 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5AF12AB54A; Wed, 20 Jul 2005 17:22:59 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 2E3664FB11; Wed, 20 Jul 2005 17:22:59 +1000 (EST) Date: Wed, 20 Jul 2005 17:22:58 +1000 From: Brett Pentland Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <92e919fb0507191914308de355@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , dna@eng.monash.edu.au Message-id: <42DDFBD2.1000602@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> <92e919fb0507191914308de355@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, >>For RA Proxying you have a new option for getting the cached RA, >>but what do you do if there's more than one router on the link? >>Should the PoA cache and forward multiple RAs? If not, then the >>host may have incomplete information. It may not have all of the >>prefixes available on the link, and it won't have a complete list >>of potential default routers. To get this additional information >>it will need to send an RS in order to receive the RAs from all >>of the routers on the link. You end up adding an RA to the overall >>process though admittedly you get that first RA very quickly. > > > I don't understand your point. DNA solution is supposed to do > its job with a single RA message. Allow me to quote from DNA > design team document, > > It was felt that by crafting the > information in the solicitation and advertisement, a single RS/RA > exchange should be sufficient for DNA. > > So in DNA point of view, I see no problem sending just one RA > (optimized for DNA). You've answered my question in your email to Tero - only the most recent RA is cached (and it will change frequently if there are multiple routers on the link). You are right that DNA only needs a single RA, and a decision about configuration can be made immediately after that RA, but router discovery may require more than that. Section 6.3.7 of RFC 2461 notes that unsolicited RAs may be incomplete and that upon reception of one before having sent an RS, that the host SHOULD send an RS. Thus we end up with an RS and its associated RAs, plus the additional original unsolicited RA. This doesn't affect the speed of DNA but does add to the total packet exchange. Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 04:36:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvA48-0004pN-8b for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 04:36:32 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19104 for ; Wed, 20 Jul 2005 04:36:29 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUWK9YVV497MAGH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 18:35:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1AB5AAB54B; Wed, 20 Jul 2005 18:35:36 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9D70B4FB02; Wed, 20 Jul 2005 18:35:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6K8YvP17794 for dna-list; Wed, 20 Jul 2005 18:34:57 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6K8Yuw17789 for ; Wed, 20 Jul 2005 18:34:56 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQUWJ3STRE94ZYBY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 18:34:40 +1000 Received: by localhost (Postfix, from userid 510) id A4455AB542; Wed, 20 Jul 2005 18:34:39 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by curly.its.monash.edu.au (Postfix) with ESMTP id 072C84FB09; Wed, 20 Jul 2005 18:34:34 +1000 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B84B4F0004; Wed, 20 Jul 2005 10:34:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 10:34:31 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 10:34:31 +0200 Date: Wed, 20 Jul 2005 10:34:30 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Revised FRD (Fast Router Discovery) I-D Thread-index: AcWM8IRd0/B7GNABSo2dA3mAnJrdpwAFFgYw Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 20 Jul 2005 08:34:31.0387 (UTC) FILETIME=[D98852B0:01C58D05] Content-Transfer-Encoding: 7BIT > > I also started wondering how the solution works with SEND and especially > > when the timestamp and nonce options are present. I think it would be worth mentioning somewhere, maybe along with the sentence: "the PoA needs to cache a suitable RA, such as 'RA optimized for DNA' defined in [5]." that RAs with the SEND nonce option can't be cached while the ones with timestamps can be cached only for a certain duration of time. Greg seems to have an idea about a proper duration. /Tero From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 09:51:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvEzI-0007Q1-FM for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 09:51:52 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16163 for ; Wed, 20 Jul 2005 09:51:49 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQV7K60HRG99P8KK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 20 Jul 2005 23:51:05 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F741AB54B; Wed, 20 Jul 2005 23:50:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id EB0C94FB04; Wed, 20 Jul 2005 23:50:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6KDnsR21520 for dna-list; Wed, 20 Jul 2005 23:49:54 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6KDnqw21516 for ; Wed, 20 Jul 2005 23:49:52 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQV7IMWPL299P8KK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 20 Jul 2005 23:49:38 +1000 Received: by localhost (Postfix, from userid 510) id 40F8BAB542; Wed, 20 Jul 2005 23:49:38 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 602B94FB04; Wed, 20 Jul 2005 23:49:36 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6KDnVr3025266; Wed, 20 Jul 2005 07:49:32 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6KDnOWB157450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Jul 2005 06:49:28 -0700 (PDT) Date: Wed, 20 Jul 2005 03:59:51 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <42DD80DA.5060409@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , James Kempf , Dna Message-id: <42DE2EA7.3010305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DCB6C7.2000506@sun.com> <42DD80DA.5060409@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: >> We should clarify that such landmark options are a no-op, i.e. that >> they don't change any state on the receiver (since they have no >> semantic value). > > > Yes, and then also tell routers not to send them. > > Is that the agreement? Works for me. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 13:47:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIfj-00024F-RT for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 13:47:56 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15049 for ; Wed, 20 Jul 2005 13:47:52 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVFTH5XJ699P361@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 03:47:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BADC7AB543; Thu, 21 Jul 2005 03:47:25 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 738544FB03; Thu, 21 Jul 2005 03:47:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6KHknB24354 for dna-list; Thu, 21 Jul 2005 03:46:49 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6KHklw24350 for ; Thu, 21 Jul 2005 03:46:47 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVFSM05TW9APHHS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 03:46:44 +1000 Received: by localhost (Postfix, from userid 510) id 83FF1AB543; Thu, 21 Jul 2005 03:46:44 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 03EF44FB06; Thu, 21 Jul 2005 03:46:42 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6KHkPLM013705; Wed, 20 Jul 2005 13:46:25 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 252A51E81B6; Wed, 20 Jul 2005 13:37:10 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 154821E819C; Wed, 20 Jul 2005 13:37:10 -0400 (EDT) Date: Wed, 20 Jul 2005 13:45:59 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix In-reply-to: <060c01c58cdd$0bdc5fa0$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Syam Madanapalli , JinHyeock Choi , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <42DE8DD7.1070406@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <42DD4A58.80003@Research.Panasonic.COM> <060c01c58cdd$0bdc5fa0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam - Even though I still feel that the synchronization requirement for the LinkID scheme is stronger, I will concede that the difference is not very high. So, in conclusion, the synchronization requirement and complexity for Landmark, CompleteRA and LinkID are the same - all three of them require that all the routers on the link know about all the prefixes on the link within a reasonable time - the difference is only in the content of the RS/RA messages. Do you agree? - Sathya > Hi Sathya, > >>> >>> >>>> As I mentioned in the earlier >>>> email, LinkID requires the synchronization of the complete list of >>>> prefixes so that it can choose the least prefix - but LinkID needs >>>> additional synchronization among the routers as to when they chose the >>>> LinkID. >>>> >>>> >>>> >>> To the extent of my knowledge even Landmark method requires the >>> synchronization among routers, otherwise one router may say 'no' >>> and other may say 'yes' for the landmark question. >>> >>> >> Yes - I am sorry I wasn't clear - LinkID, CompleteRA and Landmark >> require the synchronization of the complete list of prefixes by the >> routers - but LinkID MAY need additional synchronization in terms of the >> timing when the LinkID is chosen at each routers. What I mean is that, a >> clear indication that the complete list is collected is needed in the >> LinkID case before the routers can chose the LinkID, while in Landmark >> and CompleteRA - 'as far as I know' these are the prefixes will work >> reasonably well at each router, even when the complete list is a little >> bit off. Some hosts may get conflicting answers with Landmark, but if >> two routers chose different LinkIDs all the hosts in the link will >> receive RA messages with two different LinkIDs and keep changing >> configuration until the synchronization is complete - i.e. the >> synchronization requirement is stronger in the case of LinkID, IMHO. > > > This is incorrect. The linkid works perfectly with the scenario you > described. > In the linkid, the host maintains the list of previous linkids which > will be used > to check if any of one of these was a linkid on the link. So change in > linkid > does not mean that the host requires reconfiguration. > > My current understanding is that the landmark need to synchronize all the > time. > > Also linkid does not really require the synchronization all the time > if router > agree to have same linkid as long as possible. e.g. Router can pick one > with longer valid life time and can continue to have the same linkid > till the > life time expires. If the prefix lifetime is not renewed then router > can start > synchronization to select new linkid. > > However, I am not saying the linkid is the only perfect solution, > rather we > may need to define criteria for the evaluation and then compare the two > schemes against the defined criteria and we need to pick the best > solution. > > - Syam > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 15:52:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKcj-0007Ls-DF for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 15:52:57 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25823 for ; Wed, 20 Jul 2005 15:52:54 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVK74V9TI99NUGD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 05:52:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 364738000F; Thu, 21 Jul 2005 05:52:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E5DCE3C003; Thu, 21 Jul 2005 05:52:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6KJpdE26020 for dna-list; Thu, 21 Jul 2005 05:51:39 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6KJpdw26016 for ; Thu, 21 Jul 2005 05:51:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVK6C5IU499P88E@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 05:51:33 +1000 Received: by localhost (Postfix, from userid 510) id B9E81AB543; Thu, 21 Jul 2005 05:51:33 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id F15CB4FB03; Thu, 21 Jul 2005 05:51:31 +1000 (EST) Date: Wed, 20 Jul 2005 12:51:27 -0700 From: James Kempf Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <023401c58d64$6a5b9500$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> <42DC405F.5040501@eng.monash.edu.au> <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> <42DDE2EA.9000100@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > Sorry, I guess I didn't explain the scenario I was thinking of well > enough. If a DNA router bootstraps on a link that already has fully > bootstrapped DNA routers on it, there is no guarantee that the existing > routers will send any RAs during the new router's bootstrap period. > Unsolicited RAs might be minutes apart. The only way that they can tell > that there is a new router is by the RAs it sends. I guess we could use > those to trigger the sending of RAs, but the existing router discovery > method for soliciting RAs is with an RS. > What I am specifically concerned about is that hosts can disrupt the bootstrap by sending too many RSs. The bootstrapping router or routers are going to have to multicast retransmit RSs to All_Routers_Multicast anyway to account for drops, in order to exchange information among themselves. If lots of hosts start multicasting RSs also, it could push the routers' token bucket algorithm into the multicast region. Note that this can even happen without intent (i.e. not as a result of a DoS attack) during a full link bootstrap. Do you think there might be some way to overcome this problem using RSs to solicit? jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 20:08:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvOby-0007mb-Ry for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 20:08:26 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17585 for ; Wed, 20 Jul 2005 20:08:22 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVT3RZUSQ99PDK9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 10:07:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1E60CAB545; Thu, 21 Jul 2005 10:07:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D48144FB0B; Thu, 21 Jul 2005 10:07:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L06nC28947 for dna-list; Thu, 21 Jul 2005 10:06:49 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L06lw28943 for ; Thu, 21 Jul 2005 10:06:47 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVT2MRQBM99PDK9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 10:06:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C24198000D; Thu, 21 Jul 2005 10:06:39 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 993193C00D; Thu, 21 Jul 2005 10:06:39 +1000 (EST) Date: Thu, 21 Jul 2005 10:06:39 +1000 From: Brett Pentland Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <023401c58d64$6a5b9500$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Erik Nordmark , Dna Message-id: <42DEE70F.10208@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> <42DC405F.5040501@eng.monash.edu.au> <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> <42DDE2EA.9000100@eng.monash.edu.au> <023401c58d64$6a5b9500$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: >>Sorry, I guess I didn't explain the scenario I was thinking of well >>enough. If a DNA router bootstraps on a link that already has fully >>bootstrapped DNA routers on it, there is no guarantee that the existing >>routers will send any RAs during the new router's bootstrap period. >>Unsolicited RAs might be minutes apart. The only way that they can tell >>that there is a new router is by the RAs it sends. I guess we could use >>those to trigger the sending of RAs, but the existing router discovery >>method for soliciting RAs is with an RS. >> > > > What I am specifically concerned about is that hosts can disrupt the > bootstrap by sending too many RSs. The bootstrapping router or routers are > going to have to multicast retransmit RSs to All_Routers_Multicast anyway to > account for drops, in order to exchange information among themselves. If > lots of hosts start multicasting RSs also, it could push the routers' token > bucket algorithm into the multicast region. Note that this can even happen > without intent (i.e. not as a result of a DoS attack) during a full link > bootstrap. > > Do you think there might be some way to overcome this problem using RSs to > solicit? I don't think it's actually a problem. In that case there's a large number of RSs - enough to exhaust the token buckets in the bootstrapped routers - and they fall back to multicasting RAs which will be scheduled for within 3 seconds. The end result is that the bootstrapping router receives the RAs during its bootstrapping period. Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 20 21:20:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPjc-000455-BZ for dna-archive@megatron.ietf.org; Wed, 20 Jul 2005 21:20:24 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22651 for ; Wed, 20 Jul 2005 21:20:21 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVVMDQA1S9APHW0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 11:19:59 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 539ABAB543; Thu, 21 Jul 2005 11:19:50 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id F108D4FB04; Thu, 21 Jul 2005 11:19:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L1Ixo29801 for dna-list; Thu, 21 Jul 2005 11:18:59 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L1Iww29797 for ; Thu, 21 Jul 2005 11:18:58 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQVVKXXXJ499P5AS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 11:18:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F4E08000D; Thu, 21 Jul 2005 11:18:41 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 489AE3C00B; Thu, 21 Jul 2005 11:18:41 +1000 (EST) Date: Thu, 21 Jul 2005 11:18:40 +1000 From: Brett Pentland Subject: [DNA] Version -01 of the landmark-based DNA solution draft Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <42DEF7F0.8010909@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) Content-Transfer-Encoding: 7BIT Dear DNA group, I mentioned a couple of days ago in the thread on bootstrapping router information that we had posted a new version of the landmark-based DNA solution draft. It now appears in the IETF drafts repo: http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-01.txt All comments appreciated. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 00:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSn5-0004kx-Ks for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 00:36:11 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06571 for ; Thu, 21 Jul 2005 00:36:07 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW2G01JU699PAO8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 14:34:55 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8534F80012; Thu, 21 Jul 2005 14:34:44 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 07E2F3C012; Thu, 21 Jul 2005 14:34:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L4Xe032034 for dna-list; Thu, 21 Jul 2005 14:33:40 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L4Xdw32030 for ; Thu, 21 Jul 2005 14:33:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW2E9VTUW9APE51@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 14:33:22 +1000 Received: by localhost (Postfix, from userid 510) id 6C012AB54D; Thu, 21 Jul 2005 14:33:21 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7157E4FB04; Thu, 21 Jul 2005 14:33:19 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6L4XGcn000289; Wed, 20 Jul 2005 21:33:16 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6L4X6nm634354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Jul 2005 21:33:10 -0700 (PDT) Date: Wed, 20 Jul 2005 12:10:19 -0700 From: Erik Nordmark Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal In-reply-to: <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , greg.daley@eng.monash.edu.au, Dna Message-id: <42DEA19B.5050204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2cd39c2cd2de.2cd2de2cd39c@monash.edu.au> <42D4F926.6090708@sun.com> <42D5C1E8.5060406@eng.monash.edu.au> <42D6D53C.6050607@sun.com> <42DB170C.7090900@eng.monash.edu.au> <42DB4404.6040303@eng.monash.edu.au> <01cd01c58bb2$ff5c5d50$016115ac@dcml.docomolabsusa.com> <42DC405F.5040501@eng.monash.edu.au> <010701c58ca1$052d5f10$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT James Kempf wrote: > RFC 2461 (and RFC 2461bis) has this to say about boot time sending of > unsolicited RAs (Section 6.2.4): > > For the first few advertisements (up to > MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it > becomes an advertising interface, if the randomly chosen interval is > greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set > to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval > for the initial advertisements increases the likelihood of a router > being discovered quickly when it first becomes available, in the > presence of possible packet loss. The above RAs help to let the routers already present find out about a newly arriving/booting router, but it doesn't let the new guy find out about the routers that were already present on the link. For the second part it seems to be that the new router needs to send something which triggers the other routers to send their RAs. That sounds like an RS to me. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 00:41:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSrz-0007IY-Lo for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 00:41:16 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06753 for ; Thu, 21 Jul 2005 00:41:11 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW2KMF91K99ORJC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 14:38:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 66D07AB543; Thu, 21 Jul 2005 14:38:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1CFA64FB06; Thu, 21 Jul 2005 14:38:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L4cPH32129 for dna-list; Thu, 21 Jul 2005 14:38:25 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L4cOw32125 for ; Thu, 21 Jul 2005 14:38:24 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW2KE6TTW99ORJC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 14:38:17 +1000 Received: by localhost (Postfix, from userid 510) id 654C38000F; Thu, 21 Jul 2005 14:38:17 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1A0DB3C010; Thu, 21 Jul 2005 14:38:14 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6L4cD3t005616; Wed, 20 Jul 2005 21:38:13 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6L4c5KO636394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Jul 2005 21:38:09 -0700 (PDT) Date: Wed, 20 Jul 2005 21:38:44 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DD869A.8050402@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <42DF26D4.9020801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > I think that the problem in DNA comes (primarily) where there's > lingering state in the network: a host or router which hasn't seen > the zero lifetime retraction. > > A zero lifetime retraction is a valid mechanism, but intermittently > connected hosts may not receive the notification that the prefix is > no longer connected. Yes, there are issues even with intermittently connected hosts that don't move. Such a host might hear a prefix with a preferred lifetime of 7 days, and then never hear anything more about that prefix, even though the prefix might have been announced with a preferred and valid lifetime of zero for a while (when the host wasn't connected). There is a fix to this (keep announcing the prefix with a lifetime of zero until its original "expiration" time passes). However, such a fix wouldn't help with DNA, since the host might attach to a different link and not the same link. > I'd like to sit and think for a little while and determine if there's > a completely safe way to handle knowledge used for CPL (or CompleteRA > etc.) without facing the danger that the prefixes will be classified > as belonging to one link (when in fact they belong to two, from two > different times). Let me know if you come up with something. > This shouldn't hamper progression of CPL at the moment. ok > Do you think we may need a short PS after IETF? I'm not sure. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 00:57:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvT7V-0007JB-B4 for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 00:57:18 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07588 for ; Thu, 21 Jul 2005 00:57:13 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW36PB08Q99P2NR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 14:56:22 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76B26AB543; Thu, 21 Jul 2005 14:56:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2EA3C4FB06; Thu, 21 Jul 2005 14:56:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L4u4k32386 for dna-list; Thu, 21 Jul 2005 14:56:04 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L4u4w32382 for ; Thu, 21 Jul 2005 14:56:04 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW36C396K9APFKL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 14:55:58 +1000 Received: by localhost (Postfix, from userid 510) id D18E8AB544; Thu, 21 Jul 2005 14:55:58 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id B85234FB05 for ; Thu, 21 Jul 2005 14:55:57 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJY00F7HOBEEZ@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 21 Jul 2005 13:54:50 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJY00210OB5EK@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 21 Jul 2005 13:54:50 +0900 (KST) Date: Thu, 21 Jul 2005 10:20:59 +0530 From: Syam Madanapalli Subject: [DNA] Updated draft: draft-jinchoi-dna-protocol2-01 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <094901c58daf$cedb02e0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Dear DNA WG, We have updated the Linkid Prefix draft and it is available in the Internet Drafts repository at http://www.ietf.org/internet-drafts/draft-jinchoi-dna-protocol2-01.txt The main changes from -00 are: 1. Updated Section 3.5 Graceful linkid prefix change for a case where the linkid prefix is not advertised in the last 1.5 hrs. 2. Added two new issues: one for defining new option in RS to carry the linkid and other one for new criteria for selecting the linkid Please provide your review comments. Thank you, Syam From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 01:11:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTLW-0004jJ-TK for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 01:11:47 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08420 for ; Thu, 21 Jul 2005 01:11:45 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3O9XTNM9APF77@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 15:10:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D946AB544; Thu, 21 Jul 2005 15:10:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2BDBA4FB0D; Thu, 21 Jul 2005 15:10:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L5AAV32571 for dna-list; Thu, 21 Jul 2005 15:10:10 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L5A9w32567 for ; Thu, 21 Jul 2005 15:10:09 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3NUW75I99P785@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 15:10:06 +1000 Received: by localhost (Postfix, from userid 510) id 67384AB547; Thu, 21 Jul 2005 15:10:06 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by curly.its.monash.edu.au (Postfix) with ESMTP id 98E7D4FB05 for ; Thu, 21 Jul 2005 15:10:05 +1000 (EST) Received: by zproxy.gmail.com with SMTP id s18so58938nze for ; Wed, 20 Jul 2005 22:10:04 -0700 (PDT) Received: by 10.36.57.19 with SMTP id f19mr789250nza; Wed, 20 Jul 2005 22:09:39 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 20 Jul 2005 22:09:39 -0700 (PDT) Date: Thu, 21 Jul 2005 14:09:39 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DD3541.3010703@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072022099ff63ae@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WbSi1YuaenqfSwwrUo3Z0uuyMbgsP9y8Kg393elL5dYlRW90eBUBGwu5xt8ucAhUyG6WAFjI5lD6intRtzTFYxRyLHXXdjCGprTj8WJIZ55jb++7uy/M67d4zXV9QE5SQzQXP92nNdxqSoNKFQs12cPoqdjZcaGcKecSCAlNFj4= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Sorry for a late reply. After FRD completeion, I am still busy catching up baglog mails. > I don't think this is accurate in comparison to synchronizing for > prefix-LinkID. Prefix LinkID requires the completeRA list to be > synchronized in each of the routers so that the least prefix can be > selected from the list as LinkID. So the synchronization/bandwidth > requirements are the same for both CompleteRA and Prefix LinkID. I may not be clear. The difficulty in synchronization lies in when a prefix is added or removed. There is a scheme for graceful linkid change in Linkid but, correct me wrong, nothing like that in Landmark/ CompleteRA. I remember that DT discussed much about the flapping probmem in CompleteRA synchronization difficulty (w.r.t the prefix number) in 'CompleteRA Polished' thread. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 01:17:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTQd-000188-Jn for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 01:17:03 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08681 for ; Thu, 21 Jul 2005 01:17:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3V3768M9APHKL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 15:16:02 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 227BEAB54B; Thu, 21 Jul 2005 15:15:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D49AD4FB08; Thu, 21 Jul 2005 15:15:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L5Fo032661 for dna-list; Thu, 21 Jul 2005 15:15:50 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L5Fnw32657 for ; Thu, 21 Jul 2005 15:15:49 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3UO6QO69APF77@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 15:15:36 +1000 Received: by localhost (Postfix, from userid 510) id 107228000D; Thu, 21 Jul 2005 15:15:36 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by larry.its.monash.edu.au (Postfix) with ESMTP id 15B6F3C011 for ; Thu, 21 Jul 2005 15:15:33 +1000 (EST) Received: by zproxy.gmail.com with SMTP id p8so56325nzb for ; Wed, 20 Jul 2005 22:15:31 -0700 (PDT) Received: by 10.36.154.18 with SMTP id b18mr752544nze; Wed, 20 Jul 2005 22:15:10 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 20 Jul 2005 22:15:10 -0700 (PDT) Date: Thu, 21 Jul 2005 14:15:10 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <42DD39A0.3040009@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050720221563f7ddd7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XtQH3DJCiJbJ3TzEEjez5n7ukZzUiBm0L0KjxZy7d/DzsPyqAH0UwQ3j+KQ2uMNXLJ/7KuJFbK8vXIR1Et37pJJWEAgx1k0LfmmQUvlqh5FSdXDUkoDxoaLzSWJxlzNFEX3fvNQoR6IUkw+OlxaUA7ql/ztP6yTHF8DL+HuDS2s= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya > >Kindly see the Issue 007 of Linkid-01 draft. With Linkid prefix option > >for RS message, Linkid can achieve the same bandwidth saving. > >(But I can't be sure that it's worthwhile.) > > > I am surprised - this issue is basically suggesting the adoption of > prefix landmark into the prefix LinkID solution. If this change is made > to LinkID, then the second proposal becomes Prefix Landmark + Prefix > LinkID, as Greg suggested. But, your response to Greg's email seem to > suggest that you don't like that combination. My mail doesn't seem to be as clear as I had expected. I ask your kind understanding. I introduced Linkid prefix option only to reduce bandwidth. The answer will be always a RA with LinkID and Linkid + Landmark was not intended. I'd like to say Linkid is a complete solution by itself and can work without Landmark. If LinkID + Landmark brings forth benefits exceeding the added complexity, it's ok for me but such a benefits are not clear to me yet. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 01:20:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTTc-0002pJ-8T for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 01:20:10 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08837 for ; Thu, 21 Jul 2005 01:20:06 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3YX8EWW9APF77@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 15:19:13 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 83ED9AB543; Thu, 21 Jul 2005 15:19:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 328764FB06; Thu, 21 Jul 2005 15:19:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L5Iv432725 for dna-list; Thu, 21 Jul 2005 15:18:57 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L5Iuw32721 for ; Thu, 21 Jul 2005 15:18:56 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW3YSNR2K9APHKL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 15:18:55 +1000 Received: by localhost (Postfix, from userid 510) id 86EE8AB543; Thu, 21 Jul 2005 15:18:55 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id BB8FA4FB07 for ; Thu, 21 Jul 2005 15:18:54 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 8so58296nzo for ; Wed, 20 Jul 2005 22:18:52 -0700 (PDT) Received: by 10.36.222.13 with SMTP id u13mr801169nzg; Wed, 20 Jul 2005 22:18:30 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 20 Jul 2005 22:18:30 -0700 (PDT) Date: Thu, 21 Jul 2005 14:18:30 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <92e919fb050720221563f7ddd7@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072022181c91ebf0@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QDshnjxjnkrATKkX5fvXdbgxoKTeuVgHy4o7Wi/dXULdP0b1p3VwRZC+JKFecHUm6ujWJDB0kb0pqFayvJZ6iUJHeVJZNpZoDeNIfQByuPj37Mk7TGBEd/KTtw3UFNkJla9pSxr9zA70sdwGq7W1+Vjbs4gQFvaiSIJ3WQSRBm0= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <92e919fb050720221563f7ddd7@mail.gmail.com> Content-Transfer-Encoding: 7BIT I'd like to clarify the previous mail. "The answer will be always a RA with LinkID" means "Upon solicited, routers always reply an RA with LinkID and don't use Yes/No indicaiton." Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 03:01:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvV48-0003We-IW for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:01:56 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06220 for ; Thu, 21 Jul 2005 03:01:54 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW7FGB6Q899P8S8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 16:58:42 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 87E7580022; Thu, 21 Jul 2005 16:56:29 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 377DB3C00B; Thu, 21 Jul 2005 16:56:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L6tse01447 for dna-list; Thu, 21 Jul 2005 16:55:54 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L6tpw01443 for ; Thu, 21 Jul 2005 16:55:51 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW7C4C9LY9APGUO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 16:55:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57B6BAB61C; Thu, 21 Jul 2005 16:52:51 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 158094FB06; Thu, 21 Jul 2005 16:52:51 +1000 (EST) Date: Thu, 21 Jul 2005 16:52:50 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <92e919fb05072022099ff63ae@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Sathya Narayanan , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42DF4642.3090407@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: > Sathya > > Sorry for a late reply. After FRD completeion, I am still busy > catching up baglog mails. > > >>I don't think this is accurate in comparison to synchronizing for >>prefix-LinkID. Prefix LinkID requires the completeRA list to be >>synchronized in each of the routers so that the least prefix can be >>selected from the list as LinkID. So the synchronization/bandwidth >>requirements are the same for both CompleteRA and Prefix LinkID. > > > I may not be clear. > > The difficulty in synchronization lies in when a prefix is added or > removed. There is a scheme for graceful linkid change in Linkid but, > correct me wrong, nothing like that in Landmark/ CompleteRA. I think that there's no scheme defined in Landmark/CompleteRA, but (in my guess) the choice of the scheme itself will significantly affect whether particular "config" change management (rather than link change management) schemes are needed. > I remember that DT discussed much about the flapping > probmem in CompleteRA synchronization difficulty (w.r.t the prefix > number) in 'CompleteRA Polished' thread. Thanks for the pointer to this thread. I think there are two or three related threads: Complete RA Polished http://www.ctie.monash.edu.au/warchive/dna-dt/2005-03/msg00157.html Complete RA Re-polished http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00009.html LinkID Polished http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00097.html and http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/threads.html It's good to know that there's been so much work on this (and that everyone can read it). There were a lot of differences between individual schemes as portrayed before (in April) and now though. This may affect the way prefix addition or subtraction works. Given the individual current schemes though, let's try to characterise the effects of addition or substraction of prefixes on each protocol as configured today. Does that sound reasonable? I guess that if the state + processing requirements for Landmark/CompleteRA and LinkID are comparable (which I've indicated may be the case), implementation experiences are qualitative, and in the normal case (and non-DNA case) all schemes act sensibly, the main issues will probably be: * Synchronization/How the schemes react to change of prefixes. * Packet Sizes Does this sound like the right criteria to compare the schemes on? There may not be a clear winner with any of these, and it may be that the WG just chooses a particular scheme it likes. The comparison is likely to help with forming that opinion, and may actually highlight a winner. Should we go ahead? It may mean some in-depth description of how the schemes currently handle change (which may take some discussion). I think that we need to compare packet sizes for: RS/RA exchange for each scheme (or set of schemes) as described in current drafts. Where: a) 1 prefix is shared by all routers b) 1 distinct prefix is configured on each router. c) 1 prefix is shared by all routers and one additional prefix is advertised by one router (big or small prefix). We should probably do this for 1,2 routers (though the third test may be a bit simple with 1 router - one router 2 prefixes). We should sum the sizes of the response RAs for all routers. Does this sound OK with people? Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 03:11:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVDh-0007YF-LA for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:11:49 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06708 for ; Thu, 21 Jul 2005 03:11:47 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW7VO1XKY99P51O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 17:11:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EAEACAB548; Thu, 21 Jul 2005 17:10:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A794C4FB11; Thu, 21 Jul 2005 17:10:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L7Ahn01630 for dna-list; Thu, 21 Jul 2005 17:10:43 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L7Ahw01626 for ; Thu, 21 Jul 2005 17:10:43 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW7V7ZIY09AP9KF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 17:10:34 +1000 Received: by localhost (Postfix, from userid 510) id 8A4DC8000D; Thu, 21 Jul 2005 17:10:34 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id 643B43C00D for ; Thu, 21 Jul 2005 17:10:28 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 4so74663nzn for ; Thu, 21 Jul 2005 00:10:23 -0700 (PDT) Received: by 10.37.12.48 with SMTP id p48mr631408nzi; Thu, 21 Jul 2005 00:09:59 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 00:09:59 -0700 (PDT) Date: Thu, 21 Jul 2005 16:09:59 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DDA20F.2080400@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072100096d56000f@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NX8rZzx5kaeHgW0rqSpGSXrZrhBip+HZhDzmJEqfI5gJJGUqSAY2OdG/XxEoPUBgxOr9Lqp97oKO1B9CXQoUgaRntYFokkBins5duIguHjF6UgDC/UIoLboOA7vwBTEPTvixu2delOO9NuFoaA5V2DbDsm50EANNJI4jKtvv0Ws= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > > I think CompleteRA by itself is more complex than LinkID. (That's > > why I switched to Linkid. As you may know, I've played with CompleteRA > > quite long in DT) > > CompleteRA is not significantly more difficult. > > The only difference between storage of information in either CompleteRA > or LinkID is that routers have to keep (at least) the two smallest > Prefixes with LinkID, and that CompleteRA has to keep all prefixes > (on the router side). > > The storage and comparison requirements are quite similar, > especially on the host, where the CPL (+CCL) must be kept anyway. > > In fact, the Landmark and CompleteRA have exactly the same state > requirements, and share space and implementation code in my RADVD patch. > > So overall, the cost of storage for the combined Landmark+CompleteRA > solution is comparable to the LinkID solution. As I told to Sathya, the main difficulty for CompleteRA is to synchronize all the routers on the link to have the same CompleteRA all the time. For example, when a prefix is added, removed or prefix lifetime expires, the routers need to update there CompleteRA in time to advertise the same one. But this is hard. (Cut and pasting from DT ML), But with packet loss and a potential for the set of routers changing, I don't see how we can guarantee such synchronicity. For a known and fixed set of routers that never fail, then a two-face commit protocol can ensure that they all switch in concert, but the protocol needs to work when routers fail as well as the set of routers being dynamic. Linkid deals with this problem with special schemes as as Linkid prefix list and a few advertisement rules, such as keep advertising old linkid after a linkid change for the time being. But for CompleteRA (also for Landmark), as of my knowledge, no such mechanism is devised yet, though I myself had worked on it before I switched to linkid. My thought is that it's easier to synchronize one prefix rather than synchronize all the prefixes on the link. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 03:26:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVSB-0005oL-7B for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:26:47 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07613 for ; Thu, 21 Jul 2005 03:26:44 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQW8FNME3U8WW3HV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 17:26:33 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 06E61AB545; Thu, 21 Jul 2005 17:26:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B383E4FB07; Thu, 21 Jul 2005 17:26:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L7Q4f01816 for dna-list; Thu, 21 Jul 2005 17:26:04 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L7Q4w01811 for ; Thu, 21 Jul 2005 17:26:04 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQW8EZOYQK8WW3HV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 17:25:44 +1000 Received: by localhost (Postfix, from userid 510) id D1F9EAB54A; Thu, 21 Jul 2005 17:25:43 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7D6CB4FB13 for ; Thu, 21 Jul 2005 17:25:41 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 12so75814nzp for ; Thu, 21 Jul 2005 00:25:39 -0700 (PDT) Received: by 10.37.12.48 with SMTP id p48mr640753nzi; Thu, 21 Jul 2005 00:25:08 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 00:25:08 -0700 (PDT) Date: Thu, 21 Jul 2005 16:25:08 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb050721002515efe7c2@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C9BmUHJJuh5XLVYO8wIpqtcfxx6sUdRsNYCBUVfU0H9oAq8WrC8vhbgZ917SomporDvx92jEE2bp1bXdewXQhIjGv5L93GXj7s5BF1Hqmw0aSav84nBPJTBLJBHR72ugw8xF89Zl7nX98bbbZT5cHrvHxsvSewVuigM7DStP0vY= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Dear Tero > > No. We don't think it's desirable for PoA to modify an RA, unless > > it gets permission from AR. > > Ok. I was just thinking how long PoA should keep an entry in the cache. > Unlike it the second mail sent later, at this point I was not wondering > should the lifetime in the cached entry also be decreased. Sorry, but I have difficulty understanding the above phrase. Kindly clarify it more. > > Right now, we design the scheme in the simplest way and PoA doesn't > > manage index entries. > > > > Assume there are two routers on a link, AR1 and AR2. First AR1 > > sends RA1 and PoA caches it. Afterwards AR2 sends RA2, then > > PoA substitutes its cached RA with RA2. This doesn't affect DNA > > performance as long as both RA1 and RA2 can properly indicate > > link identity, i.e. RA optimized for DNA. > > Oh, I see. There is only one cached entry instead of multiple entries > (i.e. RAs from different APs). Right. Allow me to clarify a little more. In 01 version, FRD works with one cached entry. But in later version, FRD may be expanded to have multiple entries for better performance. > I think it would be worth mentioning somewhere, maybe along with the > sentence: > > "the PoA needs to cache a suitable RA, such as 'RA optimized for DNA' > defined in [5]." > > that RAs with the SEND nonce option can't be cached while the ones with > timestamps can be cached only for a certain duration of time. Sounds reasonable. I will coin the exact phrases for the 02-version. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 03:55:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVuR-0001Jc-Bi for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:55:59 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09731 for ; Thu, 21 Jul 2005 03:55:57 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQW9G3NT3A8WW409@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 17:55:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 176B3AB545; Thu, 21 Jul 2005 17:55:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C82DE4FB06; Thu, 21 Jul 2005 17:55:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L7tNq02199 for dna-list; Thu, 21 Jul 2005 17:55:23 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L7tMw02195 for ; Thu, 21 Jul 2005 17:55:22 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW9FR49LU99P5LU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 17:55:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 42AFC8000D; Thu, 21 Jul 2005 17:55:22 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 1FDEE3C005; Thu, 21 Jul 2005 17:55:22 +1000 (EST) Date: Thu, 21 Jul 2005 17:55:21 +1000 From: Brett Pentland Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DF4642.3090407@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: JinHyeock Choi , Sathya Narayanan , James Kempf , Dna Message-id: <42DF54E9.6000502@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > I guess that if the state + processing requirements for > Landmark/CompleteRA and LinkID are comparable (which I've > indicated may be the case), implementation experiences are > qualitative, and in the normal case > (and non-DNA case) all schemes act sensibly, the > main issues will probably be: > > * Synchronization/How the schemes react to change of prefixes. > > * Packet Sizes > > Does this sound like the right criteria to compare > the schemes on? It would be good to also consider how the schemes interact with non-DNA nodes. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 04:10:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvW8d-0007JH-Hp for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 04:10:39 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10620 for ; Thu, 21 Jul 2005 04:10:36 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW9XX73V499P7EP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 18:10:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 082878000E; Thu, 21 Jul 2005 18:10:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id A8EFF3C00C; Thu, 21 Jul 2005 18:10:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L89c102374 for dna-list; Thu, 21 Jul 2005 18:09:38 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L89cw02370 for ; Thu, 21 Jul 2005 18:09:38 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQW9X303NW9APFJ2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 18:09:20 +1000 Received: by localhost (Postfix, from userid 510) id 9810FAB543; Thu, 21 Jul 2005 18:09:20 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by moe.its.monash.edu.au (Postfix) with ESMTP id F40D44FB04 for ; Thu, 21 Jul 2005 18:09:13 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 4so84403nzn for ; Thu, 21 Jul 2005 01:09:08 -0700 (PDT) Received: by 10.36.146.2 with SMTP id t2mr853911nzd; Thu, 21 Jul 2005 01:08:45 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 01:08:45 -0700 (PDT) Date: Thu, 21 Jul 2005 17:08:45 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <42DDE8BF.7010404@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: "Tero Kauppinen (JO/LMF)" , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0507210108829856@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pm/e5MvdWkakzZXzscVfv9Hw74zjDffcpR93XSW+jqtLhn8xlK7nTYZZxP8QsdyQpMK3cDbCCLaOu1GlyV80UK4tkNieL3LDU3bz/G5B9hIlOPKekZLUqVJjPvEapUR/qZCC2IWBcA7G+yJnKqEPu097hOVbDDqj6HMLG/Pe0hY= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DDE8BF.7010404@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > I've done an analysis on this (which may yet have flaws) and there > are some tricky issues with the caching and SEND. > > With SEND, the options cannot be modified by an intervening device > (as it doesn't have the CGA private key), so all RA contents remain > the same, including lifetime and SEND Timestamp options. > > With the existing SEND specification, differences in clocks between > a host and a router are accounted for by allowing the first RA > to arrive with an allowed window. This defaults to +-300 seconds > (from section 5.3.4.2/10.2 of RFC3971). > > Therefore the cache cannot last beyond 5 minutes (without even > accounting for different clocks) by default. > > The Receiver's timelog - RDlast (and the received timestamp TSlast) of > the first RA message are then stored for comparison, and new RAs > are tested against the following inequality (the newly received > timestamp option containing TSnew, and the reception time on the > host being RDnew), only those new RAs conforming to the following > inequality are acceptable as fresh SEND RAs (sec 5.4.3.2): > > > TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz > > > The drift and fuzz factors being defined as the maximum rate of > clock drift, and the maximum (absolute) value variation in > reception of individual packets across a link, respectively. > > Using the defaults from section 10.2 (in seconds): > > TSnew - TSlast > 0.99x(RDnew - RDlast) - 2 > > Upon the first reception of a non-cached RA (after the cached RA), > TSnew - TSlast will be greater than RDnew - RDlast, since > (assuming minimal clock skew over the period): > > RDnew - RDlast = delta_t > TSnew - TSlast = delta_t + t_cache > > This then is an accepted RA, as the inequality holds. Such an RA > updates the RDlast and TSlast timers with the fresh RA's information > (as described in 5.3.4.2 of SEND). > > Where either the first received RA was non-cached, and had an up-to-date > timestamp, or a later uncached RA updated the RDlast and TSlast > parameters as described above, the situation is not as clear cut. > > Any subsequently received cached RA will be delayed by t_cache'. > > Therefore, in this case: > > RDnew' - RDlast' = delta_t' > TSnew' - TSlast' = delta_t' - t_cache' > > Using the inequality above (again assuming no significant skew) > > delta_t' - t_cache' > 0.99 x delta_t' -2 > > which implies: > > t_cache' <= 0.01 x delta_t' + 2 > > So the cache time has to be less than 2 seconds plus 1% of the > interval between received RAs in order to be accepted as a fresh > RA by the SEND host. > > This affects subsequent RA reception when transiting to the > new PoAs within the same link. > > It also affects the return of a node to a previously visited > link for which it has previously received SEND messages > (with parameters and Timestamps). As described in sections > 5.3.4, 9.2.5 (and Appendix B) of SEND, hosts are likely to > keep such information beyond the lifetime of a particular > neighbour cache entry in order to prevent replay attacks. > > So long as the SEND timer information is kept, return to > a link will ignore a Cached RA (if the cache duration is > outside the boundaries of the skew and fuzz factors for SEND). > > I'm still not quite sure about this analysis, so I'd appreciate > feedback on the issue. Thanks for a detailed and useful analysis. I'll think it through. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 04:21:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWIf-0002nB-Iu for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 04:21:02 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11136 for ; Thu, 21 Jul 2005 04:20:58 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWABVAR1E8Y50WV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 18:20:56 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC8C5AB54C; Thu, 21 Jul 2005 18:20:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8B6634FB07; Thu, 21 Jul 2005 18:20:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L8KEu02548 for dna-list; Thu, 21 Jul 2005 18:20:14 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L8KDw02544 for ; Thu, 21 Jul 2005 18:20:13 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWABFY3J899P23M@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 18:20:08 +1000 Received: by localhost (Postfix, from userid 510) id 2C009AB54A; Thu, 21 Jul 2005 18:20:08 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9516A4FB09 for ; Thu, 21 Jul 2005 18:20:03 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so85316nzd for ; Thu, 21 Jul 2005 01:20:01 -0700 (PDT) Received: by 10.36.222.46 with SMTP id u46mr884916nzg; Thu, 21 Jul 2005 01:19:36 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 01:19:36 -0700 (PDT) Date: Thu, 21 Jul 2005 17:19:36 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <074901c58ce5$907e4180$291d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb050721011935465a09@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H+Fn/8KK8et/b+ePeZQqxWaoKI24450C6MpPgLElYtk8K5YU/AZzpJ1A+AJa3xFs1j6q87FrQ8FDA9Zrkiblo3NtvERbf0FMqgN4NFF80YLxX4Iqy8C4sF+B3c4rv+skNeRlK58zRuAw2UA3tODFRjYVCs04ukNUC1t9XxAQGKw= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <92e919fb0507181814d7f98bf@mail.gmail.com> <074901c58ce5$907e4180$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Dear Alper > - "Triggered RA" has dependency on an additional protocol between the AP > and AR. I see now that there are some discussions around that, stemming > from the IEEE 802.21 work. I had a draft on such a protocol a while back > (http://www.watersprings.org/pub/id/draft-yegin-l2-triggers-01.txt) > FYI... Thanks for pointing our useful doc. I'll look it over. > - Have you analyzed what happens when you bypass the "random delay" > mechanisms? They are there for congestion avoidance. For router side, FRD doesn't say anything about the random delay for routers. It's ok for FRD if routers perform random delay as before. For PoA side, it will not cause a problem, if we bypass random delay for PoA. As of my understanding, random delay is to avoid conflict which may occur when two routers happen to send an RA at the same time. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 04:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWZb-0001ML-4s for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 04:38:31 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12127 for ; Thu, 21 Jul 2005 04:38:28 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWAXPW5WM8WW45T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 18:38:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C0BD18000E; Thu, 21 Jul 2005 18:38:04 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 773253C018; Thu, 21 Jul 2005 18:38:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L8bdF02760 for dna-list; Thu, 21 Jul 2005 18:37:39 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L8bcw02756 for ; Thu, 21 Jul 2005 18:37:38 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWAWYNM129APGKJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 18:37:30 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3FF1FAB542; Thu, 21 Jul 2005 18:37:29 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 1FCDB4FB04; Thu, 21 Jul 2005 18:37:29 +1000 (EST) Date: Thu, 21 Jul 2005 18:37:28 +1000 From: Brett Pentland Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42BF8B18.8080203@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: DNA , TM-RO2 Message-id: <42DF5EC8.7080207@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <42BF8B18.8080203@tm.uka.de> Content-Transfer-Encoding: 7BIT Hi Christian, Sorry I only just got to read through the draft. Thanks for your efforts. It's a good summary of the situation. Regarding the potential solution in section 4.2, I gather you are talking about something like: - Host sends RS with optimistic unicast source address and TSLLAO - Router replies with unicast RA (using LLA from TSLLAO) - Host only then sends MLD report (after delay) - Host send NS for oDAD This sounds good for most communications (assuming that most communications with the host go through the router). There might still be a bit of a problem if an on-link device (other than the router) tries to send a packet to the optimistic address before the MLD report goes out since the host won't receive the resulting NS from this on-link node. I guess this might come up if the host is a mobile node and tries to perform route optimization with a node that just happens to be connected to the same link as itself. Any thoughts? Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 05:09:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvX3X-0005Rk-OD for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 05:09:27 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13712 for ; Thu, 21 Jul 2005 05:09:24 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWBYNV3XK8Y51FC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 19:08:10 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CDF77AB544; Thu, 21 Jul 2005 19:07:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8A0F44FB02; Thu, 21 Jul 2005 19:07:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L97Rw03153 for dna-list; Thu, 21 Jul 2005 19:07:27 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L97Qw03149 for ; Thu, 21 Jul 2005 19:07:26 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWBXOW2HW8Y51FI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 19:07:06 +1000 Received: by localhost (Postfix, from userid 510) id EF6C1AB543; Thu, 21 Jul 2005 19:07:05 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by moe.its.monash.edu.au (Postfix) with ESMTP id 939E24FB09 for ; Thu, 21 Jul 2005 19:07:03 +1000 (EST) Received: by zproxy.gmail.com with SMTP id p8so94924nzb for ; Thu, 21 Jul 2005 02:07:01 -0700 (PDT) Received: by 10.36.5.14 with SMTP id 14mr869129nze; Thu, 21 Jul 2005 02:06:26 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 02:06:26 -0700 (PDT) Date: Thu, 21 Jul 2005 18:06:26 +0900 From: JinHyeock Choi Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42DD869A.8050402@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb050721020647eeb486@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KWzKBGhJd/E0mw8KKCPLLlqnxvlAXMrKYbplQvMyszA5P0CBwiWohztEvjX0us6lcFWnR1/H3f4qlsvTzXzxyvDexG+Hohz16IED/8mCpS886ez/GD8xHGRVsIKFFTgu2CJoHdKBbHnZbBDzLrFDMypdmydBJvBD9n77NL5pymA= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > I think that the problem in DNA comes (primarily) where there's > lingering state in the network: a host or router which hasn't seen > the zero lifetime retraction. > > A zero lifetime retraction is a valid mechanism, but intermittently > connected hosts may not receive the notification that the prefix is > no longer connected. Dormant mode also gives a problem. For example, assume a link with prefix Prefix1. A node N receives a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 is removed from the link and moved to the other link. Because N is in dormant mode, it doesn't know about this. Then N happens to move and awake to attach itself to the latter link. Because it sees Prefix1, it will falsely assume that it still is at the same link. > I'd like to sit and think for a little while and determine if there's > a completely safe way to handle knowledge used for CPL (or CompleteRA > etc.) without facing the danger that the prefixes will be classified > as belonging to one link (when in fact they belong to two, from two > different times). This is what I devise for linkid scheme. To solve "Flash renumbering and and early reassignment, linkid draft proposes that, when a linkid prefix is removed from a link, the linkid prefix should not be re-assigned to other link in 3 hours. With the above, a host would not see the same linkid prefix in two different links because linkid lifetime is 1.5 hour. > This shouldn't hamper progression of CPL at the moment. Glad to hear that. :-) > > FWIW I think this might be one reason that Keith Moore was concerned > > about using prefixes for DNAs purpose. > > That's understandable. It would be good later to have his and > other operational opinions of how relevant the problem is, and > how the solutions may be impacted by it. I talked with network operators and found out prefixes are rather stable. So my guess is, this will not affect DNA much except in some very volatile network which I can't imagine right now. > I think that this is the right place to explore the issue then > (if it's a small enough issue). > > Do you think we may need a short PS after IETF? Both Linkid & Landmark/ CompleteRA deal with this in Open Issue. For Linkid, there is Issue 003: Flash renumbering and early reassignment For Landmark/ CompleteRA, there is Issue 0012: Network renumbering - guidelines for deployment We may mention this problem in open issue presentation. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 05:20:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvXEb-0001lp-QJ for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 05:20:53 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14168 for ; Thu, 21 Jul 2005 05:20:50 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWCFCU6FS9AOH93@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Jul 2005 19:20:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7C819AB545; Thu, 21 Jul 2005 19:20:33 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 33A7D4FB03; Thu, 21 Jul 2005 19:20:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6L9KGt03332 for dna-list; Thu, 21 Jul 2005 19:20:16 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6L9KFw03328 for ; Thu, 21 Jul 2005 19:20:15 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWCEKU1NM8WW4AS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Jul 2005 19:19:58 +1000 Received: by localhost (Postfix, from userid 510) id EF6E5AB546; Thu, 21 Jul 2005 19:19:55 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by curly.its.monash.edu.au (Postfix) with ESMTP id 96D3F4FB0D for ; Thu, 21 Jul 2005 19:19:53 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z3so105207nzf for ; Thu, 21 Jul 2005 02:19:51 -0700 (PDT) Received: by 10.36.154.18 with SMTP id b18mr896865nze; Thu, 21 Jul 2005 02:19:24 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 02:19:24 -0700 (PDT) Date: Thu, 21 Jul 2005 18:19:24 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <42DDFBD2.1000602@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05072102193d845620@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IJwfP0kSuYZRLa9frc1pty/drJTNs0f0v1S70eIXiYnwDatMMnZ/rgDf2LsRcSQ4p433vQFncaRawNTe6lO+BFW/jrkCjvb24Wdya+POK1RruzfquSOMuScG27yaoNyVcvq6YyzywSIygDKKpGeaxn6zwrhSboW/Wq8eN/o2Tgk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> <92e919fb0507191914308de355@mail.gmail.com> <42DDFBD2.1000602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > > I don't understand your point. DNA solution is supposed to do > > its job with a single RA message. Allow me to quote from DNA > > design team document, > > > > It was felt that by crafting the > > information in the solicitation and advertisement, a single RS/RA > > exchange should be sufficient for DNA. > > > > So in DNA point of view, I see no problem sending just one RA > > (optimized for DNA). > > You've answered my question in your email to Tero - only the most > recent RA is cached (and it will change frequently if there are > multiple routers on the link). Yes, but we may modify this in the next version. PoA may cache multiple RAs and send them all. > You are right that DNA only needs a single RA, and a decision about > configuration can be made immediately after that RA, but router > discovery may require more than that. I assume that an RA optimized for DNA would include all the information that is necessary for a new IP configuration. > Section 6.3.7 of RFC 2461 > notes that unsolicited RAs may be incomplete and that upon reception > of one before having sent an RS, that the host SHOULD send an RS. > Thus we end up with an RS and its associated RAs, plus the additional > original unsolicited RA. I didn't recognize this yet. Thanks for your pointing this out. We may need to relax the condition a little. > This doesn't affect the speed of DNA but does add to the total packet > exchange. ok. There will be one more RA. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 10:24:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvbyB-0001yd-Mx for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 10:24:16 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05023 for ; Thu, 21 Jul 2005 10:24:13 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWN0JTVRE99P9SD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 00:24:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A56AEAB543; Fri, 22 Jul 2005 00:23:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 499CC4FB0B; Fri, 22 Jul 2005 00:23:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LEL1606777 for dna-list; Fri, 22 Jul 2005 00:21:01 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LEL0w06773 for ; Fri, 22 Jul 2005 00:21:00 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWMWJUO6K9APIEC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 00:20:45 +1000 Received: by localhost (Postfix, from userid 510) id 4A420AB543; Fri, 22 Jul 2005 00:20:45 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 069894FB02; Fri, 22 Jul 2005 00:20:43 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6LEKTat020726; Thu, 21 Jul 2005 10:20:29 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 4EB101E8187; Thu, 21 Jul 2005 10:11:13 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 3ED031E8010; Thu, 21 Jul 2005 10:11:13 -0400 (EDT) Date: Thu, 21 Jul 2005 10:20:03 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <92e919fb05072022181c91ebf0@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <42DFAF13.9000700@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:84.66180 C:15 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <92e919fb050720221563f7ddd7@mail.gmail.com> <92e919fb05072022181c91ebf0@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock - >I'd like to clarify the previous mail. > >"The answer will be always a RA with LinkID" > >means > >"Upon solicited, routers always reply an RA with LinkID >and don't use Yes/No indicaiton." > > This is just an issue of syntax - in your proposal if the RS contains LinkID_1 and if the RA comes back with LinkID_1 it means 'Yes' and if the RA comes back with LinkID_X (X != 1) then it means 'No'. Conceptually the main design issue behing the idea of 'Landmark', is to include a question in the RS and get a response for it in the RA. Obviously, the two protocols will use different syntax to achieve this - but if you agree to include some kinda question in the RS by including the LinkID, then we are in agreement ;-) as to the choice of including a 'Landmark like' component. We can move on to the specific syntax/mechanism by which we acheive it - where we do disagree, as of now. Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 14:06:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfRB-00046r-Mv for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 14:06:25 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22413 for ; Thu, 21 Jul 2005 14:06:23 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWUOPB1768Y543P@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 04:04:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 70C4E80052; Fri, 22 Jul 2005 04:02:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E259C3C00C; Fri, 22 Jul 2005 04:02:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LI1NX09378 for dna-list; Fri, 22 Jul 2005 04:01:23 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LI1Lw09374 for ; Fri, 22 Jul 2005 04:01:22 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQWUM1C8EC8Y543P@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 04:01:20 +1000 Received: by localhost (Postfix, from userid 510) id 91F6380014; Fri, 22 Jul 2005 04:01:20 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by larry.its.monash.edu.au (Postfix) with ESMTP id B299A3C00C for ; Fri, 22 Jul 2005 04:01:18 +1000 (EST) Received: by rproxy.gmail.com with SMTP id g11so31783rne for ; Thu, 21 Jul 2005 11:01:17 -0700 (PDT) Received: by 10.38.151.24 with SMTP id y24mr997658rnd; Thu, 21 Jul 2005 11:01:00 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Thu, 21 Jul 2005 11:00:59 -0700 (PDT) Date: Thu, 21 Jul 2005 23:30:59 +0530 From: Syam Madanapalli Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <42DFAF13.9000700@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: Syam Madanapalli Message-id: <10e14db205072111007aa1d904@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VXn26D4HFHLArMLc5YJlvsKhhCaiR7VygT8mNc9LH4AXXZicpzH4fAtqLYVDXpL5R4wj36akz1gpyJgWW+Rj8L82sqhIBE+pJNEYaQdkpz7e/lDQ3soH9Ck1dZlA84AN8XiYxgbj21PaEABqXm8c2LIL6t5D0I1cG6sE5YYAgPU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <92e919fb050720221563f7ddd7@mail.gmail.com> <92e919fb05072022181c91ebf0@mail.gmail.com> <42DFAF13.9000700@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, On 7/21/05, Sathya Narayanan wrote: > JinHyeock - > > >I'd like to clarify the previous mail. > > > >"The answer will be always a RA with LinkID" > > > >means > > > >"Upon solicited, routers always reply an RA with LinkID > >and don't use Yes/No indicaiton." > > > > > This is just an issue of syntax - in your proposal if the RS contains > LinkID_1 and if the RA comes back with LinkID_1 it means 'Yes' and if > the RA comes back with LinkID_X (X != 1) then it means 'No'. > Conceptually the main design issue behing the idea of 'Landmark', is to > include a question in the RS and get a response for it in the RA. > Obviously, the two protocols will use different syntax to achieve this - > but if you agree to include some kinda question in the RS by including > the LinkID, then we are in agreement ;-) as to the choice of including a > 'Landmark like' component. We can move on to the specific > syntax/mechanism by which we acheive it - where we do disagree, as of now. > > Sathya > The difference MAY be more than what you have mentioned. MN sends the linkid in RS not any prefix (which is the case in Landmark approach), as the routers treat the (old) linkid prefixes differently from the normal prefixes for graceful change in linkid. Please see the section 3.5 Graceful linkid prefix change. So the routers can give the correct answer compared to Landmark where there is a posibility of conflicting answers. However the linkid approach does not carry yes/no bit, instead hosts make decision based on the linkid carried in RA. -Syam From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 15:51:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh4S-0001sv-GI for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 15:51:06 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03900 for ; Thu, 21 Jul 2005 15:51:01 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWYFQ6GB299P28P@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 05:50:49 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 12631AB545; Fri, 22 Jul 2005 05:50:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B64454FB03; Fri, 22 Jul 2005 05:50:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LJoHc10857 for dna-list; Fri, 22 Jul 2005 05:50:17 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LJoHw10853 for ; Fri, 22 Jul 2005 05:50:17 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQWYEW6P0M99P28P@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 05:50:07 +1000 Received: by localhost (Postfix, from userid 510) id E6EF1AB543; Fri, 22 Jul 2005 05:50:06 +1000 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id BA40E4FB0A for ; Fri, 22 Jul 2005 05:50:05 +1000 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dvh3T-0003Zf-0k; Thu, 21 Jul 2005 15:50:03 -0400 Date: Thu, 21 Jul 2005 15:50:03 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-link-information-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_thPOyTA0WU46jfLQ15jVSA)" X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) --Boundary_(ID_thPOyTA0WU46jfLQ15jVSA) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Link-layer Event Notifications for Detecting Network Attachments Author(s) : A. Yegin Filename : draft-ietf-dna-link-information-02.txt Pages : 23 Date : 2005-7-21 Certain network access technologies are capable of providing various link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-link-information-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-dna-link-information-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. --Boundary_(ID_thPOyTA0WU46jfLQ15jVSA) Content-type: multipart/alternative; boundary="Boundary_(ID_6++1YqHEmyQSm0FR9sN4zw)" --Boundary_(ID_6++1YqHEmyQSm0FR9sN4zw) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-21133627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-link-information-02.txt --Boundary_(ID_6++1YqHEmyQSm0FR9sN4zw) Content-type: Message/External-body; name=draft-ietf-dna-link-information-02.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-link-information-02.txt Content-Type: text/plain Content-ID: <2005-7-21133627.I-D@ietf.org> --Boundary_(ID_6++1YqHEmyQSm0FR9sN4zw)-- --Boundary_(ID_thPOyTA0WU46jfLQ15jVSA)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 18:43:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvjlA-0001z0-7L for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 18:43:20 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22098 for ; Thu, 21 Jul 2005 18:43:16 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX4G5YOEA99PB1K@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 08:43:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 497388000E; Fri, 22 Jul 2005 08:42:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id EDD673C00C; Fri, 22 Jul 2005 08:42:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LMgNu12773 for dna-list; Fri, 22 Jul 2005 08:42:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LMgMw12769 for ; Fri, 22 Jul 2005 08:42:22 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX4FEJVKC99PDYW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 08:42:19 +1000 Received: by localhost (Postfix, from userid 510) id 95004AB547; Fri, 22 Jul 2005 08:42:19 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3B51C4FB0D for ; Fri, 22 Jul 2005 08:42:17 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK000AAV1QEPZ@mailout2.samsung.com> for dna@eng.monash.edu.au; Fri, 22 Jul 2005 07:42:14 +0900 (KST) Received: from LocalHost ([75.2.43.241]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK00080X1QEFK@mmp1.samsung.com> for dna@eng.monash.edu.au; Fri, 22 Jul 2005 07:42:14 +0900 (KST) Date: Fri, 22 Jul 2005 07:42:13 +0900 From: Heejin Jang Subject: [DNA] FRD Implementation and Test Results Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: JinHyeock Choi Message-id: <000801c58e45$70b820d0$f12b024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Dear DNA WG, We have implemented a FRD scheme of Fast Router Discovery with L2 support http://www.ietf.org/internet-drafts/draft-jinchoi-dna-frd-01.txt In brief, we made an AP (Access Point) with a Linux box, which caches a suitable RA and delivers it immediately upon a new L2 connection. The code is just 31 lines for driver (with Scanning) and an MN receives an RA within 1.3 ms in average. :-) You can find the result in http://www.diffeo.com/test/FRD_Implementation.ppt Your feedback will be appreciated. Regards, Heejin. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 19:03:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvk4q-00029l-AW for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 19:03:42 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27025 for ; Thu, 21 Jul 2005 19:03:36 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX55M489S99PEMQ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 09:03:34 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 295E5AB545; Fri, 22 Jul 2005 09:03:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id CA18A4FB04; Fri, 22 Jul 2005 09:03:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LN3HT13036 for dna-list; Fri, 22 Jul 2005 09:03:17 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LN3Gw13032 for ; Fri, 22 Jul 2005 09:03:16 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQX555FSCG8WWABZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 09:03:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DDBDAAB543; Fri, 22 Jul 2005 09:03:04 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id C47634FB04; Fri, 22 Jul 2005 09:03:04 +1000 (EST) Date: Fri, 22 Jul 2005 09:02:59 +1000 From: Greg Daley Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <92e919fb050721020647eeb486@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E029A3.5010907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> <92e919fb050721020647eeb486@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Dear Greg > > >>I think that the problem in DNA comes (primarily) where there's >>lingering state in the network: a host or router which hasn't seen >>the zero lifetime retraction. >> >>A zero lifetime retraction is a valid mechanism, but intermittently >>connected hosts may not receive the notification that the prefix is >>no longer connected. > > > Dormant mode also gives a problem. > > For example, assume a link with prefix Prefix1. A node N receives > a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 > is removed from the link and moved to the other link. Because > N is in dormant mode, it doesn't know about this. Then N happens > to move and awake to attach itself to the latter link. Because it sees > Prefix1, it will falsely assume that it still is at the same link. Yes, I believe this is the same case as "intermittently connected" though, as in both cases, the host is not aware of state changes on the link. I guess we can collapse these two cases into one. >>I'd like to sit and think for a little while and determine if there's >>a completely safe way to handle knowledge used for CPL (or CompleteRA >>etc.) without facing the danger that the prefixes will be classified >>as belonging to one link (when in fact they belong to two, from two >>different times). > > > This is what I devise for linkid scheme. > > To solve "Flash renumbering and and early reassignment, linkid draft > proposes that, when a linkid prefix is removed from a link, the linkid > prefix should not be re-assigned to other link in 3 hours. With the > above, a host would not see the same linkid prefix in two different links > because linkid lifetime is 1.5 hour. This isn't a completely safe solution, since people do strange things which violate recommendations they haven't read. I used to work in Tech Support (in another life), so I know things like this happen. Existing Router deployers may not read the DNA specifications, so I'd like to take a step back and see if we can have a sane failure mode even for less sane changes. >>This shouldn't hamper progression of CPL at the moment. > > > Glad to hear that. :-) > > >>>FWIW I think this might be one reason that Keith Moore was concerned >>>about using prefixes for DNAs purpose. >> >>That's understandable. It would be good later to have his and >>other operational opinions of how relevant the problem is, and >>how the solutions may be impacted by it. > > > I talked with network operators and found out prefixes are > rather stable. So my guess is, this will not affect DNA much > except in some very volatile network which I can't imagine > right now. That's useful to know. There are a lot of issues in IPv6 which may increase prefix churn though (for example, if SHIM6 makes it simple to maintain sessions across renumbering). Also, we haven't seen wide deployment of DHCPv6 Prefix Delegation yet. In PD, as soon as the prefix's valid lifetime has expired it could be on another link. I'm not even sure we want to see what happens if there's state loss on the server (maybe this is a flash renumbering case). If we have to plan for address prefix boundaries other than /64, we may also have to plan for dynamic environments. >>I think that this is the right place to explore the issue then >>(if it's a small enough issue). >> >>Do you think we may need a short PS after IETF? > > > Both Linkid & Landmark/ CompleteRA deal with this in Open > Issue. > > For Linkid, there is > > Issue 003: Flash renumbering and early reassignment > > For Landmark/ CompleteRA, there is > > Issue 0012: Network renumbering - guidelines for deployment > > We may mention this problem in open issue presentation. That sounde like a fair idea. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 19:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkAD-0005RB-Jc for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 19:09:18 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29078 for ; Thu, 21 Jul 2005 19:09:09 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX5CCH6VA99PE26@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 09:08:57 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D576F8000E; Fri, 22 Jul 2005 09:08:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8030D3C00E; Fri, 22 Jul 2005 09:08:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LN8mr13142 for dna-list; Fri, 22 Jul 2005 09:08:48 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LN8lw13138 for ; Fri, 22 Jul 2005 09:08:47 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQX5C2V27E8WW80K@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 09:08:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E723AB545; Fri, 22 Jul 2005 09:08:40 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id CE16B4FB0B; Fri, 22 Jul 2005 09:08:38 +1000 (EST) Date: Fri, 22 Jul 2005 09:08:33 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s.LandmarkPrefix In-reply-to: <10e14db205072111007aa1d904@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Sathya Narayanan , JinHyeock Choi , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E02AF1.9050805@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <92e919fb050720221563f7ddd7@mail.gmail.com> <92e919fb05072022181c91ebf0@mail.gmail.com> <42DFAF13.9000700@Research.Panasonic.COM> <10e14db205072111007aa1d904@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: [cut] > > > > The difference MAY be more than what you have mentioned. > MN sends the linkid in RS not any prefix (which is the case in > Landmark approach), as the routers treat the (old) linkid prefixes > differently from the normal prefixes for graceful change in linkid. > Please see the section 3.5 Graceful linkid prefix change. > So the routers can give the correct answer compared to Landmark > where there is a posibility of conflicting answers. However the linkid > approach does not carry yes/no bit, instead hosts make decision > based on the linkid carried in RA. Careful choice of the landmark prefix will avoid problems like this in most cases. For example, using a "recently seen" landmark prefix which is known to be Preferred will limit the chance that the prefix is no longer known on-link (due to reconfiguration). For intermittently connected hosts, the choice of landmark may be poor, but then again, so would that host's knowledge of valid Prefix LinkIDs. So I think that it's possible to get around this potential difference with a line or two of text. Greg. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 19:21:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkLs-0001v4-RD for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 19:21:17 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01000 for ; Thu, 21 Jul 2005 19:21:13 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX5RG0PI899P2U1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 09:21:07 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2FBC880010; Fri, 22 Jul 2005 09:21:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id CBBC43C003; Fri, 22 Jul 2005 09:21:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LNKqt13298 for dna-list; Fri, 22 Jul 2005 09:20:52 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LNKpw13294 for ; Fri, 22 Jul 2005 09:20:51 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQX5R4LRNE9APFLS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 09:20:48 +1000 Received: by localhost (Postfix, from userid 510) id 211FCAB545; Fri, 22 Jul 2005 09:20:48 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1F8194FB07 for ; Fri, 22 Jul 2005 09:20:47 +1000 (EST) Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK0000223IK91@mailout1.samsung.com> for dna@eng.monash.edu.au; Fri, 22 Jul 2005 08:20:44 +0900 (KST) Received: from ep_spt01 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK000AKW3IK4K@ms7.samsung.com> for dna@eng.monash.edu.au; Fri, 22 Jul 2005 08:20:44 +0900 (KST) Content-return: prohibited Date: Thu, 21 Jul 2005 23:20:41 +0000 (GMT) From: Daniel Park Subject: Re: [DNA] FRD Implementation and Test Results Sender: owner-dna@ecselists.eng.monash.edu.au To: Heejin Jang Cc: "dna@eng.monash.edu.au" , JinHyeock Choi Reply-to: soohong.park@samsung.com Message-id: <0IK000AKX3IK4K@ms7.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050721232043311@soohong.park X-MTR: 20050721232043311@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: ** Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

Heejin, good job and here is a simple question;

 

It is possible that the host does not see any

Router Advertisements. What happen on this

situation ?

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

------- Original Message -------
Sender : Heejin Jang<heejin.jang@samsung.com> Assistant Research Staff/Communication & Networking Lab/Samsung Advanced Institute of Technology
Date : Jul 22, 2005 07:42
Title : [DNA] FRD Implementation and Test Results
Dear DNA WG,

We have implemented a FRD scheme of

Fast Router Discovery with L2 support
http://www.ietf.org/internet-drafts/draft-jinchoi-dna-frd-01.txt

In brief, we made an AP (Access Point) with a Linux box, which
caches a suitable RA and delivers it immediately upon a new L2
connection.

The code is just 31 lines for driver (with Scanning) and an MN
receives an RA within 1.3 ms in average. :-)

You can find the result in

http://www.diffeo.com/test/FRD_Implementation.ppt

Your feedback will be appreciated.

Regards, 
Heejin.

 

 


From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 21 20:03:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvl0c-0001m2-IK for dna-archive@megatron.ietf.org; Thu, 21 Jul 2005 20:03:22 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03973 for ; Thu, 21 Jul 2005 20:03:18 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQX561JHJC8WWAC0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 09:04:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D72B9AB54B; Fri, 22 Jul 2005 09:03:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 88E464FB03; Fri, 22 Jul 2005 09:03:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6LN3j013060 for dna-list; Fri, 22 Jul 2005 09:03:45 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6LN3jw13056 for ; Fri, 22 Jul 2005 09:03:45 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQX55TJC4E8WWABF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 09:03:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 598988000D; Fri, 22 Jul 2005 09:03:37 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 332653C012; Fri, 22 Jul 2005 09:03:37 +1000 (EST) Date: Fri, 22 Jul 2005 09:03:36 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DF54E9.6000502@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: JinHyeock Choi , Sathya Narayanan , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E029C8.4010604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> <42DF54E9.6000502@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Brett Pentland wrote: >> I guess that if the state + processing requirements for >> Landmark/CompleteRA and LinkID are comparable (which I've >> indicated may be the case), implementation experiences are >> qualitative, and in the normal case >> (and non-DNA case) all schemes act sensibly, the >> main issues will probably be: >> >> * Synchronization/How the schemes react to change of prefixes. >> >> * Packet Sizes >> >> Does this sound like the right criteria to compare >> the schemes on? > > > It would be good to also consider how the schemes interact with > non-DNA nodes. OK, Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 00:20:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvp15-0001Od-SR for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 00:20:07 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19183 for ; Fri, 22 Jul 2005 00:20:04 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXG7C4F5E9APIMU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 14:19:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 16369AB545; Fri, 22 Jul 2005 14:19:25 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B692B4FB06; Fri, 22 Jul 2005 14:19:24 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M4He416882 for dna-list; Fri, 22 Jul 2005 14:17:40 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M4Hdw16878 for ; Fri, 22 Jul 2005 14:17:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXG4WOSWQ99P7FF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 14:17:27 +1000 Received: by localhost (Postfix, from userid 510) id A808AAB545; Fri, 22 Jul 2005 14:17:27 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by moe.its.monash.edu.au (Postfix) with ESMTP id CA8644FB02 for ; Fri, 22 Jul 2005 14:17:25 +1000 (EST) Received: by zproxy.gmail.com with SMTP id m22so110568nzf for ; Thu, 21 Jul 2005 21:17:24 -0700 (PDT) Received: by 10.36.59.8 with SMTP id h8mr279611nza; Thu, 21 Jul 2005 21:14:50 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 21:14:50 -0700 (PDT) Date: Fri, 22 Jul 2005 13:14:50 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DD88F4.40209@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072121143c74ef12@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zs48W5fjLEjCNlmnE1SAGTHFZ0ERNJcvI7B5iVHgkli7ToWz5eI+dk2qGym58hsIerk0qqteaKNF25qch3RUd/MxSEHXRjOISpyB1KtCNYgsm48pWeE4B7ybgWPPYD736rRB8l+fdD2vTdGfGAMgnG76W1rvkXNKVMd+IUplxuE= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg Kindly understand my belated and un-chronological reply. > CompleteRA isn't difficult to synchronize at all. > > All routers immediately update their DNAPrefixList with a > prefix as soon as it is seen. > > The next RAs all contain the prefix. > > The prefix lifetime timers (and last seen timers) count down in > real-time on the routers (exactly like CPL). > > The (re-)advertised prefixes are only advertised so long as their > original prefixes are valid. This is available in the distributed > source code. I assume the above doesn't deal with the case of prefix addition or removal in which, I think, the real difficulty of synchronization lies. > > It can. It will simply pick the smallest prefix. > > Except if the non-DNA routers do not have the smallest prefix > configured (which was my point). I have difficulty understanding your concern. > The RAs received from non-DNA routers aren't guaranteed to have > any prefixes in common with the DNA (LinkID) routers. Linkid host doesn't make a decision based on RA without linkid prefix. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 00:20:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvp1h-0001aO-Rx for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 00:20:46 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19245 for ; Fri, 22 Jul 2005 00:20:41 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXG7NGJJM99P9F4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 14:19:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B6CA80011; Fri, 22 Jul 2005 14:19:40 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C38153C00C; Fri, 22 Jul 2005 14:19:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M4Ihf16898 for dna-list; Fri, 22 Jul 2005 14:18:43 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M4Iew16894 for ; Fri, 22 Jul 2005 14:18:40 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXG6F2TQO9APJMF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 14:18:40 +1000 Received: by localhost (Postfix, from userid 510) id C0502AB546; Fri, 22 Jul 2005 14:18:40 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by curly.its.monash.edu.au (Postfix) with ESMTP id CCFCD4FB04 for ; Fri, 22 Jul 2005 14:18:39 +1000 (EST) Received: by zproxy.gmail.com with SMTP id i28so111722nzi for ; Thu, 21 Jul 2005 21:18:38 -0700 (PDT) Received: by 10.36.71.18 with SMTP id t18mr307133nza; Thu, 21 Jul 2005 21:16:05 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 21:16:05 -0700 (PDT) Date: Fri, 22 Jul 2005 13:16:05 +0900 From: JinHyeock Choi Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <42E029A3.5010907@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0507212116452097bb@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N8FjLczqgxe2HdT9XukxCUKrx4I5W8wIZE7cUZPhNTsvwRuSSJyP9WLrgP5sc6m0OprkiNZrJHvtElyOzOhefanKSA9g9MF8OeC6pvwTL7yBdbaaBXh70OMapQmsXbzPd9tBH3OJnStt7tozG0V7I0DHQKThH+UkKNqu1ee/OGU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> <92e919fb050721020647eeb486@mail.gmail.com> <42E029A3.5010907@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > > Dormant mode also gives a problem. > > > > For example, assume a link with prefix Prefix1. A node N receives > > a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 > > is removed from the link and moved to the other link. Because > > N is in dormant mode, it doesn't know about this. Then N happens > > to move and awake to attach itself to the latter link. Because it sees > > Prefix1, it will falsely assume that it still is at the same link. > > Yes, I believe this is the same case as "intermittently connected" > though, as in both cases, the host is not aware of state changes > on the link. > > I guess we can collapse these two cases into one. ok. > > This is what I devise for linkid scheme. > > > > To solve "Flash renumbering and and early reassignment, linkid draft > > proposes that, when a linkid prefix is removed from a link, the linkid > > prefix should not be re-assigned to other link in 3 hours. With the > > above, a host would not see the same linkid prefix in two different links > > because linkid lifetime is 1.5 hour. > > This isn't a completely safe solution, since people do strange things > which violate recommendations they haven't read. I agree. But this is all I can think of right now. Also can there be a solution which is completely safe from a human folly? I doubt it. :-) > I used to work in Tech Support (in another life), so I know things > like this happen. > > Existing Router deployers may not read the DNA specifications, so I'd > like to take a step back and see if we can have a sane failure mode > even for less sane changes. Even in case of trouble from a rule violation, the bad effect will go away in 1.5 hours, just like the case of CPL. But if a better way to deal with this issue is designed, it will be nice. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 00:42:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvpMQ-00026B-HC for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 00:42:10 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20297 for ; Fri, 22 Jul 2005 00:42:06 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXGYZWPN69APDWO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 14:41:48 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A0E4AB542; Fri, 22 Jul 2005 14:41:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B5F024FB06; Fri, 22 Jul 2005 14:41:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M4fUl17217 for dna-list; Fri, 22 Jul 2005 14:41:30 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M4fSw17213 for ; Fri, 22 Jul 2005 14:41:28 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXGYJC52Q9APDWO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 14:41:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DC7CBAB543; Fri, 22 Jul 2005 14:41:20 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id B641E4FB05; Fri, 22 Jul 2005 14:41:20 +1000 (EST) Date: Fri, 22 Jul 2005 14:41:19 +1000 From: Greg Daley Subject: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt In-reply-to: <92e919fb0507212116452097bb@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E078EF.5060806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> <92e919fb050721020647eeb486@mail.gmail.com> <42E029A3.5010907@eng.monash.edu.au> <92e919fb0507212116452097bb@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock. I'm writing e-mails out-of-order too. JinHyeock Choi wrote: > Dear Greg > > >>>Dormant mode also gives a problem. >>> >>>For example, assume a link with prefix Prefix1. A node N receives >>>a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 >>>is removed from the link and moved to the other link. Because >>>N is in dormant mode, it doesn't know about this. Then N happens >>>to move and awake to attach itself to the latter link. Because it sees >>>Prefix1, it will falsely assume that it still is at the same link. >> >>Yes, I believe this is the same case as "intermittently connected" >>though, as in both cases, the host is not aware of state changes >>on the link. >> >>I guess we can collapse these two cases into one. > > > ok. > > >>>This is what I devise for linkid scheme. >>> >>>To solve "Flash renumbering and and early reassignment, linkid draft >>>proposes that, when a linkid prefix is removed from a link, the linkid >>>prefix should not be re-assigned to other link in 3 hours. With the >>>above, a host would not see the same linkid prefix in two different links >>>because linkid lifetime is 1.5 hour. >> >>This isn't a completely safe solution, since people do strange things >>which violate recommendations they haven't read. > > > I agree. But this is all I can think of right now. Also can there be > a solution which is completely safe from a human folly? I doubt it. :-) Apparently not, if you read the IETF list (people have been discussing phishing). >>I used to work in Tech Support (in another life), so I know things >>like this happen. >> >>Existing Router deployers may not read the DNA specifications, so I'd >>like to take a step back and see if we can have a sane failure mode >>even for less sane changes. > > > Even in case of trouble from a rule violation, the bad effect will go away > in 1.5 hours, just like the case of CPL. I was talking to Brett about this today. I agree that safety measures like that may be necessary in some form anyway, and it may make sense to ensure that the DNA devices take the action to expire bad information. > But if a better way to deal with this issue is designed, it will be nice. As I said before, it shouldn't slow down CPL since it's OK as it stands, though. If a bolt of inspiration comes, we'll explore things then. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 01:01:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvpeq-0002IO-87 for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 01:01:16 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21125 for ; Fri, 22 Jul 2005 01:01:09 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXHKMGF0K8WWD0W@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 15:00:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 08E66AB544; Fri, 22 Jul 2005 14:59:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9D3B84FB10; Fri, 22 Jul 2005 14:59:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M4wpn17441 for dna-list; Fri, 22 Jul 2005 14:58:51 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M4wow17437 for ; Fri, 22 Jul 2005 14:58:51 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXHJZUTS89APIGM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 14:58:39 +1000 Received: by localhost (Postfix, from userid 510) id 0024A8000F; Fri, 22 Jul 2005 14:58:38 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8CE8E3C003 for ; Fri, 22 Jul 2005 14:58:37 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so115533nzp for ; Thu, 21 Jul 2005 21:58:36 -0700 (PDT) Received: by 10.36.60.18 with SMTP id i18mr1394477nza; Thu, 21 Jul 2005 21:55:47 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 21:55:47 -0700 (PDT) Date: Fri, 22 Jul 2005 13:55:47 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42DD9009.8060108@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Syam Madanapalli , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050721215591928a4@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Xuz1PU/DsnLkhZsE0DN+BHqmQfmwoc5NjbZYTrNcSd4f+k15WSXYkPFdBBVd9tTTYq8p6vXgQ4BXSSUV26OOrEcy/DSHQRH3K3TmytUbhRJQW+raHW9LmE3R1BY/+kvMZT/rLwAVjJjXz4u1Tn+81b5H9lIPU0CL+9tWm/wsdzU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > > Linkid scheme also works with RS as well as without RS if the node > > was on a DNA capable link previously. Definitely I see the advantage > > of Landmark if the node is moving from non-DNA link. > > The same can be said of CompleteRA (which has [provably] exactly > the same properties as LinkID of being able to detect link change > with DNA routers). > > The omission of RS only works in constrained environments > where one already has the right link information (FMIPv6 > predictive handover), or the Network infrastructure > can be known beforehand to provide RA information (conceivably > FastRD in a constrained environment). I don't think this is correct. For example, FRD works with current 2461 standard. Upon network attachment, a host will perform random delay before sending RS (average 500ms). During which, the host will receive an RA optimized for DNA to complete DNA. Also we can't say FMIPv6 and FRD are the only ways to perform DNA without RS. There is a possibility of other schemes. > Neither of these scenarios is under consideration for the > main DNA solution (FMIPv6 because it works without RA, FastRD > because it isn't generally applicable), As of my memory, WG didn't made such a decision. Also I don't think that the above description is exactly correct. I talked with mobile/cellular operators and in such a environment, FRD is generally very well applicable. > So I don't think we can champion one particular technology based > on the fact that it works (slowly in general) with unsolicited RA. Disagree. This may be a serious concern for moible/ceullar operators. DNA is rather about optimization, quickly checking for link change to support seamless handoff. So I think main (at least substantial part of) customers for DNA will be mobile operators It's my opinion that if one scheme can perform DNA without RS involvement, that's the pro for the scheme we need to take into consideration. > > As a host can build the complete prefix list on its own without explicit > > support for complete RA, we may need to carefully evaluate it's benefits > > against the bandwidth consumption on the link as well as synchronization > > complexity. A host may need to be at the link for less than a minute to > > acquire the complete prefix list, the chances of a node moving away from > > the link within few seconds may be less. > > But we already have CPL, and we know what its limitations are. > > The time to build sufficient information to Detect change is the > critical issue: Otherwise we wouldn't have any link > identification mechanism in the DNA solution. CPL is good > enough if you've got the time and energy to probe for RAs. > > If we want to support (potentially) rapidly changing attachment, > the state on the host needs to be as up to date as possible, whether > using a landmark, a link-id or CompleteRA. According to the current CPL recommendation, it will take 4 secs for a host to generate the complete prefix list. I think it's rather an exceptional case for a host to change attachment within 4 secs after network attachment. > CompleteRA has the potential to create a CPL immediately, which > is better for the "movement to non-DNA" link case. I may add "with added synchronization cost". > > As we have implemented the linkid scheme, we did not find any such problems. > > For landmark also all the Routers need know about all other prefixes, otherwie > > the host may get conflict answers. > > It doesn't need to know all the prefixes (as described in a previous > thread). It needs to know what prefixes it definitely has locally. > > In that case, it can answer "Yes" immediately. Answering "No" takes > definitive knowledge and synchronization. Answering "Yes" also takes definite knowledge and synchronization. Allow me an example. Assume a link with two routers R1 and R2. R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. R1 and R2 gathers the prefixes to make the complete prefix list {Prefix1, Prefix2, Prefix3}. Then R2 removes Prefix3 but the RA advertising the removal was lost and R1 doesn't receive it. So afterwards, if a (dormant) host send an RS with Prefix3 to R1, it will falsely answer "YES", i.e. Prefix3 is in this link. Am I missing something? > A prefix which answers > "Yes" will supercede a "No" if it is received first. I guess the same applies for "NO". "NO" will supercede a "YES", if it is received first, right? > The chance that a router will answer "No" when another answers "Yes" > is the chance that a prefix's advertisement has not been received > on the "No" router before the RS with a landmark query is sent. > > This is bounded by the delay of the original RA to cross the network, > and any robustness factors affecting delivery between pairs of routers. > > As the solicitor would have to have received the landmark prefix in > an RA before it can send the landmark RS, the chances are really > quite small that any remaining router would be not be updated > before answering the landmark query. In the example I present the above, "NO" is the correct one and doesn't result from "that a prefix's advertisement has not been received on the "No" router before the RS with a landmark query is sent." Correct me wrong but when I looked through Landmark/ CompleteRA last time, I don't see any mechanism to deal with the case two routers give conflicting answers, one yes and the other no. Such a case can arise from a lack of synchronization. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 01:48:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqOo-00063r-18 for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 01:48:46 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23315 for ; Fri, 22 Jul 2005 01:48:39 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXJA814K89APFKY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 15:48:05 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D1809AB54B; Fri, 22 Jul 2005 15:48:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7835E4FB03; Fri, 22 Jul 2005 15:48:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M5iW418001 for dna-list; Fri, 22 Jul 2005 15:44:32 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M5iVw17997 for ; Fri, 22 Jul 2005 15:44:31 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXJ5UG5CQ99O2M8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 15:44:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 476B08000F; Fri, 22 Jul 2005 15:44:30 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 249D63C013; Fri, 22 Jul 2005 15:44:30 +1000 (EST) Date: Fri, 22 Jul 2005 15:44:29 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072121143c74ef12@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E087BD.9060503@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD88F4.40209@eng.monash.edu.au> <92e919fb05072121143c74ef12@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: > Dear Greg > > Kindly understand my belated and un-chronological reply. > > >>CompleteRA isn't difficult to synchronize at all. >> >>All routers immediately update their DNAPrefixList with a >>prefix as soon as it is seen. >> >>The next RAs all contain the prefix. >> >>The prefix lifetime timers (and last seen timers) count down in >>real-time on the routers (exactly like CPL). >> >>The (re-)advertised prefixes are only advertised so long as their >>original prefixes are valid. This is available in the distributed >>source code. > > > I assume the above doesn't deal with the case of prefix addition or > removal in which, I think, the real difficulty of synchronization lies. Actually, I think it does cover this. Since the routers don't go to sleep, and are likely to see each others' advertisements within a finite (MaxRtrAdvInterval < 30s) period of time, They will see also advertisements with retracted prefixes (0 lifetime) with high probability. Routers can immediately stop advertising a prefix. Advertisements of the CompleteRA therefore can exclude particular prefixes which are no-longer on link, and this information can be taken as authoritative by hosts: The router thinks the current prefix list is complete, even though it doesn't contain the prefix (the host dumps the prefix). This works since the completeRA will also contain any other prefixes on the link, and no change detection will occur (as the prefixes shouldn't be disjoint). New prefixes are much easier, since as CompleteRAs overlap (only differ by the new prefixes), no change detection occurs. It is possible that the routers do not agree about all of the prefixes available on a link, but the routers will have some information in common before the prefix is added, > >>>It can. It will simply pick the smallest prefix. >> >>Except if the non-DNA routers do not have the smallest prefix >>configured (which was my point). > > > I have difficulty understanding your concern. CompleteRA routers contain all (A=1,L=1) prefixes on the link. So even if the non-DNA router has (originally) disjoint prefixes any RA from either a non-DNA or DNA router will share information in common (the non-DNA router's own prefix). Therefore any reception of an RA from a DNA or non DNA source can immediately be identified as a change or no change. This is a lot faster than moving to a network that doesn't support DNA, if the DNA solution uses a LinkID instead. It's necessary to fall back to RS/RA exchanges. We encountered this problem with numeric LinkIDs a long time ago before CPL was around (CPL improves things). >>The RAs received from non-DNA routers aren't guaranteed to have >>any prefixes in common with the DNA (LinkID) routers. > > > Linkid host doesn't make a decision based on RA without linkid prefix. That makes sense. On the DNA link the host will still need to do RS/RA exchanges to build its CPL though, otherwise CPL logic won't work immediately either. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 01:57:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqX5-0002O9-8t for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 01:57:17 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23759 for ; Fri, 22 Jul 2005 01:57:12 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXJKW6GXE8Y58O3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 15:56:51 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3CB1C8000E; Fri, 22 Jul 2005 15:56:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id ED94E3C014; Fri, 22 Jul 2005 15:56:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M5uVu18171 for dna-list; Fri, 22 Jul 2005 15:56:31 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M5uUw18167 for ; Fri, 22 Jul 2005 15:56:30 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXJKG7NEI9APIR5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 15:56:17 +1000 Received: by localhost (Postfix, from userid 510) id E6A02AB545; Fri, 22 Jul 2005 15:56:16 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by moe.its.monash.edu.au (Postfix) with ESMTP id D2D084FB08 for ; Fri, 22 Jul 2005 15:56:15 +1000 (EST) Received: by zproxy.gmail.com with SMTP id o37so120096nzf for ; Thu, 21 Jul 2005 22:56:14 -0700 (PDT) Received: by 10.36.220.70 with SMTP id s70mr350728nzg; Thu, 21 Jul 2005 22:53:28 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 21 Jul 2005 22:53:28 -0700 (PDT) Date: Fri, 22 Jul 2005 14:53:28 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix In-reply-to: <42DE8DD7.1070406@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072122531e53c073@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hPKSaxXLX9IBXsY4Nd4XgXiP1s/4gsMVg9PycLTRqUC445EOEtNyw4SCR/AUne78i0Grhm4Xhgg0meuEFusxC5umh73XRqHRlXZ41/5TwR4gIDkK6Bf800hB1n90wED2Cy6vjGH0BuSTwW47Uc5MyqqmNqhpaT+D0EP3u4y6Ekk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <42DD4A58.80003@Research.Panasonic.COM> <060c01c58cdd$0bdc5fa0$59476c6b@sisodomain.com> <42DE8DD7.1070406@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > So, in conclusion, the synchronization requirement and > complexity for Landmark, CompleteRA and LinkID are the same - all three > of them require that all the routers on the link know about all the > prefixes on the link within a reasonable time - the difference is only > in the content of the RS/RA messages. Do you agree? No. Linkid draft deals with synchronization problem by taking extra care of linkid prefix with such schemes as "linkid prefix list" or "linkid prefix lifetime". It's my guess that, for CompleteRA or Landamrk, such extra cares need to be be applied to all the prefixes. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 02:26:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqzM-0007l4-Tb for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 02:26:33 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16387 for ; Fri, 22 Jul 2005 02:26:25 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXKJWDB328Y58RR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 16:25:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 99D6CAB543; Fri, 22 Jul 2005 16:24:04 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3AE214FB02; Fri, 22 Jul 2005 16:24:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M6Njv18485 for dna-list; Fri, 22 Jul 2005 16:23:45 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M6Njw18481 for ; Fri, 22 Jul 2005 16:23:45 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXKJ2TW268Y58RR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 16:23:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D738880018; Fri, 22 Jul 2005 16:23:24 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id A70B73C005; Fri, 22 Jul 2005 16:23:24 +1000 (EST) Date: Fri, 22 Jul 2005 16:23:24 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050721215591928a4@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , James Kempf , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42E090DC.6040408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, Right at the bottom is a proposal for a "Graceful" means of surviving flash renumbering with Prefix Landmarks. It's not really necessary in the general case if routers retract prefixes with lifetime=0 advertisements, if they wish to assign the prefix elsewhere before normal lifetime expiry. JinHyeock Choi wrote: > Greg > > >>>Linkid scheme also works with RS as well as without RS if the node >>>was on a DNA capable link previously. Definitely I see the advantage >>>of Landmark if the node is moving from non-DNA link. >> >>The same can be said of CompleteRA (which has [provably] exactly >>the same properties as LinkID of being able to detect link change >>with DNA routers). >> >>The omission of RS only works in constrained environments >>where one already has the right link information (FMIPv6 >>predictive handover), or the Network infrastructure >>can be known beforehand to provide RA information (conceivably >>FastRD in a constrained environment). > > > I don't think this is correct. > > For example, FRD works with current 2461 standard. Upon network > attachment, a host will perform random delay before sending RS > (average 500ms). During which, the host will receive an RA optimized > for DNA to complete DNA. You are right only if the DNA host _knows_ FastRD is present. Then it can defer sending an RS. If it doesn't know of FastRD's presence, it cannot afford to wait before sending RS (500ms is so much longer than a VoIP session can hide, and potentially longer than a TCP window transmission). RFC2461bis already describes removal of the 0-1000ms delay on reception of link-layer indication. I don't think hosts need to defer RS transmission if they're unaware of the fact that FastRD is available on the link. Remember the goal G2 for DNA: G2 DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption. If there's no knowledge that FastRD is available in a domain, there can be no deferral of DNA to potentially save one RS. > Also we can't say FMIPv6 and FRD are the only ways to perform > DNA without RS. There is a possibility of other schemes. But we're not standardizing those unnamed schemes: As in RFC 1958 section 3.7, we have an almost complete solution, we're not likely to defer making a decision about something to support future (unmentioned) solutions. >>Neither of these scenarios is under consideration for the >>main DNA solution (FMIPv6 because it works without RA, FastRD >>because it isn't generally applicable), > > > As of my memory, WG didn't made such a decision. It made the decision at the same time it discarded Numeric LinkIDs, Deterministic FastRA etc: when it agreed to focus on 0ne or Two potential solutions (with specific properties) at the last IETF. > Also I don't think that the above description is exactly correct. I talked > with mobile/cellular operators and in such a environment, FRD is generally > very well applicable. But it's not the basic DNA solution: it's an optimization which cannot be applied to every network. >>So I don't think we can champion one particular technology based >>on the fact that it works (slowly in general) with unsolicited RA. > > > Disagree. This may be a serious concern for moible/ceullar operators. > > DNA is rather about optimization, quickly checking for link change to support > seamless handoff. So I think main (at least substantial part of) customers for > DNA will be mobile operators Not every network is to be run by cellular operators. Almost every network will need DNA. Cellular operators are likely to deploy further infrastructure such as FMIPv6 to support fast handovers. In that case, queuing an RA upon attachment to a new cell only induces delay. > It's my opinion that if one scheme can perform DNA without RS involvement, > that's the pro for the scheme we need to take into consideration. It's no more a pro for LinkID than for CompleteRA. If we have a FastRD scheme, it doesn't really matter which of those is deployed. >>>As a host can build the complete prefix list on its own without explicit >>>support for complete RA, we may need to carefully evaluate it's benefits >>>against the bandwidth consumption on the link as well as synchronization >>>complexity. A host may need to be at the link for less than a minute to >>>acquire the complete prefix list, the chances of a node moving away from >>>the link within few seconds may be less. >> >>But we already have CPL, and we know what its limitations are. >> >>The time to build sufficient information to Detect change is the >>critical issue: Otherwise we wouldn't have any link >>identification mechanism in the DNA solution. CPL is good >>enough if you've got the time and energy to probe for RAs. >> >>If we want to support (potentially) rapidly changing attachment, >>the state on the host needs to be as up to date as possible, whether >>using a landmark, a link-id or CompleteRA. > > > According to the current CPL recommendation, it will take 4 secs for > a host to generate the complete prefix list. I think it's rather an > exceptional case for a host to change attachment within 4 secs > after network attachment. It's not that hard to change attachment points quickly with ping-pong. This is a well known problem. I'm not in strict agreement with the single RS for CPL, since RA messages can be lost, and you can end up with half a CPL. If you transit outside the cell within 4 seconds, false link change detection occurs. I'd prefer "At least 1" or "Defaults to 1" x 4 seconds. >>CompleteRA has the potential to create a CPL immediately, which >>is better for the "movement to non-DNA" link case. > > > I may add "with added synchronization cost". That's not really true, if you've read the other posts in this thread. CompleteRA is more reliable than CPL, since routers don't go to sleep often (routers build better lists than hosts). >>>As we have implemented the linkid scheme, we did not find any such problems. >>>For landmark also all the Routers need know about all other prefixes, otherwie >>>the host may get conflict answers. >> >>It doesn't need to know all the prefixes (as described in a previous >>thread). It needs to know what prefixes it definitely has locally. >> >>In that case, it can answer "Yes" immediately. Answering "No" takes >>definitive knowledge and synchronization. > > > Answering "Yes" also takes definite knowledge and synchronization. > > Allow me an example. Assume a link with two routers R1 and R2. > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > R1 and R2 gathers the prefixes to make the complete prefix list > {Prefix1, Prefix2, Prefix3}. > > Then R2 removes Prefix3 but the RA advertising the removal > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > host send an RS with Prefix3 to R1, it will falsely answer "YES", > i.e. Prefix3 is in this link. > > Am I missing something? Yes. The same thing happens with LinkID In this case, the Router1 will not identify that the LinkID has changed either, if the smallest prefix disappears (for example if Prefix3 is actually the smallest prefix). Responses for LinkID will therefore also conflict, Router1 will have a LinkID of prefix Prefix3, even if that prefix has been assigned to an adjacent link. For Prefix Landmarking: If any RAs by received by R1 indicating that the lifetime is diminished, this will time out the entries. Any single reception of a lifetime zero advertisement from the owning router will remove the prefix. This is the same as LinkID. So if Prefix Landmarking believes the prefix is still on-link (and Prefix Landmarking has similar timers for lifetimes that LinkID does) then the incorrect state will last about as long for either. The assumption is that prefixes retracted without (effective) zero lifetime advertisement and assigned to another link cause problems for up to 90 minutes or so: This is the same for Prefix Landmarks, CompleteRA, LinkID and (in hosts' view) CPL. This is a very tight corner case, since routers listen to RAs in DNA, don't sleep, and routers should retract prefixes. At least with CompleteRA, you can ignore learned DNAO contents since the rest of the CompleteRA will not match the existing Complete Prefix List. >>A prefix which answers >>"Yes" will supercede a "No" if it is received first. > > > I guess the same applies for "NO". > > "NO" will supercede a "YES", if it is received first, right? Yes, but a false movement detection is actually better than a false non-movement detection, since the host recovers in milliseconds, not minutes. >>The chance that a router will answer "No" when another answers "Yes" >>is the chance that a prefix's advertisement has not been received >>on the "No" router before the RS with a landmark query is sent. >> >>This is bounded by the delay of the original RA to cross the network, >>and any robustness factors affecting delivery between pairs of routers. >> >>As the solicitor would have to have received the landmark prefix in >>an RA before it can send the landmark RS, the chances are really >>quite small that any remaining router would be not be updated >>before answering the landmark query. > > In the example I present the above, "NO" is the correct one and > doesn't result from "that a prefix's advertisement has not been received > on the "No" router before the RS with a landmark query is sent." I see your point: the most up-to-date router could respond "NO" based on updated information. In that case though, it can also update the other routers with the appropriate RA (prefix lifetime=0). The window in that case is still fairly small. > Correct me wrong but when I looked through Landmark/ CompleteRA > last time, I don't see any mechanism to deal with the case two routers > give conflicting answers, one yes and the other no. Such a case can > arise from a lack of synchronization. Indeed, this is the same as LinkID, where the out-of-date LinkID is still used by a router which has not seen the PIO with the prefix retracted. While Prefix Landmarks can conceivably answer "Yes" incorrectly in this case, so would some of the LinkID routers. A practical solution for Prefix Landmarks may be to partly ignore "Yes" answers - since they don't require much action: that is keep the DNA process open if there's a non-movement indication. The DNA addressing mechanism may be re-normalized (and packet flow can occur with the global addresses), but subsequent reception of a trusted "No" RA within (say 500ms) could be used as a hint to re-build a CPL - which may be a cause to detect change in a few seconds. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 03:19:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvrp5-0004ze-IN for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 03:19:55 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19341 for ; Fri, 22 Jul 2005 03:19:52 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXMHQXZB899P47T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 17:19:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 89F448000F; Fri, 22 Jul 2005 17:19:36 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2B1A53C011; Fri, 22 Jul 2005 17:19:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M7J0k19152 for dna-list; Fri, 22 Jul 2005 17:19:00 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M7Ixw19148 for ; Fri, 22 Jul 2005 17:18:59 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXMGPNC7Y99O0IJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 17:18:46 +1000 Received: by localhost (Postfix, from userid 510) id A2A458000D; Fri, 22 Jul 2005 17:18:46 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6BCAB3C010; Fri, 22 Jul 2005 17:18:45 +1000 (EST) Date: Fri, 22 Jul 2005 00:18:36 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, JinHyeock Choi Cc: Sathya Narayanan , Brett Pentland , Dna Message-id: <00fc01c58e8d$950123e0$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg, I think there is also the backward compatibility issue, which you raised. jak ----- Original Message ----- From: "Greg Daley" To: "JinHyeock Choi" Cc: "Sathya Narayanan" ; "Brett Pentland" ; "James Kempf" ; "Dna" Sent: Wednesday, July 20, 2005 11:52 PM Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > Hi JinHyeock, > > JinHyeock Choi wrote: > > Sathya > > > > Sorry for a late reply. After FRD completeion, I am still busy > > catching up baglog mails. > > > > > >>I don't think this is accurate in comparison to synchronizing for > >>prefix-LinkID. Prefix LinkID requires the completeRA list to be > >>synchronized in each of the routers so that the least prefix can be > >>selected from the list as LinkID. So the synchronization/bandwidth > >>requirements are the same for both CompleteRA and Prefix LinkID. > > > > > > I may not be clear. > > > > The difficulty in synchronization lies in when a prefix is added or > > removed. There is a scheme for graceful linkid change in Linkid but, > > correct me wrong, nothing like that in Landmark/ CompleteRA. > > I think that there's no scheme defined in Landmark/CompleteRA, > but (in my guess) the choice of the scheme itself will significantly > affect whether particular "config" change management (rather than link > change management) schemes are needed. > > > I remember that DT discussed much about the flapping > > probmem in CompleteRA synchronization difficulty (w.r.t the prefix > > number) in 'CompleteRA Polished' thread. > > Thanks for the pointer to this thread. > > I think there are two or three related threads: > > Complete RA Polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-03/msg00157.html > > Complete RA Re-polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00009.html > > LinkID Polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00097.html > and > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/threads.html > > > It's good to know that there's been so much work on this (and > that everyone can read it). > > There were a lot of differences between individual schemes > as portrayed before (in April) and now though. This may > affect the way prefix addition or subtraction works. > > Given the individual current schemes though, let's try to characterise > the effects of addition or substraction of prefixes on each protocol > as configured today. > > Does that sound reasonable? > > I guess that if the state + processing requirements for > Landmark/CompleteRA and LinkID are comparable (which I've > indicated may be the case), implementation experiences are > qualitative, and in the normal case > (and non-DNA case) all schemes act sensibly, the > main issues will probably be: > > * Synchronization/How the schemes react to change of prefixes. > > * Packet Sizes > > Does this sound like the right criteria to compare > the schemes on? > > There may not be a clear winner with any of these, and > it may be that the WG just chooses a particular > scheme it likes. > > The comparison is likely to help with forming that opinion, > and may actually highlight a winner. > > Should we go ahead? > > It may mean some in-depth description of how the schemes > currently handle change (which may take some discussion). > > I think that we need to compare packet sizes for: > > RS/RA exchange for each scheme (or set of schemes) as described > in current drafts. > > Where: > > a) 1 prefix is shared by all routers > > b) 1 distinct prefix is configured on each router. > > c) 1 prefix is shared by all routers and one additional prefix is > advertised by one router (big or small prefix). > > We should probably do this for 1,2 routers (though the third > test may be a bit simple with 1 router - one router 2 prefixes). > > We should sum the sizes of the response RAs for all routers. > > Does this sound OK with people? > > Greg > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 03:26:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvrva-0000At-Es for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 03:26:42 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19661 for ; Fri, 22 Jul 2005 03:26:35 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXMPZSJNW99OVCW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 17:26:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6E6EBAB545; Fri, 22 Jul 2005 17:26:15 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2DF804FB07; Fri, 22 Jul 2005 17:26:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M7Q8h19250 for dna-list; Fri, 22 Jul 2005 17:26:08 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M7Q7w19246 for ; Fri, 22 Jul 2005 17:26:07 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXMPMK9H099P2V3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 17:25:58 +1000 Received: by localhost (Postfix, from userid 510) id D0AEC80012; Fri, 22 Jul 2005 17:25:57 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 02D8E3C00E; Fri, 22 Jul 2005 17:25:56 +1000 (EST) Date: Fri, 22 Jul 2005 00:25:49 -0700 From: James Kempf Subject: Dormant Mode and DNA (was: Re: [DNA] Re: About draft-ietf-dna-cpl-00.txt) Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: Erik Nordmark , athene@sait.samsung.co.kr, dna@eng.monash.edu.au Message-id: <014401c58e8e$96d6d8d0$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <42DB68CF.4060104@sun.com> <42DC532A.6040103@eng.monash.edu.au> <42DCB594.1010105@sun.com> <42DD869A.8050402@eng.monash.edu.au> <92e919fb050721020647eeb486@mail.gmail.com> Content-Transfer-Encoding: 7BIT > > I think that the problem in DNA comes (primarily) where there's > > lingering state in the network: a host or router which hasn't seen > > the zero lifetime retraction. > > > > A zero lifetime retraction is a valid mechanism, but intermittently > > connected hosts may not receive the notification that the prefix is > > no longer connected. > > Dormant mode also gives a problem. > > For example, assume a link with prefix Prefix1. A node N receives > a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 > is removed from the link and moved to the other link. Because > N is in dormant mode, it doesn't know about this. Then N happens > to move and awake to attach itself to the latter link. Because it sees > Prefix1, it will falsely assume that it still is at the same link. > > > I'd like to sit and think for a little while and determine if there's > > a completely safe way to handle knowledge used for CPL (or CompleteRA > > etc.) without facing the danger that the prefixes will be classified > > as belonging to one link (when in fact they belong to two, from two > > different times). > Like I said during the design team discussions, dormant mode must be handled separately. When the host drops into dormant mode, it must invalidate any local link state and start from scratch when it comes out. There is other local link state that needs to be handled like this, for example autoconfigured addresses. The node shouldn't have to wake up in order to defend its address. Hence, there is no point in having it hang onto DNA state. Personally, I think we need to spend some time thinking about dormant mode a little more deeply, rather than trying to bring issues involving dormant mode up piecemeal in various contexts (it came up recently during the MIPv6 to IPv4 DT discussions too). These peripherial discussions lead to rather superficial suggestions for solutions, that don't consider the entire spectrum of what is needed to properly support dormant mode. Perhaps we need to have a BOF specifically on dormant mode support. jak From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 03:51:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvsK7-0002sQ-DL for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 03:51:59 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21058 for ; Fri, 22 Jul 2005 03:51:56 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXNLODBFA9API1L@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 17:51:52 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0B6D1AB543; Fri, 22 Jul 2005 17:51:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C244A4FB08; Fri, 22 Jul 2005 17:51:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M7pY719592 for dna-list; Fri, 22 Jul 2005 17:51:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M7pXw19588 for ; Fri, 22 Jul 2005 17:51:33 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXNLBOBNS8Y59FF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 17:51:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A1D9AB544; Fri, 22 Jul 2005 17:51:31 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id D258D4FB03; Fri, 22 Jul 2005 17:51:30 +1000 (EST) Date: Fri, 22 Jul 2005 17:51:29 +1000 From: Brett Pentland Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050721215591928a4@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E0A581.5030407@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, >>>As we have implemented the linkid scheme, we did not find any such problems. >>>For landmark also all the Routers need know about all other prefixes, otherwie >>>the host may get conflict answers. >> >>It doesn't need to know all the prefixes (as described in a previous >>thread). It needs to know what prefixes it definitely has locally. >> >>In that case, it can answer "Yes" immediately. Answering "No" takes >>definitive knowledge and synchronization. > > > Answering "Yes" also takes definite knowledge and synchronization. > > Allow me an example. Assume a link with two routers R1 and R2. > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > R1 and R2 gathers the prefixes to make the complete prefix list > {Prefix1, Prefix2, Prefix3}. > > Then R2 removes Prefix3 but the RA advertising the removal > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > host send an RS with Prefix3 to R1, it will falsely answer "YES", > i.e. Prefix3 is in this link. > > Am I missing something? Well, "YES" is the answer that LinkID would give too. The LinkID would not have changed on R1 and the host would correctly recognise that it is NOT a link change. So how is it better? With Landmarks, when the subsequent advertisement from R2 came in it would say NO, and list the available prefixes. This list would have some overlap with the prefixes that the host has seen and so it would again realise that there is no link change, and yet would be able to see that Prefix3's lifetime is zero and it had better use a different Landmark next time. You say that LinkID has a method to deal with changing prefixes. Hosts keep a record previously seen LinkIDs so that they can recognise changes. Isn't this implicit in the CompleteRA aspect of the landmark proposal? Each of the prefixes can be thought of as a LinkID, and any overlap between the prefixes in a CompleteRA and the prefixes that the host has seen implies non-movement. Putting aside, for the moment, cases where a prefix is moved to a new link before its lifetime advertised on the old link has expired, your own example shows how the Landmark part deals with changes effectively. A YES answer will only occur if the prefix has been used on the link and so will not be wrong in the sense that the current link is the same one where the Landmark came from. If that prefix is in the process of being removed, then very soon a NO answer will arrive from the applicable router informing the host of this and providing the prefixes that are available. Note also that the window of oportunity for this to happen is quite small as the router that removed the prefix should advertise this fact several times in a fairly short space of time so that all of the routers on the link are aware of the change. Returning to cases where prefixes can be reasigned to a new link before the expiry of a previously advertised valid lifetime on another link, both of the proposals face the same issue and need to deal with it by placing rules about how the reassignment is done. If a host sees a LinkID or a Landmark on one link, fails to see advertisements that the valid lifetime has been shortened, and then sees the same LinkID / Landmark on another link, they will fail to detect the link change. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 04:16:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvshv-0004Pt-4x for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 04:16:35 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22126 for ; Fri, 22 Jul 2005 04:16:31 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXOGE0ZUG8WWEJN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 18:16:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8C83AB545; Fri, 22 Jul 2005 18:15:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 50CF44FB09; Fri, 22 Jul 2005 18:15:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6M8FVx19872 for dna-list; Fri, 22 Jul 2005 18:15:31 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6M8FVw19868 for ; Fri, 22 Jul 2005 18:15:31 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXOFTK6AQ99P8IK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 18:15:19 +1000 Received: by localhost (Postfix, from userid 510) id 7F82C8000D; Fri, 22 Jul 2005 18:15:19 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 88CAA3C010; Fri, 22 Jul 2005 18:15:18 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK000EQ0S9GH6@mailout3.samsung.com>; Fri, 22 Jul 2005 17:15:16 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK000ER2S98SJ@mmp1.samsung.com>; Fri, 22 Jul 2005 17:15:16 +0900 (KST) Date: Fri, 22 Jul 2005 13:41:25 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Sathya Narayanan Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <04e801c58e94$f84c9680$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951599a65f7@mail.gmail.com> <42DD39A0.3040009@Research.Panasonic.COM> <42DD4A58.80003@Research.Panasonic.COM> <060c01c58cdd$0bdc5fa0$59476c6b@sisodomain.com> <42DE8DD7.1070406@Research.Panasonic.COM> <92e919fb05072122531e53c073@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi Satya, > > > So, in conclusion, the synchronization requirement and > > complexity for Landmark, CompleteRA and LinkID are the same - all three > > of them require that all the routers on the link know about all the > > prefixes on the link within a reasonable time - the difference is only > > in the content of the RS/RA messages. Do you agree? > > No. Linkid draft deals with synchronization problem by taking extra > care of linkid prefix with such schemes as "linkid prefix list" or "linkid > prefix lifetime". In linkid sceme ,Even if some routers misses some RAs (containing changed prefix information), because of which, these routers will be advertising old linkid, hosts will not make wrong decision by looking at different linkids advertised by different routers. If the routers can learn change in prefixes in 1.5 hours, it is not a problem in linkid. I think 1.5 hours (i.e, atleast 3 RAs will be transmitted) is fairly good enough. Thanks & Regards, Subba Reddy >It's my guess that, for CompleteRA or Landamrk, such > extra cares need to be be applied to all the prefixes. > > Best Regards > > JinHyeock > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 06:23:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvuh4-0001Gu-Sv for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 06:23:55 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28826 for ; Fri, 22 Jul 2005 06:23:46 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXSW4VBHK8Y56AY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 20:23:46 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 406C8AB543; Fri, 22 Jul 2005 20:23:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id EDE104FB0E; Fri, 22 Jul 2005 20:22:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6MAMOl21317 for dna-list; Fri, 22 Jul 2005 20:22:24 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6MAMNw21313 for ; Fri, 22 Jul 2005 20:22:23 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXSVCOB708WWFBM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 20:22:22 +1000 Received: by localhost (Postfix, from userid 510) id B6764AB542; Fri, 22 Jul 2005 20:22:22 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by curly.its.monash.edu.au (Postfix) with ESMTP id 742314FB02 for ; Fri, 22 Jul 2005 20:22:20 +1000 (EST) Received: by zproxy.gmail.com with SMTP id j25so158445nzf for ; Fri, 22 Jul 2005 03:22:10 -0700 (PDT) Received: by 10.36.7.20 with SMTP id 20mr1311685nzg; Fri, 22 Jul 2005 01:33:41 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 01:33:41 -0700 (PDT) Date: Fri, 22 Jul 2005 17:33:41 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <42DF4642.3090407@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050722013353f58362@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fxGnjDFV7HR/U/iQw9UIIVaGjTtK9pYqvtILrMI2AUnl94YXxfQpjuUGAbzJoHsQyL6Kd14k/uPKvexnUhhZ+cLaO+vwhiSXxZ+/47TUJUpJo164jIzM/iU6N7mGHBAoSHhpAgsPLU5edzmlq+vTti2Bh+fVZToTJuHCqfXP2Is= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > I think there are two or three related threads: > > Complete RA Polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-03/msg00157.html > > Complete RA Re-polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00009.html > > LinkID Polished > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00097.html > and > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/threads.html > > It's good to know that there's been so much work on this (and > that everyone can read it). It will be nice if the above threads are of help. > There were a lot of differences between individual schemes > as portrayed before (in April) and now though. This may > affect the way prefix addition or subtraction works. Actually the main changes results from the synchronization difficulties. > Given the individual current schemes though, let's try to characterise > the effects of addition or substraction of prefixes on each protocol > as configured today. > > Does that sound reasonable? > > I guess that if the state + processing requirements for > Landmark/CompleteRA and LinkID are comparable (which I've > indicated may be the case), implementation experiences are > qualitative, and in the normal case > (and non-DNA case) all schemes act sensibly, the > main issues will probably be: > > * Synchronization/How the schemes react to change of prefixes. > > * Packet Sizes > > Does this sound like the right criteria to compare > the schemes on? It's my opinion that just the above two are too narrow a criteria, (though I agree that both of them good). I think other criteria such as 'complexity (as Jak mentioned)' need to be considered. Kindly allow me some time to contemplate other criteria. > There may not be a clear winner with any of these, and > it may be that the WG just chooses a particular > scheme it likes. ok. > The comparison is likely to help with forming that opinion, > and may actually highlight a winner. > > Should we go ahead? I think the comparison list is of help. > It may mean some in-depth description of how the schemes > currently handle change (which may take some discussion). > > I think that we need to compare packet sizes for: > > RS/RA exchange for each scheme (or set of schemes) as described > in current drafts. I think we should compare the general bandwidth consumption between two schemes (including unsolicited RAs). Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 06:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvuxC-0008I8-8X for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 06:40:30 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00074 for ; Fri, 22 Jul 2005 06:40:25 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXTHJ2VMG99PH7W@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 20:40:19 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A489AB545; Fri, 22 Jul 2005 20:40:15 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1229B4FB07; Fri, 22 Jul 2005 20:40:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6MAe3Y21547 for dna-list; Fri, 22 Jul 2005 20:40:03 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6MAe2w21541 for ; Fri, 22 Jul 2005 20:40:02 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXTH7ST9099PH7W@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 20:40:00 +1000 Received: by localhost (Postfix, from userid 510) id 5451DAB543; Fri, 22 Jul 2005 20:40:00 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0381C4FB02 for ; Fri, 22 Jul 2005 20:39:57 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so160739nzd for ; Fri, 22 Jul 2005 03:39:47 -0700 (PDT) Received: by 10.36.154.18 with SMTP id b18mr1361852nze; Fri, 22 Jul 2005 01:49:23 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 01:49:23 -0700 (PDT) Date: Fri, 22 Jul 2005 17:49:23 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E090DC.6040408@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Syam Madanapalli , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050722014911d62f01@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GlKnM03VZHq52Ffj+od09TuPcI93/56toMnFbKMmWLlD9rGOG3mmkgroopb3CDDS92RmQiaDBeFldAeLpxIVLsZTNeq9zAOesQsHsJWGGBuP+TAbmSpwpLdmAtHGcHM4HMv3lJi0K1CLcBTNfv4NBDNm9p2QJH4BjydgWW/sug8= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E090DC.6040408@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > Right at the bottom is a proposal for a "Graceful" > means of surviving flash renumbering with Prefix Landmarks. > > It's not really necessary in the general case if routers > retract prefixes with lifetime=0 advertisements, if they > wish to assign the prefix elsewhere before normal > lifetime expiry. I have difficulty understanding that. Does that take into consideration packet loss? > > As of my memory, WG didn't made such a decision. > > It made the decision at the same time it discarded Numeric LinkIDs, > Deterministic FastRA etc: when it agreed to focus on 0ne or Two > potential solutions (with specific properties) at the last IETF. No, it didn't make such a decision. (It's strange that it was claimed that Linkid had been decided to be removed when I presented it. ) At the time of Minneapolis meeting, as possible DNA solution candidates, I had in mind 'CompleteRA', 'Prefix based Linkid' and 'FRD'. So I took extra and intentional care that WG would not throw away those 3 schemes. As of my memory, only "ruling out" process happened during DT discussion at Wednesday morning and neither one of three schemes was ruled out at the meeting. I cc Brett's mail after the meeting to back up my memory. ---------------------------------------------------------- Hi guys, Yesterday we agreed that several of the techniques that we have discussed are probably not worth pursuing. Those are: Explicit LinkID - random Explicit LinkID - hash of prefixes Priority Landmark Simple FastRA Deterministic FastRA That leaves us with the following: Link detection: Explicit LinkID - agreed prefix CompleteRA Requested Landmark Hybrid Landmark Fast advertisement: Fast Router Discovery Hash-ordered FastRA (is that a bit easier to say? :) ) Probabilistic FastRA Cheers, Brett. ---------------------------------------------------------- > > It's my opinion that if one scheme can perform DNA without RS involvement, > > that's the pro for the scheme we need to take into consideration. > > It's no more a pro for LinkID than for CompleteRA. ok. At this point, my assertion is only that the above is a worthy criterion to consider when we evaluate schemes. > > According to the current CPL recommendation, it will take 4 secs for > > a host to generate the complete prefix list. I think it's rather an > > exceptional case for a host to change attachment within 4 secs > > after network attachment. > > It's not that hard to change attachment points quickly with ping-pong. > This is a well known problem. > > I'm not in strict agreement with the single RS for CPL, > since RA messages can be lost, and you can end up with half a CPL. > > If you transit outside the cell within 4 seconds, false link change > detection occurs. > > I'd prefer "At least 1" or "Defaults to 1" x 4 seconds. Right but I am not arguing that such a case is impossible. I am talking only that such a case seems to be rather an exception. Also this is why we think that it is ok for a host to send 1 RS and waits for 4 secs to collect (solicited) RAs and declare CCL complete. Without a packet loss, the host will generate the complete prefix list. Even some packet loss may cause an incomplete prefix list, there is a further chance for the host to get the missing prefixes before it receives link UP notification, i.e. moves to another AP. Even the host moves to another AP with incomplete prefix list, the first RA may contain the prefix in its prefix list. Considering all those above, even if the host performs only one RS/ RA exchange, it will be very rare for the host to falsely assume a link change. So I think that occasional additional signaling is acceptable. > >>>As we have implemented the linkid scheme, we did not find any such problems. > >>>For landmark also all the Routers need know about all other prefixes, otherwie > >>>the host may get conflict answers. > >> > >>It doesn't need to know all the prefixes (as described in a previous > >>thread). It needs to know what prefixes it definitely has locally. > >> > >>In that case, it can answer "Yes" immediately. Answering "No" takes > >>definitive knowledge and synchronization. > > > > > > Answering "Yes" also takes definite knowledge and synchronization. > > > > Allow me an example. Assume a link with two routers R1 and R2. > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > R1 and R2 gathers the prefixes to make the complete prefix list > > {Prefix1, Prefix2, Prefix3}. > > > > Then R2 removes Prefix3 but the RA advertising the removal > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > i.e. Prefix3 is in this link. > > > > Am I missing something? > > Yes. > > The same thing happens with LinkID > > In this case, the Router1 will not identify that the LinkID has changed > either, if the smallest prefix disappears (for example if Prefix3 is > actually the smallest prefix). > > Responses for LinkID will therefore also conflict, Router1 will > have a LinkID of prefix Prefix3, even if that prefix has been > assigned to an adjacent link. Linkid is designed to deal with such a pathological case with linkid prefix list. Kindly check Sec 3 and 4. > For Prefix Landmarking: > > If any RAs by received by R1 indicating that the lifetime is > diminished, this will time out the entries. Any single reception > of a lifetime zero advertisement from the owning router will > remove the prefix. > > This is the same as LinkID. > > So if Prefix Landmarking believes the prefix is still on-link > (and Prefix Landmarking has similar timers for lifetimes that > LinkID does) then the incorrect state will last about as long > for either. > > The assumption is that prefixes retracted without (effective) > zero lifetime advertisement and assigned to another link cause > problems for up to 90 minutes or so: > > This is the same for Prefix Landmarks, CompleteRA, LinkID and > (in hosts' view) CPL. > > This is a very tight corner case, since routers listen to RAs > in DNA, don't sleep, and routers should retract prefixes. > > At least with CompleteRA, you can ignore learned DNAO contents > since the rest of the CompleteRA will not match the existing > Complete Prefix List. I have difficulty following the above. > >>A prefix which answers > >>"Yes" will supercede a "No" if it is received first. > > > > > > I guess the same applies for "NO". > > > > "NO" will supercede a "YES", if it is received first, right? > > Yes, but a false movement detection is actually better than a false > non-movement detection, since the host recovers in milliseconds, not > minutes. Does the above mean "NO" will always supercede "YES", because a false movement detection is actually better than a false non-movement detection? > > In the example I present the above, "NO" is the correct one and > > doesn't result from "that a prefix's advertisement has not been received > > on the "No" router before the RS with a landmark query is sent." > > I see your point: the most up-to-date router could respond "NO" based on > updated information. > > In that case though, it can also update the other routers with > the appropriate RA (prefix lifetime=0). Yes, but it needs additional mechanism to ensure every routers will receive the appropriate RA. > > Correct me wrong but when I looked through Landmark/ CompleteRA > > last time, I don't see any mechanism to deal with the case two routers > > give conflicting answers, one yes and the other no. Such a case can > > arise from a lack of synchronization. > > Indeed, this is the same as LinkID, where the out-of-date LinkID is > still used by a router which has not seen the PIO with the prefix > retracted. > > While Prefix Landmarks can conceivably answer "Yes" incorrectly > in this case, so would some of the LinkID routers. As I wrote above, it will not affect DNA performance for Linkid. Kindly look over the draft. > A practical solution for Prefix Landmarks may be to partly > ignore "Yes" answers - since they don't require much action: that > is keep the DNA process open if there's a non-movement indication. > > The DNA addressing mechanism may be re-normalized (and packet flow can > occur with the global addresses), but subsequent reception of a > trusted "No" RA within (say 500ms) could be used as a hint to re-build > a CPL - which may be a cause to detect change in a few seconds. Maybe, but the scheme seems to become more complicated. At least, I come to have difficulty following your arguments. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 09:03:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxC0-0007D0-L4 for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 09:03:57 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12396 for ; Fri, 22 Jul 2005 09:03:53 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXYIGN81Y99P8IL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 23:03:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EA182AB545; Fri, 22 Jul 2005 23:03:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A3B534FB08; Fri, 22 Jul 2005 23:03:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6MD3Io23214 for dna-list; Fri, 22 Jul 2005 23:03:18 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6MD3Hw23210 for ; Fri, 22 Jul 2005 23:03:17 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXYHM1L9Y8WWBVV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 23:03:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DB017AB543; Fri, 22 Jul 2005 23:03:05 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id B30104FB05; Fri, 22 Jul 2005 23:03:05 +1000 (EST) Received: from [211.28.113.141] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 22 Jul 2005 23:03:05 +1000 Date: Fri, 22 Jul 2005 23:03:05 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , James Kempf , Dna Message-id: <56fbc657099b.57099b56fbc6@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, I'm not added much, but this time, not removed much either. ----- Original Message ----- From: JinHyeock Choi Date: Friday, July 22, 2005 6:33 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > Greg > > > I think there are two or three related threads: > > > > Complete RA Polished > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-03/msg00157.html > > > > Complete RA Re-polished > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00009.html > > > > LinkID Polished > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/msg00097.html > > and > > http://www.ctie.monash.edu.au/warchive/dna-dt/2005-04/threads.html > > > > It's good to know that there's been so much work on this (and > > that everyone can read it). > > It will be nice if the above threads are of help. > > > There were a lot of differences between individual schemes > > as portrayed before (in April) and now though. This may > > affect the way prefix addition or subtraction works. > > Actually the main changes results from the synchronization > difficulties. > > > Given the individual current schemes though, let's try to > characterise> the effects of addition or substraction of prefixes > on each protocol > > as configured today. > > > > Does that sound reasonable? > > > > I guess that if the state + processing requirements for > > Landmark/CompleteRA and LinkID are comparable (which I've > > indicated may be the case), implementation experiences are > > qualitative, and in the normal case > > (and non-DNA case) all schemes act sensibly, the > > main issues will probably be: > > > > * Synchronization/How the schemes react to change of prefixes. > > > > * Packet Sizes > > > > Does this sound like the right criteria to compare > > the schemes on? > > It's my opinion that just the above two are too narrow a criteria, > (though I agree that both of them good). I think other criteria > such > as 'complexity (as Jak mentioned)' need to be considered. Kindly > allow me some time to contemplate other criteria. Computational/Storage Complexity is simple to calculate. Comparison of text or implementation LOCs doesn't help unless direct comparison of complete schemes is possible though. Please consider criteria though. We can work on the simple comparisons first if need be. > > There may not be a clear winner with any of these, and > > it may be that the WG just chooses a particular > > scheme it likes. > > ok. > > > The comparison is likely to help with forming that opinion, > > and may actually highlight a winner. > > > > Should we go ahead? > > I think the comparison list is of help. > > > It may mean some in-depth description of how the schemes > > currently handle change (which may take some discussion). > > > > I think that we need to compare packet sizes for: > > > > RS/RA exchange for each scheme (or set of schemes) as described > > in current drafts. > > I think we should compare the general bandwidth consumption > between two schemes (including unsolicited RAs). Oh Yes: I guess that the LinkID and CompleteRA schemes consume additional bandwidth with ongoing advertisements, so it's relevant. Brett had done some work on that previously for the early DT work, so we may see if it's still applicable I'll be travelling over the weekend, so that may slow things down. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 22 09:30:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxbM-00027E-1K for dna-archive@megatron.ietf.org; Fri, 22 Jul 2005 09:30:08 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14568 for ; Fri, 22 Jul 2005 09:30:05 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQXZETMUY69APKA3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 22 Jul 2005 23:29:55 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 56A618000E; Fri, 22 Jul 2005 23:29:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 12B973C00C; Fri, 22 Jul 2005 23:29:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6MDTfG23517 for dna-list; Fri, 22 Jul 2005 23:29:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6MDTdw23513 for ; Fri, 22 Jul 2005 23:29:39 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQXZE9BO8S8WWHHC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 23:29:25 +1000 Received: by localhost (Postfix, from userid 510) id 3B53DAB542; Fri, 22 Jul 2005 23:29:25 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id AF33E4FB02; Fri, 22 Jul 2005 23:29:23 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6MDT95B000529; Fri, 22 Jul 2005 09:29:09 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 0A5281E81FF; Fri, 22 Jul 2005 09:19:52 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id F39FC1E8178; Fri, 22 Jul 2005 09:19:51 -0400 (EDT) Received: from [68.36.161.46] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Fri, 22 Jul 2005 09:29:09 -0400 Date: Fri, 22 Jul 2005 09:29:09 -0400 From: Sathya Narayanan Subject: Re: [DNA] DNA proposal issue 19 - was [IssueX]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:14 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: JinHyeock Choi Date: Friday, July 22, 2005 1:53 am Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix > Dear Sathya > > > So, in conclusion, the synchronization requirement and > > complexity for Landmark, CompleteRA and LinkID are the same - > all three > > of them require that all the routers on the link know about all the > > prefixes on the link within a reasonable time - the difference > is only > > in the content of the RS/RA messages. Do you agree? > > No. Linkid draft deals with synchronization problem by taking > extra > care of linkid prefix with such schemes as "linkid prefix list" or > "linkid > prefix lifetime". It's my guess that, for CompleteRA or Landamrk, > such > extra cares need to be be applied to all the prefixes. > If the LinkID is being chosen based on some rule (the smallest prefix in the Complete Prefix List) applied to the complete prefix list, then LinkID solution must also make sure that all the routers have the same list. I understand that the hosts maintain a LinkID list, but that doesn't make it OK to have routers in the same link to be advertising different LinkID. (as an aside, it is more accurate to refer to this solution as LinkIDList - because AFAIK, the host, the router and the RA will contain a LinkIDList - the list may contain one or more entries - right?). Sathya From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:24:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtZX-0007hC-La for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:24:07 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17632 for ; Sun, 24 Jul 2005 23:24:03 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1L48PLPA99POEF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:23:43 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8580F80010; Mon, 25 Jul 2005 13:23:36 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E00D33C00D; Mon, 25 Jul 2005 13:23:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3JJj07447 for dna-list; Mon, 25 Jul 2005 13:19:19 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3ILw07357 for ; Mon, 25 Jul 2005 13:18:25 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1GAK81IE8Y5US8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 11:05:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C880AB542; Mon, 25 Jul 2005 11:05:11 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 0D1ED4FB0C; Mon, 25 Jul 2005 11:05:11 +1000 (EST) Date: Mon, 25 Jul 2005 11:05:10 +1000 From: Brett Pentland Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E3E669.2010902@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Christian Vogt , DNA , TM-RO2 Message-id: <42E43AC6.2030806@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Christian, > > This sounds good for most communications (assuming that most > >> communications with the host go through the router). There >> might still be a bit of a problem if an on-link device (other >> than the router) tries to send a packet to the optimistic >> address before the MLD report goes out since the host won't >> receive the resulting NS from this on-link node. I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > > But in that case wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. Ah yes. For some reason a forgot that the MN would be the one initiating the communication. Is there any way that an on-link node could obtain the MN's CoA and try to initiate a communication? Brett. From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:26:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtcF-00083G-UD for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:26:56 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17788 for ; Sun, 24 Jul 2005 23:26:52 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1L7RGIMW99POEF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:26:33 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 269C680012; Mon, 25 Jul 2005 13:26:29 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 55CC43C011; Mon, 25 Jul 2005 13:26:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3OTZ07824 for dna-list; Mon, 25 Jul 2005 13:24:29 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3Ljw07704 for ; Mon, 25 Jul 2005 13:21:48 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYSEOQ0IG99PHSQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 13:19:44 +1000 Received: by localhost (Postfix, from userid 510) id 1BAAFAB542; Sat, 23 Jul 2005 13:19:44 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by curly.its.monash.edu.au (Postfix) with ESMTP id 411354FB04 for ; Sat, 23 Jul 2005 13:19:42 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so348109nzd for ; Fri, 22 Jul 2005 20:19:41 -0700 (PDT) Received: by 10.36.25.20 with SMTP id 20mr268907nzy; Fri, 22 Jul 2005 20:19:41 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 20:19:41 -0700 (PDT) Date: Sat, 23 Jul 2005 12:19:41 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <56fbc657099b.57099b56fbc6@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507222019698353f0@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oI+gp2kzDdquUqAMxkcfdKqPQ2fBNNbqhNIi+1duGPowb5W0eox2T1B3VLQYXGgSvvx0om2Ww27BMJjaRkcWyzn3qGoWYYZh5dhzxNox4kbtAwGNWO80bGhftLbWihYdNK9cde5eDG6dKVPJ9WUavDtft1Qamh5wMwoi58vkEOo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <56fbc657099b.57099b56fbc6@monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > > It's my opinion that just the above two are too narrow a criteria, > > (though I agree that both of them good). I think other criteria > > such > > as 'complexity (as Jak mentioned)' need to be considered. Kindly > > allow me some time to contemplate other criteria. > > Computational/Storage Complexity is simple to calculate. > > Comparison of text or implementation LOCs doesn't help unless > direct comparison of complete schemes is possible though. > > Please consider criteria though. We can work on the simple comparisons > first if need be. I think that comparison needs to be made in whole aspect of schemes so that we can properly contemplate pro & con. Complexity may be a difficult one to measure (in number) but nevertheless an important factor just like 'robustness'. > I'll be travelling over the weekend, so that may slow things down. I wish you have a nice trip. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:29:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtf2-0008FP-78 for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:29:48 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17957 for ; Sun, 24 Jul 2005 23:29:44 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1L8WH1SU8Y5VNG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:27:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 34AF7AB546; Mon, 25 Jul 2005 13:27:24 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 87EA94FB03; Mon, 25 Jul 2005 13:27:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3HHL06916 for dna-list; Mon, 25 Jul 2005 13:17:17 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H8w06860 for ; Mon, 25 Jul 2005 13:17:08 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR0WY3O5GO9APKEO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 01:51:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 110C88000D; Mon, 25 Jul 2005 01:51:30 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id F2B763C005; Mon, 25 Jul 2005 01:51:29 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 25 Jul 2005 01:51:29 +1000 Date: Mon, 25 Jul 2005 01:51:29 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , James Kempf , Dna Message-id: <596170598238.598238596170@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, ----- Original Message ----- From: JinHyeock Choi Date: Saturday, July 23, 2005 1:19 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > Dear Greg > > > > It's my opinion that just the above two are too narrow a criteria, > > > (though I agree that both of them good). I think other criteria > > > such > > > as 'complexity (as Jak mentioned)' need to be considered. Kindly > > > allow me some time to contemplate other criteria. > > > > Computational/Storage Complexity is simple to calculate. > > > > Comparison of text or implementation LOCs doesn't help unless > > direct comparison of complete schemes is possible though. > > > > Please consider criteria though. We can work on the simple > > comparisons first if need be. > > I think that comparison needs to be made in whole aspect of > schemes so that we can properly contemplate pro & con. > Complexity may be a difficult one to measure (in number) but > nevertheless an important factor just like 'robustness'. I've made a first pass at complexity analysis (on all the schemes), based on assumptions from computer science. I'll pass these to you for comment. These aren't based on the implementations, only on what is required for the drafts. Does this sound like a good idea? Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:33:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtiC-0000Hx-OJ for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:33:05 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18218 for ; Sun, 24 Jul 2005 23:33:00 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1LEF9YXY99PJVP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:31:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C87F9AB559; Mon, 25 Jul 2005 13:31:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 787E24FB03; Mon, 25 Jul 2005 13:31:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3HAB06867 for dna-list; Mon, 25 Jul 2005 13:17:10 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H5w06815 for ; Mon, 25 Jul 2005 13:17:05 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR17VOLKLU99PEHL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:04:54 +1000 Received: by localhost (Postfix, from userid 510) id 908A6AB543; Mon, 25 Jul 2005 07:04:54 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id 96D0E4FB04; Mon, 25 Jul 2005 07:04:52 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6OL4lr3022514; Sun, 24 Jul 2005 15:04:48 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6OL4j9v979618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 24 Jul 2005 14:04:46 -0700 (PDT) Date: Sun, 24 Jul 2005 12:09:05 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072100096d56000f@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E3E751.1050009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Linkid deals with this problem with special schemes as as Linkid prefix > list and a few advertisement rules, such as keep advertising old linkid > after a linkid change for the time being. But for CompleteRA (also for > Landmark), as of my knowledge, no such mechanism is devised yet, > though I myself had worked on it before I switched to linkid. My thought > is that it's easier to synchronize one prefix rather than synchronize all > the prefixes on the link. I'm not sure it is conceptually simpler to synchronize one item chosen from a set, than forming the set. In the latter case each router forms the union of its own advertised prefixes and the prefixes it receives in RAs. Thus there can be no conflict; there is no selection of a prefix. In the former case, there can be transients when the sending and receiving router have a different idea of what the selected linkID prefix should be, thus one needs to worry about how such transients are handled. (One can avoid that complexity by not trying to form a single linkID all the time, but instead let each router picks its own linkID prefix and tell the other routers. I haven't worked out the details of such a scheme though.) Erik From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:33:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtiE-0000I9-As for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:33:06 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18230 for ; Sun, 24 Jul 2005 23:33:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1LEILVYI99PJVP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:03 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9C41AB561; Mon, 25 Jul 2005 13:31:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9BBFB4FB08; Mon, 25 Jul 2005 13:31:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3N3w07737 for dna-list; Mon, 25 Jul 2005 13:23:03 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3Klw07565 for ; Mon, 25 Jul 2005 13:20:48 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYU9K4D8M9APHSL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 14:12:52 +1000 Received: by localhost (Postfix, from userid 510) id 08D1DAB542; Sat, 23 Jul 2005 14:12:51 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2BB534FB0A for ; Sat, 23 Jul 2005 14:12:49 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so355543nzd for ; Fri, 22 Jul 2005 21:12:49 -0700 (PDT) Received: by 10.36.5.19 with SMTP id 19mr295733nze; Fri, 22 Jul 2005 21:12:49 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 21:12:49 -0700 (PDT) Date: Sat, 23 Jul 2005 13:12:49 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <037501c58ed3$83b8d7e0$596015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072221122451187@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rXg4I50HAaQc+xEZeg/KziqPdx4V9dp7eWmH30s0LCVm/ApS4DGmn4pOD5xtyhar9VOi4jkH3RatX03nmSEd83bvgsizhi+0HfFxx/KTJeqXq88Zd78O3lPkWtEzYL0H15xfLgdNVNIcogz/+JMwyS0r5GmCxp4HuHlGoTKKUPE= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> <92e919fb050722013353f58362@mail.gmail.com> <037501c58ed3$83b8d7e0$596015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Dear Jak > jak>> Why is this so important? I believe 802.16 (which I think you are > interested in) You know I do very much so. :-) > has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 > Mbps. 9.6 kbps links aren't really that important anymore. My point is that, if we are to compare packet size as Greg suggested, we need to compare all the packet size coming from each scheme, not only the packet size of one RS/ RA exchange. Also I talked with WiBro/ 802.16 developers here and they don't like spending bandwidth on Neighbor Discovery signaling messages. (maybe that's because those messages use up broadcast bandwidth.) Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:33:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtiG-0000Ib-1f for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:33:08 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18256 for ; Sun, 24 Jul 2005 23:33:04 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1LEPEAYS9APLK2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 85E55AB57B; Mon, 25 Jul 2005 13:31:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3DCA54FB04; Mon, 25 Jul 2005 13:31:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3Lnk07645 for dna-list; Mon, 25 Jul 2005 13:21:49 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3KHw07538 for ; Mon, 25 Jul 2005 13:20:17 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYZW15SLM99PJ6Z@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 16:54:32 +1000 Received: by localhost (Postfix, from userid 510) id 7F261AB542; Sat, 23 Jul 2005 16:54:32 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 75A324FB03; Sat, 23 Jul 2005 16:54:31 +1000 (EST) Date: Fri, 22 Jul 2005 23:54:20 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Message-id: <04f801c58f53$5bf83d60$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> <92e919fb050722013353f58362@mail.gmail.com> <037501c58ed3$83b8d7e0$596015ac@dcml.docomolabsusa.com> <92e919fb05072221122451187@mail.gmail.com> Content-Transfer-Encoding: 7BIT > has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 > Mbps. 9.6 kbps links aren't really that important anymore. My point is that, if we are to compare packet size as Greg suggested, we need to compare all the packet size coming from each scheme, not only the packet size of one RS/ RA exchange. jak>> But how often will this signaling take place? I think one must be realistic about the critera. If the signaling only takes place every handover, then I think that the size isn't really relevant, within reason of course. We're not talking about a periodic beacon in that case. jak>> To compare, 802.21 is talking about providing a way whereby, on each handover, a mobile terminal could obtain information on wireless networks. These information element laden messages are likely to be large. But the frequency, AFICT, is exactly the same as for RS/RA. Noboby is worried about reducing the size of these messages. Also I talked with WiBro/ 802.16 developers here and they don't like spending bandwidth on Neighbor Discovery signaling messages. (maybe that's because those messages use up broadcast bandwidth.) jak>> So it seems like there is an assumption that this signaling will take place on the broadcast channel? Is that right? Has WiMax Forum already decided to do IP signaling on the broadcast channel? jak>> I think there are more important criteria, like backward compatibility. How would each of these methods handle having a nonDNA router on the link, or handover between a DNA link and a nonDNA link? These are the kinds of issues that will negatively or positively impact deployment potential, not whether one or the other technique has a couple fewer bytes in the best case. jak From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:33:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtij-0000Zp-Te for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:33:37 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18370 for ; Sun, 24 Jul 2005 23:33:34 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1LFF8VPY9APMCE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:43 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 02A43AB576; Mon, 25 Jul 2005 13:32:04 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A959D4FB06; Mon, 25 Jul 2005 13:32:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3H6s06806 for dna-list; Mon, 25 Jul 2005 13:17:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3Gxw06742 for ; Mon, 25 Jul 2005 13:16:59 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR19ASN9R699PNAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:45:20 +1000 Received: by localhost (Postfix, from userid 510) id 2AE798000D; Mon, 25 Jul 2005 07:45:20 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id B463B3C00B; Mon, 25 Jul 2005 07:45:16 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DwoHV-0000Vd-F2; Sun, 24 Jul 2005 23:45:13 +0200 Date: Sun, 24 Jul 2005 23:45:08 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42DF5EC8.7080207@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: DNA , TM-RO2 Message-id: <42E40BE4.7020009@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, thanks for the feedback. > Regarding the potential solution in section 4.2, I gather you are > talking about something like: > > - Host sends RS with optimistic unicast source address and TSLLAO > - Router replies with unicast RA (using LLA from TSLLAO) > - Host only then sends MLD report (after delay) > - Host send NS for oDAD Exactly, this is what we are having in mind. The ODAD specification currently demands that the MN must send the initial NS (4th step above) before it can use an optimistic address. But this implies that the MLD Report would be the very first message, inducing a delay of up to a second. Our proposal is to allow the MN to use the optimistic address before sending the initial NS. > This sounds good for most communications (assuming that most > communications with the host go through the router). There > might still be a bit of a problem if an on-link device (other > than the router) tries to send a packet to the optimistic > address before the MLD report goes out since the host won't > receive the resulting NS from this on-link node. I guess this > might come up if the host is a mobile node and tries to perform > route optimization with a node that just happens to be connected > to the same link as itself. Good point. In this case, the mobile node should recognize that its correspondent's address is on-link. And it would initiate address resolution for the correspondent's address by sending a NS to the solicited-nodes address. If the mobile node adds a TSLLAO to that NS, the correspondent should be able to respond (provided it understands the TSLLAO, which we have to assume in this case, I guess). - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Brett Pentland wrote: > Hi Christian, > > Sorry I only just got to read through the draft. Thanks for your > efforts. It's a good summary of the situation. > > Regarding the potential solution in section 4.2, I gather you are > talking about something like: > > - Host sends RS with optimistic unicast source address and TSLLAO > - Router replies with unicast RA (using LLA from TSLLAO) > - Host only then sends MLD report (after delay) > - Host send NS for oDAD > > This sounds good for most communications (assuming that most > communications with the host go through the router). There > might still be a bit of a problem if an on-link device (other > than the router) tries to send a packet to the optimistic > address before the MLD report goes out since the host won't > receive the resulting NS from this on-link node. I guess this > might come up if the host is a mobile node and tries to perform > route optimization with a node that just happens to be connected > to the same link as itself. > > Any thoughts? > Brett. From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:33:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtil-0000a1-GO for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:33:39 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18387 for ; Sun, 24 Jul 2005 23:33:35 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1LFMGX9E99PJVP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:52 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 15C5BAB593; Mon, 25 Jul 2005 13:32:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C43BD4FB02; Mon, 25 Jul 2005 13:32:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3GtV06716 for dna-list; Mon, 25 Jul 2005 13:16:55 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3Gsw06712 for ; Mon, 25 Jul 2005 13:16:54 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1I4UKSRM8WX27K@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 11:57:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C93C8AB545; Mon, 25 Jul 2005 11:57:50 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 9171B4FB08; Mon, 25 Jul 2005 11:57:50 +1000 (EST) Date: Mon, 25 Jul 2005 11:57:49 +1000 From: Brett Pentland Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072220192dd72a1f@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E4471D.2010309@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> <92e919fb05072220192dd72a1f@mail.gmail.com> Content-Transfer-Encoding: 7BIT > I gave the above example only to show that both "YES" and "NO" need > "definite knowledge and synchronization". I didn't give it to show linkid's > superiority. (I'll prepare a better one. Just wait. :-)) :) > Correct me wrong, but in ComplteRA or Landmark, there is no > mechanism which ensures that always such a linking (or overlapping) > prefix exists. That's almost the definition of Complete RA. All routers should be advertising the same set of prefixes so that pretty much ensures overlap. The only way for there not to be is for a router which has no learned prefixes (ie. all of the prefixes it is advertising are explicitly configured on it) to instantly stop advertising those prefixes and start advertising a new set. It's trivial to add a rule to say don't do that. >>Putting aside, for the moment, cases where a prefix is moved to a new >>link before its lifetime advertised on the old link has expired, your >>own example shows how the Landmark part deals with changes effectively. >>A YES answer will only occur if the prefix has been used on the link and >>so will not be wrong in the sense that the current link is the same one >>where the Landmark came from. If that prefix is in the process of being >>removed, then very soon a NO answer will arrive from the applicable >>router informing the host of this and providing the prefixes that are >>available. Note also that the window of oportunity for this to happen >>is quite small as the router that removed the prefix should advertise >>this fact several times in a fairly short space of time so that all >>of the routers on the link are aware of the change. > > > I can think of more pathological example easily by cut and paste from > old DT ML. > > Assume a host having two prefix A and B, and making one address with > A and the other with B. Assume prefix A goes through prefix renumbering > and early reassignment and the host follows it. Then it will not perceive > that it can't no longer use the address with prefix B:. True, but LinkID doesn't prevent that either. Both methods need to manage that through the imposition of rules for renumbering, and the setting of timeouts on DNA information. > > >>Returning to cases where prefixes can be reasigned to a new link before >>the expiry of a previously advertised valid lifetime on another link, >>both of the proposals face the same issue and need to deal with it by >>placing rules about how the reassignment is done. If a host sees a >>LinkID or a Landmark on one link, fails to see advertisements that the >>valid lifetime has been shortened, and then sees the same LinkID / >>Landmark on another link, they will fail to detect the link change. > > > Linkid draft sets the rule to prevent such a case. So I may say that > Linkid is safe from flash renumbering and early reassignment, unless > there is a human error, (from which no scheme can be safe 100 %.) . And those same rules apply equally well to Landmark/CompleteRA. Brett. From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:35:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtkI-0000tc-Um for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:35:15 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18518 for ; Sun, 24 Jul 2005 23:35:11 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LELJHYK8WX270@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:09 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 63B3CAB572; Mon, 25 Jul 2005 13:31:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2001A4FB04; Mon, 25 Jul 2005 13:31:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3SOC08299 for dna-list; Mon, 25 Jul 2005 13:28:24 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3S0w08184 for ; Mon, 25 Jul 2005 13:28:05 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQYUB9WXZA8WWMJ9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 14:14:15 +1000 Received: by localhost (Postfix, from userid 510) id 0E10BAB543; Sat, 23 Jul 2005 14:14:14 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by curly.its.monash.edu.au (Postfix) with ESMTP id 361D14FB03 for ; Sat, 23 Jul 2005 14:14:13 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so355746nzd for ; Fri, 22 Jul 2005 21:14:13 -0700 (PDT) Received: by 10.36.222.25 with SMTP id u25mr290535nzg; Fri, 22 Jul 2005 21:14:13 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 21:14:13 -0700 (PDT) Date: Sat, 23 Jul 2005 13:14:13 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <03a801c58ed6$401e4bc0$596015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050722211476f47a1e@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ccbwKemS9rRqIAxWk44/5t0ZgJ2Z1DOYTfNuCZJ0IlMV06Sj4LTA7CPZx5TVrjvj96sNcZbt5qKb0RStaCrIlxD6GGty+tVq9LHtxKy7Nq8hEGotr1ZxspGGvJFLPPTFTMVjoJpnhd0Pm5G6Ad5Yhlp8Cw1+Vo+uO8uYl9tLTSo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E090DC.6040408@eng.monash.edu.au> <92e919fb050722014911d62f01@mail.gmail.com> <03a801c58ed6$401e4bc0$596015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Jak > The minutes of the IETF 62 meeting show that I proposed taking FastRA out of > contention, because it is very link specific (it would not work for 3.9G for > example), and referring it to the proper link standardization group > (probably 802.21). I remember very well of it. You also kindly proposed to make an Informational RFC out of it. Also it was of much help for you to point out 802.21. > Unfortuantely, there is no record of a consensus call on > this proposal in the minutes. Unfortunately, no action was taken. :-( > I'd like to renew my proposal and suggest to > the chairs that a consensus call be done at a convenient time. ok. But before the decision is made, I expect a chance to present the scheme properly. > We cannot make progress on getting this standard complete if discussion > never results in any decisions being made. agree. It took us 3 meetings to make a decision on CPL. :-( Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:35:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtkK-0000tq-RI for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:35:16 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18535 for ; Sun, 24 Jul 2005 23:35:13 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LE61SHA8WX5CG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:56 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F3ADCAB545; Mon, 25 Jul 2005 13:31:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A65DC4FB06; Mon, 25 Jul 2005 13:31:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3TT808479 for dna-list; Mon, 25 Jul 2005 13:29:29 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SSw08399 for ; Mon, 25 Jul 2005 13:28:29 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQY3XD3APS9API7R@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 01:39:21 +1000 Received: by localhost (Postfix, from userid 510) id 534D38000D; Sat, 23 Jul 2005 01:39:21 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 60DBA3C00C; Sat, 23 Jul 2005 01:39:20 +1000 (EST) Date: Fri, 22 Jul 2005 08:39:12 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , Brett Pentland , Dna Message-id: <037501c58ed3$83b8d7e0$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> <92e919fb050722013353f58362@mail.gmail.com> Content-Transfer-Encoding: 7BIT I think we should compare the general bandwidth consumption between two schemes (including unsolicited RAs). jak>> Why is this so important? I believe 802.16 (which I think you are interested in) has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 Mbps. 9.6 kbps links aren't really that important anymore. jak From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:35:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtkN-0000v6-Js for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:35:20 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18552 for ; Sun, 24 Jul 2005 23:35:15 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LEIN9EU8Y5VP3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:32:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 21A02AB569; Mon, 25 Jul 2005 13:31:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C72884FB04; Mon, 25 Jul 2005 13:31:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3TIT08462 for dna-list; Mon, 25 Jul 2005 13:29:18 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SOw08351 for ; Mon, 25 Jul 2005 13:28:24 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQYXFE253C8Y5GLK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 15:43:51 +1000 Received: by localhost (Postfix, from userid 510) id 82B5E8000D; Sat, 23 Jul 2005 15:43:51 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by larry.its.monash.edu.au (Postfix) with ESMTP id 793CD3C005 for ; Sat, 23 Jul 2005 15:43:50 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so369903nzd for ; Fri, 22 Jul 2005 22:43:49 -0700 (PDT) Received: by 10.36.222.54 with SMTP id u54mr339086nzg; Fri, 22 Jul 2005 22:43:49 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 22:43:49 -0700 (PDT) Date: Sat, 23 Jul 2005 14:43:49 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [IssueX]LinkIDv.s.LandmarkPrefix In-reply-to: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507222243774570f2@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G1rGhZfdZm2tBlmyQ0I6mdYbTSzZqEmHsug8zUDKmJ4l+qNd7rFReieO7y9jcl9TwweFb/BIm3oIjeUVjlsxtSg5hoVJGYpOfy2wOHTIFzGYH5AwCFnJRnrsOo0VU/HnANvl1fOmIaBbfaNmUqdeMIYOfBVALwYRR+at8gadmPo= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > If the LinkID is being chosen based on some rule (the smallest prefix in the Complete > Prefix List) applied to the complete prefix list, then LinkID solution must also make sure > that all the routers have the same list. I understand that the hosts maintain a LinkID list, > but that doesn't make it OK to have routers in the same link to be advertising different LinkID. Actually it's ok. I designed Linkid such that hosts make a correct decision even under such a temporary asynchornization. > (as an aside, it is more accurate to refer to this solution as LinkIDList - > because AFAIK, the host, the router and the RA will contain a LinkIDList - > the list may contain one or more entries - right?). No, the routers use a single linkid prefix at any given time, but due to the possibility that the linkid prefix changing, the hosts track the set of linkid prefixes. You may check "Comments on linkid draft" thread in DT ML. (Actually this is the confusion I was afraid when Erik suggested the Linkid List idea. :-( ) Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:35:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtkS-00010b-7s for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:35:24 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18554 for ; Sun, 24 Jul 2005 23:35:18 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LE85EEG8WX64S@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:02 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 83BA3AB551; Mon, 25 Jul 2005 13:31:41 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 317394FB06; Mon, 25 Jul 2005 13:31:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3H9v06842 for dna-list; Mon, 25 Jul 2005 13:17:09 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H2w06778 for ; Mon, 25 Jul 2005 13:17:02 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR17VI648U99PEHL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:04:46 +1000 Received: by localhost (Postfix, from userid 510) id E964A8000D; Mon, 25 Jul 2005 07:04:45 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id C5EDE3C00B; Mon, 25 Jul 2005 07:04:44 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6OL4gcn021559; Sun, 24 Jul 2005 14:04:42 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6OL4Xtb979603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 24 Jul 2005 14:04:41 -0700 (PDT) Date: Sun, 24 Jul 2005 12:05:13 -0700 From: Erik Nordmark Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42DF5EC8.7080207@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Christian Vogt , DNA , TM-RO2 Message-id: <42E3E669.2010902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett Pentland wrote: > Regarding the potential solution in section 4.2, I gather you are > talking about something like: > > - Host sends RS with optimistic unicast source address and TSLLAO > - Router replies with unicast RA (using LLA from TSLLAO) > - Host only then sends MLD report (after delay) > - Host send NS for oDAD Looks good to me. Presumably the last step isn't needed if the host didn't move to a different link. (One might think the same thing applies to the third item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe when the host has changed its L2 attachment point.) > This sounds good for most communications (assuming that most > communications with the host go through the router). There > might still be a bit of a problem if an on-link device (other > than the router) tries to send a packet to the optimistic > address before the MLD report goes out since the host won't > receive the resulting NS from this on-link node. I guess this > might come up if the host is a mobile node and tries to perform > route optimization with a node that just happens to be connected > to the same link as itself. But in that case wouldn't the new host send a NS as part of communicating with the CoA of the peer? I guess it depends on the details of any MIPv6 RO procedure. Erik From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011Q-CS for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18618 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LFAFR3W8WX659@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AA96EAB58A; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 493D54FB06; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3H6e06802 for dna-list; Mon, 25 Jul 2005 13:17:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H0w06746 for ; Mon, 25 Jul 2005 13:17:00 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR19HVK3LE99PNAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:51:02 +1000 Received: by localhost (Postfix, from userid 510) id 824158000E; Mon, 25 Jul 2005 07:51:02 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id E3B493C013; Mon, 25 Jul 2005 07:50:58 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DwoN2-0000em-Rq; Sun, 24 Jul 2005 23:50:55 +0200 Date: Sun, 24 Jul 2005 23:50:52 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E3E669.2010902@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , DNA , TM-RO2 Message-id: <42E40D3C.9050006@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik. >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) Right, ODAD can be canceled when the mobile node learns from the RA that it is still on the same IP link. >> [...] I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > But in that caFrom dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011Q-CS for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18618 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LFAFR3W8WX659@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AA96EAB58A; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 493D54FB06; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3H6e06802 for dna-list; Mon, 25 Jul 2005 13:17:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H0w06746 for ; Mon, 25 Jul 2005 13:17:00 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR19HVK3LE99PNAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:51:02 +1000 Received: by localhost (Postfix, from userid 510) id 824158000E; Mon, 25 Jul 2005 07:51:02 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id E3B493C013; Mon, 25 Jul 2005 07:50:58 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DwoN2-0000em-Rq; Sun, 24 Jul 2005 23:50:55 +0200 Date: Sun, 24 Jul 2005 23:50:52 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E3E669.2010902@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , DNA , TM-RO2 Message-id: <42E40D3C.9050006@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik. >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) Right, ODAD can be canceled when the mobile node learns from the RA that it is still on the same IP link. >> [...] I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > But in that case wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. The mobile node should be fine when it uses a TSLLAO in the NS (and the peer understands the TSLLAO). - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Erik Nordmark wrote: > Brett Pentland wrote: > >> Regarding the potential solution in section 4.2, I gather you are >> talking about something like: >> >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) > > > This sounds good for most communications (assuming that most > >> communications with the host go through the router). There >> might still be a bit of a problem if an on-link device (other >> than the router) tries to send a packet to the optimistic >> address before the MLD report goes out since the host won't >> receive the resulting NS from this on-link node. I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > > But in that case wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. > > Erik > From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011R-IP for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18619 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LET77XQ8Y5VP3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E504AB55D; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 40F494FB03; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3HJI06934 for dna-list; Mon, 25 Jul 2005 13:17:19 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3HAw06880 for ; Mon, 25 Jul 2005 13:17:10 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR10PIXBJS99PLTC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 03:39:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C71DAB543; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 36DA34FB06; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 25 Jul 2005 03:39:07 +1000 Date: Mon, 25 Jul 2005 03:39:07 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrese wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. The mobile node should be fine when it uses a TSLLAO in the NS (and the peer understands the TSLLAO). - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Erik Nordmark wrote: > Brett Pentland wrote: > >> Regarding the potential solution in section 4.2, I gather you are >> talking about something like: >> >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) > > > This sounds good for most communications (assuming that most > >> communications with the host go through the router). There >> might still be a bit of a problem if an on-link device (other >> than the router) tries to send a packet to the optimistic >> address before the MLD report goes out since the host won't >> receive the resulting NS from this on-link node. I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > > But in that case wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. > > Erik > From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011R-IP for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18619 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LET77XQ8Y5VP3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E504AB55D; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 40F494FB03; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3HJI06934 for dna-list; Mon, 25 Jul 2005 13:17:19 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3HAw06880 for ; Mon, 25 Jul 2005 13:17:10 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR10PIXBJS99PLTC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 03:39:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C71DAB543; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 36DA34FB06; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 25 Jul 2005 03:39:07 +1000 Date: Mon, 25 Jul 2005 03:39:07 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Message-id: <595b96597d52.597d52595b96@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi James, There are responses to the top and bottom of your e-mail. Don't be too despondent until you read the last lines... ----- Original Message ----- From: James Kempf Date: Saturday, July 23, 2005 4:54 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > > has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 > > Mbps. 9.6 kbps links aren't really that important anymore. > > My point is that, if we are to compare packet size as Greg suggested, > we need to compare all the packet size coming from each scheme, > not only the packet size of one RS/ RA exchange. > > jak>> But how often will this signaling take place? I think one > must be realistic about the critera. If the signaling only takes > place every handover, then I think that the size isn't really > relevant, within reason of course. We're not talking about a > periodic beacon in that case. You're right that the burden isn't too great, but one thing touted as an advantage for Landmarks is their smaller size (with a Yes reply). So it's a legitimate factor (though not necessarily a big one). Also, the background cost of LinkID and CompleteRA are relevant, since there are BNEP bridges available... If we compare unsolicited RA overheads we need to stress that with DNA, the unsolicited rate can be decreased and still receive good performance. We can present the rates for default RFC2461 RA, with default MinRtrAdvInterval and MaxRtrAdvInterval (in bps), given the sample scenarios. The minimum RA interval values can be presented for comparison, with a disclaimer that these values may not be needed. Does this sound reasonable? (regardless of its necessity??) I'll see if I can do this for the agreed criteria, in order to make this available to the list. My aim here is to provide enough information for the WG to make its own decision. In this case, I guess there may not be much difference, but removing the uncertainty may help the decision process. [cut] > jak>> I think there are more important criteria, like backward > compatibility. How would each of these methods handle having a > nonDNA router on the link, or handover between a DNA link and > a nonDNA link? These are the kinds of issues that will > negatively or positively impact deployment potential, not whether > one or the other technique has a couple fewer bytes in the best case. Your point is well taken. I'll elicit help from others to facilitate this. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011S-JF for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18622 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LF07M4U8Y5VP5@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3032AB582; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.fix Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Message-id: <595b96597d52.597d52595b96@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi James, There are responses to the top and bottom of your e-mail. Don't be too despondent until you read the last lines... ----- Original Message ----- From: James Kempf Date: Saturday, July 23, 2005 4:54 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > > has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 > > Mbps. 9.6 kbps links aren't really that important anymore. > > My point is that, if we are to compare packet size as Greg suggested, > we need to compare all the packet size coming from each scheme, > not only the packet size of one RS/ RA exchange. > > jak>> But how often will this signaling take place? I think one > must be realistic about the critera. If the signaling only takes > place every handover, then I think that the size isn't really > relevant, within reason of course. We're not talking about a > periodic beacon in that case. You're right that the burden isn't too great, but one thing touted as an advantage for Landmarks is their smaller size (with a Yes reply). So it's a legitimate factor (though not necessarily a big one). Also, the background cost of LinkID and CompleteRA are relevant, since there are BNEP bridges available... If we compare unsolicited RA overheads we need to stress that with DNA, the unsolicited rate can be decreased and still receive good performance. We can present the rates for default RFC2461 RA, with default MinRtrAdvInterval and MaxRtrAdvInterval (in bps), given the sample scenarios. The minimum RA interval values can be presented for comparison, with a disclaimer that these values may not be needed. Does this sound reasonable? (regardless of its necessity??) I'll see if I can do this for the agreed criteria, in order to make this available to the list. My aim here is to provide enough information for the WG to make its own decision. In this case, I guess there may not be much difference, but removing the uncertainty may help the decision process. [cut] > jak>> I think there are more important criteria, like backward > compatibility. How would each of these methods handle having a > nonDNA router on the link, or handover between a DNA link and > a nonDNA link? These are the kinds of issues that will > negatively or positively impact deployment potential, not whether > one or the other technique has a couple fewer bytes in the best case. Your point is well taken. I'll elicit help from others to facilitate this. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011S-JF for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18622 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LF07M4U8Y5VP5@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3032AB582; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7DEF84FB02; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3Lap07607 for dna-list; Mon, 25 Jul 2005 13:21:36 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3JIw07494 for ; Mon, 25 Jul 2005 13:19:24 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYY929N0C9APJN8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 16:07:00 +1000 Received: by localhost (Postfix, from userid 510) id EFF9C8000D; Sat, 23 Jul 2005 16:06:59 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id C210C3C005; Sat, 23 Jul 2005 16:06:58 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK200HDXGZK1J@mailout1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK2005RAGZBNY@mmp1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Date: Sat, 23 Jul 2005 11:33:02 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [IssueX]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , JinHyeock Choi Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <057c01c58f4c$343f3050$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Satya, > > > ----- Original Message ----- > From: JinHyeock Choi > Date: Friday, July 22, 2005 1:53 am > Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix > > > Dear Sathya > > > > > So, in conclusion, the synchronization requirement and > > > complexity for Landmark, CompleteRA and LinkID are the same - > > all three > > > of them require that all the routers on the link know about all the > > > prefixes on the link within a reasonable time - the difference > > is only > > > in the content of the RS/RA messages. Do you agree? > > > > No. Linkid draft deals with synchronization problem by taking > > extra > > care of linkid prefix with such schemes as "linkid prefix list" or > > "linkid > > prefix lifetime". It's my guess that, for CompleteRA or Landamrk, > > such > > extra cares need to be be applied to all the prefixes. > > > If the LinkID is being chosen based on some rule > (the smallest prefix in the Complete Prefix List) applied to the complete prefix list, > then LinkID solution must also make sure that all the routers have the same list. The prefix list can differ for sometime (1.5 hrs) because of additiion or change in prefix life time (i.e, if lifetime goes less than 3 hrs). > I understand that the hosts maintain a LinkID list, but that doesn't make it OK > to have routers in the same link to be advertising different LinkID. Routers can be advertising different LinkIDs at a given point of time. But hosts will not make wrong decision because of LinkID list maintained at hostFrom dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011Q-CS for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18618 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LFAFR3W8WX659@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AA96EAB58A; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 493D54FB06; Mon, 25 Jul 2005 13:32:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3H6e06802 for dna-list; Mon, 25 Jul 2005 13:17:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3H0w06746 for ; Mon, 25 Jul 2005 13:17:00 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR19HVK3LE99PNAP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 07:51:02 +1000 Received: by localhost (Postfix, from userid 510) id 824158000E; Mon, 25 Jul 2005 07:51:02 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id E3B493C013; Mon, 25 Jul 2005 07:50:58 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DwoN2-0000em-Rq; Sun, 24 Jul 2005 23:50:55 +0200 Date: Sun, 24 Jul 2005 23:50:52 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E3E669.2010902@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , DNA , TM-RO2 Message-id: <42E40D3C.9050006@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik. >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) Right, ODAD can be canceled when the mobile node learns from the RA that it is still on the same IP link. >> [...] I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > But in that ca143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7DEF84FB02; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3Lap07607 for dna-list; Mon, 25 Jul 2005 13:21:36 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3JIw07494 for ; Mon, 25 Jul 2005 13:19:24 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYY929N0C9APJN8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 16:07:00 +1000 Received: by localhost (Postfix, from userid 510) id EFF9C8000D; Sat, 23 Jul 2005 16:06:59 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id C210C3C005; Sat, 23 Jul 2005 16:06:58 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK200HDXGZK1J@mailout1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK2005RAGZBNY@mmp1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Date: Sat, 23 Jul 2005 11:33:02 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [IssueX]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , JinHyeock Choi Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <057c01c58f4c$343f3050$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Satya, > > > ----- Original Message ----- > From: JinHyeock Choi > Date: Friday, July 22, 2005 1:53 am > Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix > > > Dear Sathya > > > > > So, in conclusion, the synchronization requirement and > > > complexity for Landmark, CompleteRA and LinkID are the same - > > all three > > > of them require that all the routers on the link know about all the > > > prefixes on the link within a reasonable time - the difference > > is only > > > in the content of the RS/RA messages. Do you agree? > > > > No. Linkid draft deals with synchronization problem by taking > > extra > > care of linkid prefix with such schemes as "linkid prefix list" or > > "linkid > > prefix lifetime". It's my guess that, for CompleteRA or Landamrk, > > such > > extra cares need to be be applied to all the prefixes. > > > If the LinkID is being chosen based on some rule > (the smallest prefix in the Complete Prefix List) applied to the complete prefix list, > then LinkID solution must also make sure that all the routers have the same list. The prefix list can differ for sometime (1.5 hrs) because of additiion or change in prefix life time (i.e, if lifetime goes less than 3 hrs). > I understand that the hosts maintain a LinkID list, but that doesn't make it OK > to have routers in the same link to be advertising different LinkID. Routers can be advertising different LinkIDs at a given point of time. But hosts will not make wrong decision because of LinkID list maintained at host side. >(as an aside, it is more accurate to refer to this solution as LinkIDList - > because AFAIK, the host, the router and the RA will contain a LinkIDList - >the list may contain one or more entries - right?). > This may not be correct. Most of the time only one LinkID will be there in the LinkID list. If the prefix list changes, which causes change in LinkID, only then more than one prefix will present in LinkID list. And this is a very rare case. > Sathya > > > Thanks & Regards, Subba Reddy se wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. The mobile node should be fine when it uses a TSLLAO in the NS (and the peer understands the TSLLAO). - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Erik Nordmark wrote: > Brett Pentland wrote: > >> Regarding the potential solution in section 4.2, I gather you are >> talking about something like: >> >> - Host sends RS with optimistic unicast source address and TSLLAO >> - Router replies with unicast RA (using LLA from TSLLAO) >> - Host only then sends MLD report (after delay) >> - Host send NS for oDAD > > > Looks good to me. > > Presumably the last step isn't needed if the host didn't move to a > different link. (One might think the same thing applies to the third > item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe > when the host has changed its L2 attachment point.) > > > This sounds good for most communications (assuming that most > >> communications with the host go through the router). There >> might still be a bit of a problem if an on-link device (other >> than the router) tries to send a packet to the optimistic >> address before the MLD report goes out since the host won't >> receive the resulting NS from this on-link node. I guess this >> might come up if the host is a mobile node and tries to perform >> route optimization with a node that just happens to be connected >> to the same link as itself. > > > But in that case wouldn't the new host send a NS as part of > communicating with the CoA of the peer? I guess it depends on the > details of any MIPv6 RO procedure. > > Erik > From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011R-IP for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18619 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LET77XQ8Y5VP3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E504AB55D; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 40F494FB03; Mon, 25 Jul 2005 13:31:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3HJI06934 for dna-list; Mon, 25 Jul 2005 13:17:19 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3HAw06880 for ; Mon, 25 Jul 2005 13:17:10 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR10PIXBJS99PLTC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 03:39:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C71DAB543; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 36DA34FB06; Mon, 25 Jul 2005 03:39:07 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 25 Jul 2005 03:39:07 +1000 Date: Mon, 25 Jul 2005 03:39:07 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPre side. >(as an aside, it is more accurate to refer to this solution as LinkIDList - > because AFAIK, the host, the router and the RA will contain a LinkIDList - >the list may contain one or more entries - right?). > This may not be correct. Most of the time only one LinkID will be there in the LinkID list. If the prefix list changes, which causes change in LinkID, only then more than one prefix will present in LinkID list. And this is a very rare case. > Sathya > > > Thanks & Regards, Subba Reddy fix Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: JinHyeock Choi , greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Message-id: <595b96597d52.597d52595b96@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi James, There are responses to the top and bottom of your e-mail. Don't be too despondent until you read the last lines... ----- Original Message ----- From: James Kempf Date: Saturday, July 23, 2005 4:54 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix > > has bandwidths between 1 - 5 Mbps, and 3.9 G is up to 20 > > Mbps. 9.6 kbps links aren't really that important anymore. > > My point is that, if we are to compare packet size as Greg suggested, > we need to compare all the packet size coming from each scheme, > not only the packet size of one RS/ RA exchange. > > jak>> But how often will this signaling take place? I think one > must be realistic about the critera. If the signaling only takes > place every handover, then I think that the size isn't really > relevant, within reason of course. We're not talking about a > periodic beacon in that case. You're right that the burden isn't too great, but one thing touted as an advantage for Landmarks is their smaller size (with a Yes reply). So it's a legitimate factor (though not necessarily a big one). Also, the background cost of LinkID and CompleteRA are relevant, since there are BNEP bridges available... If we compare unsolicited RA overheads we need to stress that with DNA, the unsolicited rate can be decreased and still receive good performance. We can present the rates for default RFC2461 RA, with default MinRtrAdvInterval and MaxRtrAdvInterval (in bps), given the sample scenarios. The minimum RA interval values can be presented for comparison, with a disclaimer that these values may not be needed. Does this sound reasonable? (regardless of its necessity??) I'll see if I can do this for the agreed criteria, in order to make this available to the list. My aim here is to provide enough information for the WG to make its own decision. In this case, I guess there may not be much difference, but removing the uncertainty may help the decision process. [cut] > jak>> I think there are more important criteria, like backward > compatibility. How would each of these methods handle having a > nonDNA router on the link, or handover between a DNA link and > a nonDNA link? These are the kinds of issues that will > negatively or positively impact deployment potential, not whether > one or the other technique has a couple fewer bytes in the best case. Your point is well taken. I'll elicit help from others to facilitate this. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtl8-00011S-JF for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:06 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18622 for ; Sun, 24 Jul 2005 23:36:02 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LF07M4U8Y5VP5@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:33:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3032AB582; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7DEF84FB02; Mon, 25 Jul 2005 13:31:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3Lap07607 for dna-list; Mon, 25 Jul 2005 13:21:36 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3JIw07494 for ; Mon, 25 Jul 2005 13:19:24 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQYY929N0C9APJN8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 16:07:00 +1000 Received: by localhost (Postfix, from userid 510) id EFF9C8000D; Sat, 23 Jul 2005 16:06:59 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id C210C3C005; Sat, 23 Jul 2005 16:06:58 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK200HDXGZK1J@mailout1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK2005RAGZBNY@mmp1.samsung.com>; Sat, 23 Jul 2005 15:06:56 +0900 (KST) Date: Sat, 23 Jul 2005 11:33:02 +0530 From: Subba Reddy Subject: Re: [DNA] DNA proposal issue 19 - was [IssueX]LinkIDv.s.LandmarkPrefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , JinHyeock Choi Cc: Syam Madanapalli , Syam Madanapalli , greg.daley@eng.monash.edu.au, Brett Pentland , James Kempf , Dna Message-id: <057c01c58f4c$343f3050$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1d0a31d0a9.1d0a91d0a3@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Satya, > > > ----- Original Message ----- > From: JinHyeock Choi > Date: Friday, July 22, 2005 1:53 am > Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X]LinkIDv.s.LandmarkPrefix > > > Dear Sathya > > > > > So, in conclusion, the synchronization requirement and > > > complexity for Landmark, CompleteRA and LinkID are the same - > > all three > > > of them require that all the routers on the link know about all the > > > prefixes on the link within a reasonable time - the difference > > is only > > > in the content of the RS/RA messages. Do you agree? > > > > No. Linkid draft deals with synchronization problem by taking > > extra > > care of linkid prefix with such schemes as "linkid prefix list" or > > "linkid > > prefix lifetime". It's my guess that, for CompleteRA or Landamrk, > > such > > extra cares need to be be applied to all the prefixes. > > > If the LinkID is being chosen based on some rule > (the smallest prefix in the Complete Prefix List) applied to the complete prefix list, > then LinkID solution must also make sure that all the routers have the same list. The prefix list can differ for sometime (1.5 hrs) because of additiion or change in prefix life time (i.e, if lifetime goes less than 3 hrs). > I understand that the hosts maintain a LinkID list, but that doesn't make it OK > to have routers in the same link to be advertising different LinkID. Routers can be advertising different LinkIDs at a given point of time. But hosts will not make wrong decision because of LinkID list maintained at host side. >(as an aside, it is more accurate to refer to this solution as LinkIDList - > because AFAIK, the host, the router and the RA will contain a LinkIDList - >the list may contain one or more entries - right?). > This may not be correct. Most of the time only one LinkID will be there in the LinkID list. If the prefix list changes, which causes change in LinkID, only then more than one prefix will present in LinkID list. And this is a very rare case. > Sathya > > > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlB-000126-Jp for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:09 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18672 for ; Sun, 24 Jul 2005 23:36:05 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LGD7UTU8WX5CG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:44 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A46AAB5A6; Mon, 25 Jul 2005 13:32:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0A3154FB0F; Mon, 25 Jul 2005 13:32:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3TQD08460 for dna-list; Mon, 25 Jul 2005 13:29:26 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SOw08358 for ; Mon, 25 Jul 2005 13:28:24 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQY0BI7T1899PGJC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 23:55:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DBF0AB542; Fri, 22 Jul 2005 23:55:26 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 59E914FB09; Fri, 22 Jul 2005 23:55:26 +1000 (EST) Received: from [211.28.113.141] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 22 Jul 2005 23:55:26 +1000 Date: Fri, 22 Jul 2005 23:55:26 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , James Kempf , Dna Message-id: <56ceed56e74a.56e74a56ceed@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, There are too many topics in this e-mail, so if we need to discuss all of the topics further it may be good to split the threads. ----- Original Message ----- From: JinHyeock Choi Date: Friday, July 22, 2005 6:49 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Greg > > > Right at the bottom is a proposal for a "Graceful" > > means of surviving flash renumbering with Prefix Landmarks. > > > > It's not really necessary in the general case if routers > > retract prefixes with lifetime=0 advertisements, if they > > wish to assign the prefix elsewhere before normal > > lifetime expiry. > > I have difficulty understanding that. Does that take into > consideration packet loss? It does, if the prefixes are retracted for multiple RA intervals, or if changes are advertised as defined in RFC 2461 section 6.2.4. > > > As of my memory, WG didn't made such a decision. > > > > It made the decision at the same time it discarded Numeric LinkIDs, > > Deterministic FastRA etc: when it agreed to focus on 0ne or Two > > potential solutions (with specific propeFrom dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlB-000126-Jp for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:09 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18672 for ; Sun, 24 Jul 2005 23:36:05 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LGD7UTU8WX5CG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:44 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5A46AAB5A6; Mon, 25 Jul 2005 13:32:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0A3154FB0F; Mon, 25 Jul 2005 13:32:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3TQD08460 for dna-list; Mon, 25 Jul 2005 13:29:26 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SOw08358 for ; Mon, 25 Jul 2005 13:28:24 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQY0BI7T1899PGJC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Jul 2005 23:55:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DBF0AB542; Fri, 22 Jul 2005 23:55:26 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 59E914FB09; Fri, 22 Jul 2005 23:55:26 +1000 (EST) Received: from [211.28.113.141] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 22 Jul 2005 23:55:26 +1000 Date: Fri, 22 Jul 2005 23:55:26 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , James Kempf , Dna Message-id: <56ceed56e74a.56e74a56ceed@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, There are too many topics in this e-mail, so if we need to discuss all of the topics further it may be good to split the threads. ----- Original Message ----- From: JinHyeock Choi Date: Friday, July 22, 2005 6:49 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Greg > > > Right at the bottom is a proposal for a "Graceful" > > means of surviving flash renumbering with Prefix Landmarks. > > > > It's not really necessary in the general case if routers > > retract prefixes with lifetime=0 advertisements, if they > > wish to assign the prefix elsewhere before normal > > lifetime expiry. > > I have difficulty understanding that. Does that take into > consideration packet loss? It does, if the prefixes are retracted for multiple RA intervals, or if changes are advertised as defined in RFC 2461 section 6.2.4. > > > As of my memory, WG didn't made such a decision. > > > > It made the decision at the same time it discarded Numeric LinkIDs, > > Deterministic FastRA etc: when it agreed to focus on 0ne or Two > > potential solutions (with specific properties) at the last IETF. > > No, it didn't make such a decision. (It's strange that it was claimed > that Linkid had been decided to be removed when I presented it. ) I'm referring to draft-pentland-mobileip-linkid-03.txt (which was on the quoted list too). > At the time of Minneapolis meeting, as possible DNA solution > candidates, I had in mind 'CompleteRA', 'Prefix based Linkid' and > 'FRD'. So I took extra and intentional care that WG would not > throw away those 3 schemes. > > As of my memory, only "ruling out" process happened during DT > discussion at Wednesday morning and neither one of three schemes > was ruled out at the meeting. > > I cc Brett's mail after the meeting to back up my memory. [cut] > > Fast advertisement: > Fast Router Discovery > Hash-ordered FastRA (is that a bit easier to say? :) ) > Probabilistic FastRA [cut] I think you miss the point. FastRD was left in because it's possible to apply, but it's not capable of being _the_ general solution for DNA in all cases. Modification of Link-Layer devices is not an option for many environments, so we need to rely upon a base solution which only changes hosts and routers. Optimizations beyond this would have to be specified separately. > > > It's my opinion that if one scheme can perform DNA without > > > RS involvement, that's the pro for the scheme we need to > > > take into consideration. > > It's no more a pro for LinkID than for CompleteRA. > > ok. At this point, my assertion is only that > the above is a worthy criterion to consider when we evaluate > schemes. Well, it's the same for both schemes, and therefore shouldn't take up our highest priority (or any if we're pressed for time)... Please consider spending time on issues which help to differentiate the solutions. [cut] > > I'd prefer "At least 1" or "Defaults to 1" x 4 seconds. > > Right but I am not arguing that such a case is impossible. I am > talking only that such a case seems to be rather an exception. > > Also this is why we think that it is ok for a host to > send 1 RS and waits for 4 secs to collect (solicited) RAs > and declare CCL complete. > > Without a packet loss, the host will generate the complete prefix > list. Even some packet loss may cause an incomplete prefix list, > there is a further chance for the host to get the missing prefixes > before it receives link UP notification, i.e. moves to another AP. > > Even the host moves to another AP with incomplete prefix list, > the first RA may contain the prefix in its prefix list. > > Considering all those above, even if the host performs only one > RS/ RA exchange, it will be very rare for the host to falsely > assume a link change. So I think that occasional additional > signaling is acceptable. I guess that's a point of difference in our opinions. My belief in immediate construction of CPL with completeRA is based on how useful I've seen it to be in implementation. [cut] > > > Answering "Yes" also takes definite knowledge and synchronization. > > > > > > Allow me an example. Assume a link with two routers R1 and R2. > > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > > R1 and R2 gathers the prefixes to make the complete prefix list > > > {Prefix1, Prefix2, Prefix3}. > > > > > > Then R2 removes Prefix3 but the RA advertising the removal > > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > > i.e. Prefix3 is in this link. > > > > > > Am I missing something? > > > > Yes. > > > > The same thing happens with LinkID > > > > In this case, the Router1 will not identify that the LinkID > > has changed either, if the smallest prefix disappears (for > > example if Prefix3 is actually the smallest prefix). > > > > Responses for LinkID will therefore also conflict, Router1 will > > have a LinkID of prefix Prefix3, even if that prefix has been > > assigned to an adjacent link. > > Linkid is designed to deal with such a pathological case with > linkid prefix list. rties) at the last IETF. > > No, it didn't make such a decision. (It's strange that it was claimed > that Linkid had been decided to be removed when I presented it. ) I'm referring to draft-pentland-mobileip-linkid-03.txt (which was on the quoted list too). > At the time of Minneapolis meeting, as possible DNA solution > candidates, I had in mind 'CompleteRA', 'Prefix based Linkid' and > 'FRD'. So I took extra and intentional care that WG would not > throw away those 3 schemes. > > As of my memory, only "ruling out" process happened during DT > discussion at Wednesday morning and neither one of three schemes > was ruled out at the meeting. > > I cc Brett's mail after the meeting to back up my memory. [cut] > > Fast advertisement: > Fast Router Discovery > Hash-ordered FastRA (is that a bit easier to say? :) ) > Probabilistic FastRA [cut] I think you miss the point. FastRD was left in because it's possible to apply, but it's not capable of being _the_ general solution for DNA in all cases. Modification of Link-Layer devices is not an option for many environments, so we need to rely upon a base solution which only changes hosts and routers. Optimizations beyond this would have to be specified separately. > > > It's my opinion that if one scheme can perform DNA without > > > RS involvement, that's the pro for the scheme we need to > > > take into consideration. > > It's no more a pro for LinkID than for CompleteRA. > > ok. At this point, my assertion is only that > the above is a worthy criterion to consider when we evaluate > schemes. Well, it's the same for both schemes, and therefore shouldn't take up our highest priority (or any if we're pressed for time)... Please consider spending time on issues which help to differentiate the solutions. [cut] > > I'd prefer "At least 1" or "Defaults to 1" x 4 seconds. > > Right but I am not arguing that such a case is impossible. I am > talking only that such a case seems to be rather an exception. > > Also this is why we think that it is ok for a host to > send 1 RS and waits for 4 secs to collect (solicited) RAs > and declare CCL complete. > > Without a packet loss, the host will generate the complete prefix > list. Even some packet loss may cause an incomplete prefix list, > there is a further chance for the host to get the missing prefixes > before it receives link UP notification, i.e. moves to another AP. > > Even the host moves to another AP with incomplete prefix list, > the first RA may contain the prefix in its prefix list. > > Considering all those above, even if the host performs only one > RS/ RA exchange, it will be very rare for the host to falsely > assume a link change. So I think that occasional additional > signaling is acceptable. I guess that's a point of difference in our opinions. My belief in immediate construction of CPL with completeRA is based on how useful I've seen it to be in implementation. [cut] > > > Answering "Yes" also takes definite knowledge and synchronization. > > > > > > Allow me an example. Assume a link with two routers R1 and R2. > > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > > R1 and R2 gathers the prefixes to make the complete prefix list > > > {Prefix1, Prefix2, Prefix3}. > > > > > > Then R2 removes Prefix3 but the RA advertising the removal > > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > > i.e. Prefix3 is in this link. > > > > > > Am I missing something? > > > > Yes. > > > > The same thing happens with LinkID > > > > In this case, the Router1 will not identify that the LinkID > > has changed either, if the smallest prefix disappears (for > > example if Prefix3 is actually the smallest prefix). > > > > Responses for LinkID will therefore also conflict, Router1 will > > have a LinkID of prefix Prefix3, even if that prefix has been > > assigned to an adjacent link. > > Linkid is designed to deal with such a pathological case with > linkid prefix list. Kindly check Sec 3 and 4. From 4.2 it's not clear if the first RA received on the link (if it advertises the old LinkID) is taken as non-movement, if the host arrives from the link to which this prefix has been assigned (and is LinkID). It looks like it is. The host hasn't seen the other LinkID before, and when the next RA arrives indicating the NewLinkID and OldLinkID, it could easily be taken as a change of LinkID on the previously visited link. AFAICS, this is the exact same danger as described for Landmarks (but not completeRA, due to the redundant information). > > For Prefix Landmarking: > > > > If any RAs by received by R1 indicating that the lifetime is > > diminished, this will time out the entries. Any single reception > > of a lifetime zero advertisement from the owning router will > > remove the prefix. > > > > This is the same as LinkID. > > > > So if Prefix Landmarking believes the prefix is still on-link > > (and Prefix Landmarking has similar timers for lifetimes that > > LinkID does) then the incorrect state will last about as long > > for either. > > > > The assumption is that prefixes retracted without (effective) > > zero lifetime advertisement and assigned to another link cause > > problems for up to 90 minutes or so: > > > > This is the same for Prefix Landmarks, CompleteRA, LinkID and > > (in hosts' view) CPL. > > > > This is a very tight corner case, since routers listen to RAs > > in DNA, don't sleep, and routers should retract prefixes. > > > > At least with CompleteRA, you can ignore learned DNAO contents > > since the rest of the CompleteRA will not match the existing > > Complete Prefix List. > > I have difficulty following the above. [cut] > > > "NO" will supercede a "YES", if it is received first, right? > > > > Yes, but a false movement detection is actually better than a false > > non-movement detection, since the host recovers in milliseconds, not > > minutes. > > Does the above mean "NO" will always supercede "YES", because > a false movement detection is actually better than a false non- > movement detection? If it is received first, yes. If it isn't it's only because a router believes a prefix exists on-link, where it hasn't recveived appropriate preefix information options to update it. This is the same as for LinkID. [cut] > > In that case though, it can also update the other routers with > > the appropriate RA (prefix lifetime=0). > > Yes, but it needs additional mechanism to ensure every routers > will receive the appropriate RA. I'ts already defined. 6.2.4. Sending Unsolicited Router Advertisements Especially the section describing advertising changes It's optional but has been around for a long time, and doesn't require additional text in DNA... [cut] > > > A practical solution for Prefix Landmarks may be to partly > > ignore "Yes" answers - since they don't require much action: that > > is keep the DNA process open if there's a non-movement indication. > > > > The DNA addressing mechanism may be re-normalized (and packet > > flow can occur with the global addresses), but subsequent > > reception of a trusted "No" RA within (say 500ms) could be used > > as a hint to re-build a CPL - which may be a cause to detect > > change in a few seconds. > > Maybe, but the scheme seems to become more complicated. At least, I > come to have difficulty following your arguments. It's not particularly complicated: If you receive an indication that no change is needed: Don't change anything and start communicating again. If you then receive an indication that change is needed, it may be needed. This is all to handle the concept of "Flash renumbering" (still to be debated if it's a real issue (See section 12 of RFC2461)) under "packet loss" of three packets or where routers haven't followed the recommendation of RFC2461 section 6.2.6 Did we need to do anything anyway? If we assume that routers follow RFC2461 6.2.6 if they're flash renumbering (and we recommend it), then no live router could advertise the wrong prefix with Landmarks, CompleteRA or LinkKindly check Sec 3 and 4. From 4.2 it's not clear if the first RA received on the link (if it advertises the old LinkID) is taken as non-movement, if the host arrives from the link to which this prefix has been assigned (and is LinkID). It looks like it is. The host hasn't seen the other LinkID before, and when the next RA arrives indicating the NewLinkID and OldLinkID, it could easily be taken as a change of LinkID on the previously visited link. AFAICS, this is the exact same danger as described for Landmarks (but not completeRA, due to the redundant information). > > For Prefix Landmarking: > > > > If any RAs by received by R1 indicating that the lifetime is > > diminished, this will time out the entries. Any single reception > > of a lifetime zero advertisement from the owning router will > > remove the prefix. > > > > This is the same as LinkID. > > > > So if Prefix Landmarking believes the prefix is still on-link > > (and Prefix Landmarking has similar timers for lifetimes that > > LinkID does) then the incorrect state will last about as long > > for either. > > > > The assumption is that prefixes retracted without (effective) > > zero lifetime advertisement and assigned to another link cause > > problems for up to 90 minutes or so: > > > > This is the same for Prefix Landmarks, CompleteRA, LinkID and > > (in hosts' view) CPL. > > > > This is a very tight corner case, since routers listen to RAs > > in DNA, don't sleep, and routers should retract prefixes. > > > > At least with CompleteRA, you can ignore learned DNAO contents > > since the rest of the CompleteRA will not match the existing > > Complete Prefix List. > > I have difficulty following the above. [cut] > > > "NO" will supercede a "YES", if it is received first, right? > > > > Yes, but a false movement detection is actually better than a false > > non-movement detection, since the host recovers in milliseconds, not > > minutes. > > Does the above mean "NO" will always supercede "YES", because > a false movement detection is actually better than a false non- > movement detection? If it is received first, yes. If it isn't it's only because a router believes a prefix exists on-link, where it hasn't recveived appropriate preefix information options to update it. This is the same as for LinkID. [cut] > > In that case though, it can also update the other routers with > > the appropriate RA (prefix lifetime=0). > > Yes, but it needs additional mechanism to ensure every routers > will receive the appropriate RA. I'ts already defined. 6.2.4. Sending Unsolicited Router Advertisements Especially the section describing advertising changes It's optional but has been around for a long time, and doesn't require additional text in DNA... [cut] > > > A practical solution for Prefix Landmarks may be to partly > > ignore "Yes" answers - since they don't require much action: that > > is keep the DNA process open if there's a non-movement indication. > > > > The DNA addressing mechanism may be re-normalized (and packet > > flow can occur with the global addresses), but subsequent > > reception of a trusted "No" RA within (say 500ms) could be used > > as a hint to re-build a CPL - which may be a cause to detect > > change in a few seconds. > > Maybe, but the scheme seems to become more complicated. At least, I > come to have difficulty following your arguments. It's not particularly complicated: If you receive an indication that no change is needed: Don't change anything and start communicating again. If you then receive an indication that change is needed, it may be needed. This is all to handle the concept of "Flash renumbering" (still to be debated if it's a real issue (See section 12 of RFC2461)) under "packet loss" of three packets or where routers haven't followed the recommendation of RFC2461 section 6.2.6 Did we need to do anything anyway? If we assume that routers follow RFC2461 6.2.6 if they're flash renumbering (and we recommend it), then no live router could advertise the wrong prefix with Landmarks, CompleteRA or LinkID. This is a lot less complicated... Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlB-000125-Io for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:09 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18673 for ; Sun, 24 Jul 2005 23:36:05 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LFXEEEA8WX659@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 619CFAB55A; Mon, 25 Jul 2005 13:32:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0D2204FB02; Mon, 25 Jul 2005 13:32:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3SQc08346 for dna-list; Mon, 25 Jul 2005 13:28:26 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SFw08251 for ; Mon, 25 Jul 2005 13:28:17 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQYSE6P1S48Y5FU3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 13:19:20 +1000 Received: by localhost (Postfix, from userid 510) id DA741AB542; Sat, 23 Jul 2005 13:19:19 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id 994D94FB0B for ; Sat, 23 Jul 2005 13:19:17 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so348062nzd for ; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Received: by 10.36.71.18 with SMTP id t18mr265965nza; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Date: Sat, 23 Jul 2005 12:19:16 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E0A581.5030407@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072220192dd72a1f@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qDGYU+h9nCJaXlLJknLYs2AzkfXfZZU2oyh6QkD8rM30L2iWnNxPcLZoC3uEk7T6N5Olc0/ZCpngWjYH0vBoba5RqssGnKpiV8N+tmzo2MSEipay0Gl3Xf+HipkdfsVJcn2kc06BMn6XQit27A36LaW0uTvCVhYmovEZDKrRMwY= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > > Answering "Yes" also takes definite knowledge and synchronization. > > > > Allow me an example. Assume a link with two routers R1 and R2. > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > R1 and R2 gathers the prefixes to make the cID. This is a lot less complicated... Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlB-000125-Io for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:09 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18673 for ; Sun, 24 Jul 2005 23:36:05 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LFXEEEA8WX659@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 619CFAB55A; Mon, 25 Jul 2005 13:32:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0D2204FB02; Mon, 25 Jul 2005 13:32:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3SQc08346 for dna-list; Mon, 25 Jul 2005 13:28:26 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SFw08251 for ; Mon, 25 Jul 2005 13:28:17 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQYSE6P1S48Y5FU3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 13:19:20 +1000 Received: by localhost (Postfix, from userid 510) id DA741AB542; Sat, 23 Jul 2005 13:19:19 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id 994D94FB0B for ; Sat, 23 Jul 2005 13:19:17 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so348062nzd for ; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Received: by 10.36.71.18 with SMTP id t18mr265965nza; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 20:19:16 -0700 (PDT) Date: Sat, 23 Jul 2005 12:19:16 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E0A581.5030407@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072220192dd72a1f@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qDGYU+h9nCJaXlLJknLYs2AzkfXfZZU2oyh6QkD8rM30L2iWnNxPcLZoC3uEk7T6N5Olc0/ZCpngWjYH0vBoba5RqssGnKpiV8N+tmzo2MSEipay0Gl3Xf+HipkdfsVJcn2kc06BMn6XQit27A36LaW0uTvCVhYmovEZDKrRMwY= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > > Answering "Yes" also takes definite knowledge and synchronization. > > > > Allow me an example. Assume a link with two routers R1 and R2. > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > R1 and R2 gathers the prefixes to make the complete prefix list > > {Prefix1, Prefix2, Prefix3}. > > > > Then R2 removes Prefix3 but the RA advertising the removal > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > i.e. Prefix3 is in this link. > > > > Am I missing something? > > Well, "YES" is the answer that LinkID would give too. The LinkID would > not have changed on R1 and the host would correctly recognise that it is > NOT a link change. So how is it better? I gave the above example only to show that both "YES" and "NO" need "definite knowledge and synchronization". I didn't give it to show linkid's superiority. (I'll prepare a better one. Just wait. :-)) > You say that LinkID has a method to deal with changing prefixes. Hosts > keep a record previously seen LinkIDs so that they can recognise > changes. Isn't this implicit in the CompleteRA aspect of the landmark > proposal? Each of the prefixes can be thought of as a LinkID, and any > overlap between the prefixes in a CompleteRA and the prefixes that the > host has seen implies non-movement. The problem is that such a overlapping prefix may not exist. For the CompleteRA or Landmark, there is no MOI (Message Order Independence) property. (Greg wrote a related draft. http://www.ctie.monash.edu.au/dna/mmoi-draft-dont-distrib.pdf ) In linkid scheme, when a linkid is changed, I take extra care to make it sure that there is at least one (old) linkid prefix that assures the hosts that this is linkid change without link change. (I was tempted to call such a prefix as a linking prefix, but dared not for the fear of confusion. :-) ) Correct me wrong, but in ComplteRA or Landmark, there is no mechanism which ensures that always such a linking (or overlapping) prefix exists. > Putting aside, for the moment, cases where a prefix is moved to a new > link before its lifetime advertised on the old link has expired, your > own example shows how the Landmark part deals with changes effectively. > A YES answer will only occur if the prefix has been used on the link and > so will not be wrong in the sense that the current link is the same one > where the Landmark came from. If that prefix is in the process of being > removed, then very soon a NO answer will arrive from the applicable > router informing the host of this and providing the prefixes that are > available. Note also that the window of oportunity for this to happen > is quite small as the router that removed the prefix should advertise > this fact several times in a fairly short space of time so that all > of the routers on the link are aware of the change. I can think of more pathological example easily by cut and paste from old DT ML. Assume a host having two prefix A and B, and making one address with A and the other with B. Assume prefix A goes through prefix renumbering and early reassignment and the host follows it. Then it will not perceive that it can't no longer use the address with prefix B:. > Returning to cases where prefixes can be reasigned to a new link before > the expiry of a previously advertised valid lifetime on another link, > both of the proposals face the same issue and need to deal with it by > placing rules about how the reassignment is done. If a host sees a > LinkID or a Landmark on one link, fails to see advertisements that the > valid lifetime has been shortened, and then sees the same LinkID / > Landmark on another link, they will fail to detect the link change. Linkid draft sets the rule to prevent such a case. So I may say that Linkid is safe from flash renumbering and early reassignment, unless there is a human error, (from which no scheme can be safe 100 %.) . Best Regards JinHyeock. omplete prefix list > > {Prefix1, Prefix2, Prefix3}. > > > > Then R2 removes Prefix3 but the RA advertising the removal > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > i.e. Prefix3 is in this link. > > > > Am I missing something? > > Well, "YES" is the answer that LinkID would give too. The LinkID would > not have changed on R1 and the host would correctly recognise that it is > NOT a link change. So how is it better? I gave the above example only to show that both "YES" and "NO" need "definite knowledge and synchronization". I didn't give it to show linkid's superiority. (I'll prepare a better one. Just wait. :-)) > You say that LinkID has a method to deal with changing prefixes. Hosts > keep a record previously seen LinkIDs so that they can recognise > changes. Isn't this implicit in the CompleteRA aspect of the landmark > proposal? Each of the prefixes can be thought of as a LinkID, and any > overlap between the prefixes in a CompleteRA and the prefixes that the > host has seen implies non-movement. The problem is that such a overlapping prefix may not exist. For the CompleteRA or Landmark, there is no MOI (Message Order Independence) property. (Greg wrote a related draft. http://www.ctie.monash.edu.au/dna/mmoi-draft-dont-distrib.pdf ) In linkid scheme, when a linkid is changed, I take extra care to make it sure that there is at least one (old) linkid prefix that assures the hosts that this is linkid change without link change. (I was tempted to call such a prefix as a linking prefix, but dared not for the fear of confusion. :-) ) Correct me wrong, but in ComplteRA or Landmark, there is no mechanism which ensures that always such a linking (or overlapping) prefix exists. > Putting aside, for the moment, cases where a prefix is moved to a new > link before its lifetime advertised on the old link has expired, your > own example shows how the Landmark part deals with changes effectively. > A YES answer will only occur if the prefix has been used on the link and > so will not be wrong in the sense that the current link is the same one > where the Landmark came from. If that prefix is in the process of being > removed, then very soon a NO answer will arrive from the applicable > router informing the host of this and providing the prefixes that are > available. Note also that the window of oportunity for this to happen > is quite small as the router that removed the prefix should advertise > this fact several times in a fairly short space of time so that all > of the routers on the link are aware of the change. I can think of more pathological example easily by cut and paste from old DT ML. Assume a host having two prefix A and B, and making one address with A and the other with B. Assume prefix A goes through prefix renumbering and early reassignment and the host follows it. Then it will not perceive that it can't no longer use the address with prefix B:. > Returning to cases where prefixes can be reasigned to a new link before > the expiry of a previously advertised valid lifetime on another link, > both of the proposals face the same issue and need to deal with it by > placing rules about how the reassignment is done. If a host sees a > LinkID or a Landmark on one link, fails to see advertisements that the > valid lifetime has been shortened, and then sees the same LinkID / > Landmark on another link, they will fail to detect the link change. Linkid draft sets the rule to prevent such a case. So I may say that Linkid is safe from flash renumbering and early reassignment, unless there is a human error, (from which no scheme can be safe 100 %.) . Best Regards JinHyeock. From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlE-00012W-8L for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:12 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18674 for ; Sun, 24 Jul 2005 23:36:06 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LG0AHB28WX64S@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0540AAB59A; Mon, 25 Jul 2005 13:32:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9280F4FB02; Mon, 25 Jul 2005 13:32:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3UDH08637 for dna-list; Mon, 25 Jul 2005 13:30:13 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3U8w08599 for ; Mon, 25 Jul 2005 13:30:08 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LQYXIW3GG88WWMFI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 15:46:41 +1000 Received: by localhost (Postfix, from userid 510) id D9616AB542; Sat, 23 Jul 2005 15:46:40 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by curly.its.monash.edu.au (Postfix) with ESMTP id AB2D74FB06 for ; Sat, 23 Jul 2005 15:46:39 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so370301nzd for ; Fri, 22 Jul 2005 22:46:38 -0700 (PDT) Received: by 10.36.222.66 with SMTP id u66mr342854nzg; Fri, 22 Jul 2005 22:46:38 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 22 Jul 2005 22:46:38 -0700 (PDT) Date: Sat, 23 Jul 2005 14:46:38 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <56ceed56e74a.56e74a56ceed@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050722224649dae3f4@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sMd3zSywjrtYrrm0mZ9/01hRR+XZlkBOy70ai8pYoAQlZ0sfCTC/Ni0IT1Hrmca/ptMYuwGPet3YJJrdIfbYOwrSQyk4P3p8GqAWVvTw4/JQtkTnOUpgZ5TCVwJ4jME+3M0YdOB7YhfsGDUYfepwEu0uG7E8pCLERgUYt/MEOs0= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <56ceed56e74a.56e74a56ceed@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > > No, it didn't make such a decision. (It's strange that it was claimed > > that Linkid had been decided to be removed when I presented it. ) > > I'm referring to draft-pentland-mobileip-linkid-03.txt (which was on > the quoted list too). I meant the claim made by other person, not by you. > [cut] > > > > Fast advertisement: > > Fast Router Discovery > > Hash-ordered FastRA (is that a bit easier to say? :) ) > > Probabilistic FastRA > [cut] > > I think you miss the point. FastRD was left in because it's > possible to apply, but it's not capable of being _the_ general > solution for DNA in all cases. > > Modification of Link-Layer devices is not an option for many > environments, so we need to rely upon a base solution which > only changes hosts and routers. > > Optimizations beyond this would have to be specified separately. As of my memory, in DT meeting, no such agreement (about why FRD is left) is made. An unfortunate incident in D.C. made a paranoid out of me, so I took keen notice about FRD treatment. About the FRD applicability, that's the decision for WG. If WG chooses FRD for its high performance in spite of L2 reliance, it's WG's call. It's ok for you have an opinion about FRD and its treatment but I ask you NOT to assume it as an official agreement before going through a proper decision procedure. > > ok. At this point, my assertion is only that > > the above is a worthy criterion to consider when we evaluate > > schemes. > > Well, it's the same for both schemes, and therefore shouldn't > take up our highest priority (or any if we're pressed for time)... This the the conclusion I can't be sure of. There may be a link in which CompleteRA can't be made as mentioned in Brett's draft below, It may not be possible to include all of the prefixes in use on the link due to MTU or administrative limitations. > Please consider spending time on issues which help to differentiate > the solutions. ok. I guess we are in agreement that unsolicited RA concern is a worthy criterion, so let's investigate how it differentiate two schemes. > From 4.2 it's not clear if the first RA received on the link > (if it advertises the old LinkID) is taken as non-movement, if the > host arrives from the link to which this prefix has been > assigned (and is LinkID). > > It looks like it is. > > The host hasn't seen the other LinkID before, and when the next > RA arrives indicating the NewLinkID and OldLinkID, it could easily be > taken as a change of LinkID on the previously visited link. > > AFAICS, this is the exact same danger as described for Landmarks > (but not completeRA, due to the redundant information). I have difficulty understanding the above example. Kindly clarify more. > > Yes, but it needs additional mechanism to ensure every routers > > will receive the appropriate RA. > > I'ts already defined. > > 6.2.4. Sending Unsolicited Router Advertisements > > Especially the section describing advertising changes > > It's optional but has been around for a long time, and > doesn't require additional text in DNA... I meant to make it extra-sure that all routers have received the appropriate RA even under the packet loss. 6.2.4 is rather a UDP like and I meant a TCP like assurance. > > Maybe, but the scheme seems to become more complicated. At least, I > > come to have difficulty following your arguments. > > It's not particularly complicated: > > If you receive an indication that no change is needed: > Don't change anything and start communicating again. > If you then receive an indication that change is needed, > it may be needed. > > This is all to handle the concept of "Flash renumbering" > (still to be debated if it's a real issue (See section 12 of > RFC2461)) under "packet loss" of three packets or where routers > haven't followed the recommendation of RFC2461 section 6.2.6 > > Did we need to do anything anyway? > > If we assume that routers follow RFC2461 6.2.6 if they're > flash renumbering (and we recommend it), then no live router > could advertise the wrong prefix with Landmarks, CompleteRA > or LinkID. I have difficulty following your thoughts on the synchronization issue for Landmark/ CompleteRA because new arguments pops up in each mail. It would help me a lot, if you summarize your thoughts in whole. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 24 23:36:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtlF-00012v-KD for dna-archive@megatron.ietf.org; Sun, 24 Jul 2005 23:36:13 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18714 for ; Sun, 24 Jul 2005 23:36:09 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1LGHN6DU8Y5U51@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 13:34:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B4796AB5AF; Mon, 25 Jul 2005 13:32:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 62E984FB03; Mon, 25 Jul 2005 13:32:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P3SUg08359 for dna-list; Mon, 25 Jul 2005 13:28:30 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P3SHw08267 for ; Mon, 25 Jul 2005 13:28:17 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LQY4MM7PU29API88@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Jul 2005 01:58:56 +1000 Received: by localhost (Postfix, from userid 510) id 03ADD8000D; Sat, 23 Jul 2005 01:58:55 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6955F3C00B; Sat, 23 Jul 2005 01:58:54 +1000 (EST) Date: Fri, 22 Jul 2005 08:58:47 -0700 From: James Kempf Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: Syam Madanapalli , Brett Pentland , Dna Message-id: <03a801c58ed6$401e4bc0$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E090DC.6040408@eng.monash.edu.au> <92e919fb050722014911d62f01@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeok, The minutes of the IETF 62 meeting show that I proposed taking FastRA out of contention, because it is very link specific (it would not work for 3.9G for example), and referring it to the proper link standardization group (probably 802.21). Unfortuantely, there is no record of a consensus call on this proposal in the minutes. I'd like to renew my proposal and suggest to the chairs that a consensus call be done at a convenient time. We cannot make progress on getting this standard complete if discussion never results in any decisions being made. jak ----- Original Message ----- From: "JinHyeock Choi" To: Cc: "Syam Madanapalli" ; "Brett Pentland" ; "James Kempf" ; "Dna" Sent: Friday, July 22, 2005 1:49 AM Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Greg > > > Right at the bottom is a proposal for a "Graceful" > > means of surviving flash renumbering with Prefix Landmarks. > > > > It's not really necessary in the general case if routers > > retract prefixes with lifetime=0 advertisements, if they > > wish to assign the prefix elsewhere before normal > > lifetime expiry. > > I have difficulty understanding that. Does that take into consideration > packet loss? > > > > As of my memory, WG didn't made such a decision. > > > > It made the decision at the same time it discarded Numeric LinkIDs, > > Deterministic FastRA etc: when it agreed to focus on 0ne or Two > > potential solutions (with specific properties) at the last IETF. > > No, it didn't make such a decision. (It's strange that it was claimed > that Linkid had been decided to be removed when I presented it. ) > > At the time of Minneapolis meeting, as possible DNA solution candidates, > I had in mind 'CompleteRA', 'Prefix based Linkid' and 'FRD'. So I took > extra and intentional care that WG would not throw away those 3 schemes. > > As of my memory, only "ruling out" process happened during DT > discussion at Wednesday morning and neither one of three schemes > was ruled out at the meeting. > > I cc Brett's mail after the meeting to back up my memory. > > ---------------------------------------------------------- > Hi guys, > > Yesterday we agreed that several of the techniques that we have > discussed are probably not worth pursuing. Those are: > > Explicit LinkID - random > Explicit LinkID - hash of prefixes > Priority Landmark > Simple FastRA > Deterministic FastRA > > That leaves us with the following: > > Link detection: > Explicit LinkID - agreed prefix > CompleteRA > Requested Landmark > Hybrid Landmark > > Fast advertisement: > Fast Router Discovery > Hash-ordered FastRA (is that a bit easier to say? :) ) > Probabilistic FastRA > > Cheers, > Brett. > > ---------------------------------------------------------- > > > > It's my opinion that if one scheme can perform DNA without RS involvement, > > > that's the pro for the scheme we need to take into consideration. > > > > It's no more a pro for LinkID than for CompleteRA. > > ok. At this point, my assertion is only that > > the above is a worthy criterion to consider when we evaluate schemes. > > > > According to the current CPL recommendation, it will take 4 secs for > > > a host to generate the complete prefix list. I think it's rather an > > > exceptional case for a host to change attachment within 4 secs > > > after network attachment. > > > > It's not that hard to change attachment points quickly with ping-pong. > > This is a well known problem. > > > > I'm not in strict agreement with the single RS for CPL, > > since RA messages can be lost, and you can end up with half a CPL. > > > > If you transit outside the cell within 4 seconds, false link change > > detection occurs. > > > > I'd prefer "At least 1" or "Defaults to 1" x 4 seconds. > > Right but I am not arguing that such a case is impossible. I am > talking only that such a case seems to be rather an exception. > > Also this is why we think that it is ok for a host to > send 1 RS and waits for 4 secs to collect (solicited) RAs > and declare CCL complete. > > Without a packet loss, the host will generate the complete prefix list. > > Even some packet loss may cause an incomplete prefix list, > there is a further chance for the host to get the missing prefixes > before it receives link UP notification, i.e. moves to another AP. > > Even the host moves to another AP with incomplete prefix list, > the first RA may contain the prefix in its prefix list. > > Considering all those above, even if the host performs only one > RS/ RA exchange, it will be very rare for the host to falsely > assume a link change. So I think that occasional additional > signaling is acceptable. > > > >>>As we have implemented the linkid scheme, we did not find any such problems. > > >>>For landmark also all the Routers need know about all other prefixes, otherwie > > >>>the host may get conflict answers. > > >> > > >>It doesn't need to know all the prefixes (as described in a previous > > >>thread). It needs to know what prefixes it definitely has locally. > > >> > > >>In that case, it can answer "Yes" immediately. Answering "No" takes > > >>definitive knowledge and synchronization. > > > > > > > > > Answering "Yes" also takes definite knowledge and synchronization. > > > > > > Allow me an example. Assume a link with two routers R1 and R2. > > > R1 advertises Prefix1 and R2 advertise Prefix2 and Prefix3. > > > R1 and R2 gathers the prefixes to make the complete prefix list > > > {Prefix1, Prefix2, Prefix3}. > > > > > > Then R2 removes Prefix3 but the RA advertising the removal > > > was lost and R1 doesn't receive it. So afterwards, if a (dormant) > > > host send an RS with Prefix3 to R1, it will falsely answer "YES", > > > i.e. Prefix3 is in this link. > > > > > > Am I missing something? > > > > Yes. > > > > The same thing happens with LinkID > > > > In this case, the Router1 will not identify that the LinkID has changed > > either, if the smallest prefix disappears (for example if Prefix3 is > > actually the smallest prefix). > > > > Responses for LinkID will therefore also conflict, Router1 will > > have a LinkID of prefix Prefix3, even if that prefix has been > > assigned to an adjacent link. > > Linkid is designed to deal with such a pathological case with > linkid prefix list. Kindly check Sec 3 and 4. > > > For Prefix Landmarking: > > > > If any RAs by received by R1 indicating that the lifetime is > > diminished, this will time out the entries. Any single reception > > of a lifetime zero advertisement from the owning router will > > remove the prefix. > > > > This is the same as LinkID. > > > > So if Prefix Landmarking believes the prefix is still on-link > > (and Prefix Landmarking has similar timers for lifetimes that > > LinkID does) then the incorrect state will last about as long > > for either. > > > > The assumption is that prefixes retracted without (effective) > > zero lifetime advertisement and assigned to another link cause > > problems for up to 90 minutes or so: > > > > This is the same for Prefix Landmarks, CompleteRA, LinkID and > > (in hosts' view) CPL. > > > > This is a very tight corner case, since routers listen to RAs > > in DNA, don't sleep, and routers should retract prefixes. > > > > At least with CompleteRA, you can ignore learned DNAO contents > > since the rest of the CompleteRA will not match the existing > > Complete Prefix List. > > I have difficulty following the above. > > > >>A prefix which answers > > >>"Yes" will supercede a "No" if it is received first. > > > > > > > > > I guess the same applies for "NO". > > > > > > "NO" will supercede a "YES", if it is received first, right? > > > > Yes, but a false movement detection is actually better than a false > > non-movement detection, since the host recovers in milliseconds, not > > minutes. > > Does the above mean "NO" will always supercede "YES", because > a false movement detection is actually better than a false non-movement > detection? > > > > In the example I present the above, "NO" is the correct one and > > > doesn't result from "that a prefix's advertisement has not been received > > > on the "No" router before the RS with a landmark query is sent." > > > > I see your point: the most up-to-date router could respond "NO" based on > > updated information. > > > > In that case though, it can also update the other routers with > > the appropriate RA (prefix lifetime=0). > > Yes, but it needs additional mechanism to ensure every routers > will receive the appropriate RA. > > > > Correct me wrong but when I looked through Landmark/ CompleteRA > > > last time, I don't see any mechanism to deal with the case two routers > > > give conflicting answers, one yes and the other no. Such a case can > > > arise from a lack of synchronization. > > > > Indeed, this is the same as LinkID, where the out-of-date LinkID is > > still used by a router which has not seen the PIO with the prefix > > retracted. > > > > While Prefix Landmarks can conceivably answer "Yes" incorrectly > > in this case, so would some of the LinkID routers. > > As I wrote above, it will not affect DNA performance for Linkid. > Kindly look over the draft. > > > A practical solution for Prefix Landmarks may be to partly > > ignore "Yes" answers - since they don't require much action: that > > is keep the DNA process open if there's a non-movement indication. > > > > The DNA addressing mechanism may be re-normalized (and packet flow can > > occur with the global addresses), but subsequent reception of a > > trusted "No" RA within (say 500ms) could be used as a hint to re-build > > a CPL - which may be a cause to detect change in a few seconds. > > Maybe, but the scheme seems to become more complicated. At least, I > come to have difficulty following your arguments. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 01:09:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvDm-0003vU-91 for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 01:09:46 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24277 for ; Mon, 25 Jul 2005 01:09:44 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1OTF5O8C99PNB6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 15:09:31 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 48583AB550; Mon, 25 Jul 2005 15:09:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id CCFAA4FB06; Mon, 25 Jul 2005 15:09:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P59Ow10986 for dna-list; Mon, 25 Jul 2005 15:09:24 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P59Nw10980 for ; Mon, 25 Jul 2005 15:09:24 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1OTAO8HK8WX6ZO@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 15:09:21 +1000 Received: by localhost (Postfix, from userid 510) id 715B3AB543; Mon, 25 Jul 2005 15:09:21 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9677A4FB03 for ; Mon, 25 Jul 2005 15:09:20 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so813404nzd for ; Sun, 24 Jul 2005 22:09:19 -0700 (PDT) Received: by 10.36.7.9 with SMTP id 9mr91386nzg; Sun, 24 Jul 2005 22:09:19 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Sun, 24 Jul 2005 22:09:19 -0700 (PDT) Date: Mon, 25 Jul 2005 14:09:19 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E4471D.2010309@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507242209d09cf66@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OUHGQPPWZjgVeKIWnZLIiJ/gETd0MvUfZLksojiJqlud3VUOZXo6wHL6Wo7G7tN01Ob9vbdqYC1BHCcLdUc8b1TLa4tt5tb8d9cGlqFSTxmGIvAWlfEyegrM5+k1njxIO+LrmYTOxl72up5UBGtcNnFGNTy7cBtHiJbRfLvHEsU= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> <92e919fb05072220192dd72a1f@mail.gmail.com> <42E4471D.2010309@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > > Correct me wrong, but in ComplteRA or Landmark, there is no > > mechanism which ensures that always such a linking (or overlapping) > > prefix exists. > > That's almost the definition of Complete RA. All routers should be > advertising the same set of prefixes so that pretty much ensures > overlap. The only way for there not to be is for a router which has > no learned prefixes (ie. all of the prefixes it is advertising are > explicitly configured on it) to instantly stop advertising those > prefixes and start advertising a new set. It's trivial to add a rule > to say don't do that. ok. Kindly add that rule and then we may resume this discussion. > > Assume a host having two prefix A and B, and making one address with > > A and the other with B. Assume prefix A goes through prefix renumbering > > and early reassignment and the host follows it. Then it will not perceive > > that it can't no longer use the address with prefix B:. > > True, but LinkID doesn't prevent that either. Both methods need to > manage that through the imposition of rules for renumbering, and the > setting of timeouts on DNA information. No, Linkid has a rule to prevent "Renumbering and Early reassignment." > > Linkid draft sets the rule to prevent such a case. So I may say that > > Linkid is safe from flash renumbering and early reassignment, unless > > there is a human error, (from which no scheme can be safe 100 %.) . > > And those same rules apply equally well to Landmark/CompleteRA. Maybe. Then kindly also write down those rules in the draft. I will be happy if you also adopt the similar rule for Landmark/ CompleteRA. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 01:10:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvEI-0003xQ-9I for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 01:10:18 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24316 for ; Mon, 25 Jul 2005 01:10:16 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1OTANQV88Y5WET@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 15:09:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BC6B8000F; Mon, 25 Jul 2005 15:09:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DC70B3C00E; Mon, 25 Jul 2005 15:09:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P58tB10944 for dna-list; Mon, 25 Jul 2005 15:08:55 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P58rw10940 for ; Mon, 25 Jul 2005 15:08:53 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1OSHZ15Y9APIV3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 15:08:43 +1000 Received: by localhost (Postfix, from userid 510) id DC16E8000E; Mon, 25 Jul 2005 15:08:42 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by larry.its.monash.edu.au (Postfix) with ESMTP id D196D3C00D for ; Mon, 25 Jul 2005 15:08:41 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so813346nzd for ; Sun, 24 Jul 2005 22:08:40 -0700 (PDT) Received: by 10.36.71.18 with SMTP id t18mr1749955nza; Sun, 24 Jul 2005 22:08:39 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Sun, 24 Jul 2005 22:08:39 -0700 (PDT) Date: Mon, 25 Jul 2005 14:08:39 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix In-reply-to: <04f801c58f53$5bf83d60$596015ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: greg.daley@eng.monash.edu.au, Sathya Narayanan , Brett Pentland , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050724220825aff96a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aBdibcvXrKSnrKTLLu0sBZlVanrTb/6nVcMsZLkavEbhSQQvOZmdarWjQPavPqyGgWxi7pNNjKQja/68hdEqD/DAtfZpQ538jYJDR3nspwzcY8avFpEQvbn0xwSKiNzIwN+8uWyS56CEWz73uBmGvWNBHhVvw54cMcXeyOvGj04= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCAC43.2030602@eng.monash.edu.au> <92e919fb0507190951362ec87c@mail.gmail.com> <42DD3541.3010703@Research.Panasonic.COM> <92e919fb05072022099ff63ae@mail.gmail.com> <42DF4642.3090407@eng.monash.edu.au> <92e919fb050722013353f58362@mail.gmail.com> <037501c58ed3$83b8d7e0$596015ac@dcml.docomolabsusa.com> <92e919fb05072221122451187@mail.gmail.com> <04f801c58f53$5bf83d60$596015ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Dear Jak > My point is that, if we are to compare packet size as Greg suggested, > we need to compare all the packet size coming from each scheme, > not only the packet size of one RS/ RA exchange. > > jak>> But how often will this signaling take place? I think one must be > realistic about the critera. If the signaling only takes place every > handover, then I think that the size isn't really relevant, within reason of > course. We're not talking about a periodic beacon in that case. If we take into consideration unsolicted RA, we may need to talk about periodic beacon. > jak>> So it seems like there is an assumption that this signaling will take > place on the broadcast channel? Is that right? Has WiMax Forum already > decided to do IP signaling on the broadcast channel? It is not decided on yet. But if a node is to send, for example, an Neighbor Solicitation message for DAD, broadcast channel seems to be needed. > jak>> I think there are more important criteria, like backward > compatibility. How would each of these methods handle having a nonDNA router > on the link, or handover between a DNA link and a nonDNA link? These are the > kinds of issues that will negatively or positively impact deployment > potential, not whether one or the other technique has a couple fewer bytes > in the best case. I see your point. Kindly allow me a question. Sathya asserted that efficient bandwidth utilization is a pro of Landmark/ CompleteRA over Linkid as below. Prefix Landmark provides a way for the router to know whether the host with the 'landmark question' has changed link or not and build its (unicast-)RA accordingly, which I think will be very efficient in terms of bandwidth utilization as 'no link change' is more likely than not. From your stand toward packet size, I understand that you think the above is irrelevant for comparison. Right? Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 01:11:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvFo-00045B-AR for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 01:11:53 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24419 for ; Mon, 25 Jul 2005 01:11:50 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1OVUAC4S99PPC0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 15:11:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54D1FAB542; Mon, 25 Jul 2005 15:11:24 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 11A914FB07; Mon, 25 Jul 2005 15:11:24 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P5BKL11062 for dna-list; Mon, 25 Jul 2005 15:11:20 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P5BKw11058 for ; Mon, 25 Jul 2005 15:11:20 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1OVIICR88Y5WEU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 15:11:08 +1000 Received: by localhost (Postfix, from userid 510) id 979C98000E; Mon, 25 Jul 2005 15:11:08 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by larry.its.monash.edu.au (Postfix) with ESMTP id 42FF63C010 for ; Mon, 25 Jul 2005 15:11:07 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so813616nzd for ; Sun, 24 Jul 2005 22:11:06 -0700 (PDT) Received: by 10.36.25.20 with SMTP id 20mr1772138nzy; Sun, 24 Jul 2005 22:11:06 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Sun, 24 Jul 2005 22:11:06 -0700 (PDT) Date: Mon, 25 Jul 2005 14:11:06 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <59a7c05958bc.5958bc59a7c0@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050724221148058e87@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JtNuqW7FWfnpfXPkysBVVxbZz70tSKBM6yk25fiIARD1Mk1BOPfKdWKPqVc4lVGqrwnVYtmCwTmkvfW9XAwVCNMMmn9Cn+tCAY7u9cWKaPD+1G+4taj8eUYgmy+bypC+bLEHLvwxybul5MYlK2/3uSf709bM87njPm4uSG6rylQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <59a7c05958bc.5958bc59a7c0@monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > > As of my memory, in DT meeting, no such agreement (about why > > FRD is left) is made. > > It was left _in_, not _out_. > > So it is still under consideration, but it is important to > note (as I said above) that the scheme relies on > modified link-layer devices on the network side, so it > is important (IMO) to have a Base DNA protocol scheme which > doesn't explicitly rely on the presence of FastRD to get > useful performance. > > If the WG desires that FastRD is included in another document, > then that's OK. > > > An unfortunate incident in D.C. made a paranoid out of me, so > > I took keen notice about FRD treatment. > > You've received my (public) apology on that count (and my > statement that I was of good, if misguided intention), and my > undertaking that I'll not interfere in any presentation or > decision making by the WG. > > > About the FRD applicability, that's the decision for WG. If WG > > chooses FRD for its high performance in spite of L2 reliance, > > it's WG's call. > > Yes. > > > It's ok for you have an opinion about FRD and its treatment but > > I ask you NOT to assume it as an official agreement before going > > through a proper decision procedure. > > I never did. Your own quotation of the e-mails describes this. Unfortunately I got the impression you did. When I mentioned that WG didn't make a decision that FRD is not under consideration for the main DNA solution, you wrote that WG decided at Minneapolis. If that impression was not intended, we agreed that WG didn't make a decision on FRD yet, right? In case, I wish we close this not-so-pleasant issue here. > > > Well, it's the same for both schemes, and therefore shouldn't > > > take up our highest priority (or any if we're pressed for time)... > > > > This the the conclusion I can't be sure of. There may be a link > > in which CompleteRA can't be made as mentioned in Brett's draft > > below, > > > > It may not be possible to include all of the prefixes in use on the > > link due to MTU or administrative limitations. > > Please let me make this clear then: > > This is handled by falling back to CPL, and the RAs do not contain > completeness indications (i.e it is not a CompleteRA). > This is described in the draft (2nd paragraph of page 7, and > fourth Paragraph of page 20). > > Please notice that in the usual case, CompleteRA has the same > per-packet overhead as Prefix LinkIDs: none. So in the usual case > the comments aren't applicable. > > The MTU argument isn't useful for today's RAs and is present > mainly for future protection: > > For most deployments of routers: say 4 distinct prefixes/link, the > maximum overheads for CompleteRA and LinkID aren't very different: > > CompleteRA :- maximum 56 octets Max overhead/RA > LinkID:- 32 (64 transition) octets Max overhead/RA. > > This assumes that each router advertises at least one prefix. > > Since SEND will add less than 632 octets (320 CGA option, > 280 octets Signature option, 16 timestamp, 16 Nonce) even > with 2048bit RSA keys, there will still be 648 octets > left for the IPv6 header, RA header and options, if we > limit the RA to even the minimum IPv6 MTU (1280 octets). > > With the headers, SLLAO and MIPv6 Advertisement Interval, > there are still 576 octets left for PIOs and DNAO or > LinkID LPIO options. > > So the limitations have to be administrative today (due to > storage or transmission limitations). > > It's not going to take much/any text to describe > the tradeoff, if it's needed. > > So, getting back to my main point: > > The schemes (CompleteRA and LinkID) are the same for > unsolicited RA (disregarding co-existance and > synchronization issues). So we really don't need > to identify one scheme as being better for > unsolicited RAs. The above analysis is dependent on # prefixes on a link. When I worked on CompleteRA, some DT members showed concern for the link with high # prefixes. Also I think we'd better have this kind of discussion to investigate whether unsoilcted RA differentiates or not first, before jumping to the conclusion that unsolicited RA is irrelevant. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 02:52:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwwp8-0001fK-MT for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 02:52:26 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21749 for ; Mon, 25 Jul 2005 02:52:25 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1SBSCHXU8Y5P7A@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 16:50:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E44580012; Mon, 25 Jul 2005 16:49:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D80163C018; Mon, 25 Jul 2005 16:49:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P6nFj12242 for dna-list; Mon, 25 Jul 2005 16:49:15 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P6nDw12238 for ; Mon, 25 Jul 2005 16:49:13 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1SB1U7CW99PMSS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 16:49:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ABD37AB543; Mon, 25 Jul 2005 16:49:10 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 63FB34FB14; Mon, 25 Jul 2005 16:49:10 +1000 (EST) Date: Mon, 25 Jul 2005 16:49:09 +1000 From: Brett Pentland Subject: [DNA] Issue 12: Network renumbering - guidelines for deployment? - was Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb0507242209d09cf66@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E48B65.4030108@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> <92e919fb05072220192dd72a1f@mail.gmail.com> <42E4471D.2010309@eng.monash.edu.au> <92e919fb0507242209d09cf66@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Dear Brett > > >>>Correct me wrong, but in ComplteRA or Landmark, there is no >>>mechanism which ensures that always such a linking (or overlapping) >>>prefix exists. >> >>That's almost the definition of Complete RA. All routers should be >>advertising the same set of prefixes so that pretty much ensures >>overlap. The only way for there not to be is for a router which has >>no learned prefixes (ie. all of the prefixes it is advertising are >>explicitly configured on it) to instantly stop advertising those >>prefixes and start advertising a new set. It's trivial to add a rule >>to say don't do that. > > > ok. Kindly add that rule and then we may resume this discussion. I'll add this to the discussion on issue 12 which was about this point. We had more or less decided to just describe the consequences of flash reassignment. It's trivial to say "don't reassign a prefix to a new link before it's old lifetime has expired" and that solves this problem, but maybe that's too strict a requirement (or maybe it's not). I'm not sure how this fits in with DHCPv6 prefix delegation, for example. It sounds like this needs further investigation. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 03:33:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwxSc-0006ZO-DW for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 03:33:14 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23537 for ; Mon, 25 Jul 2005 03:33:12 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1TTELN9I9APJF2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 17:33:03 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E61EFAB54E; Mon, 25 Jul 2005 17:32:59 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6922F4FB09; Mon, 25 Jul 2005 17:32:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P7WWq12715 for dna-list; Mon, 25 Jul 2005 17:32:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P7WWw12711 for ; Mon, 25 Jul 2005 17:32:32 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1TSHXYC89APJF2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 17:32:16 +1000 Received: by localhost (Postfix, from userid 510) id 3620A8000E; Mon, 25 Jul 2005 17:32:16 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id D66453C00D; Mon, 25 Jul 2005 17:32:12 +1000 (EST) Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DwxRU-0007oy-TR; Mon, 25 Jul 2005 09:32:09 +0200 Date: Mon, 25 Jul 2005 09:32:03 +0200 From: Christian Vogt Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E43AC6.2030806@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , DNA , TM-RO2 Message-id: <42E49573.8030105@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> <42E43AC6.2030806@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, hi Erik. > Ah yes. For some reason a forgot that the MN would be the one > initiating the communication. Is there any way that an on-link > node could obtain the MN's CoA and try to initiate a > communication? Ok, you are talking about the case were an on-link node configures the MN's optimistic address after the MN has configured that address (as optimistic), but before the MN has sent the initial NS for that address, right? Draft-ietf-ipv6-optimistic-dad-05.txt says: * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation for an Optimistic Address from the unspecified address. This NS indicates that the address is a duplicate, and it MUST be deconfigured as per the behaviour specified in RFC2462 for Tentative addresses. In this case, the NS is from a node doing (0)DAD. The rule ensures that the node who sends the NS first wins and can retain the address. * (modifies 5.4.3) The node MUST reply to a Neighbor Solicitation for an Optimistic Address from a unicast address, but the reply MUST have the Override flag cleared (O=0). In this case, the NS is from a node doing normal address resolution. This rule should not be a problem. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Brett Pentland wrote: > Hi Erik, Christian, > >> > This sounds good for most communications (assuming that most >> >>> communications with the host go through the router). There >>> might still be a bit of a problem if an on-link device (other >>> than the router) tries to send a packet to the optimistic >>> address before the MLD report goes out since the host won't >>> receive the resulting NS from this on-link node. I guess this >>> might come up if the host is a mobile node and tries to perform >>> route optimization with a node that just happens to be connected >>> to the same link as itself. >> >> But in that case wouldn't the new host send a NS as part of >> communicating with the CoA of the peer? I guess it depends on the >> details of any MIPv6 RO procedure. > > Ah yes. For some reason a forgot that the MN would be the one > initiating the communication. Is there any way that an on-link > node could obtain the MN's CoA and try to initiate a > communication? > > Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 03:42:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwxc2-0008NZ-Ka for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 03:42:58 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24448 for ; Mon, 25 Jul 2005 03:42:56 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1U668OCO8Y5VPX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 17:42:42 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B2F5CAB54B; Mon, 25 Jul 2005 17:42:30 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 632D54FB05; Mon, 25 Jul 2005 17:42:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P7gP612879 for dna-list; Mon, 25 Jul 2005 17:42:25 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P7gOw12875 for ; Mon, 25 Jul 2005 17:42:24 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1U60011I99PQC2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 17:42:22 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 62600AB542; Mon, 25 Jul 2005 17:42:22 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 38F9F4FB08; Mon, 25 Jul 2005 17:42:22 +1000 (EST) Date: Mon, 25 Jul 2005 17:42:21 +1000 From: Brett Pentland Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E49573.8030105@tm.uka.de> Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: Erik Nordmark , DNA , TM-RO2 Message-id: <42E497DD.8090305@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> <42E43AC6.2030806@eng.monash.edu.au> <42E49573.8030105@tm.uka.de> Content-Transfer-Encoding: 7BIT Christian Vogt wrote: > Hi Brett, hi Erik. > > > Ah yes. For some reason a forgot that the MN would be the one > > initiating the communication. Is there any way that an on-link > > node could obtain the MN's CoA and try to initiate a > > communication? > > Ok, you are talking about the case were an on-link node configures the > MN's optimistic address after the MN has configured that address (as > optimistic), but before the MN has sent the initial NS for that address, > right? No. I was wondering if it's possible for an on-link node to obtain the CoA and try to start a communication with the MN. I guess this doesn't make sense. Thinking further, the MN would only be using the address in this pre-oDAD state to get a RA. It would have to send the MLD and NS packets before it started using the address any further. Maybe this does have implications for MIPv6, etc. The MN can't really send a binding update until after the NS which has to wait for the MLD report. Any thoughts? Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 03:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwxnx-0001zk-Rq for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 03:55:23 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25180 for ; Mon, 25 Jul 2005 03:55:15 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1ULN2BYK99PN71@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 17:55:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D2897AB543; Mon, 25 Jul 2005 17:54:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8A8794FB02; Mon, 25 Jul 2005 17:54:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P7sfF13055 for dna-list; Mon, 25 Jul 2005 17:54:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P7sew13051 for ; Mon, 25 Jul 2005 17:54:40 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1UKX6M208WX8G9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 17:54:24 +1000 Received: by localhost (Postfix, from userid 510) id 3FE558000F; Mon, 25 Jul 2005 17:54:24 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by larry.its.monash.edu.au (Postfix) with ESMTP id D05C23C012 for ; Mon, 25 Jul 2005 17:54:22 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so854562nzd for ; Mon, 25 Jul 2005 00:54:21 -0700 (PDT) Received: by 10.36.7.9 with SMTP id 9mr183701nzg; Mon, 25 Jul 2005 00:54:21 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 00:54:21 -0700 (PDT) Date: Mon, 25 Jul 2005 16:54:21 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E3E751.1050009@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050725005475659f66@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ulu4LxroPbr95enLBGi+CzL4UuNZnQYR61Sr6C+YqHWBLouiBmg+Dv0wsNLsrCoSEcCMupuSUxNRKEW6gsbLzt/jiH0VkVTd6tfY5p2wRG8WHjAqeWwaQC2VwGpT+pp1OpflwtLLBLR9sSoG0YauAHn9FDEPcbPzqm46kTBmJjs= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > > Linkid deals with this problem with special schemes as as Linkid prefix > > list and a few advertisement rules, such as keep advertising old linkid > > after a linkid change for the time being. But for CompleteRA (also for > > Landmark), as of my knowledge, no such mechanism is devised yet, > > though I myself had worked on it before I switched to linkid. My thought > > is that it's easier to synchronize one prefix rather than synchronize all > > the prefixes on the link. > > I'm not sure it is conceptually simpler to synchronize one item chosen > from a set, than forming the set. These are my line of thoughts. We can't avoid a temporary flapping for the related set, the set of all prefixes on a link. In linkid scheme, one item (linkid prefix) of the set matters for DNA performance. So we designed a few special schemes for the linkid prefix so that linkid prefix(es) won't give incorrect information about a link change, even under temporary flapping. But for Complete RA or Landmark, IMO, we need to adopt similar schemes such as "Linkid Prefix List" or "Old linkid advertising rule" to all prefixes because we don't know which prefix will affect DNA decision. > In the latter case each router forms the union of its own advertised > prefixes and the prefixes it receives in RAs. Thus there can be no > conflict; there is no selection of a prefix. > > In the former case, there can be transients when the sending and > receiving router have a different idea of what the selected linkID > prefix should be, thus one needs to worry about how such transients are > handled. If all routers agree on the selection algorithm, it's almost automatical to select the prefix among the set of prefixes. That's why I chose the simplest selection scheme, picking the smallest prefix. > (One can avoid that complexity by not trying to form a single > linkID all the time, but instead let each router picks its own linkID > prefix and tell the other routers. I haven't worked out the details of > such a scheme though.) I thought it simpler to make routers agree on the same selection scheme but would like to hear your scheme when developed. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 04:19:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyBr-0006Jw-1P for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 04:19:59 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26737 for ; Mon, 25 Jul 2005 04:19:54 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1VEXK3H88WX8JL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 18:19:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BBD75AB54B; Mon, 25 Jul 2005 18:18:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 668504FB09; Mon, 25 Jul 2005 18:18:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P8IPf13330 for dna-list; Mon, 25 Jul 2005 18:18:25 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P8IOw13326 for ; Mon, 25 Jul 2005 18:18:24 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1VE9TDWO8Y5P2O@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 18:18:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D9A77AB54A; Mon, 25 Jul 2005 18:18:03 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 9B4BE4FB0D; Mon, 25 Jul 2005 18:18:03 +1000 (EST) Date: Mon, 25 Jul 2005 18:18:03 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050725005475659f66@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E4A03B.6080601@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Dear Erik > > >>>Linkid deals with this problem with special schemes as as Linkid prefix >>>list and a few advertisement rules, such as keep advertising old linkid >>>after a linkid change for the time being. But for CompleteRA (also for >>>Landmark), as of my knowledge, no such mechanism is devised yet, >>>though I myself had worked on it before I switched to linkid. My thought >>>is that it's easier to synchronize one prefix rather than synchronize all >>>the prefixes on the link. >> >>I'm not sure it is conceptually simpler to synchronize one item chosen >>from a set, than forming the set. > > > These are my line of thoughts. > > We can't avoid a temporary flapping for the related set, the set of > all prefixes > on a link. > > In linkid scheme, one item (linkid prefix) of the set matters for DNA > performance. > So we designed a few special schemes for the linkid prefix so that > linkid prefix(es) > won't give incorrect information about a link change, even under > temporary flapping. > > But for Complete RA or Landmark, IMO, we need to adopt similar schemes such > as "Linkid Prefix List" or "Old linkid advertising rule" to all > prefixes because we > don't know which prefix will affect DNA decision. For Landmarks: If a prefix is removed, the host will receive a "NO" answer, which also include prefixes that are on the link and have been seen by the host before so it can see there is no link change and yet will also know that the prefix it was using as a landmark is no longer valid. (I think we need text to clear that up) If a prefix is added the host will have no knowledge of it and so it won't be involved in the decision making process at all. For CompleteRA (which is proposed as a fallback for when it is not possible to use landmarks): By its nature it creates overlap between the sets of RAs advertised by the routers on a link. It doesn't matter whether the sets agree completely or not, as long as there's overlap (because link- change is detected by receiving a RA with a set disjoint from the set of prefixes the host has seen on the link). The pathological case that we may need to take action to avoid is where a router that is currently configured with all of the prefixes in use on a link, suddenly has all of them removed and replaced with a new disjoint set. We need to add some text to say not to do that. LinkID has a much more complex technique for managing prefix change involving advertising prefixes for some length of time with short lifetimes before advertising them with zero lifetimes in order to avoid confusion. I don't think this is needed for Landmark/CompleteRA. I hope I've got that right. Can you see any faults? Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 05:09:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwyxo-0006nC-A2 for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 05:09:37 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29740 for ; Mon, 25 Jul 2005 05:09:29 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1X6M7V7A9APN8R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 19:09:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7518E8000F; Mon, 25 Jul 2005 19:09:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 179463C003; Mon, 25 Jul 2005 19:09:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6P98dq13934 for dna-list; Mon, 25 Jul 2005 19:08:39 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6P98cw13930 for ; Mon, 25 Jul 2005 19:08:38 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1X5NKRCY8Y5XWI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 19:08:23 +1000 Received: by localhost (Postfix, from userid 510) id 2536CAB542; Mon, 25 Jul 2005 19:08:23 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id D8DFA4FB04; Mon, 25 Jul 2005 19:08:21 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK600D9HEPV4E@mailout3.samsung.com>; Mon, 25 Jul 2005 18:08:19 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK6003H6EPJG3@mmp1.samsung.com>; Mon, 25 Jul 2005 18:08:19 +0900 (KST) Date: Mon, 25 Jul 2005 14:34:05 +0530 From: Syam Madanapalli Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , JinHyeock Choi Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <01c901c590f7$dd377c10$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, [cut] >> >> These are my line of thoughts. We can't avoid a temporary flapping for >> the related set, the set of >> all prefixes >> on a link. In linkid scheme, one item (linkid prefix) of the set matters >> for DNA >> performance. >> So we designed a few special schemes for the linkid prefix so that >> linkid prefix(es) >> won't give incorrect information about a link change, even under >> temporary flapping. >> >> But for Complete RA or Landmark, IMO, we need to adopt similar schemes >> such as "Linkid Prefix List" or "Old linkid advertising rule" to all >> prefixes because we >> don't know which prefix will affect DNA decision. > > For Landmarks: > > If a prefix is removed, the host will receive a "NO" answer, which > also include prefixes that are on the link and have been seen by the > host before so it can see there is no link change and yet will also > know that the prefix it was using as a landmark is no longer valid. > (I think we need text to clear that up) A host may get 'YES' answer from a Router (R2) before the 'NO' answer from Router (R1) because the deletion of the prefix (P1) at R1 might not have propagated to R2 at the time of answering the landmar query for P1. > > If a prefix is added the host will have no knowledge of it and so > it won't be involved in the decision making process at all. > > For CompleteRA (which is proposed as a fallback for when it is not > possible to use landmarks): > > By its nature it creates overlap between the sets of RAs advertised > by the routers on a link. It doesn't matter whether the sets > agree completely or not, as long as there's overlap (because link- > change is detected by receiving a RA with a set disjoint from the > set of prefixes the host has seen on the link). The pathological > case that we may need to take action to avoid is where a router > that is currently configured with all of the prefixes in use on a > link, suddenly has all of them removed and replaced with a new > disjoint set. We need to add some text to say not to do that. As we are not anyway interested in building the complete prefix list, why cannot we just depend on CPL to build. I did not remember the waiting time for building the CPL, but I am sure it will be in few seconds. When a host sends RS with Landmark question, and answer is 'NO' a host can buid the CPL (almost) from the resulting RAs which is sufficient to detect the link change at the new link even if the node moves within few seconds. > > LinkID has a much more complex technique for managing prefix change > involving advertising prefixes for some length of time with short > lifetimes before advertising them with zero lifetimes in order to > avoid confusion. I don't think this is needed for Landmark/CompleteRA. If we need to have the similar confidence in determining the link change with graceful prefix addition/deletion, we need similar techniques for all of the prefixes on the link incase of Landmark/CompleteRA. > > I hope I've got that right. Can you see any faults? > Cheers, > Brett. > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 06:25:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx09F-0002ai-Py for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 06:25:25 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04094 for ; Mon, 25 Jul 2005 06:25:22 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1ZSPJM9S8WX9BH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 20:24:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3E0BAAB542; Mon, 25 Jul 2005 20:24:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id F37644FB05; Mon, 25 Jul 2005 20:24:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6PANe614802 for dna-list; Mon, 25 Jul 2005 20:23:40 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6PANdw14798 for ; Mon, 25 Jul 2005 20:23:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1ZRV34F49APMQC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 20:23:33 +1000 Received: by localhost (Postfix, from userid 510) id 678B2AB543; Mon, 25 Jul 2005 20:23:33 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2A4404FB0C; Mon, 25 Jul 2005 20:23:26 +1000 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 524144F0004; Mon, 25 Jul 2005 12:22:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 12:22:28 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 12:22:27 +0200 Date: Mon, 25 Jul 2005 12:22:26 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] New I-D: draft-vogt-dna-relocation-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Christian Vogt Cc: Erik Nordmark , DNA , TM-RO2 Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] New I-D: draft-vogt-dna-relocation-00.txt Thread-index: AcWQ7HaB9S9rMlRlSiy5Tza3TsTwmAAFBZxg Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 25 Jul 2005 10:22:27.0989 (UTC) FILETIME=[C1F41C50:01C59102] Content-Transfer-Encoding: 7BIT Hi Brett, > No. I was wondering if it's possible for an on-link node to obtain the > CoA and try to start a communication with the MN. I guess this doesn't > make sense. No, I don't think so. CNs should use MN's home address to initiate the communication (unless it has a binding cache entry). Tero Thinking further, the MN would only be using the address in > this pre-oDAD state to get a RA. It would have to send the MLD and NS > packets before it started using the address any further. > > Maybe this does have implications for MIPv6, etc. The MN can't really > send a binding update until after the NS which has to wait for the MLD > report. > > Any thoughts? > Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 06:29:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0Dd-0003gs-Im for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 06:29:57 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04364 for ; Mon, 25 Jul 2005 06:29:54 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR1ZXSP0OE8Y5XDK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 20:28:33 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2EAE88000D; Mon, 25 Jul 2005 20:28:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DC59E3C005; Mon, 25 Jul 2005 20:28:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6PASGO14868 for dna-list; Mon, 25 Jul 2005 20:28:16 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6PASGw14864 for ; Mon, 25 Jul 2005 20:28:16 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR1ZXGPE909APMQC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 20:28:04 +1000 Received: by localhost (Postfix, from userid 510) id 59B11AB543; Mon, 25 Jul 2005 20:28:04 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 60D584FB02; Mon, 25 Jul 2005 20:28:02 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6PAS03t028790; Mon, 25 Jul 2005 03:28:00 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6PARwDa199841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 03:27:59 -0700 (PDT) Date: Mon, 25 Jul 2005 03:28:42 -0700 From: Erik Nordmark Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E43AC6.2030806@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Christian Vogt , DNA , TM-RO2 Message-id: <42E4BEDA.9020802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> <42E43AC6.2030806@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett Pentland wrote: > Ah yes. For some reason a forgot that the MN would be the one > initiating the communication. Is there any way that an on-link > node could obtain the MN's CoA and try to initiate a > communication? I decided to walk through the details for the case when a CN on a link and the MN moves to that link, and does RO with the CN. The steps would be: 1. MN uses DNA to detect that it has moved; sees a link up notification, and sends an RS (address is optimistic) 2. Receives an RA which indicates that it has moved. 3. Sends a BU to the HA. Initiates the BU process with the CN by sending a CoTI (and HoTI). The CoTI is sent from the CoA to the CN's address, thus it triggers the NS/NA exchange with the CN. 4. CN receives the HoTI and responds with a HoT. Receives the CoTI at about the same time. Tries to send a CoT. Has the neighbor cache entry for the CoA from the NS it received in #3. Looks ok. But if the CN was really a MN (MN2) (i.e., we have two MNs which have moved to the same link), then the CoTI wouldn't be sent to the HoA2, and tunneled by HA2 to CoA2. Thus in #3 there wouldn't be a NS/NA exchange - the CoTI would be sent to HA2 (which we assume is off link). But even in that case I think we are ok; the CoT will be sourced by MN2 with HoA2 as the source address, thus MN2 will reverse tunnel it via HA2. Hence MN2 doesn't need a neighbor cache entry in #4. Later (step 5) the MN sends the BU from CoA to CoA2, which makes it do a NS/NA exchange to find the link layer address for CoA2. I guess one can do similar analysis for other RO schemes, but it might be a bit tedious. One can instead argue that if the MN sends the MLD report as part of #3, even if it is sent after the other messages in #3, then the probability that something will try to do a NS/NA exchange with the MN before the MLD report is sent is very small. And should that ever happen, then the fact that the NS will be retransmitted after 1 second should take care of things. So in summary, it's ok as long as the MLD report is sent "early", even if it isn't sent first. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 06:51:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0Yb-0007Ct-UI for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 06:51:42 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05472 for ; Mon, 25 Jul 2005 06:51:34 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR20QLS4GU8WX9FB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Jul 2005 20:50:59 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EDDE3AB544; Mon, 25 Jul 2005 20:50:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 973BB4FB02; Mon, 25 Jul 2005 20:50:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6PAoab15185 for dna-list; Mon, 25 Jul 2005 20:50:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6PAoZw15181 for ; Mon, 25 Jul 2005 20:50:35 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR20Q769A48Y5RGW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 25 Jul 2005 20:50:27 +1000 Received: by localhost (Postfix, from userid 510) id 725DBAB542; Mon, 25 Jul 2005 20:50:27 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6CFAA4FB0A; Mon, 25 Jul 2005 20:50:25 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6PAoLr3020074; Mon, 25 Jul 2005 04:50:21 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6PAoJEp208582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 03:50:20 -0700 (PDT) Date: Mon, 25 Jul 2005 03:51:00 -0700 From: Erik Nordmark Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb0507242209d09cf66@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E4C414.70601@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DCA6F0.1030302@eng.monash.edu.au> <42DCAC43.2030602@eng.monash.edu.au> <10e14db20507191105264e01f7@mail.gmail.com> <42DD9009.8060108@eng.monash.edu.au> <92e919fb050721215591928a4@mail.gmail.com> <42E0A581.5030407@eng.monash.edu.au> <92e919fb05072220192dd72a1f@mail.gmail.com> <42E4471D.2010309@eng.monash.edu.au> <92e919fb0507242209d09cf66@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > No, Linkid has a rule to prevent "Renumbering and Early reassignment." I agree that Linkid (as well as CPL I think) has a recommendation to the administrator to not reassign a prefix to another link in less than 3 hours. I'm not sure the same text is in the landmark draft yet, but it would be trivial to add. But my concern is what happens should the administrator not follow this recommendation. The worst case would be when P1 and P2 are assigned to link1, and P2 is immediately reassigned to link3 (which had prefix P3 before), at about the same time that the a host moves from link1 to link3. In that case, any prefix based scheme for link identification (CPL, landmark, linkid, or anything else we can invent) can get into trouble, by the host assuming that P1, P2, and P3 are assigned to link3. Should this happen, then the host will assume that P1 is usable until the last valid/preferred lifetimes it saw has expired. Since RFC 2461 suggests a default preferred lifetime of 7 days, the host will try to use P1 as a source address for 7 days, even though no packets returned to P1 will make it back to the link to which the host is attached. We could decide this is the administrators fault, and not do anything. Or we could add a mechanism to attempt to detect this and recover in less than 7 days. But the problem certainly isn't specific to any particular proposal, since they all rely on prefixes for link identification. And I suspect that we have the same choices in terms of solutions independent of which proposal we apply this to. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 14:55:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx86t-0007hQ-HM for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 14:55:31 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14199 for ; Mon, 25 Jul 2005 14:55:28 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2HMURCEC8WXD8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 04:55:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 444F58000E; Tue, 26 Jul 2005 04:54:54 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E515E3C00E; Tue, 26 Jul 2005 04:54:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6PIq5Q21047 for dna-list; Tue, 26 Jul 2005 04:52:05 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6PIq4w21043 for ; Tue, 26 Jul 2005 04:52:04 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2HIZE1108Y5ZJR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 04:51:49 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 86966AB542; Tue, 26 Jul 2005 04:51:47 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6F3C14FB0D; Tue, 26 Jul 2005 04:51:47 +1000 (EST) Received: from [208.54.95.151] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 26 Jul 2005 04:51:47 +1000 Date: Tue, 26 Jul 2005 04:51:47 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <5f3a2d5f2f2f.5f2f2f5f3a2d@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Erik, ----- Original Message ----- From: Erik Nordmark Date: Monday, July 25, 2005 8:51 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > JinHyeock Choi wrote: > > > No, Linkid has a rule to prevent "Renumbering and Early > reassignment." > > I agree that Linkid (as well as CPL I think) has a recommendation > to the administrator to not reassign a prefix to another link in less > than 3 hours. > I'm not sure the same text is in the landmark draft yet, but it > would be trivial to add. > > But my concern is what happens should the administrator not follow > this recommendation. > > The worst case would be when P1 and P2 are assigned to link1, and > P2 is immediately reassigned to link3 (which had prefix P3 before), at > about the same time that the a host moves from link1 to link3. > > In that case, any prefix based scheme for link identification > (CPL, landmark, linkid, or anything else we can invent) can get into > trouble, by the host assuming that P1, P2, and P3 are assigned to link3. > > Should this happen, then the host will assume that P1 is usable > until the last valid/preferred lifetimes it saw has expired. Since RFC > 2461 suggests a default preferred lifetime of 7 days, the host will try > to use P1 as a source address for 7 days, even though no packets > returned to P1 will make it back to the link to which the host is > attached. In CPL which is host (only) based, the timers are on the host, and protect the host from long term damage, by removing unupdated information at the host. Even with the most broken readvartisement scheme for stale information, the damage could only occur for a maximum: (Router out-of-date timer + Host out-of-date timer) If the readvertisement schemes for routers override bad state for the hosts, The lifetime for bad information is less than: (Router out-of-date timer) + (MaxRtrAdvInterval * ROBUSTNESS) By this time, the host should be updated, with fresh state. This time is actually related to the readvertising router's actual configuration timers (rather than defaults, etc), so it may be significantly lower than the previous cost. So if Router out-of-date timer = 1800s (MAXRA) and Host out-of-date timer=3600s (2x MAXRA). This assumes fairly reliable transmission between routers (potentially 2 x MAXRA for routers though)). Overall the possibility for out of date information is reduced to 2 hours after change (in that situation, and potentially, 1 hour and a very few seconds if the override mechanism is possible). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 15:12:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8NC-000211-Al for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 15:12:22 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15733 for ; Mon, 25 Jul 2005 15:12:19 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2I8T4JTO8WXDA1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 05:12:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C87DA8000D; Tue, 26 Jul 2005 05:11:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7E25F3C00E; Tue, 26 Jul 2005 05:11:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6PJBea21260 for dna-list; Tue, 26 Jul 2005 05:11:40 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6PJBdw21256 for ; Tue, 26 Jul 2005 05:11:39 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2I8GZ9SS8Y616N@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 05:11:34 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9391CAB542; Tue, 26 Jul 2005 05:11:33 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 71E0D4FB05; Tue, 26 Jul 2005 05:11:33 +1000 (EST) Received: from [208.54.95.151] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 26 Jul 2005 05:11:33 +1000 Date: Tue, 26 Jul 2005 05:11:33 +1000 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, Syam Madanapalli , Brett Pentland , James Kempf , Dna Message-id: <5f58525f580f.5f580f5f5852@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, ----- Original Message ----- From: JinHyeock Choi Date: Monday, July 25, 2005 3:11 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Dear Greg > > > > As of my memory, in DT meeting, no such agreement (about why > > > FRD is left) is made. > > > > It was left _in_, not _out_. > > > > So it is still under consideration, but it is important to > > note (as I said above) that the scheme relies on > > modified link-layer devices on the network side, so it > > is important (IMO) to have a Base DNA protocol scheme which > > doesn't explicitly rely on the presence of FastRD to get > > useful performance. > > > > If the WG desires that FastRD is included in another document, > > then that's OK. > > > > > An unfortunate incident in D.C. made a paranoid out of me, so > > > I took keen notice about FRD treatment. > > > > You've received my (public) apology on that count (and my > > statement that I was of good, if misguided intention), and my > > undertaking that I'll not interfere in any presentation or > > decision making by the WG. > > > > > About the FRD applicability, that's the decision for WG. If WG > > > chooses FRD for its high performance in spite of L2 reliance, > > > it's WG's call. > > > > Yes. > > > > > It's ok for you have an opinion about FRD and its treatment but > > > I ask you NOT to assume it as an official agreement before going > > > through a proper decision procedure. > > > > I never did. Your own quotation of the e-mails describes this. > > Unfortunately I got the impression you did. When I mentioned that > WG didn't make a decision that FRD is not under consideration for > the main DNA solution, you wrote that WG decided at Minneapolis. > If that impression was not intended, we agreed that WG didn't make > a decision on FRD yet, right? In case, I wish > we close this not-so-pleasant issue here. OK. [cut] > > So, getting back to my main point: > > > > The schemes (CompleteRA and LinkID) are the same for > > unsolicited RA (disregarding co-existance and > > synchronization issues). So we really don't need > > to identify one scheme as being better for > > unsolicited RAs. > > The above analysis is dependent on # prefixes on a link. When I > worked on CompleteRA, some DT members showed concern for the > link with high # prefixes. Certainly, but the fallback case is also described with CPL. Each router is able to make an assessment if it can support the complete number of Prefixes. Any single router which can take the load can send the RA as complete. This will work so long as the prefixes are advertised by at least one router on the link. Advertisement of a subset of the prefixes is even possible (without coordination) if the cost of completeRA is too high At the moment DNAO costs floor( ((#prefix * 17)+ 2+7)/ 8) octets. for all additional prefixes advertised. That's pretty efficient compared to PIO. Even more efficient schemes have been described - floor (((#prefix *9)+3+7)/8) octets) - variant 2. Given the size of the packets available in IPv6, the larger option ( even with 6 native PIO prefixes) that can fit 22 learned prefixes in the DNAO, even with the nastiest SEND scenario I could describe. That's a big # of prefixes. As described before, this is not going to happen on any well designed network. We can even add 2 lines to help describe network configurations which are bad for this. > Also I think we'd better have this kind of discussion to > investigate whether unsoilcted RA differentiates or not > first, before jumping to the conclusion that unsolicited > RA is irrelevant. OK, but except in never deployed pathological cases, CompleteRA is able to provide the same function as LinkID (with additional completeness for CPL). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 21:28:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEEi-0005nM-Nd for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 21:28:05 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12522 for ; Mon, 25 Jul 2005 21:27:58 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2VBTC4988WXFEL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 11:27:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E626AB542; Tue, 26 Jul 2005 11:26:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3D8914FB02; Tue, 26 Jul 2005 11:26:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q1QGm25620 for dna-list; Tue, 26 Jul 2005 11:26:16 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q1QEw25616 for ; Tue, 26 Jul 2005 11:26:14 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2VAZIRCA99PSI2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 11:26:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A85FAB543; Tue, 26 Jul 2005 11:26:12 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 41BBE4FB02; Tue, 26 Jul 2005 11:26:12 +1000 (EST) Date: Tue, 26 Jul 2005 11:26:11 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <01c901c590f7$dd377c10$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: JinHyeock Choi , Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E59133.6090603@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: > Hi Brett, > > [cut] > >>> >>> These are my line of thoughts. We can't avoid a temporary flapping >>> for the related set, the set of >>> all prefixes >>> on a link. In linkid scheme, one item (linkid prefix) of the set >>> matters for DNA >>> performance. >>> So we designed a few special schemes for the linkid prefix so that >>> linkid prefix(es) >>> won't give incorrect information about a link change, even under >>> temporary flapping. >>> >>> But for Complete RA or Landmark, IMO, we need to adopt similar >>> schemes such as "Linkid Prefix List" or "Old linkid advertising rule" >>> to all >>> prefixes because we >>> don't know which prefix will affect DNA decision. >> >> >> For Landmarks: >> >> If a prefix is removed, the host will receive a "NO" answer, which >> also include prefixes that are on the link and have been seen by the >> host before so it can see there is no link change and yet will also >> know that the prefix it was using as a landmark is no longer valid. >> (I think we need text to clear that up) > > > A host may get 'YES' answer from a Router (R2) before the 'NO' answer > from Router (R1) because the deletion of the prefix (P1) at R1 might not > have > propagated to R2 at the time of answering the landmar query for P1. Yes, and as far as DNA goes that is the correct answer in that there is no link change. When the subsequent NO answer arrives, the accompanying prefixes will also show that there has been no link change and the NO on that particular prefix gives the _additional information_ that it is no longer valid (though the extra information is not necessary because the second RA will have that expressed with a P1 PIO with zero lifetime). LinkID gives the same result. >> For CompleteRA (which is proposed as a fallback for when it is not >> possible to use landmarks): >> >> By its nature it creates overlap between the sets of RAs advertised >> by the routers on a link. It doesn't matter whether the sets >> agree completely or not, as long as there's overlap (because link- >> change is detected by receiving a RA with a set disjoint from the >> set of prefixes the host has seen on the link). The pathological >> case that we may need to take action to avoid is where a router >> that is currently configured with all of the prefixes in use on a >> link, suddenly has all of them removed and replaced with a new >> disjoint set. We need to add some text to say not to do that. > > > As we are not anyway interested in building the complete prefix list, > why cannot we just depend on CPL to build. I did not remember > the waiting time for building the CPL, but I am sure it will be in few > seconds. When a host sends RS with Landmark question, and answer > is 'NO' a host can buid the CPL (almost) from the resulting RAs which > is sufficient to detect the link change at the new link even if the node > moves within few seconds. Just relying on CPL instead of CompleteRA is a possibility. Depends if folks are willing to have a window of 12 seconds (?) after each link change where another link change will not be able to be detect rapidly. When we wrote the proposal, we felt that we needed something more. >> >> LinkID has a much more complex technique for managing prefix change >> involving advertising prefixes for some length of time with short >> lifetimes before advertising them with zero lifetimes in order to >> avoid confusion. I don't think this is needed for Landmark/CompleteRA. > > > If we need to have the similar confidence in determining the link change > with > graceful prefix addition/deletion, we need similar techniques for all of > the > prefixes on the link incase of Landmark/CompleteRA. I think I've shown that those additional techniques are not needed for Landmark/CompleteRA. It may be that they are not needed for LinkID either. I think the LinkID proposal would need to be modified to allow hosts to use the other prefixes in the RA for link identification, not just those marked as LinkIDs. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 21:28:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEEn-0005nY-SB for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 21:28:06 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12525 for ; Mon, 25 Jul 2005 21:28:03 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2VCX042Q99O8ZN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 11:27:49 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D90BFAB543; Tue, 26 Jul 2005 11:27:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8E5CA4FB0B; Tue, 26 Jul 2005 11:27:44 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q1RgW25654 for dna-list; Tue, 26 Jul 2005 11:27:42 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q1Rfw25650 for ; Tue, 26 Jul 2005 11:27:41 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2VCGPTEK9APO62@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 11:27:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E226AB542; Tue, 26 Jul 2005 11:27:24 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id D326A4FB02; Tue, 26 Jul 2005 11:27:23 +1000 (EST) Date: Tue, 26 Jul 2005 11:27:23 +1000 From: Brett Pentland Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt In-reply-to: <42E4BEDA.9020802@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Christian Vogt , DNA , TM-RO2 Message-id: <42E5917B.8050702@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <42BF8B18.8080203@tm.uka.de> <42DF5EC8.7080207@eng.monash.edu.au> <42E3E669.2010902@sun.com> <42E43AC6.2030806@eng.monash.edu.au> <42E4BEDA.9020802@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > > So in summary, it's ok as long as the MLD report is sent "early", even > if it isn't sent first. OK. Sounds fine. Thanks for working through it. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 21:55:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEfQ-0001ok-60 for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 21:55:36 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13763 for ; Mon, 25 Jul 2005 21:55:33 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2W8BF8R68WX60Z@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 11:53:27 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB9F9AB543; Tue, 26 Jul 2005 11:52:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A2FA64FB07; Tue, 26 Jul 2005 11:52:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q1q8S25994 for dna-list; Tue, 26 Jul 2005 11:52:08 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q1q7w25990 for ; Tue, 26 Jul 2005 11:52:07 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2W7R31M09APKU0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 11:51:50 +1000 Received: by localhost (Postfix, from userid 510) id B00EBAB545; Tue, 26 Jul 2005 11:51:50 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id C44424FB0A; Tue, 26 Jul 2005 11:51:48 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6Q1pi3t025349; Mon, 25 Jul 2005 18:51:44 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q1pgMI461595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 18:51:43 -0700 (PDT) Date: Mon, 25 Jul 2005 04:56:24 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <01c901c590f7$dd377c10$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Brett Pentland , JinHyeock Choi , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E4D368.2010803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Syam Madanapalli wrote: > If we need to have the similar confidence in determining the link change > with > graceful prefix addition/deletion, we need similar techniques for all of > the > prefixes on the link incase of Landmark/CompleteRA. Syam, You keep making this statement, but I think it is factually incorrect. See my other email responding to JinHyoeck. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:10:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEtw-0004Ig-A9 for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:10:36 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14287 for ; Mon, 25 Jul 2005 22:10:33 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2WUEYZZI8Y5VE8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:10:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D60D9AB545; Tue, 26 Jul 2005 12:10:06 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 858594FB02; Tue, 26 Jul 2005 12:10:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q29uI26286 for dna-list; Tue, 26 Jul 2005 12:09:56 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q29uw26282 for ; Tue, 26 Jul 2005 12:09:56 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2WU1KKXK8WX63Z@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:09:49 +1000 Received: by localhost (Postfix, from userid 510) id 07D43AB543; Tue, 26 Jul 2005 12:09:48 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id F3E104FB03; Tue, 26 Jul 2005 12:09:47 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.56.144]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6Q29hr3027792; Mon, 25 Jul 2005 20:09:44 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q29fkS464520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 19:09:42 -0700 (PDT) Date: Mon, 25 Jul 2005 19:10:25 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050725005475659f66@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E59B91.2050007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > We can't avoid a temporary flapping for the related set, the set of > all prefixes > on a link. Just to make it sure we are all talking about the same thing, by "flapping" I assume we mean the following: When the set of prefixes on a link changes, e.g., a prefix is being added or a prefix is being removed, there is the possibility that a host see more than one change (see things flapping back and forth) until the routers have been synchronized. For instance, if the prefix set is {P1, P2} and P3 is added, one would ideally have the host see {P1, P2} and then see {P1, P2, P3}, but when RAs come from different routers, there might be a small window when the host sees RAs vary in a sequence like {P1, P2}, {P1, P2, P3}, {P1, P2}, {P1, P2, P3}. This is due to the third RA (with {P1, P2}) coming from a router which hadn't seen P3 yet. If there is no packet loss, the window during which this can happen is very small (basically the propagation delay of the RA which carries the new prefix from one router to another). With packet loss, the worst case window is the time it takes to successfully retransmit the RA so that the other routers see it. > In linkid scheme, one item (linkid prefix) of the set matters for DNA > performance. > So we designed a few special schemes for the linkid prefix so that > linkid prefix(es) > won't give incorrect information about a link change, even under > temporary flapping. Yes, but linkid still has flapping issues; you just have a technique to avoid this resulting in an incorrect result. (In the case of linkid the flapping effects the linkID which each routers picks. Thus if P3 was the numerically smallest prefix then the flapping in the prefix set would result in flapping in the linkID prefix the host sees.) Handling this requires some additional logic in linkID. > But for Complete RA or Landmark, IMO, we need to adopt similar schemes such > as "Linkid Prefix List" or "Old linkid advertising rule" to all > prefixes because we > don't know which prefix will affect DNA decision. I don't think so. CompleteRA is basically the same as CPL in this respect, in that the prefix sets are compared to see whether they are disjoint. In the above example, there is overlap between {P1, P2} and {P1, P2, P3} hence the host would correctly conclude that it didn't move. Landmark is basically an optimization of completeRA, with a fallback to completeRA/CPL prefix comparisons when there was no landmark response, or no DNA capable router, respectively. Thus the completeRA/CPL observation holds. This even takes care of the case when a host picks up {P1, P2, P3}, selects P3 as its landmark, gets a new link up notification, sends a RS, and get a response with "landmark P3 = NO, PIO={P1, P2}, from a router which hasn't yet seen P3, since the host would compare the prefix sets in that case as well. (I'm not sure that is in the I-D, but I think it needs to be in the I-D to handle the analogous case of moving to a link with no DNA routers.) > If all routers agree on the selection algorithm, it's almost automatical > to select the prefix among the set of prefixes. That's why I chose the > simplest selection scheme, picking the smallest prefix. Sure. But my point is that a router needs to be prepared to receive a RA where some other router, due to not having seen an RA, or being broken, is claiming that some other prefix is the linkID. That's some added complexity. > I thought it simpler to make routers agree on the same selection > scheme but would like to hear your scheme when developed. I think it would be isomorphic to linkid; just a different way of thinking about the problem. (BTW: "simple" and "distributed agreement" don't belong together in the same sentence. :-) Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:25:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxF8e-00078N-DB for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:25:48 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15042 for ; Mon, 25 Jul 2005 22:25:45 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2XCLCLZO8Y645H@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:25:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0039980014; Tue, 26 Jul 2005 12:24:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 614093C00E; Tue, 26 Jul 2005 12:24:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q2ObC26477 for dna-list; Tue, 26 Jul 2005 12:24:37 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q2Obw26473 for ; Tue, 26 Jul 2005 12:24:37 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2XC1WSDQ8Y645G@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:24:21 +1000 Received: by localhost (Postfix, from userid 510) id 14D87AB543; Tue, 26 Jul 2005 12:24:20 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0D3BC4FB07; Tue, 26 Jul 2005 12:24:18 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6Q2OEvU008382; Mon, 25 Jul 2005 20:24:14 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q2OCFG467269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 19:24:13 -0700 (PDT) Date: Mon, 25 Jul 2005 19:24:55 -0700 From: Erik Nordmark Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <5f3a2d5f2f2f.5f2f2f5f3a2d@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: JinHyeock Choi , Brett Pentland , Syam Madanapalli , James Kempf , Dna Message-id: <42E59EF7.1010801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <5f3a2d5f2f2f.5f2f2f5f3a2d@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > In CPL which is host (only) based, the timers are on the host, and > protect > the host from long term damage, by removing unupdated information > at the host. > > Even with the most broken readvartisement scheme for stale information, > the damage could only occur for a maximum: > (Router out-of-date timer + Host out-of-date timer) Are you talking about RFC 2461, or are you talking about a proposal for how CPL could work? Erik > If the readvertisement schemes for routers override bad state > for the hosts, The lifetime for bad information is less than: > > (Router out-of-date timer) + (MaxRtrAdvInterval * ROBUSTNESS) > > By this time, the host should be updated, with fresh state. > This time is actually related to the readvertising router's actual > configuration timers (rather than defaults, etc), so it may be > significantly lower than the previous cost. > > So if Router out-of-date timer = 1800s (MAXRA) and Host out-of-date > timer=3600s > (2x MAXRA). This assumes fairly reliable transmission between routers > (potentially 2 x MAXRA for routers though)). > > Overall the possibility for out of date information is reduced to 2 > hours > after change (in that situation, and potentially, 1 hour and a very > few seconds > if the override mechanism is possible). > > Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:45:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFRh-0001mN-Uk for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:45:34 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15895 for ; Mon, 25 Jul 2005 22:45:27 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2Y2QWGG499PM1F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:45:10 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67A028000F; Tue, 26 Jul 2005 12:45:04 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 02C843C010; Tue, 26 Jul 2005 12:45:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q2idu26758 for dna-list; Tue, 26 Jul 2005 12:44:39 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q2ibw26754 for ; Tue, 26 Jul 2005 12:44:37 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2Y22KD2W8WXGIY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:44:32 +1000 Received: by localhost (Postfix, from userid 510) id CB34CAB54A; Tue, 26 Jul 2005 12:44:31 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by moe.its.monash.edu.au (Postfix) with ESMTP id ED6ED4FB09 for ; Tue, 26 Jul 2005 12:44:29 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1125698nzd for ; Mon, 25 Jul 2005 19:44:28 -0700 (PDT) Received: by 10.36.25.15 with SMTP id 15mr122142nzy; Mon, 25 Jul 2005 19:44:28 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 19:44:28 -0700 (PDT) Date: Tue, 26 Jul 2005 11:44:28 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E4D368.2010803@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072519444d670456@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uP8WNlKKqL+Xcdi8A/geHfmSnAzu4RMNEiwWq6d9uOS20ladeKYpRKktpDATOaIkeNMkT1Km1bvfMPbx094FjjdeD9kOX2EobGdNtApZXLvZYYnAAeT6MdQ6CW3thZ2D8I4780ISijJOyfJNvGefcfRfCn9dp5sXdSbtekvKGXk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > > If we need to have the similar confidence in determining the link change > > with > > graceful prefix addition/deletion, we need similar techniques for all of > > the > > prefixes on the link incase of Landmark/CompleteRA. > > Syam, > You keep making this statement, but I think it is factually incorrect. > See my other email responding to JinHyoeck. In linkid scheme, a prefix addition or deletion would not cause an incorrect decision, whereas there is such a possibility for Landmark/ CompleteRA. Allow me an example. Assume a link with a router R and host H. R advertises Prefix1. R1 happens to stop advertising Prefix1 and start advertising a new prefix Prefix2. R announces it by sending an RA but H doesn't receive it. Then next time H receives CompleteRA with Prefix2, it will falsely assume a link change. Linkid scheme deal with such a temporary flapping by adopting extra techniques such as "Linkid Prefix List" or "LEAST_VALID_LIFETIME". I don't know how Landmark/ CompleteRA can make a correct decision under flapping without such an extra techniques. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:51:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFXL-00035E-0q for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:51:19 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16269 for ; Mon, 25 Jul 2005 22:51:16 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2Y9T7W9499PMTX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:50:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1E503AB54D; Tue, 26 Jul 2005 12:50:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C87774FB03; Tue, 26 Jul 2005 12:50:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q2og026876 for dna-list; Tue, 26 Jul 2005 12:50:42 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q2ofw26872 for ; Tue, 26 Jul 2005 12:50:41 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2Y9NR5JC99PMTX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:50:39 +1000 Received: by localhost (Postfix, from userid 510) id EC135AB54A; Tue, 26 Jul 2005 12:50:38 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id F2C544FB07; Tue, 26 Jul 2005 12:50:37 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6Q2oV3t006770; Mon, 25 Jul 2005 19:50:31 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q2oSoi470275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 19:50:29 -0700 (PDT) Date: Mon, 25 Jul 2005 19:51:12 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072519444d670456@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E5A520.8070502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > In linkid scheme, a prefix addition or deletion would not > cause an incorrect decision, whereas there is such a > possibility for Landmark/ CompleteRA. > > Allow me an example. > > Assume a link with a router R and host H. > R advertises Prefix1. > > R1 happens to stop advertising Prefix1 and > start advertising a new prefix Prefix2. But in this case, when all the prefixes are being removed and replaced with a completely new set of prefixes, there is little if no harm to incorrectly assume a link change (after all, all the addresses need to be reconfigured, etc). A more realistic example is the one I included in my more recent email today. > R announces it by sending an RA but H > doesn't receive it. > > Then next time H receives CompleteRA with > Prefix2, it will falsely assume a link change. Actually not; if will only assume a link change if it receives a link up event notification between the last time it heard a RA with Prefix1 and the first time it heard an RA with Prefix2. Erik > Linkid scheme deal with such a temporary flapping by adopting > extra techniques such as "Linkid Prefix List" or "LEAST_VALID_LIFETIME". > > I don't know how Landmark/ CompleteRA can make a correct decision > under flapping without such an extra techniques. > > Thanks in advance for your kind consideration. > > Best Regards > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:51:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFXz-0003BP-Gi for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:51:59 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16328 for ; Mon, 25 Jul 2005 22:51:56 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2YA5WHSM99NYKY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:51:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 284D9AB550; Tue, 26 Jul 2005 12:51:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id BA5344FB09; Tue, 26 Jul 2005 12:51:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q2p0g26898 for dna-list; Tue, 26 Jul 2005 12:51:00 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q2p0w26894 for ; Tue, 26 Jul 2005 12:51:00 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2Y9Q3OAI9APO2T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:50:42 +1000 Received: by localhost (Postfix, from userid 510) id 1BDC3AB546; Tue, 26 Jul 2005 12:50:42 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6AD864FB0A; Tue, 26 Jul 2005 12:50:40 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6Q2oQ7j031482; Mon, 25 Jul 2005 22:50:26 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 457781E8217; Mon, 25 Jul 2005 22:41:05 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 3B2C41E81B6; Mon, 25 Jul 2005 22:41:05 -0400 (EDT) Received: from [68.36.161.46] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Mon, 25 Jul 2005 22:50:26 -0400 Date: Mon, 25 Jul 2005 22:50:26 -0400 From: Sathya Narayanan Subject: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[Issue X] LinkID v.s. LandmarkPrefix) Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:59.00244 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Erik - I reordered the text in your email (and changed the subject line) with my comments inline. > But the problem certainly isn't specific to any particular proposal, > since they all rely on prefixes for link identification. And I suspect > that we have the same choices in terms of solutions independent of which > proposal we apply this to. FWIW, I completely agree with you on this. IMHO, the synchronization complexity/issue is same/similar for all of these schemes. > We could decide this is the administrators fault, and not do anything. > Or we could add a mechanism to attempt to detect this and recover > in less than 7 days. Having said that, I am going to try to solve this problem using the Landmark scheme. Be warned that this is me just thinking out loud and you should remember how lost I get when I do that ;-) > The worst case would be when P1 and P2 are assigned to link1, and P2 is > immediately reassigned to link3 (which had prefix P3 before), at about > the same time that the a host moves from link1 to link3. > > In that case, any prefix based scheme for link identification (CPL, landmark, linkid, or anything else we can invent) can get into trouble, > by the host assuming that P1, P2, and P3 are assigned to link3. It can be argued that the semantics of landmark exchange is not to imply all those prefixes are on the link - if the host did a landmark question using 'P3', then a 'yes' answer just means P3 is on the link (link3 in this case). Does that make sense? The negative side is that when a host is on a link with P4, P5, P6, sends a landmark question with P6 and gets a 'yes' answer, the host cannot say anything about the availability of P4 or P5. The host will have to do separate landmark questions for each of them or hope for a complete RA to be received. The choice of the landmark on the host side becomes crucial in doing DNA. Now, since G1 in the goals document is "G1: DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration.", if the chosen landmark-prefix corresponds to a non-local IPv6 address of the host, its validity of atleast one address can be ascertained. Such a change in the semantics, I think, restricts the host from making assumptions about prefixes on link unless explicitly seen in RA messages continuously and hence can address the flash renumbering and early assignment problem. What do you think? -Sathya > > Should this happen, then the host will assume that P1 is usable until > the last valid/preferred lifetimes it saw has expired. Since RFC > 2461 > suggests a default preferred lifetime of 7 days, the host will try > to > use P1 as a source address for 7 days, even though no packets > returned > to P1 will make it back to the link to which the host is attached. > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 22:58:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFeW-0004E8-R1 for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 22:58:44 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16792 for ; Mon, 25 Jul 2005 22:58:41 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2YHTR5KA9APIY8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 12:57:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A160CAB54D; Tue, 26 Jul 2005 12:57:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4B1024FB09; Tue, 26 Jul 2005 12:57:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q2v5J27014 for dna-list; Tue, 26 Jul 2005 12:57:05 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q2v4w27010 for ; Tue, 26 Jul 2005 12:57:04 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2YHGVBDO8Y64A5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 12:56:56 +1000 Received: by localhost (Postfix, from userid 510) id ADB25AB543; Tue, 26 Jul 2005 12:56:56 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id A4F6D4FB0D; Tue, 26 Jul 2005 12:56:54 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6Q2upM5031796; Mon, 25 Jul 2005 22:56:51 -0400 Received: from localhost (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with SMTP id DCD301E8CF7; Mon, 25 Jul 2005 22:47:29 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id A89EB1E8DB9; Mon, 25 Jul 2005 22:47:26 -0400 (EDT) Received: from [68.36.161.46] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Mon, 25 Jul 2005 22:56:48 -0400 Date: Mon, 25 Jul 2005 22:56:48 -0400 From: Sathya Narayanan Subject: Re: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 -was[Issue X]LinkID v.s. LandmarkPrefix) Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <20c541f68f.1f68f20c54@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Please read "landmark question using 'P3', then a 'yes' answer just means P3 is on the link" as "landmark question using 'P2', then a 'yes' answer just means P2 is on the link" since P2 is the prefix moved from Link1 to Link3. - Sathya ----- Original Message ----- From: Sathya Narayanan Date: Monday, July 25, 2005 10:50 pm Subject: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[Issue X]LinkID v.s. LandmarkPrefix) > Erik - > > I reordered the text in your email (and changed the subject line) > with my comments inline. > > > But the problem certainly isn't specific to any particular > proposal, > > since they all rely on prefixes for link identification. And I > suspect > > that we have the same choices in terms of solutions independent > of which > > proposal we apply this to. > FWIW, I completely agree with you on this. IMHO, the > synchronization complexity/issue is same/similar for all of these > schemes. > > We could decide this is the administrators fault, and not do > anything. > > Or we could add a mechanism to attempt to detect this and > recover > > in less than 7 days. > > Having said that, I am going to try to solve this problem using > the Landmark scheme. Be warned that this is me just thinking out > loud and you should remember how lost I get when I do that ;-) > > > The worst case would be when P1 and P2 are assigned to link1, > and P2 is > > immediately reassigned to link3 (which had prefix P3 before), at > about > > the same time that the a host moves from link1 to link3. > > > > In that case, any prefix based scheme for link identification > (CPL, landmark, linkid, or anything else we can invent) can get > into trouble, > > by the host assuming that P1, P2, and P3 are assigned to link3. > It can be argued that the semantics of landmark exchange is not to > imply all those prefixes are on the link - if the host did a > landmark question using 'P3', then a 'yes' answer just means P3 is > on the link (link3 in this case). Does that make sense? > > The negative side is that when a host is on a link with P4, P5, > P6, sends a landmark question with P6 and gets a 'yes' answer, the > host cannot say anything about the availability of P4 or P5. The > host will have to do separate landmark questions for each of them > or hope for a complete RA to be received. The choice of the > landmark on the host side becomes crucial in doing DNA. Now, since > G1 in the goals document is > "G1: DNA schemes should detect the identity of the currently > attached link to ascertain the validity of the existing IP > configuration.", if the chosen landmark-prefix corresponds to a > non-local IPv6 address of the host, its validity of atleast one > address can be ascertained. > > Such a change in the semantics, I think, restricts the host from > making assumptions about prefixes on link unless explicitly seen > in RA messages continuously and hence can address the flash > renumbering and early assignment problem. > > What do you think? > > -Sathya > > > > > Should this happen, then the host will assume that P1 is usable > until > > the last valid/preferred lifetimes it saw has expired. Since RFC > > 2461 > > suggests a default preferred lifetime of 7 days, the host will > try > > to > > use P1 as a source address for 7 days, even though no packets > > returned > > to P1 will make it back to the link to which the host is attached. > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 23:06:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFlq-0005o8-OU for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 23:06:19 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17207 for ; Mon, 25 Jul 2005 23:06:15 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2YR83STM8Y64BF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 13:05:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F1BE8000F; Tue, 26 Jul 2005 13:04:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 04E623C00B; Tue, 26 Jul 2005 13:04:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q34gi27155 for dna-list; Tue, 26 Jul 2005 13:04:42 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q34fw27151 for ; Tue, 26 Jul 2005 13:04:41 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2YQS623E8Y64BF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 13:04:27 +1000 Received: by localhost (Postfix, from userid 510) id 3F79EAB542; Tue, 26 Jul 2005 13:04:27 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id 008BB4FB02 for ; Tue, 26 Jul 2005 13:04:25 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1130057nzd for ; Mon, 25 Jul 2005 20:04:24 -0700 (PDT) Received: by 10.36.80.15 with SMTP id d15mr2764213nzb; Mon, 25 Jul 2005 20:04:24 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 20:04:24 -0700 (PDT) Date: Tue, 26 Jul 2005 12:04:24 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E5A520.8070502@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072520046d018db1@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aFsGUU80VfoRvjVcN4wgtAA2PkijZmmQ1fEVySITvU2pH7IkvePyuZbHpxyuC332WRYKvN4zbeX+YAeIjQ4HQLQuEa7dC3U5wWLb/tIS4yDKbJ7JJqUdsNrvWBbYEGuzOQWOUFK8sK8xtAdhPWKbcswYMRrDaleDmJecF0zAFHA= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> Content-Transfer-Encoding: 7BIT Erik > > Allow me an example. > > > > Assume a link with a router R and host H. > > R advertises Prefix1. > > > > R1 happens to stop advertising Prefix1 and > > start advertising a new prefix Prefix2. > > But in this case, when all the prefixes are being removed and replaced > with a completely new set of prefixes, there is little if no harm to > incorrectly assume a link change (after all, all the addresses need to > be reconfigured, etc). By adding another router and a few more packet losses, we can make a pathological case with a problem. > A more realistic example is the one I included in my more recent email > today. We can discuss about how real such a problem is but my point is that linkid adopts extra techniques to survive even such an extreme pathologies. > > R announces it by sending an RA but H > > doesn't receive it. > > > > Then next time H receives CompleteRA with > > Prefix2, it will falsely assume a link change. > > Actually not; if will only assume a link change if it receives a link up > event notification between the last time it heard a RA with Prefix1 and > the first time it heard an RA with Prefix2. Is it so? Does that mean the hosts would not make a decision based on unsolicited CompleteRAs? Is it written in an I-D? Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 23:18:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFxU-0007ke-6s for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 23:18:20 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17670 for ; Mon, 25 Jul 2005 23:18:17 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR2Z7NM78299PO3W@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 13:18:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 355438000F; Tue, 26 Jul 2005 13:18:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B892D3C003; Tue, 26 Jul 2005 13:18:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q3HmF27327 for dna-list; Tue, 26 Jul 2005 13:17:48 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q3Hlw27323 for ; Tue, 26 Jul 2005 13:17:47 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2Z7AXLYQ8Y60F1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 13:17:46 +1000 Received: by localhost (Postfix, from userid 510) id 56BA5AB544; Tue, 26 Jul 2005 13:17:46 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3E8404FB03; Tue, 26 Jul 2005 13:17:44 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6Q3HfvU027257; Mon, 25 Jul 2005 21:17:41 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q3Hcet480813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 20:17:39 -0700 (PDT) Date: Mon, 25 Jul 2005 20:18:22 -0700 From: Erik Nordmark Subject: Re: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[Issue X] LinkID v.s. LandmarkPrefix) In-reply-to: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E5AB7E.6020803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > It can be argued that the semantics of landmark exchange is not to > imply all those prefixes are on the link - if the host did a landmark > question using 'P2', then a 'yes' answer just means P2 is on the link > (link3 in this case). Does that make sense? I'm not sure it helps. If P2 was retracted from link1 either silently (e.g., a single router was advertising P2, and that router was moved or decommissioned as part of the flash renumbering), or a few RAs were sent with valid lifetime=0, and, due to packet loss, some routers on link1 did not hear those RAs, then we'd still have an inconsistent state; a landmark query for P2 would return "yes" even though the prefix isn't assigned to link1 any more. This will persist for the maximum time the learned prefixes are retained by a router on link1 (90 minutes). > The negative side is that when a host is on a link with P4, P5, P6, > sends a landmark question with P6 and gets a 'yes' answer, the host > cannot say anything about the availability of P4 or P5. The host will > have to do separate landmark questions for each of them or hope for a > complete RA to be received. Based on the comment above, we would also have to forbid the routers from using learned prefixes as part of the DNA solution. That sounds like fairly severe restrictions, especially given the low probability of - flash renumbering - immediate reassignment of the prefix to a different link, and - a host moving from the old link to the new link at the same time as the flash renumbering and reassignment Thus I'm more favorable to an approach which tries to recover from the problem in a reasonable way once it has occurred, but without impacting the performance of the main DNA operation. A possible way to do this is exemplified by this sequence: - the host sees P1 and P2 on the link - the host gets a link up notification; sends a RS with a landmark question for P2 - receives a landmark response with P2=yes - later receives a periodic RA with some prefixes (P2, P3 in the example) - 90 minutes after the link up it observes that it has not yet heard any RA with a subset of the prefixes it heard before the link up (P1 in the example); this is suspicious. In this case it could - drop those prefixes; basically assume that it has moves to a link with (P2, P3) - try to reverify whether P1 is on the link by sending a RS with P1 as the landmark. The last thing would not need to be performed for each prefix; only one prefix which was heard before the link up but has not been heard after the link up should be sufficient. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 23:22:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxG19-00009A-Ch for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 23:22:07 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17830 for ; Mon, 25 Jul 2005 23:22:04 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2ZBKIJXG8WXH3N@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 13:21:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AD796AB54A; Tue, 26 Jul 2005 13:21:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5BF5C4FB0B; Tue, 26 Jul 2005 13:21:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q3Kvr27387 for dna-list; Tue, 26 Jul 2005 13:20:57 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q3Kuw27383 for ; Tue, 26 Jul 2005 13:20:57 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR2ZB609DI8Y64DG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 13:20:53 +1000 Received: by localhost (Postfix, from userid 510) id 33F318000D; Tue, 26 Jul 2005 13:20:53 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5594E3C00E; Tue, 26 Jul 2005 13:20:51 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6Q3Kkcn012560; Mon, 25 Jul 2005 20:20:47 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q3Ki05483746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2005 20:20:45 -0700 (PDT) Date: Mon, 25 Jul 2005 20:21:27 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072520046d018db1@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E5AC37.1090603@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > By adding another router and a few more packet losses, we can make > a pathological case with a problem. Can you provide an example? > Is it so? Does that mean the hosts would not make a decision > based on unsolicited CompleteRAs? Is it written in an I-D? I thought this was a working group trying to figure out how we'd like the solution to work; not some attempt to choose one out of a set of competing, and perhaps incomplete, internet-drafts. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Jul 25 23:45:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGNw-0004ZL-Cz for dna-archive@megatron.ietf.org; Mon, 25 Jul 2005 23:45:44 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19698 for ; Mon, 25 Jul 2005 23:45:36 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR305QRC128WXH6L@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 13:45:11 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4E96CAB54E; Tue, 26 Jul 2005 13:44:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0ECA04FB07; Tue, 26 Jul 2005 13:44:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q3iDu27693 for dna-list; Tue, 26 Jul 2005 13:44:13 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q3iCw27689 for ; Tue, 26 Jul 2005 13:44:12 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR304QR4QS9APMCG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 13:43:57 +1000 Received: by localhost (Postfix, from userid 510) id 13EA2AB54A; Tue, 26 Jul 2005 13:43:56 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 04BF84FB0C; Tue, 26 Jul 2005 13:43:55 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6Q3hpfA000769; Mon, 25 Jul 2005 23:43:51 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 93A091E8CF2; Mon, 25 Jul 2005 23:34:29 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 835021E81B6; Mon, 25 Jul 2005 23:34:29 -0400 (EDT) Date: Mon, 25 Jul 2005 23:43:23 -0400 From: Sathya Narayanan Subject: Re: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[IssueX]LinkID v.s. LandmarkPrefix) In-reply-to: <42E5AB7E.6020803@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E5B15B.7060609@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:6 M:5 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <42E5AB7E.6020803@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Sathya Narayanan wrote: > >> It can be argued that the semantics of landmark exchange is not to >> imply all those prefixes are on the link - if the host did a landmark >> question using 'P2', then a 'yes' answer just means P2 is on the link >> (link3 in this case). Does that make sense? > > > I'm not sure it helps. > If P2 was retracted from link1 either silently (e.g., a single router > was advertising P2, and that router was moved or decommissioned as > part of the flash renumbering), or a few RAs were sent with valid > lifetime=0, and, due to packet loss, some routers on link1 did not > hear those RAs, then we'd still have an inconsistent state; a landmark > query for P2 would return "yes" even though the prefix isn't assigned > to link1 any more. This will persist for the maximum time the learned > prefixes are retained by a router on link1 (90 minutes). > Agreed !!! But ... >> The negative side is that when a host is on a link with P4, P5, P6, >> sends a landmark question with P6 and gets a 'yes' answer, the host >> cannot say anything about the availability of P4 or P5. The host will >> have to do separate landmark questions for each of them or hope for a >> complete RA to be received. > > > Based on the comment above, we would also have to forbid the routers > from using learned prefixes as part of the DNA solution. ... why? The problems becomes worse with wrong state for upto 7 days only with reassignment. The above comment is only about flash renumbering which will be corrected within 90 minutes and is not that bad (A) > That sounds like fairly severe restrictions, especially given the low > probability of > - flash renumbering > - immediate reassignment of the prefix to a different link, and > - a host moving from the old link to the new link at the same time as > the flash renumbering and reassignment Even without agreeing to the severe restriction, I agree with the low-probability of this event and that it may not make sense to design solution that avoids this possibility. My aim was just to start thinking about a mechanism to address this ... > Thus I'm more favorable to an approach which tries to recover from the > problem in a reasonable way once it has occurred, but without > impacting the performance of the main DNA operation. > > A possible way to do this is exemplified by this sequence: > - the host sees P1 and P2 on the link > - the host gets a link up notification; sends a RS with a landmark > question for P2 > - receives a landmark response with P2=yes > - later receives a periodic RA with some prefixes (P2, P3 in the > example) > - 90 minutes after the link up it observes that it has not yet heard > any RA with a subset of the prefixes it heard before the link up (P1 > in the example); this is suspicious. By suggesting that this is suspicious, we are suggesting that the prefix-lifetime being greater than 90 minutes is not necessarily right - in effect putting an upper limit on the prefix-lifetime and overruling 2461. Right? Is it OK to do that? > In this case it could > - drop those prefixes; basically assume that it has moves to a > link with (P2, P3) > - try to reverify whether P1 is on the link by sending a RS with > P1 as the landmark. > > The last thing would not need to be performed for each prefix; only > one prefix which was heard before the link up but has not been heard > after the link up should be sufficient. In support of my argument above marked (A), this solution doesn't address the flash renumbering problem - only flash renumbering with early reassignment. But, I do agree that this simpler defensive scheme can handle the low-probability occurance of flash-renumbering with early reassignment. -Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 00:20:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGvi-0002wg-HJ for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 00:20:34 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21636 for ; Tue, 26 Jul 2005 00:20:31 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR31DV9EHI99PW6S@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 14:20:26 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3CE68000E; Tue, 26 Jul 2005 14:20:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5CFDB3C003; Tue, 26 Jul 2005 14:20:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q4Jxa28137 for dna-list; Tue, 26 Jul 2005 14:19:59 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q4Jww28133 for ; Tue, 26 Jul 2005 14:19:58 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR31DB5UMQ9APJT7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 14:19:53 +1000 Received: by localhost (Postfix, from userid 510) id D480A8000F; Tue, 26 Jul 2005 14:19:52 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 549843C00B; Tue, 26 Jul 2005 14:19:51 +1000 (EST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK700BLCW0L1P@mailout1.samsung.com>; Tue, 26 Jul 2005 13:19:33 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IK700DUFW0D5B@mmp2.samsung.com>; Tue, 26 Jul 2005 13:19:33 +0900 (KST) Date: Tue, 26 Jul 2005 09:45:34 +0530 From: Syam Madanapalli Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , JinHyeock Choi Cc: Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <008801c59198$b0578770$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> Content-Transfer-Encoding: 7BIT Erik, > JinHyeock Choi wrote: > >> In linkid scheme, a prefix addition or deletion would not cause an >> incorrect decision, whereas there is such a possibility for Landmark/ >> CompleteRA. Allow me an example. Assume a link with a router R and host >> H. R advertises Prefix1. R1 happens to stop advertising Prefix1 and start >> advertising a new prefix Prefix2. > > But in this case, when all the prefixes are being removed and replaced > with a completely new set of prefixes, there is little if no harm to > incorrectly assume a link change (after all, all the addresses need to be > reconfigured, etc). > > A more realistic example is the one I included in my more recent email > today. > >> R announces it by sending an RA but H doesn't receive it. Then next time >> H receives CompleteRA with >> Prefix2, it will falsely assume a link change. > > Actually not; if will only assume a link change if it receives a link up > event notification between the last time it heard a RA with Prefix1 and > the first time it heard an RA with Prefix2. Let us assume the host is rebooting on the same link or changing its Layer 2 access, even in this case the current linkid scheme does not make the wrong decision of link change. Syam > > Erik > >> Linkid scheme deal with such a temporary flapping by adopting extra >> techniques such as "Linkid Prefix List" or "LEAST_VALID_LIFETIME". I >> don't know how Landmark/ CompleteRA can make a correct decision >> under flapping without such an extra techniques. Thanks in advance for >> your kind consideration. Best Regards >> >> JinHyeock >> > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 00:23:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGy7-0003CT-4H for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 00:23:04 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21752 for ; Tue, 26 Jul 2005 00:22:59 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR31GF70ZO8WXFQM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 14:22:35 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43D238000E; Tue, 26 Jul 2005 14:22:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E34843C012; Tue, 26 Jul 2005 14:22:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q4MJi28190 for dna-list; Tue, 26 Jul 2005 14:22:19 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q4MJw28186 for ; Tue, 26 Jul 2005 14:22:19 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR31G8TR629APLSD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 14:22:15 +1000 Received: by localhost (Postfix, from userid 510) id E2701AB543; Tue, 26 Jul 2005 14:22:14 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0606B4FB05 for ; Tue, 26 Jul 2005 14:22:12 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1150033nzd for ; Mon, 25 Jul 2005 21:22:11 -0700 (PDT) Received: by 10.36.3.9 with SMTP id 9mr2826184nzc; Mon, 25 Jul 2005 21:22:11 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 21:22:11 -0700 (PDT) Date: Tue, 26 Jul 2005 13:22:11 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E5AC37.1090603@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050725212266de187e@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BRVBjB4U3GjigOml3kd3NIW4TsGUn75/PcASua9RvO5YVjjtCne+Qh5FaUwwFyacRLQdAISii2Tltb3Get5Rmg8ImPv7QTXicoJaskBSKgG0ZWdAfAKm7nzOJ/KTMaxE0PEbZky54QYKUWXc4bfGKf7pSDRZmJaqc1aMNvNR7d8= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> Content-Transfer-Encoding: 7BIT Erik > > By adding another router and a few more packet losses, we can make > > a pathological case with a problem. > > Can you provide an example? ok. I admit this is a crude one but all I can think of right now. (Because it's not clear to me how a host base its decision on CompleteRA, I switch to landmark one.) Assume a link with two routers R1 and R2 and a host H. R1 advertises Prefix1 and R2 Prefix2. R2 stops advertising Prefix2 and starts advertising Prefix3. R2 announces the prefix change by sending an RA but both R1 and H don't receive it. Then H happens to change its AP in the same link and send an RS with landmark Prefix2. It also happens that R2 replies first and sends an RA with NO and Prefix3. H falsely assumes a link change. > > Is it so? Does that mean the hosts would not make a decision > > based on unsolicited CompleteRAs? Is it written in an I-D? > > I thought this was a working group trying to figure out how we'd like > the solution to work; not some attempt to choose one out of a set of > competing, and perhaps incomplete, internet-drafts. ok. >> Then next time H receives CompleteRA with >> Prefix2, it will falsely assume a link change. > > Actually not; if will only assume a link change if it receives a link up > event notification between the last time it heard a RA with Prefix1 and > the first time it heard an RA with Prefix2. The above is not clear to me yet. Allow me a question to help my understanding. Assume a host moves to a different link but fails to receive a Link Up event Notification. Then the host will not assume a link change even if it receives a different unsolicted CompleteRA? Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 00:32:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxH6t-0004pl-0t for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 00:32:07 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22048 for ; Tue, 26 Jul 2005 00:32:03 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR31R5HVU28WXHSS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 14:31:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C05CAB543; Tue, 26 Jul 2005 14:31:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0C5CE4FB04; Tue, 26 Jul 2005 14:31:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q4Uo628298 for dna-list; Tue, 26 Jul 2005 14:30:50 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q4Uow28294 for ; Tue, 26 Jul 2005 14:30:50 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR31QOVKO88Y650R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 14:30:40 +1000 Received: by localhost (Postfix, from userid 510) id 12A0FAB543; Tue, 26 Jul 2005 14:30:39 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id D99BF4FB10; Tue, 26 Jul 2005 14:30:38 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK700C0AWJ0UU@mailout3.samsung.com>; Tue, 26 Jul 2005 13:30:36 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IK700EPUWIRW9@mmp2.samsung.com>; Tue, 26 Jul 2005 13:30:36 +0900 (KST) Date: Tue, 26 Jul 2005 09:56:37 +0530 From: Syam Madanapalli Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: JinHyeock Choi , Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <009a01c5919a$3b7435f0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E59133.6090603@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, > Hi Syam, > > Syam Madanapalli wrote: >> Hi Brett, >> >> [cut] >> >>>> >>>> These are my line of thoughts. We can't avoid a temporary flapping for >>>> the related set, the set of >>>> all prefixes >>>> on a link. In linkid scheme, one item (linkid prefix) of the set >>>> matters for DNA >>>> performance. >>>> So we designed a few special schemes for the linkid prefix so that >>>> linkid prefix(es) >>>> won't give incorrect information about a link change, even under >>>> temporary flapping. >>>> >>>> But for Complete RA or Landmark, IMO, we need to adopt similar schemes >>>> such as "Linkid Prefix List" or "Old linkid advertising rule" to all >>>> prefixes because we >>>> don't know which prefix will affect DNA decision. >>> >>> >>> For Landmarks: >>> >>> If a prefix is removed, the host will receive a "NO" answer, which >>> also include prefixes that are on the link and have been seen by the >>> host before so it can see there is no link change and yet will also >>> know that the prefix it was using as a landmark is no longer valid. >>> (I think we need text to clear that up) >> >> >> A host may get 'YES' answer from a Router (R2) before the 'NO' answer >> from Router (R1) because the deletion of the prefix (P1) at R1 might not >> have >> propagated to R2 at the time of answering the landmar query for P1. > > Yes, and as far as DNA goes that is the correct answer in that there is > no link change. What if you get answer 'NO' first? Will you check with the prefixes received in the RA? This looks better compared just depending on the Landmark answer. Otherwise host makes wrong decision. [cut] >> >> As we are not anyway interested in building the complete prefix list, >> why cannot we just depend on CPL to build. I did not remember >> the waiting time for building the CPL, but I am sure it will be in few >> seconds. When a host sends RS with Landmark question, and answer >> is 'NO' a host can buid the CPL (almost) from the resulting RAs which >> is sufficient to detect the link change at the new link even if the node >> moves within few seconds. > > Just relying on CPL instead of CompleteRA is a possibility. Depends if > folks are willing to have a window of 12 seconds (?) after each link > change where another link change will not be able to be detect rapidly. > When we wrote the proposal, we felt that we needed something more. I think 12 seconds is very small considering mobility :) > >>> >>> LinkID has a much more complex technique for managing prefix change >>> involving advertising prefixes for some length of time with short >>> lifetimes before advertising them with zero lifetimes in order to >>> avoid confusion. I don't think this is needed for Landmark/CompleteRA. >> >> >> If we need to have the similar confidence in determining the link change >> with >> graceful prefix addition/deletion, we need similar techniques for all of >> the >> prefixes on the link incase of Landmark/CompleteRA. > > I think I've shown that those additional techniques are not needed for > Landmark/CompleteRA. It may be that they are not needed for LinkID > either. I think the LinkID proposal would need to be modified to allow > hosts to use the other prefixes in the RA for link identification, not > just those marked as LinkIDs. Linkid does allows the checking for the other prefixes in RA, but it checks with only the linkid list that host maintains. > > Brett. > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 00:54:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHS1-0000Qt-8M for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 00:54:04 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23590 for ; Tue, 26 Jul 2005 00:53:53 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR32K9TWWG99PIGV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 14:53:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A518AB547; Tue, 26 Jul 2005 14:53:44 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9ADC64FB0E; Tue, 26 Jul 2005 14:53:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q4rGA28629 for dna-list; Tue, 26 Jul 2005 14:53:16 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q4rEw28625 for ; Tue, 26 Jul 2005 14:53:14 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR32JFVI049APK8A@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 14:53:04 +1000 Received: by localhost (Postfix, from userid 510) id 13C71AB544; Tue, 26 Jul 2005 14:53:04 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by curly.its.monash.edu.au (Postfix) with ESMTP id C768D4FB09 for ; Tue, 26 Jul 2005 14:53:02 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1156178nzd for ; Mon, 25 Jul 2005 21:53:01 -0700 (PDT) Received: by 10.36.56.18 with SMTP id e18mr7609nza; Mon, 25 Jul 2005 21:53:01 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 21:53:01 -0700 (PDT) Date: Tue, 26 Jul 2005 13:53:01 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E59B91.2050007@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072521531fba472d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uKLrW7xWBMyYb9I+ja5glFeN5zpyFWcmSP2sik7k95DPJuAXsFoUJif7bgZbjKmjzLa89x3HQ5RwTDdehBUX7ihsbhC66S8ECEYxFePvuKI6gn0YECCJQz0yNLKmG8NpZhCPo1Fp1KhZC7qwONdVoqHVzL/jD/Jgts38nAjVH3E= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E59B91.2050007@sun.com> Content-Transfer-Encoding: 7BIT Erik > Just to make it sure we are all talking about the same thing, by > "flapping" I assume we mean the following: > > When the set of prefixes on a link changes, e.g., a prefix is being > added or a prefix is being removed, there is the possibility that a host > see more than one change (see things flapping back and forth) until the > routers have been synchronized. > For instance, if the prefix set is {P1, P2} and P3 is added, one would > ideally have the host see {P1, P2} and then see {P1, P2, P3}, but when > RAs come from different routers, there might be a small window when the > host sees RAs vary in a sequence like {P1, P2}, {P1, P2, P3}, {P1, P2}, > {P1, P2, P3}. This is due to the third RA (with {P1, P2}) coming from a > router which hadn't seen P3 yet. > > If there is no packet loss, the window during which this can happen is > very small (basically the propagation delay of the RA which carries the > new prefix from one router to another). With packet loss, the worst case > window is the time it takes to successfully retransmit the RA so that > the other routers see it. I use flapping in more general case as below. When the set of prefixes on a link changes, there is the possibility of temporary lack of synchronization, i.e. the nodes on the link (such as routers and hosts) may have different set of prefixes (on the link) for the time being. For example, if the prefix set is {P1, P2} and P3 is added, one would ideally have all the nodes on the link have the prefix set {P1, P2, P3} instantly. But due to packet loss, it is possible that one router has the prefix set {P1, P2} and the other router has {P1, P2, P3} for some time. If hosts check for link change with prefix information, such a lack of (temporary) synchronization may cause a false link identity detection. > Yes, but linkid still has flapping issues; you just have a technique to > avoid this resulting in an incorrect result. (In the case of linkid the > flapping effects the linkID which each routers picks. Thus if P3 was the > numerically smallest prefix then the flapping in the prefix set would > result in flapping in the linkID prefix the host sees.) Handling this > requires some additional logic in linkID. Exactly. I found it extremely difficult to abolishing flapping completely. So I took the approach to make hosts to make the right decision under mild flapping. > > But for Complete RA or Landmark, IMO, we need to adopt similar schemes such > > as "Linkid Prefix List" or "Old linkid advertising rule" to all > > prefixes because we > > don't know which prefix will affect DNA decision. > > I don't think so. CompleteRA is basically the same as CPL in this > respect, in that the prefix sets are compared to see whether they are > disjoint. In the above example, there is overlap between {P1, P2} and > {P1, P2, P3} hence the host would correctly conclude that it didn't move. > > Landmark is basically an optimization of completeRA, with a fallback to > completeRA/CPL prefix comparisons when there was no landmark response, > or no DNA capable router, respectively. Thus the completeRA/CPL > observation holds. This even takes care of the case when a host picks up > {P1, P2, P3}, selects P3 as its landmark, gets a new link up > notification, sends a RS, and get a response with "landmark P3 = NO, > PIO={P1, P2}, from a router which hasn't yet seen P3, since the host > would compare the prefix sets in that case as well. (I'm not sure that > is in the I-D, but I think it needs to be in the I-D to handle the > analogous case of moving to a link with no DNA routers.) ok. Allow me to clarify this In Landmark/ CompleteRA, when a host receives a solicited RA, the host check for link change with both 1) Landmark option with YES/NO bit and 2) prefixes in the RA. If the (solicited) RA carries 1) NO answer and 2) a known prefix, the host would not assume a link change. (So in effect, "known prefix" would overrule "NO".) Is this right? > > If all routers agree on the selection algorithm, it's almost automatical > > to select the prefix among the set of prefixes. That's why I chose the > > simplest selection scheme, picking the smallest prefix. > > Sure. But my point is that a router needs to be prepared to receive a RA > where some other router, due to not having seen an RA, or being broken, > is claiming that some other prefix is the linkID. That's some added > complexity. Routers don't pay attention what other routers advertise as a linkid. They generate the complete prefix set and pick the linkid prefix for themselves. You recommended this approach. > > I thought it simpler to make routers agree on the same selection > > scheme but would like to hear your scheme when developed. > > I think it would be isomorphic to linkid; just a different way of > thinking about the problem. (BTW: "simple" and "distributed agreement" > don't belong together in the same sentence. :-) ok and agree. :-) Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 00:57:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHVQ-0000sB-RL for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 00:57:32 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23795 for ; Tue, 26 Jul 2005 00:57:25 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR32OFDSC499PQYP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 14:57:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1474BAB543; Tue, 26 Jul 2005 14:57:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id BDC664FB06; Tue, 26 Jul 2005 14:57:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q4v2u28688 for dna-list; Tue, 26 Jul 2005 14:57:02 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q4v1w28684 for ; Tue, 26 Jul 2005 14:57:01 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR32NZI3E68Y6543@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 14:56:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D48CB8000D; Tue, 26 Jul 2005 14:56:43 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 3BBE43C013; Tue, 26 Jul 2005 14:56:43 +1000 (EST) Date: Tue, 26 Jul 2005 14:56:42 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050725212266de187e@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , Syam Madanapalli , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E5C28A.3080000@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, >>>By adding another router and a few more packet losses, we can make >>>a pathological case with a problem. >> >>Can you provide an example? > > > ok. I admit this is a crude one but all I can think of right now. > (Because it's not clear to me how a host base its decision > on CompleteRA, I switch to landmark one.) > > Assume a link with two routers R1 and R2 and a host H. > R1 advertises Prefix1 and R2 Prefix2. > > R2 stops advertising Prefix2 and starts advertising Prefix3. > R2 announces the prefix change by sending an RA but > both R1 and H don't receive it. > > Then H happens to change its AP in the same link > and send an RS with landmark Prefix2. It also happens that > R2 replies first and sends an RA with NO and Prefix3. > H falsely assumes a link change. I think you might have found one :) Actually, there was some discussion recently on whether a NO answer should only include explcitly configured PIOs or should include a DNA option as well. You may have found a good reason to include the DNA option. In this case the DNAO in the NO answer would include P1 which would allow the host to correctly recognise that there has been no change. >>>Then next time H receives CompleteRA with >>>Prefix2, it will falsely assume a link change. >> >>Actually not; if will only assume a link change if it receives a link up >>event notification between the last time it heard a RA with Prefix1 and >>the first time it heard an RA with Prefix2. > > > The above is not clear to me yet. Allow me a question to help > my understanding. > > Assume a host moves to a different link but fails to receive a > Link Up event Notification. Then the host will not assume a link > change even if it receives a different unsolicted CompleteRA? As written, I don't think the draft ties the decision making to a link layer indication. In the instance you brought up an incorrect decision would be made. However, this is the pathological case I mentioned the other day and the fix is the same as for LinkID. That is, to require the router to advertise both prefixes (or in fact just some overlap in the sets of prefixes) for some period of time. There is nothing fundamental about LinkID that lets it cope with this situation. It's just that the LinkID draft has a bit of text that says not to do that. Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:26:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHxX-0006yg-OG for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:26:31 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25500 for ; Tue, 26 Jul 2005 01:26:30 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR33OMMWMU9APO0O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:26:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3A1A0AB543; Tue, 26 Jul 2005 15:26:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id E07974FB03; Tue, 26 Jul 2005 15:26:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5Ptg29040 for dna-list; Tue, 26 Jul 2005 15:25:55 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5Psw29036 for ; Tue, 26 Jul 2005 15:25:54 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR33O02OSG99PX6S@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:25:46 +1000 Received: by localhost (Postfix, from userid 510) id 1CFA9AB542; Tue, 26 Jul 2005 15:25:46 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by curly.its.monash.edu.au (Postfix) with ESMTP id 26D924FB07 for ; Tue, 26 Jul 2005 15:25:44 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1161909nzd for ; Mon, 25 Jul 2005 22:25:44 -0700 (PDT) Received: by 10.36.79.2 with SMTP id c2mr31728nzb; Mon, 25 Jul 2005 22:25:43 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 22:25:43 -0700 (PDT) Date: Tue, 26 Jul 2005 14:25:43 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E4A03B.6080601@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072522257549d386@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J75fPKc0zYGTQNhDhW0p2uroZOf23SfKxL4SJUd+zYxnS84SRqEJAfs0IYB5FCkId47m8HWcMAb9mlVk//OaQxuGk19mTgA/gInWl/O7foZ6Dcr1/Kc9L2XAnCqRyspE3BRQU1BCzmRmNmjeYDzYSEGgjK0aN0CVR1hbPROlvaQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett Thanks for your summary. I assume Landmark/ CompleteRA will follow the memo. > For Landmarks: > > If a prefix is removed, the host will receive a "NO" answer, which > also include prefixes that are on the link and have been seen by the > host before so it can see there is no link change and yet will also > know that the prefix it was using as a landmark is no longer valid. > (I think we need text to clear that up) So in this case, the known prefix in the RA overrules "NO" answer. Right? > For CompleteRA (which is proposed as a fallback for when it is not > possible to use landmarks): > > By its nature it creates overlap between the sets of RAs advertised > by the routers on a link. It doesn't matter whether the sets > agree completely or not, as long as there's overlap (because link- > change is detected by receiving a RA with a set disjoint from the > set of prefixes the host has seen on the link). The pathological > case that we may need to take action to avoid is where a router > that is currently configured with all of the prefixes in use on a > link, suddenly has all of them removed and replaced with a new > disjoint set. We need to add some text to say not to do that. So I understand you try to assure that there always a overlapping prefix among CompleteRAs even under prefix change. Right? I admit that I don't look over Landmark/CompleteRA 01-draft but the above seems a little different from what I remember. I think it would help to write those down lest there should be unnecessary confusion. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:31:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI2V-0007uy-TO for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:31:40 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25761 for ; Tue, 26 Jul 2005 01:31:38 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR33UVFQTI9APO0O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:31:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C4ABAB545; Tue, 26 Jul 2005 15:31:18 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 04B444FB08; Tue, 26 Jul 2005 15:31:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5VEt29120 for dna-list; Tue, 26 Jul 2005 15:31:14 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5VCw29116 for ; Tue, 26 Jul 2005 15:31:12 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR33UQTOP699PPHL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:31:12 +1000 Received: by localhost (Postfix, from userid 510) id 4B85FAB54A; Tue, 26 Jul 2005 15:31:12 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by curly.its.monash.edu.au (Postfix) with ESMTP id 28D334FB03; Tue, 26 Jul 2005 15:31:06 +1000 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F2536AB; Tue, 26 Jul 2005 07:31:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 07:31:04 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 07:31:03 +0200 Date: Tue, 26 Jul 2005 07:31:02 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] [Issue X] LinkID v.s. Landmark Prefix Thread-index: AcWRmasYD+/xLRleTnm0OmSqh7O4qgACMGdg Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 26 Jul 2005 05:31:03.0699 (UTC) FILETIME=[36EAEE30:01C591A3] Content-Transfer-Encoding: 7BIT > Assume a link with two routers R1 and R2 and a host H. > R1 advertises Prefix1 and R2 Prefix2. > > R2 stops advertising Prefix2 and starts advertising Prefix3. > R2 announces the prefix change by sending an RA but > both R1 and H don't receive it. > > Then H happens to change its AP in the same link > and send an RS with landmark Prefix2. It also happens that > R2 replies first and sends an RA with NO and Prefix3. > H falsely assumes a link change. But isn't it actually so that in this case the host shouldn't use an address based on Prefix2 and thus reconfiguration is required (i.e. link change from host H point of view)? After all, Prefix2 is not anymore valid. Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:34:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI5j-0008TX-Oq for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:34:59 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26051 for ; Tue, 26 Jul 2005 01:34:58 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR33YDGTAQ8WXI2T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:34:26 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B478D80010; Tue, 26 Jul 2005 15:34:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 52C723C011; Tue, 26 Jul 2005 15:34:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5Y3P29174 for dna-list; Tue, 26 Jul 2005 15:34:03 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5Y3w29170 for ; Tue, 26 Jul 2005 15:34:03 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR33XWKH9S8WXI2Q@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:33:45 +1000 Received: by localhost (Postfix, from userid 510) id A1360AB54A; Tue, 26 Jul 2005 15:33:44 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id D7E814FB0C; Tue, 26 Jul 2005 15:33:38 +1000 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78941682; Tue, 26 Jul 2005 07:33:37 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 07:33:36 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 07:33:36 +0200 Date: Tue, 26 Jul 2005 07:33:35 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[Issue X] LinkID v.s. LandmarkPrefix) Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 - was[Issue X] LinkID v.s. LandmarkPrefix) Thread-index: AcWRkLtWRPZLX/Q0RpqYZm1hNDqUiAAEovpw Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 26 Jul 2005 05:33:36.0134 (UTC) FILETIME=[91C6AA60:01C591A3] Content-Transfer-Encoding: 7BIT Resending... For some reason I didn't see this on the list. > But the problem certainly isn't specific to any particular proposal, > since they all rely on prefixes for link identification. And I suspect > that we have the same choices in terms of solutions independent of > which proposal we apply this to. > > Erik Erik is absolutely right. I now remember faintly discussing this matter with Jari and Pekka a long time ago. I think we were wondering and playing with the idea that maybe the DNA process should consider using hints from different entities (e.g. TCP timeout, MobileIPv6) in addition to the link layer. The problem, I guess, in such an approach would be how to prevent the solution from not being too vague or abstract. Tero -- Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:38:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI9N-0001G4-Cd for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:38:47 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26256 for ; Tue, 26 Jul 2005 01:38:43 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR343CML9Y9APMUH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:37:29 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6BD3AAB544; Tue, 26 Jul 2005 15:37:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 164234FB02; Tue, 26 Jul 2005 15:37:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5bF929251 for dna-list; Tue, 26 Jul 2005 15:37:15 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5bEw29247 for ; Tue, 26 Jul 2005 15:37:14 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3430UUN88Y5YXL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:37:06 +1000 Received: by localhost (Postfix, from userid 510) id CC149AB547; Tue, 26 Jul 2005 15:37:05 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by curly.its.monash.edu.au (Postfix) with ESMTP id E907A4FB02 for ; Tue, 26 Jul 2005 15:37:03 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1164264nzd for ; Mon, 25 Jul 2005 22:37:02 -0700 (PDT) Received: by 10.36.9.9 with SMTP id 9mr38948nzi; Mon, 25 Jul 2005 22:37:02 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 22:37:02 -0700 (PDT) Date: Tue, 26 Jul 2005 14:37:02 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E5C28A.3080000@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , Syam Madanapalli , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072522374e73df8@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Alb4lAar90Hds5l0EsxsvWB1u3bK5Hlx565hvkHpEHrOypz3Y0+ndujghiflk9cETvCDRH+AUvNiv4bgKjLuGVT9EdDnC+So0f7+Qwq0WU/8co4+XZW8EX23yupKzLf7N0khFh/v7MavfhIsJVTxzIBxlLIw8dvnBg8q87d62zg= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E5C28A.3080000@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett > I think you might have found one :) Thanks for your kind words. :-) > Actually, there was some > discussion recently on whether a NO answer should only include > explcitly configured PIOs or should include a DNA option as well. > You may have found a good reason to include the DNA option. > > In this case the DNAO in the NO answer would include P1 which would > allow the host to correctly recognise that there has been no change. ok. Then NO answer would include PIOs and a DNA option. Right? Then the RA is a CompleteRA, isn't it? > > The above is not clear to me yet. Allow me a question to help > > my understanding. > > > > Assume a host moves to a different link but fails to receive a > > Link Up event Notification. Then the host will not assume a link > > change even if it receives a different unsolicted CompleteRA? > > As written, I don't think the draft ties the decision making to a link > layer indication. In the instance you brought up an incorrect decision > would be made. ok. But I am still confused. Kindly clarify in which way hosts would make a decision. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:38:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxI9O-0001GA-9B for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:38:47 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26259 for ; Tue, 26 Jul 2005 01:38:44 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR344INVRM9APN1F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:38:21 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 004E2AB545; Tue, 26 Jul 2005 15:38:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A75F64FB09; Tue, 26 Jul 2005 15:38:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5cFs29283 for dna-list; Tue, 26 Jul 2005 15:38:15 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5cFw29279 for ; Tue, 26 Jul 2005 15:38:15 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR344DJE0K9APM96@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:38:11 +1000 Received: by localhost (Postfix, from userid 510) id 45AA8AB545; Tue, 26 Jul 2005 15:38:11 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id A3B4B4FB09; Tue, 26 Jul 2005 15:38:09 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK7008Z7ZM8EN@mailout1.samsung.com>; Tue, 26 Jul 2005 14:37:20 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK7004NCZLVCJ@mmp1.samsung.com>; Tue, 26 Jul 2005 14:37:20 +0900 (KST) Date: Tue, 26 Jul 2005 11:03:16 +0530 From: Ranjitsinh Wable Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , JinHyeock Choi Cc: Dna Message-id: <01b701c591a3$8d9d24f0$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E5C28A.3080000@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, ----- Original Message ----- From: "Brett Pentland" To: "JinHyeock Choi" Cc: "Erik Nordmark" ; "Syam Madanapalli" ; ; "James Kempf" ; "Dna" Sent: Tuesday, July 26, 2005 10:26 AM Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix > Hi JinHyeock, > >>>>By adding another router and a few more packet losses, we can make >>>>a pathological case with a problem. >>> >>>Can you provide an example? >> >> >> ok. I admit this is a crude one but all I can think of right now. >> (Because it's not clear to me how a host base its decision on CompleteRA, >> I switch to landmark one.) Assume a link with two routers R1 and R2 and a >> host H. R1 advertises Prefix1 and R2 Prefix2. R2 stops advertising >> Prefix2 and starts advertising Prefix3. R2 announces the prefix change by >> sending an RA but >> both R1 and H don't receive it. Then H happens to change its AP in the >> same link and send an RS with landmark Prefix2. It also happens that R2 >> replies first and sends an RA with NO and Prefix3. H falsely assumes a >> link change. > > I think you might have found one :) Actually, there was some > discussion recently on whether a NO answer should only include > explcitly configured PIOs or should include a DNA option as well. > You may have found a good reason to include the DNA option. > > In this case the DNAO in the NO answer would include P1 which would > allow the host to correctly recognise that there has been no change. > So you mean to say that all the answers to the landmark questions will have complete RA? Also how the P1 will help Host to decide that the link is not changed? Host may not keep the list of all the prefixes on link, which inturn makes it CPL. >>>>Then next time H receives CompleteRA with >>>>Prefix2, it will falsely assume a link change. >>> >>>Actually not; if will only assume a link change if it receives a link up >>>event notification between the last time it heard a RA with Prefix1 and >>>the first time it heard an RA with Prefix2. >> >> >> The above is not clear to me yet. Allow me a question to help my >> understanding. Assume a host moves to a different link but fails to >> receive a Link Up event Notification. Then the host will not assume a >> link change even if it receives a different unsolicted CompleteRA? > > As written, I don't think the draft ties the decision making to a link > layer indication. In the instance you brought up an incorrect decision > would be made. However, this is the pathological case I mentioned the > other day and the fix is the same as for LinkID. That is, to require > the router to advertise both prefixes (or in fact just some overlap in > the sets of prefixes) for some period of time. There is nothing > fundamental about LinkID that lets it cope with this situation. It's > just that the LinkID draft has a bit of text that says not to do that. > If the decision in not made on the unsolicited CompleteRA and the Link up indication is not the link to trigger the Landmark check. Then what is must condition to achieve it. When you will trigger the Landmark question? I think either both the cases has to be there or it should just work with the link up indication. Regards, Wable R. U. > Brett. > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 01:52:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIMF-0003sG-8g for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:52:03 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26928 for ; Tue, 26 Jul 2005 01:51:57 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR34K5Z95S8WXGJT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 15:51:32 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D282B8000D; Tue, 26 Jul 2005 15:50:54 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7C5613C015; Tue, 26 Jul 2005 15:50:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q5of829489 for dna-list; Tue, 26 Jul 2005 15:50:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q5oew29485 for ; Tue, 26 Jul 2005 15:50:40 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR34JMGEEE8Y5ZR7@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 15:50:29 +1000 Received: by localhost (Postfix, from userid 510) id B2FBC8000D; Tue, 26 Jul 2005 15:50:28 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by larry.its.monash.edu.au (Postfix) with ESMTP id CF81E3C010 for ; Tue, 26 Jul 2005 15:50:26 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1166743nzd for ; Mon, 25 Jul 2005 22:50:25 -0700 (PDT) Received: by 10.36.61.7 with SMTP id j7mr26390nza; Mon, 25 Jul 2005 22:50:25 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 22:50:25 -0700 (PDT) Date: Tue, 26 Jul 2005 14:50:25 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050725225049c9728a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hYoGavxM8Oho7dJUocGfU4IuB5B3WddUbm8onZiJLF/04/TUk2uXiK2QpDDH2T77562KRfDxX4EVMyNGZjyv7sAdvfOBXvL6Ncgsl9omMlvkJife0+YEvlpTP80apngs1n+y/OrhnI4TaDhExaQc0Hiuo1YnHx9RVOWO2tkl2do= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Dear Tero > > Assume a link with two routers R1 and R2 and a host H. > > R1 advertises Prefix1 and R2 Prefix2. > > > > R2 stops advertising Prefix2 and starts advertising Prefix3. > > R2 announces the prefix change by sending an RA but > > both R1 and H don't receive it. > > > > Then H happens to change its AP in the same link > > and send an RS with landmark Prefix2. It also happens that > > R2 replies first and sends an RA with NO and Prefix3. > > H falsely assumes a link change. > > But isn't it actually so that in this case the host shouldn't use an > address based on Prefix2 and thus reconfiguration is required (i.e. link > change from host H point of view)? After all, Prefix2 is not anymore > valid. Host may also have an address with Prefix1. While the address with Prefix1 is valid, the host will throw it away because it thinks it is at a different link. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 02:02:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIWI-0005yc-NI for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 02:02:28 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29584 for ; Tue, 26 Jul 2005 02:02:24 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR34WBP7XK8WXIKK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 16:01:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 100798000E; Tue, 26 Jul 2005 16:00:43 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C4A443C00E; Tue, 26 Jul 2005 16:00:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q60Wo29617 for dna-list; Tue, 26 Jul 2005 16:00:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q60Uw29613 for ; Tue, 26 Jul 2005 16:00:30 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR34VR2YOW9APMAX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 16:00:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CE55AB542; Tue, 26 Jul 2005 16:00:15 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 5384E4FB04; Tue, 26 Jul 2005 16:00:15 +1000 (EST) Date: Tue, 26 Jul 2005 16:00:14 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <009a01c5919a$3b7435f0$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: JinHyeock Choi , Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E5D16E.8080102@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E59133.6090603@eng.monash.edu.au> <009a01c5919a$3b7435f0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, >>>>> These are my line of thoughts. We can't avoid a temporary flapping >>>>> for the related set, the set of >>>>> all prefixes >>>>> on a link. In linkid scheme, one item (linkid prefix) of the set >>>>> matters for DNA >>>>> performance. >>>>> So we designed a few special schemes for the linkid prefix so that >>>>> linkid prefix(es) >>>>> won't give incorrect information about a link change, even under >>>>> temporary flapping. >>>>> >>>>> But for Complete RA or Landmark, IMO, we need to adopt similar >>>>> schemes such as "Linkid Prefix List" or "Old linkid advertising >>>>> rule" to all >>>>> prefixes because we >>>>> don't know which prefix will affect DNA decision. >>>> >>>> >>>> >>>> For Landmarks: >>>> >>>> If a prefix is removed, the host will receive a "NO" answer, which >>>> also include prefixes that are on the link and have been seen by the >>>> host before so it can see there is no link change and yet will also >>>> know that the prefix it was using as a landmark is no longer valid. >>>> (I think we need text to clear that up) >>> >>> >>> >>> A host may get 'YES' answer from a Router (R2) before the 'NO' answer >>> from Router (R1) because the deletion of the prefix (P1) at R1 might >>> not have >>> propagated to R2 at the time of answering the landmar query for P1. >> >> >> Yes, and as far as DNA goes that is the correct answer in that there is >> no link change. > > > What if you get answer 'NO' first? > Will you check with the prefixes received in the RA? > This looks better compared just depending on the > Landmark answer. Otherwise host makes wrong decision. > > [cut] This question is one of the open issues (9). My personal opinion is that yes, the host should check the prefixes and if it sees overlap with the prefixes it has already seen on the link, should decide that link change has not taken place. Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 02:06:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIZv-0006mF-Lb for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 02:06:11 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03422 for ; Tue, 26 Jul 2005 02:06:08 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR351A2C3K9APNI0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 16:04:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B76828000F; Tue, 26 Jul 2005 16:04:42 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6112E3C018; Tue, 26 Jul 2005 16:04:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q64aC29691 for dna-list; Tue, 26 Jul 2005 16:04:36 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q64Zw29687 for ; Tue, 26 Jul 2005 16:04:35 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR350U1EJ68WXIKK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 16:04:21 +1000 Received: by localhost (Postfix, from userid 510) id 5C0C8AB542; Tue, 26 Jul 2005 16:04:21 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7F88F4FB0F for ; Tue, 26 Jul 2005 16:04:20 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so1169307nzd for ; Mon, 25 Jul 2005 23:04:19 -0700 (PDT) Received: by 10.36.251.35 with SMTP id y35mr30104nzh; Mon, 25 Jul 2005 23:04:19 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Mon, 25 Jul 2005 23:04:19 -0700 (PDT) Date: Tue, 26 Jul 2005 15:04:19 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072523047382e0fb@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OkPTcLDDcjUEaqbjrjS3TJky+FSXDnYQKRXgFIAaXmF9lYN+RtfGBZs6qjiYQ6sKIxXP259tLE8wWpHpYFhQaV4jYx+6+yBQViilrVM72zZ5mqxQmz5h+XZQ6MQ56+fubIymcdd8Ve+4jhOYY2+QK6piHPe4NeHBrMHx8DQhnZk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Dear Tero > I have been dead silence for quite a long time now. I haven't been able > to follow the WG progress and I feel somewhat lost. I spent a couple of > days last week trying to catch up with the work ... ~200 unread mails > and new drafts. Oh, dear... I contributed some for that. Sorry. I ask your kind understanding. :-) > > How do you think of FRD? We got a pretty nice result. :-) > > I see it has potential. At a glance one concern which emerged to me was > possible security issues. Unfortunately I'm not much of a security > expert, and have some difficulties further analyzing the proposal from > that perspective. ok. > > Maybe that's the way I'd better follow and FRD would better to be > > content with informational RFC as a kind of auxiliary solution. > > I'm sort of newbie when it comes to the IETF but I would assume that > some IETF people would have allergic reactions (much like I have with > politics) on solutions that have operator "connections" (couldn't find > any better English word right now). Taking that into account, I would > guess that the road of an informational RFC would be a bit less bumpy. ok. Nowadays I barely keep myself afloat dealing with the volume of mailing list. (Am I already drowning?) To me, trying to process mailings feels like trying to swallow water directly out of high-pressure fire hose. :-) See you soon in Paris, La Ville Luminaire, and let's have some fun together. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 02:08:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIcA-0007BS-T0 for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 02:08:31 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05567 for ; Tue, 26 Jul 2005 02:08:29 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR355MPCUI99PHOP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 16:08:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 38EE28000F; Tue, 26 Jul 2005 16:08:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id E91143C005; Tue, 26 Jul 2005 16:08:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q687k29751 for dna-list; Tue, 26 Jul 2005 16:08:07 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q686w29747 for ; Tue, 26 Jul 2005 16:08:06 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR35550EL68Y65PS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 16:07:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 931C1AB543; Tue, 26 Jul 2005 16:07:49 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 648784FB04; Tue, 26 Jul 2005 16:07:49 +1000 (EST) Date: Tue, 26 Jul 2005 16:07:48 +1000 From: Brett Pentland Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072522257549d386@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E5D334.1010402@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <92e919fb05072522257549d386@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Dear Brett > > Thanks for your summary. I assume Landmark/ CompleteRA will follow > the memo. > > >>For Landmarks: >> >> If a prefix is removed, the host will receive a "NO" answer, which >> also include prefixes that are on the link and have been seen by the >> host before so it can see there is no link change and yet will also >> know that the prefix it was using as a landmark is no longer valid. >> (I think we need text to clear that up) > > > So in this case, the known prefix in the RA overrules "NO" answer. > Right? See my answer to Syam. >>For CompleteRA (which is proposed as a fallback for when it is not >>possible to use landmarks): >> >> By its nature it creates overlap between the sets of RAs advertised >> by the routers on a link. It doesn't matter whether the sets >> agree completely or not, as long as there's overlap (because link- >> change is detected by receiving a RA with a set disjoint from the >> set of prefixes the host has seen on the link). The pathological >> case that we may need to take action to avoid is where a router >> that is currently configured with all of the prefixes in use on a >> link, suddenly has all of them removed and replaced with a new >> disjoint set. We need to add some text to say not to do that. > > > So I understand you try to assure that there always a overlapping > prefix among CompleteRAs even under prefix change. Right? Yes. > I admit that I don't look over Landmark/CompleteRA 01-draft but the > above seems a little different from what I remember. I think it would > help to write those down lest there should be unnecessary confusion. OK. Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 02:21:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIov-0001HU-Kc for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 02:21:42 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18316 for ; Tue, 26 Jul 2005 02:21:39 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR35KYO5I88Y65SA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 16:21:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EF2B7AB545; Tue, 26 Jul 2005 16:20:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9CFA94FB0A; Tue, 26 Jul 2005 16:20:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6Q6KRx29917 for dna-list; Tue, 26 Jul 2005 16:20:27 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6Q6KPw29913 for ; Tue, 26 Jul 2005 16:20:25 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR35KKHVOA99PYW9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 16:20:16 +1000 Received: by localhost (Postfix, from userid 510) id ADDB58001A; Tue, 26 Jul 2005 16:20:15 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by larry.its.monash.edu.au (Postfix) with ESMTP id BA2773C00C for ; Tue, 26 Jul 2005 16:20:13 +1000 (EST) Received: by rproxy.gmail.com with SMTP id g11so717406rne for ; Mon, 25 Jul 2005 23:20:12 -0700 (PDT) Received: by 10.38.12.47 with SMTP id 47mr1743303rnl; Mon, 25 Jul 2005 23:20:12 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Mon, 25 Jul 2005 23:20:12 -0700 (PDT) Date: Tue, 26 Jul 2005 11:50:12 +0530 From: Syam Madanapalli Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E5D16E.8080102@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Syam Madanapalli , JinHyeock Choi , Erik Nordmark , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: Syam Madanapalli Message-id: <10e14db205072523207eaf989d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rfwezNfV2TcgUzXq9e+4IpITyP7oR2hlnB0+WkcI+ZqH/V+cL2fH787aUNB39xBcU5BvZa0QjxJCBbFpi8M82Z0mz7l/t8R/K5G7P2csVxd3CaNhTFVjzt38OO80IEIYEEz905dvKoy9NXvhHQIGZ3nY98Gy779v+dx/GbtsTWg= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E59133.6090603@eng.monash.edu.au> <009a01c5919a$3b7435f0$59476c6b@sisodomain.com> <42E5D16E.8080102@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, [cut] > > > > > > What if you get answer 'NO' first? > > Will you check with the prefixes received in the RA? > > This looks better compared just depending on the > > Landmark answer. Otherwise host makes wrong decision. > > > > [cut] > > This question is one of the open issues (9). My personal opinion is > that yes, the host should check the prefixes and if it sees overlap with > the prefixes it has already seen on the link, should decide that link > change has not taken place. I think it is definitely a good idea to check the prefixes in the RA in case of NO answer. -Syam > > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 06:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxN9W-0001yM-R0 for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 06:59:14 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06207 for ; Tue, 26 Jul 2005 06:59:11 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3FB09MXG99PS5Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 20:58:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43BD68000D; Tue, 26 Jul 2005 20:58:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id F03F03C005; Tue, 26 Jul 2005 20:58:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QAw2Q00617 for dna-list; Tue, 26 Jul 2005 20:58:02 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QAw2w00613 for ; Tue, 26 Jul 2005 20:58:02 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3F9MPHTA9APMY7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 20:57:46 +1000 Received: by localhost (Postfix, from userid 510) id C2787AB545; Tue, 26 Jul 2005 20:57:46 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id BC1F64FB06 for ; Tue, 26 Jul 2005 20:57:40 +1000 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7643E69B for ; Tue, 26 Jul 2005 12:57:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 12:57:37 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 12:57:37 +0200 Date: Tue, 26 Jul 2005 12:57:37 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] [Issue X] LinkID v.s. Landmark Prefix Thread-index: AcWRqlRXrBoGdm5CQby77u3MUMse1wAIHRYg Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 26 Jul 2005 10:57:37.0488 (UTC) FILETIME=[D5B9DD00:01C591D0] Content-Transfer-Encoding: 7BIT I'm starting to get so confused in the middle of this LinkID v.s. Landmark Prefix discussion that I'm afraid that I'm loosing my grasp even with the basics. I started wondering what will actually happen in the following scenario: Let there be two routers, 'A' and 'B' and some access points. 'A' advertises prefixes 1 and 2 whereas 'B' advertises prefix 3. After connecting to an AP host, 'N', sends an RS and gets an RA (from 'A'), and finally configures an address (basing on prefix 2). In the case of LinkID 'N' gets the current link-id prefix from the RA, and in the case of Landmark Prefix 'N' chooses a landmark prefix. Let's assume that prefix 1 is both the smallest prefix and the prefix 'N' chooses to be the landmark prefix. If we then say that 'A' stops advertising prefix 2 and zero-lifetime messages disappear, what will be the outcome? I mean, 'N' could attach to another AP, send an RA and learn that it's still in the same network. However, even though 'N' still in the same network, the address 'N' is using (prefix 2 based) is not valid anymore. As I said, I'm so confused that I can't even be sure if this has already been discussed on the list. -- Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 08:11:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOHX-0001j8-QQ for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 08:11:40 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11536 for ; Tue, 26 Jul 2005 08:11:33 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3HTE0DUS8WXL3Z@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 22:11:20 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6BD43AB544; Tue, 26 Jul 2005 22:10:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id F1D834FB05; Tue, 26 Jul 2005 22:10:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QCAUW01477 for dna-list; Tue, 26 Jul 2005 22:10:30 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QCASw01473 for ; Tue, 26 Jul 2005 22:10:28 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3HSITHYE9APDPQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 22:10:16 +1000 Received: by localhost (Postfix, from userid 510) id 94C5EAB543; Tue, 26 Jul 2005 22:10:16 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5F0724FB0D; Tue, 26 Jul 2005 22:10:15 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK800J71HT1VV@mailout1.samsung.com>; Tue, 26 Jul 2005 21:10:13 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK800LWKHSTC0@mmp1.samsung.com>; Tue, 26 Jul 2005 21:10:13 +0900 (KST) Date: Tue, 26 Jul 2005 17:36:13 +0530 From: Subba Reddy Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , JinHyeock Choi , Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <09ac01c591da$7003ea50$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Hi Tero, > > > Assume a link with two routers R1 and R2 and a host H. > > R1 advertises Prefix1 and R2 Prefix2. > > > > R2 stops advertising Prefix2 and starts advertising Prefix3. > > R2 announces the prefix change by sending an RA but > > both R1 and H don't receive it. > > > > Then H happens to change its AP in the same link > > and send an RS with landmark Prefix2. It also happens that > > R2 replies first and sends an RA with NO and Prefix3. > > H falsely assumes a link change. > > But isn't it actually so that in this case the host shouldn't use an > address based on Prefix2 and thus reconfiguration is required (i.e. link > change from host H point of view)? After all, Prefix2 is not anymore > valid. I think, host can not assume link change, if one of the prefixes is invalid. In the case of link change, host deletes all its addresses, prefix table and NC entries, which is not the exact case if prefix changes. In the above example, entries with Prefix1 are still valid. Thanks & Regards, Subba Reddy > > Tero > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 08:29:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOZ2-0006fO-6I for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 08:29:40 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12543 for ; Tue, 26 Jul 2005 08:29:38 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3IG8X68S99PVCE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 22:29:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 365478000E; Tue, 26 Jul 2005 22:28:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DA4B33C012; Tue, 26 Jul 2005 22:28:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QCSQi01692 for dna-list; Tue, 26 Jul 2005 22:28:26 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QCSPw01688 for ; Tue, 26 Jul 2005 22:28:25 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3IFPSIS499PPTR@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 22:28:12 +1000 Received: by localhost (Postfix, from userid 510) id AD456AB543; Tue, 26 Jul 2005 22:28:11 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by curly.its.monash.edu.au (Postfix) with ESMTP id 17F2E4FB09; Tue, 26 Jul 2005 22:28:06 +1000 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EE3DC5FE; Tue, 26 Jul 2005 14:28:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:28:01 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:28:01 +0200 Date: Tue, 26 Jul 2005 14:28:00 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy , JinHyeock Choi , Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] [Issue X] LinkID v.s. Landmark Prefix Thread-index: AcWR2vy/jY91cnFdS7KgfZR5LQO3lgAAdSRA Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 26 Jul 2005 12:28:01.0498 (UTC) FILETIME=[76B01BA0:01C591DD] Content-Transfer-Encoding: 7BIT Hello Subba, > > > Assume a link with two routers R1 and R2 and a host H. > > > R1 advertises Prefix1 and R2 Prefix2. > > > > > > R2 stops advertising Prefix2 and starts advertising Prefix3. > > > R2 announces the prefix change by sending an RA but > > > both R1 and H don't receive it. > > > > > > Then H happens to change its AP in the same link > > > and send an RS with landmark Prefix2. It also happens that > > > R2 replies first and sends an RA with NO and Prefix3. > > > H falsely assumes a link change. > > > > But isn't it actually so that in this case the host shouldn't use an > > address based on Prefix2 and thus reconfiguration is required (i.e. link > > change from host H point of view)? After all, Prefix2 is not anymore > > valid. > > I think, host can not assume link change, if one of the prefixes is > invalid. > In the case of link change, host deletes all its addresses, prefix table > and > NC entries, > which is not the exact case if prefix changes. > > In the above example, entries with Prefix1 are still valid. True. Still, as in the mail I sent earlier, I started wondering how the node knows to "switch" to use an address based on Prefix1? /Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 08:37:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOgH-0007h9-2a for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 08:37:09 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13132 for ; Tue, 26 Jul 2005 08:37:06 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3IQFFGUY8WXA3R@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 22:37:02 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 90B7E8000D; Tue, 26 Jul 2005 22:36:49 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 420CE3C015; Tue, 26 Jul 2005 22:36:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QCaf601801 for dna-list; Tue, 26 Jul 2005 22:36:41 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QCaew01797 for ; Tue, 26 Jul 2005 22:36:41 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3IQ7G6CE8WXA3R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 22:36:39 +1000 Received: by localhost (Postfix, from userid 510) id 23408AB542; Tue, 26 Jul 2005 22:36:39 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3D4454FB07 for ; Tue, 26 Jul 2005 22:36:36 +1000 (EST) Received: by rproxy.gmail.com with SMTP id g11so766545rne for ; Tue, 26 Jul 2005 05:36:35 -0700 (PDT) Received: by 10.38.9.67 with SMTP id 67mr1856481rni; Tue, 26 Jul 2005 05:36:35 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Tue, 26 Jul 2005 05:36:35 -0700 (PDT) Date: Tue, 26 Jul 2005 18:06:35 +0530 From: Syam Madanapalli Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Dna Reply-to: Syam Madanapalli Message-id: <10e14db20507260536df2c66c@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ridkV/LSac33DVbLczdcbwLTyXksewXIFNGyS5eOG4pi+pZ2kFoXv/GYQeh+ZVGh5TcfHJ2bBW/CrEJtq/I7/jtrLnPDQCR1QBhy3LvIIWdV7EpisHbNPb4iuDHdU+VB6A8dfnWFyZFqE3grkw1tvM+qzOlMNuhcFfGvOc2Os5k= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Hi Tero, > I'm starting to get so confused in the middle of this LinkID v.s. > Landmark Prefix discussion that I'm afraid that I'm loosing my grasp > even with the basics. > > I started wondering what will actually happen in the following scenario: > > > Let there be two routers, 'A' and 'B' and some access points. 'A' > advertises prefixes 1 and 2 whereas 'B' advertises prefix 3. After > connecting to an AP host, 'N', sends an RS and gets an RA (from 'A'), > and finally configures an address (basing on prefix 2). In the case of > LinkID 'N' gets the current link-id prefix from the RA, and in the case > of Landmark Prefix 'N' chooses a landmark prefix. Let's assume that > prefix 1 is both the smallest prefix and the prefix 'N' chooses to be > the landmark prefix. > > If we then say that 'A' stops advertising prefix 2 and zero-lifetime > messages disappear, what will be the outcome? I mean, 'N' could attach > to another AP, send an RA and learn that it's still in the same network. Either Landmark or Linkid approaches detect that there is no link change. I think, as far DNA is concerned the job is done. > However, even though 'N' still in the same network, the address 'N' is > using (prefix 2 based) is not valid anymore. This is the host problem and is same problem if the router suddenly stops advertising prefix 2. I looked into 2462bis and found the following text: 5.5.3 Router Advertisement Processing --- d) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical), and the Valid Lifetime is not 0, form an address (and add it to the list) by combining the advertised prefix with the link's interface identifier If the node did not configure the address based on prefix 1 then it should either wait till the prefix 2 life time expiry or if the router does not support forwarding for the prefix 2, an intelligent host can configure new address using prefix 1 based on packet loss. I am not sure about choosing new address based on packet loss. > > As I said, I'm so confused that I can't even be sure if this has already > been discussed on the list. > > -- > Tero > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 08:46:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOpl-0002gf-TT for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 08:46:58 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13992 for ; Tue, 26 Jul 2005 08:46:55 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3J2LZAFC9APLFW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 22:46:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0896F8000D; Tue, 26 Jul 2005 22:46:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B5EF23C014; Tue, 26 Jul 2005 22:46:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QCkbl02057 for dna-list; Tue, 26 Jul 2005 22:46:37 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QCkaw02053 for ; Tue, 26 Jul 2005 22:46:36 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3J2C55PA9APK29@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 22:46:26 +1000 Received: by localhost (Postfix, from userid 510) id E3891AB543; Tue, 26 Jul 2005 22:46:25 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id F1A864FB05; Tue, 26 Jul 2005 22:46:24 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK800JVMJHBVV@mailout1.samsung.com>; Tue, 26 Jul 2005 21:46:23 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IK800458JH1BQ@mmp1.samsung.com>; Tue, 26 Jul 2005 21:46:23 +0900 (KST) Date: Tue, 26 Jul 2005 18:12:22 +0530 From: Subba Reddy Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , JinHyeock Choi , Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <09fb01c591df$7d5da1f0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Hi Tero, > > > But isn't it actually so that in this case the host shouldn't use an > > > address based on Prefix2 and thus reconfiguration is required (i.e. > link > > > change from host H point of view)? After all, Prefix2 is not anymore > > > valid. > > > > I think, host can not assume link change, if one of the prefixes is > > invalid. > > In the case of link change, host deletes all its addresses, prefix > table > > and > > NC entries, > > which is not the exact case if prefix changes. > > > > In the above example, entries with Prefix1 are still valid. > > True. Still, as in the mail I sent earlier, I started wondering how the > node knows to "switch" to use an address based on Prefix1? I think, after some time, H may get RA with Prefix2 lifetimes set to 0 from R2. > > /Tero > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 08:47:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOps-0002jK-1d for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 08:47:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14016 for ; Tue, 26 Jul 2005 08:47:01 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3J2CGR8S8WXLWP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Jul 2005 22:46:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3E075AB543; Tue, 26 Jul 2005 22:46:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E82BD4FB0B; Tue, 26 Jul 2005 22:46:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QCkGd02032 for dna-list; Tue, 26 Jul 2005 22:46:16 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QCkFw02028 for ; Tue, 26 Jul 2005 22:46:15 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3J1SRCZM99PS9L@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Jul 2005 22:46:00 +1000 Received: by localhost (Postfix, from userid 510) id DA9768000D; Tue, 26 Jul 2005 22:45:59 +1000 (EST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by larry.its.monash.edu.au (Postfix) with ESMTP id 34C7C3C015 for ; Tue, 26 Jul 2005 22:45:53 +1000 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EB633A9A; Tue, 26 Jul 2005 14:45:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:45:51 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:45:51 +0200 Date: Tue, 26 Jul 2005 14:45:50 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] [Issue X] LinkID v.s. Landmark Prefix Thread-index: AcWR3qqN3/oxrYhPTu+pdeQmOLKK2QAALrYw Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 26 Jul 2005 12:45:51.0288 (UTC) FILETIME=[F4551B80:01C591DF] Content-Transfer-Encoding: 7BIT > This is the host problem and is same problem if the router suddenly > stops advertising prefix 2. I looked into 2462bis and found the following > text: > > 5.5.3 Router Advertisement Processing > > --- > > d) If the prefix advertised is not equal to the prefix of an address > configured by stateless autoconfiguration already in the list of > addresses associated with the interface (where "equal" means the > two prefix lengths are the same and the first prefix-length bits > of the prefixes are identical), and the Valid Lifetime is not 0, > form an address (and add it to the list) by combining the > advertised prefix with the link's interface identifier > > If the node did not configure the address based on prefix 1 then > it should either wait till the prefix 2 life time expiry or if the router > does not support forwarding for the prefix 2, an intelligent host can > configure new address using prefix 1 based on packet loss. I am > not sure about choosing new address based on packet loss. True. In the middle of this confusion I didn't think that the node could indeed configure itself multiple addresses. It's then up to the source address selection logic to decide which one to use. Thanks, Tero From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 11:00:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQv2-00050T-7f for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:00:32 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26064 for ; Tue, 26 Jul 2005 11:00:29 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NPDPR1O8Y683T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 01:00:07 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 568D2AB545; Wed, 27 Jul 2005 00:59:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 020884FB02; Wed, 27 Jul 2005 00:59:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QEwvc03601 for dna-list; Wed, 27 Jul 2005 00:58:57 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QEwuw03597 for ; Wed, 27 Jul 2005 00:58:56 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3NOHREJS99OHYL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 00:58:49 +1000 Received: by localhost (Postfix, from userid 510) id 975B88000E; Wed, 27 Jul 2005 00:58:49 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by larry.its.monash.edu.au (Postfix) with ESMTP id 875803C00C; Wed, 27 Jul 2005 00:58:46 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j6QEwgr3016019; Tue, 26 Jul 2005 08:58:42 -0600 (MDT) Received: from [129.148.174.193] (dhcp-ubur02-174-193.East.Sun.COM [129.148.174.193]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6QEweHN602796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2005 07:58:41 -0700 (PDT) Date: Tue, 26 Jul 2005 05:55:49 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072521531fba472d@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E632D5.904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E59B91.2050007@sun.com> <92e919fb05072521531fba472d@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > I use flapping in more general case as below. > > When the set of prefixes on a link changes, > there is the possibility of temporary lack of synchronization, i.e. > the nodes on the link (such as routers and hosts) > may have different set of prefixes (on the link) for the time being. > > For example, if the prefix set is {P1, P2} and P3 is added, one would > ideally have all the nodes on the link have the prefix set {P1, P2, P3} > instantly. But due to packet loss, it is possible that one router has the > prefix set {P1, P2} and the other router has {P1, P2, P3} for some time. It isn't only packet loss that is the problem; in a distributed system the notion of "at the same time" isn't a useful concept. We've talked about this in the DT and I referred to the Lamport paper which I think is titled "time, clocks, and the ordering of events in a distributed system". So we shouldn't require that DNA solve a known unsolvable problem :-) Hence I postulated "flapping" as being the more specific case when a single host, instead of seeing a "clean" switch from one prefix set to another, sees the set of prefixes flap back and forth before settling down on the new set. Such flapping is unavoidable for the cases we are interested in (an unknown and changeable set of routers on the link, and a changeable set of prefixes being advertised.) I think it is important that the DNA solution cope gracefully with such flapping. > If hosts check for link change with prefix information, such a lack of > (temporary) synchronization may cause a false link identity detection. From my understanding of CPL, completeRA, landmark, and linkID, none of them have this problem. So which solutions do you refer to with your "may"? > ok. Allow me to clarify this > > In Landmark/ CompleteRA, > when a host receives a solicited RA, > the host check for link change with both > 1) Landmark option with YES/NO bit and > 2) prefixes in the RA. > > If the (solicited) RA carries 1) NO answer and 2) a known prefix, > the host would not assume a link change. > (So in effect, "known prefix" would overrule "NO".) > > Is this right? I think that makes sense. > Routers don't pay attention what other routers advertise as a linkid. > They generate the complete prefix set and pick the linkid prefix for > themselves. You recommended this approach. Blush :-) Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 11:00:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQvC-00059h-UY for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:00:43 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26082 for ; Tue, 26 Jul 2005 11:00:39 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NPJXG1O8Y683T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 01:00:13 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADE56AB547; Wed, 27 Jul 2005 00:59:40 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 541354FB02; Wed, 27 Jul 2005 00:59:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QEx7303624 for dna-list; Wed, 27 Jul 2005 00:59:07 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QEx6w03617 for ; Wed, 27 Jul 2005 00:59:06 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NOLIKQQ8Y683T@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 00:58:54 +1000 Received: by localhost (Postfix, from userid 510) id A25E7AB542; Wed, 27 Jul 2005 00:58:54 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 857954FB06; Wed, 27 Jul 2005 00:58:53 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6QEwnvU020239; Tue, 26 Jul 2005 08:58:49 -0600 (MDT) Received: from [129.148.174.193] (dhcp-ubur02-174-193.East.Sun.COM [129.148.174.193]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6QEwlnG602833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2005 07:58:48 -0700 (PDT) Date: Tue, 26 Jul 2005 06:31:22 -0700 From: Erik Nordmark Subject: [DNA] Re: Flash renumbering In-reply-to: <42E5B15B.7060609@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E63B2A.20800@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <42E5AB7E.6020803@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: >>Based on the comment above, we would also have to forbid the routers >>from using learned prefixes as part of the DNA solution. > > > ... why? The problems becomes worse with wrong state for upto 7 days > only with reassignment. The above comment is only about flash > renumbering which will be corrected within 90 minutes and is not that > bad (A) I guess we need to first agree what goals we are trying to satisfy. I see three possible levels: 1. do nothing special for flash renumbering and immediate reassignment (other than telling network admin to not immediately reassign prefixes) 2. do something so that a host can recover, but it might take a while (e.g., 90 minutes) 3. handle it without any delay Which goal are you attempting for? (And we should ask the same of the whole WG.) I was assuming you were trying for #3, since in some cases you'd recover in zero time. But in order to accomplish #3 we'd also have to remove any notion of using learned prefixes in the routers. And if we want to reach #2 then I don't think we need to affect the efficiency of the normal DNA operations, but instead have some slower sanity check which can recover. > By suggesting that this is suspicious, we are suggesting that the > prefix-lifetime being greater than 90 minutes is not necessarily right - > in effect putting an upper limit on the prefix-lifetime and overruling > 2461. Right? Is it OK to do that? Good question. I wish I had a firm answer. We have an inherent conflict between RFC 2461, which was designed we long default lifetimes just so that a host wouldn't throw away its addresses and prefixes just because a router died for a short time. But our need to quickly and reliably detect movement, if we combine it with the renumbering and reassignment issue, is in conflict. We can't solve both. Hence the best I think we can do is to use the absence of a 'link up' as a way to tell the host to stay in the RFC 2461/62 "stability is important" mode. Note that your suggestion to use a RS to reverify each prefix has the same issue as triggering a sanity check after 90 minutes, since it would also remove a prefix from aggressively than 2461 if the advertising router is temporarily down. > In support of my argument above marked (A), this solution doesn't > address the flash renumbering problem - only flash renumbering with > early reassignment. But, I do agree that this simpler defensive scheme > can handle the low-probability occurance of flash-renumbering with early > reassignment. Flash renumbering without any reassignment wouldn't cause any additional problems for DNA, would it? I think it is only an issue/feature of RFC 2461/62. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 11:01:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQvi-0005Ui-Tf for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:01:14 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26152 for ; Tue, 26 Jul 2005 11:01:11 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NPW5FSS8WXLZJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 01:00:50 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DFA1CAB54B; Wed, 27 Jul 2005 00:59:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 94F8E4FB02; Wed, 27 Jul 2005 00:59:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QEx6103619 for dna-list; Wed, 27 Jul 2005 00:59:06 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QEx6w03612 for ; Wed, 27 Jul 2005 00:59:06 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NOI7MVW8Y683T@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 00:58:51 +1000 Received: by localhost (Postfix, from userid 510) id 0FF9AAB545; Wed, 27 Jul 2005 00:58:50 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 12C554FB07 for ; Wed, 27 Jul 2005 00:58:46 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6QEwjcn022785; Tue, 26 Jul 2005 07:58:46 -0700 (PDT) Received: from [129.148.174.193] (dhcp-ubur02-174-193.East.Sun.COM [129.148.174.193]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6QEwi2u602809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2005 07:58:45 -0700 (PDT) Date: Tue, 26 Jul 2005 06:16:22 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Dna Message-id: <42E637A6.2010802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Tero Kauppinen (JO/LMF) wrote: > Let there be two routers, 'A' and 'B' and some access points. 'A' > advertises prefixes 1 and 2 whereas 'B' advertises prefix 3. After > connecting to an AP host, 'N', sends an RS and gets an RA (from 'A'), > and finally configures an address (basing on prefix 2). In the case of > LinkID 'N' gets the current link-id prefix from the RA, and in the case > of Landmark Prefix 'N' chooses a landmark prefix. Let's assume that > prefix 1 is both the smallest prefix and the prefix 'N' chooses to be > the landmark prefix. > > If we then say that 'A' stops advertising prefix 2 and zero-lifetime > messages disappear, what will be the outcome? I mean, 'N' could attach > to another AP, send an RA and learn that it's still in the same network. > However, even though 'N' still in the same network, the address 'N' is > using (prefix 2 based) is not valid anymore. > > As I said, I'm so confused that I can't even be sure if this has already > been discussed on the list. My tongue in cheek answer is that this is a feature of RFC 2461 :-) Even if there was no DNA, or there was DNA and the host didn't move to a different AP, the host would continue to use prefix2 until it expired. This could be viewed as a feature in RFC 2461 in that even if a router fails and stops advertising a prefix for some time, it will not upset the configuration of the hosts unnecessarily. So when the administrator wants to remove a prefix, she has to explicitly configure the routers to drop the lifetime to zero (either abruptly or gradually). The narrow path I've tried to follow is to realize the above issue, but yet make sure that DNA doesn't get any more confused by this then a host would get that doesn't move. For instance, by looking at how a non-moving host would behave when it attaches to the network. But I might be making the wrong call here, and that in the light of intermittently connected hosts and lossy (radio) links, we should make the reverification of being connected to the same "place" a lot less forgiving. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 11:01:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQvi-0005Uh-LU for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:01:15 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26151 for ; Tue, 26 Jul 2005 11:01:11 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NPQ2RWC8WXLZJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 01:00:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E6B4280012; Wed, 27 Jul 2005 00:59:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 682503C00D; Wed, 27 Jul 2005 00:59:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QEx6F03614 for dna-list; Wed, 27 Jul 2005 00:59:06 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QEx5w03608 for ; Wed, 27 Jul 2005 00:59:05 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3NOI2B9U8WXLZJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 00:58:50 +1000 Received: by localhost (Postfix, from userid 510) id 013BDAB543; Wed, 27 Jul 2005 00:58:49 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 226054FB04; Wed, 27 Jul 2005 00:58:48 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j6QEwi3t014684; Tue, 26 Jul 2005 07:58:44 -0700 (PDT) Received: from [129.148.174.193] (dhcp-ubur02-174-193.East.Sun.COM [129.148.174.193]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6QEwghc602804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2005 07:58:43 -0700 (PDT) Date: Tue, 26 Jul 2005 06:06:48 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050725212266de187e@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E63568.2080503@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > ok. I admit this is a crude one but all I can think of right now. > (Because it's not clear to me how a host base its decision > on CompleteRA, I switch to landmark one.) > > Assume a link with two routers R1 and R2 and a host H. > R1 advertises Prefix1 and R2 Prefix2. > > R2 stops advertising Prefix2 and starts advertising Prefix3. > R2 announces the prefix change by sending an RA but > both R1 and H don't receive it. > > Then H happens to change its AP in the same link > and send an RS with landmark Prefix2. It also happens that > R2 replies first and sends an RA with NO and Prefix3. > H falsely assumes a link change. I assumed that you'd found a case when a host would fail to detect a link change when there was one (which is the case we must avoid); I'm not too worried about there being some corner cases when the host interprets a change in the prefix set as a link change when in fact the host has stayed on the same link. (This would just result in some additional, e.g., MIPv6 signaling. And as Tero pointed out, this more rapid way to react to the prefix being removed might be viewed as a feature.) > The above is not clear to me yet. Allow me a question to help > my understanding. > > Assume a host moves to a different link but fails to receive a > Link Up event Notification. Then the host will not assume a link > change even if it receives a different unsolicted CompleteRA? Let me explain my reasoning. When we worked on CPL we concluded that if the implementation can't reliably deliver a 'link up' event notification from the link layer to the DNA module, then there are cases when the host would end up treating the prefixes from two links as being from one link. Thus for CPL to work reliably, the 'link up' indication in the implementation must be present. Given that we have this, then we have the choice to assume this notification even for the DNA solution, as a way to optimize things. Alternatively, we can try to make the DNA solution be more robust again a missing 'link up' notification. I haven't thought through all the details, but the fact that landmark falls back on prefix comparisons, and linkID handles routers that temporarily disagree on the linkID, might imply that these schemes could be confused when the link up is missing. If that's the case we can't make the solution robust against a missing link up. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jul 26 11:35:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRSl-0005bo-Qx for dna-archive@megatron.ietf.org; Tue, 26 Jul 2005 11:35:23 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28318 for ; Tue, 26 Jul 2005 11:35:20 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR3OXIJS808Y691B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 01:35:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2C29180010; Wed, 27 Jul 2005 01:34:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B0E673C00E; Wed, 27 Jul 2005 01:34:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6QFY6w04098 for dna-list; Wed, 27 Jul 2005 01:34:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6QFY5w04094 for ; Wed, 27 Jul 2005 01:34:05 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR3OWWGMHA99Q00F@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 01:33:51 +1000 Received: by localhost (Postfix, from userid 510) id D89AC8000F; Wed, 27 Jul 2005 01:33:50 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 10E813C00D; Wed, 27 Jul 2005 01:33:47 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6QFXXI9024742; Tue, 26 Jul 2005 11:33:33 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id E69A71E923E; Tue, 26 Jul 2005 11:24:10 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id D78F81E923C; Tue, 26 Jul 2005 11:24:10 -0400 (EDT) Date: Tue, 26 Jul 2005 11:33:05 -0400 From: Sathya Narayanan Subject: Re: [DNA] Re: Flash renumbering In-reply-to: <42E63B2A.20800@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E657B1.5010106@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:14 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <"42 E5AB7E.6020803"@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> <42E63B2A.20800@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Sathya Narayanan wrote: > >>> Based on the comment above, we would also have to forbid the routers >>> from using learned prefixes as part of the DNA solution. >> >> ... why? The problems becomes worse with wrong state for upto 7 days >> only with reassignment. The above comment is only about flash >> renumbering which will be corrected within 90 minutes and is not that >> bad (A) > > I guess we need to first agree what goals we are trying to satisfy. I > see three possible levels: > 1. do nothing special for flash renumbering and immediate reassignment > (other than telling network admin to not immediately reassign prefixes) > 2. do something so that a host can recover, but it might take a while > (e.g., 90 minutes) > 3. handle it without any delay > > Which goal are you attempting for? (And we should ask the same of the > whole WG.) I believe I was going for #2 - not that I clearly thought about it like this ;-) I think leaving it as #1 is bad, #3 is too much and will put unnecessary restrictions on normal operation to address a 'low-probability' problem, hence we are left with #2. >> By suggesting that this is suspicious, we are suggesting that the >> prefix-lifetime being greater than 90 minutes is not necessarily right - >> in effect putting an upper limit on the prefix-lifetime and overruling >> 2461. Right? Is it OK to do that? > > > Good question. I wish I had a firm answer. We have an inherent > conflict between RFC 2461, which was designed we long default > lifetimes just so that a host wouldn't throw away its addresses and > prefixes just because a router died for a short time. > > But our need to quickly and reliably detect movement, if we combine it > with the renumbering and reassignment issue, is in conflict. We can't > solve both. > > Hence the best I think we can do is to use the absence of a 'link up' > as a way to tell the host to stay in the RFC 2461/62 "stability is > important" mode. > > Note that your suggestion to use a RS to reverify each prefix has the > same issue as triggering a sanity check after 90 minutes, since it > would also remove a prefix from aggressively than 2461 if the > advertising router is temporarily down. Agreed. Also, the periodic RA, if it is complete will not include P1 and that can be used as indication also. If N CompleteRA messages are received without the prefix, start getting suspicious. In conclusion, I suggest we create some text based on your suggestion from the previous email as a starting point. >> In support of my argument above marked (A), this solution doesn't >> address the flash renumbering problem - only flash renumbering with >> early reassignment. But, I do agree that this simpler defensive >> scheme can handle the low-probability occurance of flash-renumbering >> with early >> reassignment. > > Flash renumbering without any reassignment wouldn't cause any > additional problems for DNA, would it? I think it is only an > issue/feature of RFC 2461/62. I am not sure what is a issue and what is a feature anymore ;-). But, the 90 minute limitation on the learned prefixes will ensure that the prefix (P2) is removed from the link (link 1). A host that is configured with P2, but not using it as landmark prefix will continue to use the address, until a completeRA gives it a 'hint' - while a host configured with P2 and using P2 for its landmark prefix, will choose a different prefix for its address after a landmark question/answer exchange. Does that make sense? Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 03:46:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxgc1-00074k-G4 for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 03:46:01 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04894 for ; Wed, 27 Jul 2005 03:45:53 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR4MTPXQDO8WXQ0K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 27 Jul 2005 17:45:04 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43284AB54D; Wed, 27 Jul 2005 17:44:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id F05E34FB04; Wed, 27 Jul 2005 17:44:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6R7h5F15513 for dna-list; Wed, 27 Jul 2005 17:43:05 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6R7h4w15509 for ; Wed, 27 Jul 2005 17:43:04 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR4MRA9JFI9APPCO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 27 Jul 2005 17:42:50 +1000 Received: by localhost (Postfix, from userid 510) id BF3EDAB545; Wed, 27 Jul 2005 17:42:50 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by moe.its.monash.edu.au (Postfix) with ESMTP id BDEFE4FB07 for ; Wed, 27 Jul 2005 17:42:48 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so191731nzd for ; Wed, 27 Jul 2005 00:42:47 -0700 (PDT) Received: by 10.36.56.6 with SMTP id e6mr662530nza; Wed, 27 Jul 2005 00:42:47 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 27 Jul 2005 00:42:47 -0700 (PDT) Date: Wed, 27 Jul 2005 16:42:47 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E632D5.904@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050727004264c293e@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z0iYUsNQoau4CSmqJbBe+GNAN5g4VVSCLmBL4wFqAwPYf6I4sMLnRbpN8sRo3JA65OsRyK8B2npFOU0/Klfh4k0KtPRmrht/aiTafYpskdVmhEqLbuFE4Dc/a7aS5/kpfX2JIbhUJ6m7flrGDr5jPVDhkiMmJu6npf9enCEljq4= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E59B91.2050007@sun.com> <92e919fb05072521531fba472d@mail.gmail.com> <42E632D5.904@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > > I use flapping in more general case as below. > > > > When the set of prefixes on a link changes, > > there is the possibility of temporary lack of synchronization, i.e. > > the nodes on the link (such as routers and hosts) > > may have different set of prefixes (on the link) for the time being. > > > > For example, if the prefix set is {P1, P2} and P3 is added, one would > > ideally have all the nodes on the link have the prefix set {P1, P2, P3} > > instantly. But due to packet loss, it is possible that one router has the > > prefix set {P1, P2} and the other router has {P1, P2, P3} for some time. > > It isn't only packet loss that is the problem; in a distributed system > the notion of "at the same time" isn't a useful concept. We've talked > about this in the DT and I referred to the Lamport paper which I think > is titled "time, clocks, and the ordering of events in a distributed > system". > > So we shouldn't require that DNA solve a known unsolvable problem :-) ok. I don't think we can remove such a temporary "Lack of Synchronization" entirely. RA travels with the speed of light, so to deliver RA to all the routers "at the same time", we may need to study "Theory of Relativity". :-) > Hence I postulated "flapping" as being the more specific case when a > single host, instead of seeing a "clean" switch from one prefix set to > another, sees the set of prefixes flap back and forth before settling > down on the new set. ok. From now on, I will use the term "flapping" only in the sense you describes. For the more general case I presented, I will use the term 'LOS (Lack of Synchronization). Is it ok? (The term "link" gave me enough trouble already. I don't want another Jason problem arising from ambiguous terms.) > Such flapping is unavoidable for the cases we are > interested in (an unknown and changeable set of routers on the link, and > a changeable set of prefixes being advertised.) > > I think it is important that the DNA solution cope gracefully with such > flapping. ok. I think it's also important that DNA solution cope gracefully with more general case of temporary LOS (Lack of Synchronization). If DNA solution can deal with LOS, I think it can deal with flapping automatically. > > If hosts check for link change with prefix information, such a lack of > > (temporary) synchronization may cause a false link identity detection. > > From my understanding of CPL, completeRA, landmark, and linkID, none of > them have this problem. So which solutions do you refer to with your "may"? I guess I presented one problem with Landmark in the other mail. :-) > > ok. Allow me to clarify this > > > > In Landmark/ CompleteRA, > > when a host receives a solicited RA, > > the host check for link change with both > > 1) Landmark option with YES/NO bit and > > 2) prefixes in the RA. > > > > If the (solicited) RA carries 1) NO answer and 2) a known prefix, > > the host would not assume a link change. > > (So in effect, "known prefix" would overrule "NO".) > > > > Is this right? > > I think that makes sense. ok. I think the above is a non-trivial change for Link Identification criteria, so needs to be reflected in the Landmark/ CompleteRA draft. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 10:23:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxmom-0007DZ-RF for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 10:23:35 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01943 for ; Wed, 27 Jul 2005 10:23:29 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR50QGEX1Q8WXXKX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 00:23:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F025AB545; Thu, 28 Jul 2005 00:23:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E9EBE4FB05; Thu, 28 Jul 2005 00:23:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6REMN420091 for dna-list; Thu, 28 Jul 2005 00:22:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6REMMw20087 for ; Thu, 28 Jul 2005 00:22:22 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR50PBI2WQ9APMCL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 00:22:07 +1000 Received: by localhost (Postfix, from userid 510) id 80C83AB542; Thu, 28 Jul 2005 00:22:07 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 88C274FB03; Thu, 28 Jul 2005 00:22:06 +1000 (EST) Date: Tue, 26 Jul 2005 12:12:40 -0700 From: James Kempf Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , Gregory Daley , Dna Message-id: <04fa01c592b6$8d789400$626015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> Content-Transfer-Encoding: 7BIT ok. I admit this is a crude one but all I can think of right now. (Because it's not clear to me how a host base its decision on CompleteRA, I switch to landmark one.) Assume a link with two routers R1 and R2 and a host H. R1 advertises Prefix1 and R2 Prefix2. R2 stops advertising Prefix2 and starts advertising Prefix3. R2 announces the prefix change by sending an RA but both R1 and H don't receive it. Then H happens to change its AP in the same link and send an RS with landmark Prefix2. It also happens that R2 replies first and sends an RA with NO and Prefix3. H falsely assumes a link change. jak>> So what is the realistic probability of this actually happening? One could use this same kind of search for corner cases to shoot down oDAD, yet it is on the verge of becoming a PS RFC and we are planning on using it for DNA. jak From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 10:29:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxmv0-0000EG-F2 for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 10:29:58 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02503 for ; Wed, 27 Jul 2005 10:29:55 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR50Y98HJC99PZOU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 00:29:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B5165AB543; Thu, 28 Jul 2005 00:29:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 636494FB0B; Thu, 28 Jul 2005 00:29:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RETEV20181 for dna-list; Thu, 28 Jul 2005 00:29:14 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RETDw20177 for ; Thu, 28 Jul 2005 00:29:13 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR50XRQYQ68WXWU0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 00:28:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35DA2AB542; Thu, 28 Jul 2005 00:28:56 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 18BAF4FB07; Thu, 28 Jul 2005 00:28:56 +1000 (EST) Received: from [129.6.60.72] by mail-store-2.its.monash.edu.au (mshttpd); Wed, 27 Jul 2005 10:28:56 -0400 Date: Wed, 27 Jul 2005 10:28:56 -0400 From: Greg Daley Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , Syam Madanapalli , James Kempf , Dna Message-id: <6b464c6b4c2a.6b4c2a6b464c@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Erik, ----- Original Message ----- From: Erik Nordmark Date: Monday, July 25, 2005 10:24 pm Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. Landmark Prefix > Greg Daley wrote: > > > In CPL which is host (only) based, the timers are on the host, > and > > protect > > the host from long term damage, by removing unupdated > information > > at the host. > > > > Even with the most broken readvartisement scheme for stale > information,> the damage could only occur for a maximum: > > (Router out-of-date timer + Host out-of-date timer) > > Are you talking about RFC 2461, or are you talking about a > proposal for > how CPL could work? Sorry I think I changed topics in mid e-mail, and referred to CPL as an example of particular behaviour, before going back to my main topic. The inequality refers to modified advertisement schemes (those which readvertise learnt information), rather than CPL. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 10:55:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnJr-0008TS-Th for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 10:55:40 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04635 for ; Wed, 27 Jul 2005 10:55:35 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR51TKKWXK8Y6GSX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 00:54:43 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 65DB88000F; Thu, 28 Jul 2005 00:54:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0EE593C003; Thu, 28 Jul 2005 00:54:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6REsNZ20531 for dna-list; Thu, 28 Jul 2005 00:54:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6REsMw20527 for ; Thu, 28 Jul 2005 00:54:22 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR51T0UJ6K99PYYZ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 00:54:08 +1000 Received: by localhost (Postfix, from userid 510) id 1C977AB543; Thu, 28 Jul 2005 00:54:08 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0A05A4FB07; Thu, 28 Jul 2005 00:54:06 +1000 (EST) Date: Wed, 27 Jul 2005 07:54:02 -0700 From: James Kempf Subject: [DNA] Re: Flash renumbering Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , Dna Message-id: <05d001c592bb$08894280$626015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <42E5AB7E.6020803@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> <42E63B2A.20800@sun.com> Content-Transfer-Encoding: 7BIT Erik, I agree with using absence of link up to detect renumbering. Also, I prefer #1, unless one of the other solutions can be done without introducing additional complexity into the protocol. jak ----- Original Message ----- From: "Erik Nordmark" To: "Sathya Narayanan" Cc: "JinHyeock Choi" ; "Brett Pentland" ; ; "Syam Madanapalli" ; "James Kempf" ; "Dna" Sent: Tuesday, July 26, 2005 6:31 AM Subject: Re: Flash renumbering > Sathya Narayanan wrote: > > >>Based on the comment above, we would also have to forbid the routers > >>from using learned prefixes as part of the DNA solution. > > > > > > ... why? The problems becomes worse with wrong state for upto 7 days > > only with reassignment. The above comment is only about flash > > renumbering which will be corrected within 90 minutes and is not that > > bad (A) > > I guess we need to first agree what goals we are trying to satisfy. I > see three possible levels: > 1. do nothing special for flash renumbering and immediate reassignment > (other than telling network admin to not immediately reassign prefixes) > 2. do something so that a host can recover, but it might take a while > (e.g., 90 minutes) > 3. handle it without any delay > > Which goal are you attempting for? (And we should ask the same of the > whole WG.) > > I was assuming you were trying for #3, since in some cases you'd recover > in zero time. But in order to accomplish #3 we'd also have to remove > any notion of using learned prefixes in the routers. > > And if we want to reach #2 then I don't think we need to affect the > efficiency of the normal DNA operations, but instead have some slower > sanity check which can recover. > > > By suggesting that this is suspicious, we are suggesting that the > > prefix-lifetime being greater than 90 minutes is not necessarily right - > > in effect putting an upper limit on the prefix-lifetime and overruling > > 2461. Right? Is it OK to do that? > > Good question. I wish I had a firm answer. We have an inherent conflict > between RFC 2461, which was designed we long default lifetimes just so > that a host wouldn't throw away its addresses and prefixes just because > a router died for a short time. > > But our need to quickly and reliably detect movement, if we combine it > with the renumbering and reassignment issue, is in conflict. We can't > solve both. > > Hence the best I think we can do is to use the absence of a 'link up' as > a way to tell the host to stay in the RFC 2461/62 "stability is > important" mode. > > Note that your suggestion to use a RS to reverify each prefix has the > same issue as triggering a sanity check after 90 minutes, since it would > also remove a prefix from aggressively than 2461 if the advertising > router is temporarily down. > > > In support of my argument above marked (A), this solution doesn't > > address the flash renumbering problem - only flash renumbering with > > early reassignment. But, I do agree that this simpler defensive scheme > > can handle the low-probability occurance of flash-renumbering with early > > reassignment. > > Flash renumbering without any reassignment wouldn't cause any additional > problems for DNA, would it? I think it is only an issue/feature of RFC > 2461/62. > > Erik > > From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 11:17:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnfL-0007Y6-Ud for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 11:17:53 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06713 for ; Wed, 27 Jul 2005 11:17:47 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR52LIZJEO99PWO6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 01:16:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2DE69AB543; Thu, 28 Jul 2005 01:16:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C80084FB02; Thu, 28 Jul 2005 01:16:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RFG9420796 for dna-list; Thu, 28 Jul 2005 01:16:09 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RFG8w20792 for ; Thu, 28 Jul 2005 01:16:08 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR52KX88I88Y6HO9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 01:15:51 +1000 Received: by localhost (Postfix, from userid 510) id B61D38000E; Thu, 28 Jul 2005 01:15:50 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by larry.its.monash.edu.au (Postfix) with ESMTP id C0A743C014 for ; Thu, 28 Jul 2005 01:15:48 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so282342nzd for ; Wed, 27 Jul 2005 08:15:47 -0700 (PDT) Received: by 10.36.71.2 with SMTP id t2mr1019866nza; Wed, 27 Jul 2005 08:15:46 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 27 Jul 2005 08:15:46 -0700 (PDT) Date: Thu, 28 Jul 2005 00:15:46 +0900 From: JinHyeock Choi Subject: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <42E63568.2080503@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0507270815223243ee@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JjFhwLV2oXEPWOrnEFB4wU6D1GJv8TY5y0dbxyEAGI1QhW9D7j9y5DM3I2QMKD4kMtGAium8A87CP+Hpt7lvlVbqlLopqmCgWWcBW127a2q6KrtX9LoGEC2SpTCd3HnCnSQASO0aMbm6ICw7/ujnsW6YojkhZDMBrLHr3FieXBQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E63568.2080503@sun.com> Content-Transfer-Encoding: 7BIT Erik > > The above is not clear to me yet. Allow me a question to help > > my understanding. > > > > Assume a host moves to a different link but fails to receive a > > Link Up event Notification. Then the host will not assume a link > > change even if it receives a different unsolicted CompleteRA? > > Let me explain my reasoning. > > When we worked on CPL we concluded that if the implementation can't > reliably deliver a 'link up' event notification from the link layer to > the DNA module, then there are cases when the host would end up treating > the prefixes from two links as being from one link. > Thus for CPL to work reliably, the 'link up' indication in the > implementation must be present. > > Given that we have this, then we have the choice to assume this > notification even for the DNA solution, as a way to optimize things. > Alternatively, we can try to make the DNA solution be more robust again > a missing 'link up' notification. I took the latter approach. (that may be the road less traveled. :-)) Allow me to explain my reasoning too. In the previous CPL draft, we wrote that Thus we think the prefix-based approach has a stronger assumption here than the Link Identifier-based approach, because the latter can operate reliably without any link-layer event notifications [14]. though the current version omits this. So I tried to build 'linkid prefix' scheme as independent of Link UP event notification as possible. I avoided to rely on Link UP. For example, with Link UP notification, Linkid scheme may work to detect link change from non-supporting link to supporting one as below. Assume a host is at a non-supporting link. Then it doesn't have a linkid prefix. When it moves to a supporting link, it will see a new linkid. The host may assume a link change upon receiving this new linkid. But the current draft mandates that the host doesn't make any decision becuase there is the other possibility that the host is at the same link but a router on the link becomes a DNA router and starts advertising the linkid. I contemplated the idea to distinguish the above two cases with Link UP indication but gave it up because I thought the simplicity and less assumption is better. > I haven't thought through all the details, but the fact that landmark > falls back on prefix comparisons, and linkID handles routers that > temporarily disagree on the linkID, might imply that these schemes could > be confused when the link up is missing. If that's the case we can't > make the solution robust against a missing link up. We intended Linkid scheme not to depend on Link UP and the scheme is supposed to work rubustly even without any Link UP notificaiton. We can't deny the possibility of confusion (even Titanic sank in its maiden voyage :-)) but can't find the example yet. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 12:34:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxorW-0008Gk-UO for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 12:34:35 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12599 for ; Wed, 27 Jul 2005 12:34:26 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR559ZDF5S99PYN7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 02:33:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E20E88000E; Thu, 28 Jul 2005 02:33:18 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 825F73C00D; Thu, 28 Jul 2005 02:33:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RGWoK21727 for dna-list; Thu, 28 Jul 2005 02:32:50 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RGWnw21723 for ; Thu, 28 Jul 2005 02:32:49 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5597NN4W9APN7X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 02:32:41 +1000 Received: by localhost (Postfix, from userid 510) id AEEA98000D; Thu, 28 Jul 2005 02:32:41 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id 93FC63C00D; Thu, 28 Jul 2005 02:32:40 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6RGWavU025277; Wed, 27 Jul 2005 10:32:36 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6RGWRkw614686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2005 09:32:31 -0700 (PDT) Date: Tue, 26 Jul 2005 16:40:26 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: Flash renumbering In-reply-to: <42E657B1.5010106@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E6C9EA.9080703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <"42 E5AB7E.6020803"@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> <42E63B2A.20800@sun.com> <42E657B1.5010106@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > I believe I was going for #2 - not that I clearly thought about it like > this ;-) > > I think leaving it as #1 is bad, #3 is too much and will put unnecessary > restrictions on normal operation to address a 'low-probability' problem, > hence we are left with #2. FWIW I'm of the same opinion. > Agreed. Also, the periodic RA, if it is complete will not include P1 and > that can be used as indication also. If N CompleteRA messages are > received without the prefix, start getting suspicious. That is an interesting idea, because when there is intermittent connectivity and packet loss, it is more likely to occur for the hosts than for router-to-router communication (assuming the traditional deployment of routers on a wired network - a wireless mesh of routers would potentially change this). Thus the router not hearing a prefix from another router for 1.5 hours is a more reasonable indication that the prefix can be dropped, than a host not hearing it for 1.5 hours. But what would we do in the case when all the prefixes don't fit in one RA hence the complete bit can not be set? > In conclusion, I suggest we create some text based on your suggestion > from the previous email as a starting point. ok Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 14:05:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxqHM-0003cH-0C for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 14:05:20 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18947 for ; Wed, 27 Jul 2005 14:05:12 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR58HGM1EQ8WXYPP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 04:05:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A42CAB544; Thu, 28 Jul 2005 04:04:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id CD46C4FB05; Thu, 28 Jul 2005 04:04:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RI4Md23003 for dna-list; Thu, 28 Jul 2005 04:04:22 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RI4Gw22997 for ; Thu, 28 Jul 2005 04:04:17 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR58GEFGOY99PTJV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 04:04:00 +1000 Received: by localhost (Postfix, from userid 510) id E1651AB545; Thu, 28 Jul 2005 04:03:59 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 87BF94FB09; Thu, 28 Jul 2005 04:03:57 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6RI3ePp022898; Wed, 27 Jul 2005 14:03:40 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 283911E819B; Wed, 27 Jul 2005 13:54:17 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 199B61E8184; Wed, 27 Jul 2005 13:54:17 -0400 (EDT) Date: Wed, 27 Jul 2005 14:03:13 -0400 From: Sathya Narayanan Subject: Re: [DNA] Re: Flash renumbering In-reply-to: <42E6C9EA.9080703@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E7CC61.5090506@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <"42 E5AB7E.6020803"@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> <42E63B2A.20800@sun.com> <42E657B1.5010106@Research.Panasonic.COM> <42E6C9EA.9080703@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Sathya Narayanan wrote: > >> I believe I was going for #2 - not that I clearly thought about it like >> this ;-) >> >> I think leaving it as #1 is bad, #3 is too much and will put unnecessary >> restrictions on normal operation to address a 'low-probability' problem, >> hence we are left with #2. > > FWIW I'm of the same opinion. > >> Agreed. Also, the periodic RA, if it is complete will not include P1 and >> that can be used as indication also. If N CompleteRA messages are >> received without the prefix, start getting suspicious. > > That is an interesting idea, because when there is intermittent > connectivity and packet loss, it is more likely to occur for the hosts > than for router-to-router communication (assuming the traditional > deployment of routers on a wired network - a wireless mesh of routers > would potentially change this). > > Thus the router not hearing a prefix from another router for 1.5 hours > is a more reasonable indication that the prefix can be dropped, than a > host not hearing it for 1.5 hours. > > But what would we do in the case when all the prefixes don't fit in > one RA hence the complete bit can not be set? I know this is always an issue. But, isn't it a general problem about CompleteRA which we need to think about either way? I don't remember why we decided to remove the #prefixes field from the DNAO. I thought most of us felt that this field will help out with being able to send the prefixes in two or more RA if they don't fit in a single RA. So, let me bring #prefixes back instead of the complete bit, here is what I propose when the prefixes don't fit in one RA: 1) Divide the prefixes into groups with atleast one common prefix so that each group will fit in a single RA. 2) Set the #prefixes field in the DNAO to the total number of prefixes (The semantics for this is "This is the number of prefixes on the link *I* know of"). >> In conclusion, I suggest we create some text based on your suggestion >> from the previous email as a starting point. > > ok So, do you want me to write it? Brett? - Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 15:03:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrBO-0006vc-MI for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 15:03:10 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23864 for ; Wed, 27 Jul 2005 15:03:07 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5AIIVAT499PRXY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 05:03:04 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 394A4AB545; Thu, 28 Jul 2005 05:02:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E0FB04FB03; Thu, 28 Jul 2005 05:02:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RJ2cv23764 for dna-list; Thu, 28 Jul 2005 05:02:38 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RJ2bw23760 for ; Thu, 28 Jul 2005 05:02:37 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5AHS7Z6Y9AOOD3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 05:02:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BF1BE8000D; Thu, 28 Jul 2005 05:02:22 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id A95953C011; Thu, 28 Jul 2005 05:02:22 +1000 (EST) Received: from [129.6.60.72] by mail-store-2.its.monash.edu.au (mshttpd); Wed, 27 Jul 2005 15:02:22 -0400 Date: Wed, 27 Jul 2005 15:02:22 -0400 From: Greg Daley Subject: Re: [DNA] Re: Flash renumbering Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <6b1f156b76ea.6b76ea6b1f15@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Sathya, ----- Original Message ----- [cut] > > > > But what would we do in the case when all the prefixes don't fit in > > one RA hence the complete bit can not be set? > > I know this is always an issue. But, isn't it a general problem about > CompleteRA which we need to think about either way? > > I don't remember why we decided to remove the #prefixes field from the > DNAO. I thought most of us felt that this field will help out with > being able to send the prefixes in two or more RA if they don't > fit in a > single RA. > > So, let me bring #prefixes back instead of the complete bit, here is > what I propose when the prefixes don't fit in one RA: > 1) Divide the prefixes into groups with atleast one common prefix so > that each group will fit in a single RA. > 2) Set the #prefixes field in the DNAO to the total number of prefixes > (The semantics for this is "This is the number of prefixes on the link > *I* know of"). The number of prefixes isn't useful, and may be misleading, if prefixes are substituted 1 for 1 on a link. The messages will occur with time in between them. So it may not be possible to distinguish exactly that the RAs in one set unioned with those in another constitute all the prefixes on the link, at the time of the second advertisement. (This approximation is OK for CPL, which has a timeout on prefixes, but it isn't exact in this case, and there's no inferred completeness from the numbers of prefixes provided). The numbers of prefixes we're discussing here are quite large: For RAs with 500 octets remaining for advertisement, if PIOs are transmitted in this space, 15 PIOs will fit. If PIOs are outnumbered by LPIOs 1:5, then 4 PIOs and 20 LPIOs will fit into the RA. So changing the operations of DNA for such large numbers of prefixes seems unnecessary, especially if there is prefix overlap, since CPL is available. It may be possible to suggest that a common prefix is sent in the RAs (I thought we already did that in DNA Routers though). Later if there are likely to be large numbers of prefixes on a link, it may be possible to write another document, which provides better performance in those cases. I don't really think this is necessary though. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 15:16:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrNz-0002by-Pa for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 15:16:12 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25287 for ; Wed, 27 Jul 2005 15:16:08 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5AYQJNZY9APPB8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 05:16:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BFD16AB543; Thu, 28 Jul 2005 05:16:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7EBAF4FB09; Thu, 28 Jul 2005 05:16:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RJFaO23934 for dna-list; Thu, 28 Jul 2005 05:15:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RJFYw23930 for ; Thu, 28 Jul 2005 05:15:34 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR5AY1W6968WXXQN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 05:15:31 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B5A5DAB54A; Thu, 28 Jul 2005 05:15:29 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 96F8E4FB02; Thu, 28 Jul 2005 05:15:29 +1000 (EST) Received: from [129.6.60.72] by mail-store-2.its.monash.edu.au (mshttpd); Wed, 27 Jul 2005 15:15:29 -0400 Date: Wed, 27 Jul 2005 15:15:29 -0400 From: Greg Daley Subject: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <6b8cc96b2874.6b28746b8cc9@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, Please don't be shocked, I may agree with you in this e-mail. ----- Original Message ----- [cut] > > I haven't thought through all the details, but the fact that > landmark > > falls back on prefix comparisons, and linkID handles routers > that > > temporarily disagree on the linkID, might imply that these > schemes could > > be confused when the link up is missing. If that's the case we > can't > > make the solution robust against a missing link up. > > We intended Linkid scheme not to depend on Link UP and the > scheme is supposed to work rubustly even without any Link UP > notificaiton. I'd prefer something which could work even if the host's driver wasn't able to provide Link Up indications. While my host implementation basically assumes them, not all drivers and operating systems do (or even will) support them. In some media (for example, CDMA-like media) it may be difficult to distinguish when one base station is "UP" or not, since multiple base-stations are visible. So understanding if the schemes would work without indications is useful, if this is a goal. > We can't deny the possibility of confusion (even Titanic > sank in its maiden voyage :-)) but can't find the example yet. I've got a case where all 3 (CompleteRA, Landmark, LinkID) schemes fail, and I've written it out 3 times, with just the names of the schemes changed (It is a corner case though). At the moment I'm not able to connect my own computer to my visited network, but will post it for everyone, when able. It's not meant to prove any scheme is better than another, just that all the schemes are fallible. Some of the simple safety measures proposed would recover any of the solutions (Aim #2 from the other thread), and some would limit the possibility of it occurring (Recommendations for flash renumbering). These may be sufficient, with or without advertisement of the old LinkID. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 20:22:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxwAB-0000SW-KV for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 20:22:16 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20500 for ; Wed, 27 Jul 2005 20:22:12 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR5JO5MDVG8WY0WN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 09:26:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 237E2AB548; Thu, 28 Jul 2005 09:25:36 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D683A4FB02; Thu, 28 Jul 2005 09:25:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RNPWR26977 for dna-list; Thu, 28 Jul 2005 09:25:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RNPVw26973 for ; Thu, 28 Jul 2005 09:25:31 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5JNXR0049APPWB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 09:25:25 +1000 Received: by localhost (Postfix, from userid 510) id C5771AB545; Thu, 28 Jul 2005 09:25:25 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by moe.its.monash.edu.au (Postfix) with ESMTP id AE3A04FB04 for ; Thu, 28 Jul 2005 09:25:24 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so376140nzd for ; Wed, 27 Jul 2005 16:25:23 -0700 (PDT) Received: by 10.36.56.6 with SMTP id e6mr1390244nza; Wed, 27 Jul 2005 16:25:23 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Wed, 27 Jul 2005 16:25:23 -0700 (PDT) Date: Thu, 28 Jul 2005 08:25:23 +0900 From: JinHyeock Choi Subject: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <6b8cc96b2874.6b28746b8cc9@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050727162576ad1fd4@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NvejKsVj+WGijXpJSnnsc0OX9f0NiWG0Gmk5o0l9/d3Yw/agv4xsI58evpy0pCcNOvR1v/P6BGh+ufmvwDDV7civ+Oo5FgeIDSB6VWAeFOOl/VX/YJEue8guXovCm7CT7t+X48YwYc8jSa4WyK3LU2T5LQQJWZ0V4wEIUEYQd8s= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <6b8cc96b2874.6b28746b8cc9@monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg > Please don't be shocked, I may agree with > you in this e-mail. What a nice shock! I hope to have such a surprise many many more times that it won't be a surprise any longer. :-) > > We intended Linkid scheme not to depend on Link UP and the > > scheme is supposed to work rubustly even without any Link UP > > notificaiton. > > I'd prefer something which could work even if the host's > driver wasn't able to provide Link Up indications. > > While my host implementation basically assumes them, > not all drivers and operating systems do (or even will) > support them. > > In some media (for example, CDMA-like media) it may be > difficult to distinguish when one base station is "UP" > or not, since multiple base-stations are visible. > > So understanding if the schemes would work without > indications is useful, if this is a goal. ok. > > We can't deny the possibility of confusion (even Titanic > > sank in its maiden voyage :-)) but can't find the example yet. > > I've got a case where all 3 (CompleteRA, Landmark, LinkID) > schemes fail, and I've written it out 3 times, with just > the names of the schemes changed (It is a corner case though). > > At the moment I'm not able to connect my own computer to > my visited network, but will post it for everyone, when able. ok. We'd like to see the case. It may show us the way for improvement. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 20:22:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxwAE-0000Sj-CI for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 20:22:20 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20517 for ; Wed, 27 Jul 2005 20:22:14 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR5JI8MZH88Y6JHX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 09:21:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 043A9AB544; Thu, 28 Jul 2005 09:20:50 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B83104FB03; Thu, 28 Jul 2005 09:20:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6RNKCv26902 for dna-list; Thu, 28 Jul 2005 09:20:12 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6RNKBw26898 for ; Thu, 28 Jul 2005 09:20:11 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5JHF1OBM9APQA4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 09:20:10 +1000 Received: by localhost (Postfix, from userid 510) id 70B2B8000E; Thu, 28 Jul 2005 09:20:10 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 480CB3C00E for ; Thu, 28 Jul 2005 09:20:07 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DxvBz-000JgM-VG for dna@eng.monash.edu.au; Wed, 27 Jul 2005 19:20:04 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6RNK1V06016 for ; Wed, 27 Jul 2005 16:20:02 -0700 Date: Wed, 27 Jul 2005 16:20:01 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Proposed Resolution to DNAv4 Issue 30 X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT The text of DNAv4 issue 30 is enclosed below. This and other DNAv4 issues are tracked on the DNAv4 Issue page, located at: http://www.drizzle.com/~aboba/DNA/ A version of the document with the proposed changes applied is available here: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-14.txt The proposed resolution is as follows: In Section 1.2, change the definition of MLN to: "Most Likely Networks (MLNs) The attached network(s) determined by the host to be most likely." Change Section 2, 2.1, 2.2 and 2.3 to the following: "2. Overview DNAv4 consists of three phases: determination of the Most Likely Networks (MLNs), reachability testing, and IPv4 address acquisition. On connecting to a new point of attachment, the host responds to a "Link Up" indication from the link layer by carrying out the DNAv4 procedure. Based on the networks that the host has most recently connected to, as well as hints available from the link and Internet layers, the host determines the "Most Likely Network(s)" (MLNs) and determines whether it has an operable IPv4 configuration associated with each of them. If the host believes that it has an operable IPv4 configuration on a MLN, it performs a reachability test in order to confirm that configuration. The reachability test is designed to verify bi- directional connectivity to the default gateway(s) on the MLN. If the reachability test is successful, the host SHOULD continue to use an operable routable IPv4 address, without needing to re-acquire it, thereby allowing the host to bypass DHCPv4 as well as Duplicate Address Detection (DAD). If the host believes that it has attached to a network on which it has no operable IPv4 configuration, or if the reachability test fails, then the host attempts to obtain an IPv4 configuration using DHCPv4. Since DNAv4 represents a performance optimization, it is important to avoid compromising robustness. In some circumstances, DNAv4 may result in a host successfully verifying an existing IPv4 configuration where attempting to obtain configuration via DHCPv4 would fail (such as when the DHCPv4 server is down). To improve robustness, this document suggests that hosts behave conservatively with respect to assignment of IPv4 Link-Local addresses [RFC3927], configuring them only in situations in which they can do no harm. Experience has shown that IPv4 Link-Local addresses are often assigned inappropriately, compromising both performance and connectivity. Where the host tests reachability only to a single MLN, the performance of DNAv4 is to some extent dependent on the reliability of the hints provided to the client. However, the host will ultimately determine the correct IPv4 configuration even in the presence of misleading hints. Where reachability test(s) fail a timeout will occur, after which the host will eventually obtain the correct configuration using DHCPv4, albeit with a performance penalty. Where there is more than one MLN, the host can test reachability to the MLN(s) in serial or in parallel. An implementation can also attempt to obtain IPv4 configuration via DHCPv4 in parallel with one or more reachability tests, with the host using the first answer returned. These optimizations reduce the reliance on link and Internet layer hints, which may not be present or may be misleading. Attempting to obtain IPv4 configuration via DHCPv4 in parallel is particularly valuable in implementations that only test reachability of a single MLN. Since confirming failure of a reachability test requires a timeout, mistakes are costly and therefore sending a DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131] Section 3.2 and 4.3.2 may complete more quickly than the reachability test. DNAv4 does not increase the likelihood of an address conflict. The DNAv4 procedure is only carried out when the host has an operable IPv4 configuration on one or more MLNs, implying that duplicate address detection has previously been completed. Restrictions on sending ARP Requests and Responses are described in Section 2.2.1. 2.1. Most Likely Networks (MLNs) In order to determine the MLN(s), it is assumed that the host saves to stable storage parameters relating to the networks it connects to: [1] The IPv4 and MAC address of the default gateway(s) on each network. [2] The link type, such as whether the link utilizes Ethernet, or 802.11 adhoc or infrastructure mode. [3] Link and Internet layer hints associated with each network. For details, see Appendix A. Appendix A discusses hints useful for the determination of the MLN(s). By matching received hints against network parameters previously stored, an implementation testing reachability to a single MLN can make an an educated guess as to which network it has attached to. Alternatively, an implementation that simultaneously tests reachability to multiple MLNs can select them solely based on the networks it has most recently connected to, in which case it may not be necessary to consult hints. 2.2. Reachability Test If the host has an operable routable IPv4 address on a MLN, a host conforming to this specification SHOULD perform a reachability test, in order to confirm that it is connected to a network on which it has an operable routable IPv4 address. The host skips the reachability test for a MLN if any of the following conditions are true: [a] The host does not have an operable routable IPv4 address on a MLN. In this case, the reachability test cannot confirm that the host has an operable routable IPv4 address, so completing the reachability test would serve no purpose. A host MUST NOT use the reachability test to confirm configuration of an IPv4 Link-Local address. [b] The host does not have information on the default gateway(s) on a MLN. In this case, insufficient information is available to carry out the reachability test. [c] If secure detection of network attachment is required. The reachability test utilizes ARP which is insecure, whereas DHCPv4 can be secured via DHCPv4 authentication, described in [RFC3118]. See Section 5 for details. [d] If the default gateway address is an IPv4 Link-Local address. In this case, it is possible that the reachability test could be misinterpreted as indication of an address conflict. See [RFC3927] Section 2.2.1 for details. For a particular MLN, the host MAY test the reachability of the primary default gateway, or it MAY test reachability of the primary and secondary default gateways in series or in parallel. In order to ensure configuration validity, the host SHOULD only configure default gateway(s) which pass the reachability test. 2.3. IPv4 Address Acquisition If the host has an operable routable IPv4 address on one or more MLNs, but the reachability test(s) fail, the host SHOULD attempt to revalidate the configuration by entering the INIT-REBOOT state, and sending a DHCPREQUEST to the broadcast address as specified in [RFC2131] Section 4.4.2. As noted in Section 2, it is also possible for IPv4 address acquisition to occur in parallel with the reachability test. If the host does not have an operable routable IPv4 address on any MLN, the host enters the INIT state and sends a DHCPDISCOVER packet to the broadcast address, as described in [RFC2131] Section 4.4.1. If the host supports the Rapid Commit Option [RFC4039], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange. If the host does not receive a response to a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 4.1. As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING state that knows the address of a DHCP server may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast address. In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast address so that the host will receive a response regardless of whether the previously configured IPv4 address is correct for the network to which it has connected. Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is not appropriate, since if the DHCP client has moved to another subnet, a DHCP server response cannot be routed back to the client since the DHCPREQUEST will bypass the DHCP relay and will contain an invalid source address." In Appendix A.1, add the following sentences to the fourth paragraph: " In order to examine the tradeoffs in implementations that only test reachability to a single MLN..." Add the following sentence at the end of the section: " If instead in the above example IPv4 address acquisition were carried out simultaneously with the reachability test, then performance would not suffer, even where hints are unreliable." --------------------------------------------------------------------------- Issue 30: Review of DNAv-13 Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: July 12, 2005 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05188.html Document: DNA-13 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I just read draft-ietf-dhc-dna-ipv4-13.txt. I support the goals, but I think the current document misses the target. I have a long list of comments, but these are the three major ones: 1. Hints and heuristics It seems to me that the reliance on hints and heuristics is vastly overstated. The biggest and best heuristic of network attachment is the MAC address of the default gateway, which can be verified with a trivial ARP request (i.e. the proposed DNA mechanism itself), thereby negating much of the usefulness of all the other hints. The document even has a section for IP-layer hints, and then says they're pointless and shouldn't be used. Given than an ARP request can be answered in under 1ms, any hint or heuristic has to be significantly faster than that, or it's self-defeating. [BA] I agree with Stuart that link layer hints may not be very useful. If the host attempts verification of multiple MLNs, then it is likely to be less sensitive to bad hints, and more likely to figure things out without any hints at all. This should be pointed out. [Stuart] The argument in Appendix A that you don't want to delay the normal DHCP INIT-REBOOT process while waiting for DNA is bogus. There's no reason why a host that wants rapid attachment to the network (which is, after all, the whole point of DNA) wouldn't do both simultaneously, and then just wait and see which approach yields a fruitful result quickest. [BA] I agree that an implementation could choose to do both DHCP and DNAv4 in parallel. This will be useful in circumstances where hints are unreliable or the router may have gone down, or doesn't respond for some reason. We should clarify this. [Stuart] 2. Why only one MLN candidate? Why limit a host to picking just one candidate network to verify? The drafts says, "In the absence of other information, the MLN defaults to the network to which the host was most recently attached." Consider a laptop computer that moves daily between Ethernet at work and Ethernet at home. If each time it picks its most recently attached as its best guess, it's going to be wrong 100% of the time. It would be much better if a device simply sent ten ARP Requests for the last ten default gateway addresses it has seen, and then sees which, if any, are answered. If you don't want to hit the network with ten back-to-back wire-rate ARP Requests, then they can be staggered 100ms apart, starting with the most recently seen network, then the previous, and so on. Most network gateways should be able to answer an ARP Request almost instantaneously, since answering ARP Requests is something they have to do all the time anyway, and if they're slow at that, then that would adversely impact the performance of pretty much all IP traffic flowing through the gateway. This stream of ARP Requests would of course be going on concurrently with DHCP INIT-REBOOT processing, and as soon as one of them yields a fruitful result, the device should stop. It's simple, it's fast, and it yields the desired result. [BA] As Stuart points out, an implementation can test reachability to multiple MLNs in parallel. We should clarify that it is ok for the implementation to do that. Assuming that the number of MLNs chosen is reasonable, I don't think it's necessary to rate limit. From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 22:05:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxxlx-0002ZK-LN for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 22:05:22 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25384 for ; Wed, 27 Jul 2005 22:05:17 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5P81UKCA99PYOE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 12:04:33 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0382EAB54D; Thu, 28 Jul 2005 12:04:25 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1AF9A4FB12; Thu, 28 Jul 2005 12:04:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S23s228840 for dna-list; Thu, 28 Jul 2005 12:03:54 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S23qw28836 for ; Thu, 28 Jul 2005 12:03:52 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR5P75HIJI8WXRBV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 12:03:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E6398000F; Thu, 28 Jul 2005 12:03:41 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 856633C00C; Thu, 28 Jul 2005 12:03:41 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 12:03:41 +1000 Date: Thu, 28 Jul 2005 12:03:41 +1000 From: Greg Daley Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <6d186a6d2bce.6d2bce6d186a@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, ----- Original Message ----- [cut] > > > > We can't deny the possibility of confusion (even Titanic > > > sank in its maiden voyage :-)) but can't find the example yet. > > > > I've got a case where all 3 (CompleteRA, Landmark, LinkID) > > schemes fail, and I've written it out 3 times, with just > > the names of the schemes changed (It is a corner case though). > > > > At the moment I'm not able to connect my own computer to > > my visited network, but will post it for everyone, when able. > > ok. We'd like to see the case. It may show us the way for > improvement. Here's the case, written out three times (once for each scheme). There may yet be mistakes, but I think it's a valid case. I think that this is incorrect change detection for all cases, although there are assumptions about the ordering of packet arrivals. Link Identifiers --------------------- A Host H, exists and moves around the Internet. On an link unvisited by the host, Link L, a prefix, P is retracted by one of the routers Router1. Subsequent to this, the actual lowest prefix on the link is Prefix Q. Another router, Router2 fails to see the prefix retraction. (Perhaps RAs are lost, or Router1 didn't comply with section 6.2.6 of RFC2461). The prefix is then reassigned within its previous lifetime to another link, link M, whose lowest prefix was prefix T. Link M, has also not been visited by host H. Link Identifiers are in use on both Link L and Link M. On Link M, all routers advertise Prefix P as current LinkID and Prefix T as OldLinkID. On Link L, Router2 advertises prefix P as Current LinkID. If the host H arrives on Link L, it may receive Prefix P as LinkID even though it is no longer present on-link. The host would configure Prefix Q (or a higher prefix) which is advertised in a PIO. If the LinkID is not contradicted, for example if there are no other advertising routers left on the link, when the host moves to Link M, it will also receive an RA with prefix P as the Current LinkID. The Old LinkID will be ignored (it hasn't been seen before). In this case, no change will be detected upon arrival to link M, and the previous prefix will remain configured. Complete RA ----------- A Host H, exists and moves around the Internet. On an link unvisited by the host, Link L, a prefix, P is retracted by one of the routers Router1. Subsequent to this, the actual lowest prefix on the link is Prefix Q. Another router, Router2 fails to see the prefix retraction. (Perhaps RAs are lost, or Router1 didn't comply with section 6.2.6 of RFC2461). The prefix is then reassigned within its previous lifetime to another link, link M, whose lowest prefix was prefix T. Link M, has also not been visited by host H. CompleteRA is in use on both Link L and Link M. On Link M, all routers advertise Prefix P and Prefix T (and any higher prefixes). On Link L, Router2 advertises prefix P as well as prefix R. If the host H arrives on Link L, it will receive the prefix set {P, Q, ...}, even though P is no longer on the link. The host would configure Prefix Q (or a higher prefix) which is advertised in a PIO. If the CompleteRA is not contradicted by another well configured router, for example if there are no other advertising routers left on the link, when the host moves to Link M, it will also receive an RA with prefix P. If the RA received only advertises P and is not a CompleteRA it is impossible to tell if the link has changed (The prefixes from the received RA and previous prefix set overlap). If the received RA is a CompleteRA, the host will receive a prefix set {P, T, ...} which overlaps but does not match the old prefix list {P, Q, ...}. Since the prefix lists overlap, it may be possible that these are the same link (according to CPL, for instance). In either of these cases, no change will be detected upon arrival to link M, and the previous prefix will remain configured. It is possible to define that received CompleteRAs override previous Link Identification, as they represent a complete view of the information of a link (This is not done by default in the current draft). In that case, a received CompleteRA may then invalidate address prefixes - doesn't work with the reassigned prefix though (which will remain configured if moves back). Prefix Landmarks ---------------- A Host H, exists and moves around the Internet. On an link unvisited by the host, Link L, a prefix, P is retracted by one of the routers Router1. Subsequent to this, the actual lowest prefix on the link is Prefix Q. Another router, Router2 fails to see the prefix retraction. (Perhaps RAs are lost, or Router1 didn't comply with section 6.2.6 of RFC2461). The prefix is then reassigned within its previous lifetime to another link, link M, whose lowest prefix was prefix T. Link M, has also not been visited by host H. Prefix Landmarking is in use on both Link L and Link M. On Link M, routers advertise either P or T but are aware of both prefixes' presence. On Link L, Router2 advertises prefix Q, but also believes prefix P is on-link. The host H arrives on Link L, and learns that link's prefixes (for example, configuring an address from Q). The host then moves to Link M and solicits the routers and asks if one of the previous link's prefixes is available here. If it asks about P - 'Is P on this Link?', then the routers will answer (correctly) 'Yes'. In this case, no change will be detected upon arrival to link M, and the previous prefix will remain configured. If the host asks 'Is Q on this Link?', then it would receive a 'No' answer, and would detect change. Alternatively, if the host instead visited Link M and then Link L, the host would similarly have had problems if it asked (on Link L) 'Is P on this link?" but not if it asked 'Is T on this link?' Querying the moved prefix will be unsuccessful, even though on link M, the prefix is advertised natively in PIOs. ---- I'm not sure what it means we should be doing, but more knowledge has been emerging about the issue, and we may be able to move closer to agreement soon (Lets hope). Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 22:16:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxxxD-0006Gf-4b for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 22:16:59 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25947 for ; Wed, 27 Jul 2005 22:16:55 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5PFTEN8K99Q67D@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 12:10:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D4873AB542; Thu, 28 Jul 2005 12:10:40 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 95C464FB05; Thu, 28 Jul 2005 12:10:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S2AYS28939 for dna-list; Thu, 28 Jul 2005 12:10:34 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S2AXw28935 for ; Thu, 28 Jul 2005 12:10:33 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5PFCCUUA99Q67D@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 12:10:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F0FB180010; Thu, 28 Jul 2005 12:10:17 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id DA8C13C00B; Thu, 28 Jul 2005 12:10:17 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 12:10:17 +1000 Date: Thu, 28 Jul 2005 12:10:17 +1000 From: Greg Daley Subject: [DNA] Draft session agenda for IETF63 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: pekka.nikander@nomadiclab.com Message-id: <6d1bdb6d4c64.6d4c646d1bdb@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Dear WG, Sorry it has taken so long to get a draft agenda out. Please provide me with feedback as to whether there needs to be any modification or clarification. Greg ------------ IETF 63, Paris Detecting Network Attachment (DNA) Working Group Session Agenda Afternoon I, Thursday Chairs: Pekka Nikander, Greg Daley Internet Area: INT Area Directors: Margaret Wasserman Mark Townsley --------------------------------------------- Introduction and Agenda - Chairs 5 min Document Status - Chairs 5 min Open Document Issues: - Chairs + Editors - Issue Status and Discussion - draft-ietf-dna-link-information-01.txt 10 min w/disc - draft-ietf-dna-cpl-00.txt 10 min w/disc - draft-ietf-dna-soln-framework-00.txt 10 min w/disc - draft-ietf-dna-routers-00.txt 10 min w/disc - draft-ietf-dna-hosts-01.txt 10 min w/disc ===========================================================> 60 min DNA Solution Progress: - Chairs 10 min w/disc - Existing Progress. DNA Solution Link Identification: - Description & Status - Chairs 5 min - draft-pentland-dna-protocol-00 link identification: Landmarks and Complete RA - Brett (?) 10 min - draft-jinchoi-dna-protocol2-00 link identification: Prefix LinkID - JinHyeock 10 min Comparison of LinkID techniques: BP,JHC,EN,GD - 10 min Discussion 10 min Summary and Actions 5 min =========================================================> 120 min Fast Router Discovery - JinHyeock Choi 15 min w/disc draft-jinchoi-dna-fastrd-01.txt DNA Relocation - Christian Vogt 10 min w/disc draft-vogt-dna-relocation-01.txt =========================================================> 145 min From dna-owner@webcamserver.eng.monash.edu.au Wed Jul 27 22:38:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxyII-0003UD-0A for dna-archive@megatron.ietf.org; Wed, 27 Jul 2005 22:38:46 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27213 for ; Wed, 27 Jul 2005 22:38:42 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5QFDX0TM9APPAO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 12:38:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3E9758000F; Thu, 28 Jul 2005 12:38:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C658A3C003; Thu, 28 Jul 2005 12:38:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S2cI929273 for dna-list; Thu, 28 Jul 2005 12:38:18 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S2cHw29269 for ; Thu, 28 Jul 2005 12:38:17 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5QEV8CM899PWFB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 12:38:10 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F315AB542; Thu, 28 Jul 2005 12:38:09 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 597724FB08; Thu, 28 Jul 2005 12:38:09 +1000 (EST) Date: Thu, 28 Jul 2005 12:38:08 +1000 From: Brett Pentland Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <6d186a6d2bce.6d2bce6d186a@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: JinHyeock Choi , Erik Nordmark , Syam Madanapalli , James Kempf , Dna Message-id: <42E84510.1000409@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) References: <6d186a6d2bce.6d2bce6d186a@monash.edu.au> Content-Transfer-Encoding: 7BIT > Prefix Landmarks > ---------------- > > > A Host H, exists and moves around the Internet. > > On an link unvisited by the host, Link L, a prefix, P is > retracted by one of the routers Router1. Subsequent to this, > the actual lowest prefix on the link is Prefix Q. > > > Another router, Router2 fails to see the prefix retraction. > (Perhaps RAs are lost, or Router1 didn't comply with > section 6.2.6 of RFC2461). > > The prefix is then reassigned within its previous > lifetime to another link, link M, whose lowest prefix > was prefix T. Link M, has also not been visited by > host H. > > Prefix Landmarking is in use on both Link L and > Link M. On Link M, routers advertise either P or T > but are aware of both prefixes' presence. > > > On Link L, Router2 advertises prefix Q, but also > believes prefix P is on-link. > > The host H arrives on Link L, and learns that link's > prefixes (for example, configuring an address from Q). > The host then moves to Link M and solicits > the routers and asks if one of the previous link's > prefixes is available here. > > If it asks about P - 'Is P on this Link?', then > the routers will answer (correctly) 'Yes'. > In this case, no change will be detected upon arrival to > link M, and the previous prefix will remain configured. > > If the host asks 'Is Q on this Link?', then it would > receive a 'No' answer, and would detect change. This case couldn't actually happen, because the draft requires that the landmark be a prefix that the host has an address configured with. It couldn't get this from link L. This is only a minor point though, because the following case could occur because the host might configure an address with prefix P when it visited link M and then router 2 would answer yes if it asked about prefix P when it moved to link L. Brett. > > Alternatively, if the host instead visited Link M and then > Link L, the host would similarly have had problems if > it asked (on Link L) > > 'Is P on this link?" but not if it asked 'Is T on this link?' > Querying the moved prefix will be unsuccessful, even though > on link M, the prefix is advertised natively in PIOs. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 00:29:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy01Z-0007cr-1l for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 00:29:37 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02767 for ; Thu, 28 Jul 2005 00:29:32 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5UA7QI6Y99Q6LL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 14:29:02 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DB33DAB545; Thu, 28 Jul 2005 14:28:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 93FA64FB07; Thu, 28 Jul 2005 14:28:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S4SJp30612 for dna-list; Thu, 28 Jul 2005 14:28:19 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S4SIw30608 for ; Thu, 28 Jul 2005 14:28:18 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5U947ZMG9APO6U@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 14:28:03 +1000 Received: by localhost (Postfix, from userid 510) id 56A458000F; Thu, 28 Jul 2005 14:28:01 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id ABA293C016; Thu, 28 Jul 2005 14:28:00 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKB00CENLQMX0@mailout3.samsung.com>; Thu, 28 Jul 2005 13:27:58 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IKB0095FLQJJE@mmp2.samsung.com>; Thu, 28 Jul 2005 13:27:58 +0900 (KST) Date: Thu, 28 Jul 2005 09:54:01 +0530 From: Subba Reddy Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , JinHyeock Choi Cc: Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <0ac501c5932c$300bc910$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <6d186a6d2bce.6d2bce6d186a@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > Link Identifiers > --------------------- > > A Host H, exists and moves around the Internet. > > On an link unvisited by the host, Link L, a prefix, P is > retracted by one of the routers Router1. Subsequent to this, > the actual lowest prefix on the link is Prefix Q. > > > Another router, Router2 fails to see the prefix retraction. > (Perhaps RAs are lost, or Router1 didn't comply with > section 6.2.6 of RFC2461). > > The prefix is then reassigned within its previous > lifetime to another link, link M, whose lowest prefix > was prefix T. Link M, has also not been visited by > host H. > > Link Identifiers are in use on both Link L and > Link M. On Link M, all routers advertise Prefix P > as current LinkID and Prefix T as OldLinkID. > > On Link L, Router2 advertises prefix P as Current LinkID. > > If the host H arrives on Link L, it may receive > Prefix P as LinkID even though it is no longer present > on-link. The host would configure Prefix Q (or a higher prefix) > which is advertised in a PIO. > > If the LinkID is not contradicted, for example if there are > no other advertising routers left on the link, when the host > moves to Link M, it will also receive an RA with prefix P as > the Current LinkID. The Old LinkID will be ignored (it hasn't > been seen before). > > > In this case, no change will be detected upon arrival to > link M, and the previous prefix will remain configured. > I am just giving one example, where H may not take wrong decision. If the H stays for atleast 3 hours (worst case) in the Link L, H will delete that linkid from list and will not make wrong decision when it is moved to Link M. In detail, Let us say life time of P is 10 hrs when the P is removed from L and assigned to M. Sice Router2 don't know the removal of P, it will be advertising P as linkid. After 1.5hrs, Router2 will stop advertising as linkid (since the prefix is not updated by any router, in this case Router1). Let us say H has received the last RA from Router2 with P as linkid (exactly after 1.5hrs after P is removed). After 1.5 hrs from this point of time H also will remove P from linkid list, since it is not updated in the last 1.5hrs. So after 3 hrs, P will be removed from linkid list of H. Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 02:19:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy1jh-0002kO-RS for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 02:19:22 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25472 for ; Thu, 28 Jul 2005 02:19:15 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5Y47VKFC99Q64P@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 16:18:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F8BDAB543; Thu, 28 Jul 2005 16:18:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EA5D44FB14; Thu, 28 Jul 2005 16:18:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S6IBW31936 for dna-list; Thu, 28 Jul 2005 16:18:11 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S6IAw31932 for ; Thu, 28 Jul 2005 16:18:10 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5Y3GSP9W9APNJ1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 16:18:02 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DED288000D; Thu, 28 Jul 2005 16:18:01 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id B8B393C010; Thu, 28 Jul 2005 16:18:01 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 16:18:01 +1000 Date: Thu, 28 Jul 2005 16:18:01 +1000 From: Greg Daley Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: JinHyeock Choi , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <6f53a86ef2c7.6ef2c76f53a8@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Subba, ----- Original Message ----- [cut] > > > > In this case, no change will be detected upon arrival to > > link M, and the previous prefix will remain configured. > > > > I am just giving one example, where H may not take wrong decision. [cut] I understand that LinkID is quite robust against change. The point I originally was making was that while it is robust, All of the schemes are flawed to some extent. Some of the strategies described in LinkID (timers, etc) are applicable to all schemes, and would probably be adopted in any of the schemes now. So the question is: Is the problem big enough that the advantage of advertising oldLinkID, gains significantly over the other schemes (when timeouts and prefix retraction advertisement are recommended)? Are the other schemes good enough? I don't expect there are clear answers which everyone agrees with, but it may be possible to discuss things until we agree about the comparison. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 02:56:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2JG-0004Us-4l for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 02:56:02 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00524 for ; Thu, 28 Jul 2005 02:55:59 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR5ZEBEF3G9APQBJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 16:55:50 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10F02AB545; Thu, 28 Jul 2005 16:55:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id BE8604FB03; Thu, 28 Jul 2005 16:55:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S6tYc32428 for dna-list; Thu, 28 Jul 2005 16:55:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S6tYw32424 for ; Thu, 28 Jul 2005 16:55:34 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR5ZDRKRC48WY4T5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 16:55:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F58F8000F for ; Thu, 28 Jul 2005 16:55:21 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 468433C003 for ; Thu, 28 Jul 2005 16:55:21 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 16:55:21 +1000 Date: Thu, 28 Jul 2005 16:55:21 +1000 From: Greg Daley Subject: [DNA] Updated draft agenda for IETF63 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <6f76146f70c4.6f70c46f7614@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT IETF 63, Paris Detecting Network Attachment (DNA) Working Group Session Agenda Afternoon I, Thursday Chairs: Pekka Nikander, Greg Daley Area Directors: Margaret Wasserman Mark Townsley --------------------------------------------- Introduction and Agenda - Chairs 5 min Document Status - Chairs 5 min Open Document Issues: - Chairs + Editors - Issue Status and Discussion - draft-ietf-dna-link-information-01.txt 10 min w/disc - draft-ietf-dna-cpl-00.txt 10 min w/disc - draft-ietf-dna-soln-framework-00.txt 10 min w/disc - draft-ietf-dna-routers-00.txt 10 min w/disc - draft-ietf-dna-hosts-01.txt 10 min w/disc ===========================================================> 60 min DNA Solution Progress: - Chairs 10 min w/disc - Existing Progress. DNA Solution Link Identification: - draft-pentland-dna-protocol-00 link identification: Landmarks and Complete RA - Brett (?) 10 min - draft-jinchoi-dna-protocol2-00 link identification: Prefix LinkID - JinHyeock 10 min Comparison of LinkID techniques: BP,JHC,EN,GD - 10 min Discussion 10 min Summary and Actions 5 min =========================================================> 115 min Fast Router Discovery - JinHyeock Choi 15 min w/disc draft-jinchoi-dna-fastrd-01.txt DNA Relocation - Christian Vogt 10 min w/disc draft-vogt-dna-relocation-01.txt FMIPv6 Usage with DNA Protocol - Rajeev or Syam 10 min w/disc. draft-koodli-dna-fmip-00.txt From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 03:57:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3Gr-00051l-67 for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 03:57:37 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04062 for ; Thu, 28 Jul 2005 03:57:34 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR61JEQ2B88Y6O0K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 17:57:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 331FD8000F; Thu, 28 Jul 2005 17:57:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D45F33C014; Thu, 28 Jul 2005 17:57:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S7srn00652 for dna-list; Thu, 28 Jul 2005 17:54:53 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S7sqw00648 for ; Thu, 28 Jul 2005 17:54:52 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR61GGPV228Y6O0G@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 17:54:48 +1000 Received: by localhost (Postfix, from userid 510) id 206DEAB542; Thu, 28 Jul 2005 17:54:48 +1000 (EST) Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5B6634FB04 for ; Thu, 28 Jul 2005 17:54:45 +1000 (EST) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 2D9B137F94; Thu, 28 Jul 2005 09:54:43 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id A223237F2D; Thu, 28 Jul 2005 09:54:41 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4094737E42; Thu, 28 Jul 2005 09:54:41 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1Dy3E0-00051A-NK; Thu, 28 Jul 2005 09:54:40 +0200 Date: Thu, 28 Jul 2005 09:54:40 +0200 From: Henrik Levkowetz Subject: Re: [DNA] Proposed Resolution to DNAv4 Issue 30 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <42E88F40.4040904@levkowetz.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: 7BIT Hi Bernard, On 2005-07-28 01:20 Bernard Aboba said the following: > The text of DNAv4 issue 30 is enclosed below. This and other DNAv4 issues > are tracked on the DNAv4 Issue page, located at: > http://www.drizzle.com/~aboba/DNA/ Good point. Experience with the ipUnplugged MIPv4 client implementation indicated clearly that doing parallel (multiple) reachability testing and DHCPv4 address acquisition is worthwhile. > A version of the document with the proposed changes applied is available > here: > http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-14.txt or http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-14.txt > The proposed resolution is as follows: > > In Section 1.2, change the definition of MLN to: > > "Most Likely Networks (MLNs) > The attached network(s) determined by the host to be most likely." > > Change Section 2, 2.1, 2.2 and 2.3 to the following: > Some comments: [...] > Where there is more than one MLN, the host can test reachability to > the MLN(s) in serial or in parallel. An implementation can also > attempt to obtain IPv4 configuration via DHCPv4 in parallel with one > or more reachability tests, with the host using the first answer > returned. These optimizations reduce the reliance on link and > Internet layer hints, which may not be present or may be misleading. > Attempting to obtain IPv4 configuration via DHCPv4 in parallel is Maybe s/in parallel/in parallel with reachability testing/ ? > particularly valuable in implementations that only test reachability > of a single MLN. Since confirming failure of a reachability test > requires a timeout, mistakes are costly and therefore sending a > DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131] > Section 3.2 and 4.3.2 may complete more quickly than the reachability > test. [...] > Appendix A discusses hints useful for the determination of the > MLN(s). By matching received hints against network parameters > previously stored, an implementation testing reachability to a single > MLN can make an an educated guess as to which network it has attached > to. Alternatively, an implementation that simultaneously tests > reachability to multiple MLNs can select them solely based on the > networks it has most recently connected to, in which case it may not > be necessary to consult hints. Reads a bit awkwardly to me, and leaves out one reasonable strategy. Maybe something like: "Appendix A discusses hints useful for the determination of the MLN(s). By matching received hints against network parameters previously stored, it is possible to select one or a set of networks as most likely. An implementation that tests reachability to a single MLN would do its test based on the hints. An implementation that simultaneously tests reachability to multiple MLNs may do the tests solely based on the networks it has most recently connected to, or may alternatively test a set of likely networks based both on networks recently connected to and networks selected based on the hints." Henrik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 05:08:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4N4-0000AJ-BC for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 05:08:10 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07708 for ; Thu, 28 Jul 2005 05:08:03 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR63Y72YGW9APOVU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 19:06:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AD6DEAB544; Thu, 28 Jul 2005 19:06:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 687154FB09; Thu, 28 Jul 2005 19:06:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S95dN01495 for dna-list; Thu, 28 Jul 2005 19:05:39 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S95bw01491 for ; Thu, 28 Jul 2005 19:05:38 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR63WYCRTQ8Y6O8F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 19:05:21 +1000 Received: by localhost (Postfix, from userid 510) id BC5B18000D; Thu, 28 Jul 2005 19:05:21 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id 98AA53C012; Thu, 28 Jul 2005 19:05:19 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6S95Fcn010515; Thu, 28 Jul 2005 02:05:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6S94QvA152028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2005 02:04:56 -0700 (PDT) Date: Thu, 28 Jul 2005 02:04:59 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: Flash renumbering In-reply-to: <42E7CC61.5090506@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42E89FBB.8070705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <1ed7c20f5b.20f5b1ed7c@pintlmail.MITL.Research.Panasonic.COM> <"42 E5AB7E.6020803"@sun.com> <42E5B15B.7060609@Research.Panasonic.COM> <42E63B2A.20800@sun.com> <42E657B1.5010106@Research.Panasonic.COM> <42E6C9EA.9080703@sun.com> <42E7CC61.5090506@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > I know this is always an issue. But, isn't it a general problem about > CompleteRA which we need to think about either way? In other cases we have the CPL logic ("wait for 4 seconds") to fall back on when the complete bit isn't set. I suspect in you suggestion we can have the routers handle things without a complete bit; if a router hasn't heard a learned prefix from any other router, then after 1.5 hours it can drop it from the learned prefixes. Thus the issue now becomes whether and how the router can communicate to the hosts that this is no longer a (learned) prefix on the link. We can overload the complete bit with this when the prefixes all fit in one RA, but we could perhaps also do some explicit "removal of learned prefix" type of option?? > I don't remember why we decided to remove the #prefixes field from the > DNAO. I thought most of us felt that this field will help out with > being able to send the prefixes in two or more RA if they don't fit in a > single RA. Sure you can send them, but that doesn't mean we know what the semantics need to be on the receiver. > So, let me bring #prefixes back instead of the complete bit, here is > what I propose when the prefixes don't fit in one RA: > 1) Divide the prefixes into groups with atleast one common prefix so > that each group will fit in a single RA. > 2) Set the #prefixes field in the DNAO to the total number of prefixes > (The semantics for this is "This is the number of prefixes on the link > *I* know of"). I don't think #2 can work in a robust manner unless we apply normal fragmentation/reassembly to such large RAs. And I don't think we need this complexity. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 05:32:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4kh-00087C-CW for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 05:32:31 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09679 for ; Thu, 28 Jul 2005 05:32:27 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR64UZP6DK8Y6OO6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 19:32:18 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1B141AB543; Thu, 28 Jul 2005 19:32:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B0B234FB10; Thu, 28 Jul 2005 19:32:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6S9Vkg01784 for dna-list; Thu, 28 Jul 2005 19:31:46 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6S9Vjw01780 for ; Thu, 28 Jul 2005 19:31:46 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR64UNRXGU9APPOW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 19:31:45 +1000 Received: by localhost (Postfix, from userid 510) id 514628000D; Thu, 28 Jul 2005 19:31:45 +1000 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8E2CF3C016; Thu, 28 Jul 2005 19:31:43 +1000 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1F867212C8E; Thu, 28 Jul 2005 12:31:42 +0300 (EEST) Date: Thu, 28 Jul 2005 11:31:41 +0200 From: Pekka Nikander Subject: =?ISO-8859-1?Q?[DNA]=A0Apologies_and_stepping_down?= Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: Margaret Wasserman , Greg Daley Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Dear DNA WG, Since a couple of months I have had severe scheduling problems leading to too little time for acting as an effective co-chair of the DNA WG. My sincere apologies for this. I have discussed the situation a number of times with Greg, and his wish has been that I would still try, and I have tried until now. However, it has become clear that this just does not work. You and Greg deserve someone who has more cycles available; I don't want to act as an ignorant manager that is out of touch with the technical details. I have today indicated to Margaret that I want to step down from my role as a DNA co-chair as soon as we are able to find a replacement. If you have good candidates in mind, please contact Margaret and/or Greg directly. In the mean while, I will do my best to help Greg. Yours, --Pekka Nikander From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 07:55:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy6yt-0008IO-Kc for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 07:55:19 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18906 for ; Thu, 28 Jul 2005 07:55:16 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR69TZYP5Q8WY5U6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 21:55:12 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7FEAFAB545; Thu, 28 Jul 2005 21:54:46 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 331274FB0D; Thu, 28 Jul 2005 21:54:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SBs8403693 for dna-list; Thu, 28 Jul 2005 21:54:08 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SBs7w03689 for ; Thu, 28 Jul 2005 21:54:07 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR69T1MGFA8WY5U6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 21:54:00 +1000 Received: by localhost (Postfix, from userid 510) id 8F7A3AB543; Thu, 28 Jul 2005 21:54:00 +1000 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0D32C4FB08; Thu, 28 Jul 2005 21:53:54 +1000 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5BC2A5F4; Thu, 28 Jul 2005 13:53:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 13:53:49 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 13:53:49 +0200 Date: Thu, 28 Jul 2005 13:53:48 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j6SBs7w03690 Content-type: text/plain; charset=iso-8859-1 Thread-Topic: [DNA] Re: LinkID v.s. Landmark Prefix Thread-index: AcWTPE84LZMinA5HTumTSRTohHyuoAAKsaBg Content-class: urn:content-classes:message X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 28 Jul 2005 11:53:49.0472 (UTC) FILETIME=[04694A00:01C5936B] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA18906 Hi Brett, I'm having this endless LinkID v.s. Landmark battle in my head while tryi= ng to grasp what has been said and written.=20 Anyway, I started think the following na=EFve example: R1 : advertising P1 R2 : adverstining P2 thus {adv:P1, learned:P2} thus {adv:P2, learned: P1} node H: knows P1, P2 and has chosen P1 as the landmark prefix Let's assume that R1 stops advertising P1 and starts advertising a new pr= efix P3. The host doesn't receive RAs and is unaware of the change. The n= ode moves to another AP and gets a "no" answer. The landmark approach ind= icates wrongly a link change, but CPL will show that there is actually no= link change. If I have been able to follow the discussion, it has been s= aid that the CPL decision should overwrite Landmark's decision in this ca= se.=20 I agree but I guess a lot of fuzz is because this is not clearly stated i= n the draft -- should it or is it still an open issue? This would practic= ally mean that every time a "no" answer is received, the current list of= all known prefixes on the link is checked in order to confirm that the R= A doesn't contain a prefix which is already known to be on the link. ...or am I just once again completely lost? :) Might also be that we should write down something about the case when a n= ode changes the landmark prefix. If the node received a zero-lifetime adv= ertisement for the current landmark prefix, it should pick another prefix= . On the other hand, "5.2.3. The prefix MUST have a non-zero valid lifeti= me" is a way to say it. -- Tero=20 > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: 28. hein=E4kuuta 2005 9:18 > To: Subba Reddy > Cc: JinHyeock Choi; Erik Nordmark; Syam Madanapalli; Brett Pentland; > greg.daley@eng.monash.edu.au; James Kempf; Dna > Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix >=20 > Hi Subba, >=20 > ----- Original Message ----- > [cut] > > > > > > In this case, no change will be detected upon arrival to > > > link M, and the previous prefix will remain configured. > > > > > > > I am just giving one example, where H may not take wrong decision. > [cut] >=20 > I understand that LinkID is quite robust against change. >=20 > The point I originally was making was that while it is robust, > All of the schemes are flawed to some extent. >=20 > Some of the strategies described in LinkID (timers, etc) > are applicable to all schemes, and would probably be adopted > in any of the schemes now. >=20 > So the question is: Is the problem big enough that the > advantage of advertising oldLinkID, gains significantly > over the other schemes (when timeouts and prefix retraction > advertisement are recommended)? >=20 > Are the other schemes good enough? >=20 > I don't expect there are clear answers which everyone agrees > with, but it may be possible to discuss things until > we agree about the comparison. >=20 > Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 08:30:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7WX-0001j8-Pu for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 08:30:05 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21599 for ; Thu, 28 Jul 2005 08:30:03 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR6B27CF3A99PXGY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 22:29:49 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1019EAB54C; Thu, 28 Jul 2005 22:29:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id AC0FD4FB08; Thu, 28 Jul 2005 22:29:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SCTKD04079 for dna-list; Thu, 28 Jul 2005 22:29:20 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SCTIw04075 for ; Thu, 28 Jul 2005 22:29:19 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6B1JCEB28Y6IGF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 22:29:06 +1000 Received: by localhost (Postfix, from userid 510) id D354C8000F; Thu, 28 Jul 2005 22:29:05 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by larry.its.monash.edu.au (Postfix) with ESMTP id BB9613C00C for ; Thu, 28 Jul 2005 22:29:04 +1000 (EST) Received: by rproxy.gmail.com with SMTP id a41so711026rng for ; Thu, 28 Jul 2005 05:29:03 -0700 (PDT) Received: by 10.38.161.60 with SMTP id j60mr1182279rne; Thu, 28 Jul 2005 05:29:03 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Thu, 28 Jul 2005 05:29:03 -0700 (PDT) Date: Thu, 28 Jul 2005 17:59:03 +0530 From: Syam Madanapalli Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <42DC9A4C.9010601@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: JinHyeock Choi , Greg Daley , dna@eng.monash.edu.au Reply-to: Syam Madanapalli Message-id: <10e14db205072805295655762b@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bPgsM5g/5pSFPgeUAgQ/PfGXBr7VJaLDdwF7QBYcMsPovKqt/hurCL0dL0q6AjEE2F3DCxjSAayQ/Iio21D2jkIq2RTeRaLgfkdIC2DNP7gyW1hVAsn5e/axMonBsM7f81QxyFGQzltgtD/t8s/LUpoFb+bo8tBqFapDf1jfzEQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, I am replying little late :) On 7/19/05, Brett Pentland wrote: > Hi JinHyeock, > > I just read over your update and have a few observations. > > I see you now have triggering as well as caching. Triggering seems > to make good sense when the AR and Point of Attachment (PoA) are > co-located, but when they are not it seems that you are just > reinventing RS/RA. Compared to the host initiating the RS, you > save one store-and-forward time in the PoA, but that doesn't seem > like much of a saving for a new protocol. We have implemented the sending RS from AP while an MN is associating with it and found that the RA comes at MN faster than the cached RA sent from AP. We have surprised with these results. It took ~700 micro seconds (0.7 ms) for an RA to reach MN from the completion of association. And it is very easy to implement. We were sending RA from the Router kernel to MN MAC. We are sending RA from the router without random delay as AP sends unicast RS with TSLLAO option. A host can also send an RS but it may need to employ a some logic to avoid random delay. -Syam From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 08:34:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7aW-0002p1-MX for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 08:34:12 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21862 for ; Thu, 28 Jul 2005 08:34:10 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR6B6GCCWU9APMFL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 22:33:06 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A8C56AB546; Thu, 28 Jul 2005 22:33:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5B0EF4FB0C; Thu, 28 Jul 2005 22:33:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SCWvk04141 for dna-list; Thu, 28 Jul 2005 22:32:57 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SCWvw04137 for ; Thu, 28 Jul 2005 22:32:57 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6B63WRPI8Y6PLA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 22:32:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BADC80010; Thu, 28 Jul 2005 22:32:47 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id DF5A63C003; Thu, 28 Jul 2005 22:32:46 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 22:32:46 +1000 Date: Thu, 28 Jul 2005 22:32:46 +1000 From: Greg Daley Subject: [DNA] =?iso-8859-1?Q?Re=3A_=5BDNA=5D=A0Apologies_and_stepping_down?= Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna , Margaret Wasserman , Greg Daley Message-id: <70e99d709ad0.709ad070e99d@monash.edu.au> MIME-version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j6SCWvw04138 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=iso-8859-1 Content-language: en Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21862 Dear Pekka, I think I can speak on behalf of the WG, in expressing our appreciation for the work you have done within DNA. Your wisdom and experience have been incredibly valuable, and have advanced work within the group. Thanks for your contribution. Greg ----- Original Message ----- From: Pekka Nikander Date: Thursday, July 28, 2005 7:31 pm Subject: [DNA]=A0Apologies and stepping down > Dear DNA WG, >=20 > Since a couple of months I have had severe scheduling problems =20 > leading to too little time for acting as an effective co-chair > of the DNA WG. My sincere apologies for this. I have > discussed the situation a number of times with Greg, and his > wish has been that I would still try, and I have tried until > now. However, it has become clear that this just does not work. > You and Greg deserve someone who has more cycles available; I > don't want to act as an ignorant manager that is out of touch > with the technical details. >=20 > I have today indicated to Margaret that I want to step down from=20 > my role as a DNA co-chair as soon as we are able to find a=20 > replacement. If you have good candidates in mind, please contact > Margaret and/or Greg directly. In the mean while, I will do my > best to help Greg. >=20 > Yours, >=20 > --Pekka Nikander >=20 >=20 From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 08:44:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7kH-00051W-79 for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 08:44:17 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22333 for ; Thu, 28 Jul 2005 08:44:14 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR6BJXUUAU99Q21O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Jul 2005 22:44:02 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DBA2DAB54B; Thu, 28 Jul 2005 22:43:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 115AC4FB0E; Thu, 28 Jul 2005 22:43:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SChje04301 for dna-list; Thu, 28 Jul 2005 22:43:45 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SChiw04297 for ; Thu, 28 Jul 2005 22:43:44 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6BJHV1048Y6PMH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Jul 2005 22:43:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8468D8000D; Thu, 28 Jul 2005 22:43:34 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 70C673C00D; Thu, 28 Jul 2005 22:43:34 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 28 Jul 2005 22:43:34 +1000 Date: Thu, 28 Jul 2005 22:43:34 +1000 From: Greg Daley Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Brett Pentland , JinHyeock Choi , Greg Daley , dna@eng.monash.edu.au Message-id: <70c9bc710217.71021770c9bc@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Syam, ----- Original Message ----- [cut] > > We were sending RA from the Router kernel to MN MAC. We are > sending RA from the router without random delay as AP sends > unicast RS with TSLLAO option. Can I ask what the source address of the RS from the AP is? I am interested in which features of TSLLAO are being used. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 11:43:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAXr-0000Mo-JY for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 11:43:42 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06381 for ; Thu, 28 Jul 2005 11:43:36 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6HT9EAKA8WXYMK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 01:43:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B4BAFAB544; Fri, 29 Jul 2005 01:43:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A3BF44FB09; Fri, 29 Jul 2005 01:43:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SFgXK06534 for dna-list; Fri, 29 Jul 2005 01:42:33 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SFgWw06530 for ; Fri, 29 Jul 2005 01:42:32 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6HS1OV3M8Y6QK5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 01:42:16 +1000 Received: by localhost (Postfix, from userid 510) id 259AE8000D; Fri, 29 Jul 2005 01:42:16 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2F9DD3C00E; Fri, 29 Jul 2005 01:42:13 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6SFgAvU022537; Thu, 28 Jul 2005 09:42:10 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6SFg094289742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2005 08:42:04 -0700 (PDT) Date: Thu, 28 Jul 2005 08:42:44 -0700 From: Erik Nordmark Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <92e919fb050727004264c293e@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E8FCF4.1010304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <92e919fb05071909502f4fa258@mail.gmail.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E59B91.2050007@sun.com> <92e919fb05072521531fba472d@mail.gmail.com> <42E632D5.904@sun.com> <92e919fb050727004264c293e@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > ok. From now on, I will use the term "flapping" only in the sense you > describes. > > For the more general case I presented, I will use the term 'LOS (Lack > of Synchronization). Is it ok? ok, but see below. Also, I don't think "out of synch" can be determined in a distributed system, since there is always a non-zero delay. Hence if R1 sends a RA and R2 and R3 receives it, an observer can't tell which or R2 and R3 updated the prefix list first (or whether they did it at exactly the same time). > (The term "link" gave me enough trouble already. I don't want another > Jason problem arising from ambiguous terms.) > > >>Such flapping is unavoidable for the cases we are >>interested in (an unknown and changeable set of routers on the link, and >>a changeable set of prefixes being advertised.) >> >>I think it is important that the DNA solution cope gracefully with such >>flapping. > > > ok. I think it's also important that DNA solution cope gracefully with > more general case of temporary LOS (Lack of Synchronization). If > DNA solution can deal with LOS, I think it can deal with flapping > automatically. I don't see using the LOS term as helpful here. LOS captures the case when router1's list of prefixes is out of date with router2's two list of prefixes, even if only for a nanosecond. What matters is the sequence of events that are observable. >>>If the (solicited) RA carries 1) NO answer and 2) a known prefix, >>>the host would not assume a link change. >>>(So in effect, "known prefix" would overrule "NO".) >>> >>>Is this right? >> >>I think that makes sense. > > > ok. I think the above is a non-trivial change for Link Identification > criteria, so needs to be reflected in the Landmark/ CompleteRA draft. Agreed. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 11:53:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAhq-0003tF-JJ for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 11:53:58 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07074 for ; Thu, 28 Jul 2005 11:53:54 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6I6ICEP68WXYNK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 01:53:40 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 63ECFAB547; Fri, 29 Jul 2005 01:53:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 094CD4FB06; Fri, 29 Jul 2005 01:53:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SFqvO06707 for dna-list; Fri, 29 Jul 2005 01:52:57 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SFquw06703 for ; Fri, 29 Jul 2005 01:52:56 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6I5XVN0A8Y6L1E@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 01:52:41 +1000 Received: by localhost (Postfix, from userid 510) id 66B07AB545; Fri, 29 Jul 2005 01:52:41 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4C26A4FB08; Fri, 29 Jul 2005 01:52:39 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6SFqZvU002847; Thu, 28 Jul 2005 09:52:35 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6SFqIii293315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2005 08:52:23 -0700 (PDT) Date: Thu, 28 Jul 2005 08:53:02 -0700 From: Erik Nordmark Subject: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <92e919fb0507270815223243ee@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42E8FF5E.6050109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E4A03B.6080601@eng.monash.edu.au> <01c901c590f7$dd377c10$59476c6b@sisodomain.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E63568.2080503@sun.com> <92e919fb0507270815223243ee@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: >>Given that we have this, then we have the choice to assume this >>notification even for the DNA solution, as a way to optimize things. >>Alternatively, we can try to make the DNA solution be more robust again >>a missing 'link up' notification. > > > I took the latter approach. (that may be the road less traveled. :-)) > Allow me to explain my reasoning too. ok But when taking that draft, what guarantees can you provide when you need to use a combination of linkID and CPL/completeRA? You end up with these combinations when 1. Some but not all routers on the link are new (i.e., are doing linkID) 2. The host moves to/from a link where not all routers on the link are new My gut feel is that there are many places where you have to defer to prefix comparisons, and if the prefix list you are comparing against is based on CPL, then you have the CPL problem of needing reliably 'link up' indications. But I haven't worked through all the cases to see if this is indeed the case, or whether we can do better. > For example, with Link UP notification, Linkid scheme may work > to detect link change from non-supporting link to supporting one > as below. > > Assume a host is at a non-supporting link. Then it doesn't have > a linkid prefix. When it moves to a supporting link, it will see a > new linkid. > > The host may assume a link change upon receiving this new linkid. > But the current draft mandates that the host doesn't make any > decision becuase there is the other possibility that the host is at > the same link but a router on the link becomes a DNA router and > starts advertising the linkid. > > I contemplated the idea to distinguish the above two cases with > Link UP indication but gave it up because I thought the simplicity > and less assumption is better. So assume that linkA has R1 which uses linkID, and R2 which does not. linkB has R3 which does not implement linkID. A host H is on linkB and moves to linkA. Assume H receives the RA from R2 before the RA from R1. How can it tell whether it should assume that R2 is on the same link as R3, or not? When it receives the RA from R2, the only thing it can rely on is the link up notification (R3 and R3 do not advertise any common prefixes), since R2 and R3 could be two old routers that are on the same link and announce disjoint prefixes. Thus link up is at least needed "temporarily"; once the RA from R1 arrives (which includes all the prefixes for linkA I assume), then the host can tell that the prefixes it got from R3 are really not on the new link; but until that RA is receives the host needs to rely on the link up. Do you see a way around this? Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 13:57:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCdZ-000288-88 for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 13:57:41 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16743 for ; Thu, 28 Jul 2005 13:57:38 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6MH1C5IM8Y6RAE@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 03:56:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D8E35AB54A; Fri, 29 Jul 2005 03:56:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9491D4FB05; Fri, 29 Jul 2005 03:56:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SHte308175 for dna-list; Fri, 29 Jul 2005 03:55:40 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SHtdw08171 for ; Fri, 29 Jul 2005 03:55:39 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6MGCQ6FI8WY9P9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 03:55:37 +1000 Received: by localhost (Postfix, from userid 510) id 08209AB543; Fri, 29 Jul 2005 03:55:36 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id D74034FB06; Fri, 29 Jul 2005 03:55:35 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKC00C9WN4LUG@mailout2.samsung.com>; Fri, 29 Jul 2005 02:55:33 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKC00KS7N4JSH@mmp1.samsung.com>; Fri, 29 Jul 2005 02:55:33 +0900 (KST) Date: Thu, 28 Jul 2005 10:55:31 -0700 From: Alper Yegin Subject: RE: [DNA] Updated draft agenda for IETF63 In-reply-to: <6f76146f70c4.6f70c46f7614@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Greg Daley'" , dna@eng.monash.edu.au Message-id: <340901c5939d$8cfee230$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT > - draft-ietf-dna-link-information-01.txt 10 min w/disc The latest version of this document is draft-ietf-dna-link-information-02.txt Alper From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 18:48:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHAu-0008Cr-P3 for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 18:48:25 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04523 for ; Thu, 28 Jul 2005 18:48:20 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6WNHE72M8Y6SWN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 08:48:08 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F885AB54F; Fri, 29 Jul 2005 08:47:41 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 58F0D4FB06; Fri, 29 Jul 2005 08:47:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SMkre11690 for dna-list; Fri, 29 Jul 2005 08:46:53 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SMkqw11686 for ; Fri, 29 Jul 2005 08:46:52 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6WM5OMHO8Y6SWN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 08:46:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8A349AB542 for ; Fri, 29 Jul 2005 08:46:37 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6EC9C4FB03 for ; Fri, 29 Jul 2005 08:46:37 +1000 (EST) Received: from [150.169.1.105] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 29 Jul 2005 08:46:37 +1000 Date: Fri, 29 Jul 2005 08:46:37 +1000 From: Greg Daley Subject: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <718816719555.719555718816@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi, Here's my time/space requirement analysis of the Link Identification methods. Based on my analysis, none of them seems to be terribly difficult to support. Greg Parameters: ----------- P number of distinct prefixes on a link p_r number of distinct prefixes received in pios from router r l_r number 0of learned prefixes received in pios from router r N number of links visited recently. Discussion of issues and assumptions: ------------------------------------- Schemes are described with individual sub components, as well as when combined in compound solutions (as proposed in drafts). This made building the analysis easier. Proposed schemes from the drafts are marked as: **** (Proposed Scheme) Ignores number of routers on link None of the schemes: LinkID, CompleteRA, Landmarks require sorted storage, LinkID requires Minimum selection comparison Hash tables work fine for DNAPrefixList in completeRA and Prefix Landmark, so long as hash table traversal for CompleteRA generation is linear: O(P). Additional Storage indicates storage for learned information on routers, and ignores storage requirements for the RFC2461 AdvPrefixList. Additional comparison of host side requirements for schemes when also using Complete Prefix Lists is provided for context. Time calculations ignore signature generation and verification times (which are affected by the overall length of the message). In order to be robust against prefix departures, O(P) prefixes may need to be stored for LinkID, but the minimum is O(1). Router Side storage and processing requirements. ================================================ CompleteRA: ----------- Additional Storage: O(P) keep DNAPrefixList RA build time: O(P) traverse DNAPrefixList. RA processing: O(p_r) insertion of prefixes into hash table. Timers: 1 Expiry timer (callback or operation based) Prefix Landmarks: ----------------- Additional Storage: O(P) keep DNAprefixlist RA build time: O(1) comparison of landmark with DNAPrefixList. RA processing: O(p_r) insertion of prefixes into hash table. Timers: 1 Expiry timer (callback or operation based) CompleteRA+PrefixLandmarks **** (Proposed Scheme) ------------------------------------------------- Additional Storage: O(P) keep DNAprefixlist RA build time: O(1) comparison of landmark with DNAPrefixList. OR O(P) traverse DNAPrefixList. RA processing: O(p_r) insertion of prefixes into hash table. Timers: 1 Expiry timer (callback or operation based) Prefix LinkID **** (Proposed Scheme): --------------------------------------- Additional Storage: O(1) keep LinkID and Old LinkID RA Build time: O(1) selection of LinkID and Old LinkID RA Processing: O(p_r) comparison of each prefix with LinkID Timers: 1 expiry timer (callback or operation based) Unmodified RFC 2461 Routers: ---------------------------- Additional Storage: zero RA Build time: O(1) (add pio processing time for own prefixes) RA processing: O(1) (RA consistency checks) OR zero Timers: 0 or 1 expiry timer (prefix retraction) Host Side storage and processing requirements. ============================================== CompleteRA: ----------- Storage: O(P) Prefix List of distinct prefixes on link RA Processing: O(P) = O(p_r+l_r) storage of prefixes in prefix list. RS build time: O(1), normal RS. OR zero, no RS. Learning time: 1 message Prefix Landmark: ---------------- Storage: O(1) landmark prefix (minimum) O(P) prefix list (maximum/robust). RA Processing: O(1) landmark inpsection RS build time: O(1), normal RS + selected landmark. Learning time: 1 message CompleteRA+Prefix Landmark **** (Proposed Scheme -- see below for CPL): -------------------------------------------------- Storage: O(P) Prefix List of distinct prefixes on link RA Processing: O(1)landmark inspection or O(P) storage of prefixes in prefix list. RS build time: O(1), normal RS. OR O(1), normal RS + selected landmark OR zero, no RS. Learning time: 1 message ( more if Landmark:"NO" is incomplete) Prefix LinkID **** (Proposed Scheme -- see below for CPL): ------------------------------------- Storage: O(1) Prefix LinkID (minimum) O(N) set of linkIDs received recently on different IP links. RA Processing: O(1) LinkID inspection, comparison to recent LinkIDs. RS build time: O(1), normal RS. OR zero, no RS. Learning time: 1 message. Complete Prefix Lists: ---------------------- Storage: O(P + P') Current link object + Candidate Link Object. RA processing: O(p_r) insertion of prefixes into candidate link object, + comparison with current link object. RS build time: O(1), normal RS. Learning time: NUM_RS_RA_COMPLETE (1..3) * 4 seconds. CompleteRA + Complete Prefix Lists: ----------------------------------- Storage: O(P + P') Current link object + Candidate Link Object. RA processing: O(P) insertion of prefixes into candidate link object, + comparison with current link object. RS build time: O(1), normal RS. Learning time: 1 message. Landmark + Complete Prefix Lists: ----------------------------------- Storage: O(P + P') Current link object + Candidate Link Object. RA processing: O(1) Landmark inspection OR O(P) insertion of prefixes into candidate link object, + comparison with current link object. RS build time: O(1), normal RS + selected landmark Learning time: 1 message (Landmark) NUM_RS_RA_COMPLETE (1..3) * 4 seconds (Complete Prefix List). CompleteRA + Landmark + Complete Prefix Lists **** (Proposed Scheme): --------------------------------------------------------------------- Storage: O(P + P') Current link object + Candidate Link Object. RA processing: O(1) Landmark inspection OR O(P) insertion of prefixes into candidate link object, + comparison with current link object. RS build time: O(1), normal RS + selected landmark OR O(1), normal RS. OR zero. Learning time: 1 message LinkID + Complete Prefix Lists **** (Proposed Scheme): ------------------------------------------------------- Storage: O(P + P') Current link object + Candidate Link Object. Maybe + O(N) set of linkIDs received recently on different IP links. RA processing: O(1) LinkID inspection, comparison to recent LinkIDs. OR O(P) insertion of prefixes into candidate link object, + comparison with current link object. RS build time: O(1), normal RS. OR zero, no RS. Learning time: 1 message OR NUM_RS_RA_COMPLETE (1..3) * 4 seconds (Complete Prefix List). From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 19:05:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHRR-0004n4-VG for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 19:05:30 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05230 for ; Thu, 28 Jul 2005 19:05:25 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6X8XH1TG8WYBU5@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 09:05:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1AFC5AB543; Fri, 29 Jul 2005 09:04:59 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C53954FB07; Fri, 29 Jul 2005 09:04:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SN4kx11902 for dna-list; Fri, 29 Jul 2005 09:04:46 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SN4jw11898 for ; Fri, 29 Jul 2005 09:04:45 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6X8KO8DO8Y6SYJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 09:04:42 +1000 Received: by localhost (Postfix, from userid 510) id E4C7080010; Fri, 29 Jul 2005 09:04:41 +1000 (EST) Received: from sm.sait.samsung.co.kr (unknown [202.20.142.15]) by larry.its.monash.edu.au (Postfix) with ESMTP id 35FCC3C005; Fri, 29 Jul 2005 09:04:40 +1000 (EST) Received: from sm.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2298CE5AB2; Fri, 29 Jul 2005 08:00:55 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Fri, 29 Jul 2005 08:00:54 +0900 (KST) Received: from jinchoe (unknown [75.2.43.239]) by sm.sait.samsung.co.kr (Postfix) with SMTP id:3E058E5A4A; Fri, 29 Jul 2005 08:00:54 +0900 (KST) Date: Fri, 29 Jul 2005 08:04:36 +0900 From: JinHyeock Choi Subject: Re: [DNA] Updated draft agenda for IETF63 Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Message-id: <014501c593c8$b99e2aa0$ef2b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <6f76146f70c4.6f70c46f7614@monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg Thanks for your trouble. I looked through the agenda and have a few questions. First, will there is no presentation for Hash based FastRA? (It seems only link identification part of draft-pentland-dna-protocol-01 will be presented.) Second, will there be no presentation for TSLLAO? Third, will there be a discussion about "RA optimized for DNA"? (I think we need to consider what kind of information the (DNA) RA should include.) Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 19:07:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHT5-0005LW-BN for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 19:07:11 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05300 for ; Thu, 28 Jul 2005 19:07:07 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR6XAZW31O99Q3XD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 09:06:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D7F0AB54C; Fri, 29 Jul 2005 09:06:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B3F254FB08; Fri, 29 Jul 2005 09:06:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SN6Xi11947 for dna-list; Fri, 29 Jul 2005 09:06:33 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SN6Ww11943 for ; Fri, 29 Jul 2005 09:06:32 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6XARMFLY8Y6TDV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 09:06:28 +1000 Received: by localhost (Postfix, from userid 510) id 0AC138000D; Fri, 29 Jul 2005 09:06:27 +1000 (EST) Received: from [192.168.1.2] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 4A84B3C00B; Fri, 29 Jul 2005 09:06:26 +1000 (EST) Date: Fri, 29 Jul 2005 09:06:30 +1000 From: Brett Pentland Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: "Tero Kauppinen (JO/LMF)" Cc: Dna Message-id: <42E964F6.2010504@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA05300 Tero Kauppinen (JO/LMF) wrote: > Hi Brett, >=20 > I'm having this endless LinkID v.s. Landmark battle in my head while > trying to grasp what has been said and written. >=20 > Anyway, I started think the following na=EFve example: >=20 > R1 : advertising P1 R2 : adverstining P2 thus {adv:P1, > learned:P2} thus {adv:P2, learned: P1} >=20 > node H: knows P1, P2 and has chosen P1 as the landmark prefix >=20 > Let's assume that R1 stops advertising P1 and starts advertising a > new prefix P3. The host doesn't receive RAs and is unaware of the > change. The node moves to another AP and gets a "no" answer. The > landmark approach indicates wrongly a link change, but CPL will show > that there is actually no link change. If I have been able to follow > the discussion, it has been said that the CPL decision should > overwrite Landmark's decision in this case. It doesn't have to be CPL, but the presence of prefixes in the RA that the host has seen before are a strong indication that link change has not taken place. The draft is not clear on this because we still have it as an open issue (issue 9 - actually dates back to when we had the "landmark not on link option" but the concept is the same). I definitely think that matching prefixes should overrule a "NO" answer. There were some concerns that the inconsistancy should mean that we fall back to another means of identifying the link (CPL?) but I think that means we'll end up with the same result. >=20 > I agree but I guess a lot of fuzz is because this is not clearly > stated in the draft -- should it or is it still an open issue? This > would practically mean that every time a "no" answer is received, the > current list of all known prefixes on the link is checked in order to > confirm that the RA doesn't contain a prefix which is already known > to be on the link. >=20 > ...or am I just once again completely lost? :) No, I think you've pretty much got it. See above re: the open issue. >=20 > Might also be that we should write down something about the case when > a node changes the landmark prefix. If the node received a > zero-lifetime advertisement for the current landmark prefix, it > should pick another prefix. On the other hand, "5.2.3. The prefix > MUST have a non-zero valid lifetime" is a way to say it. I think so. :) Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 19:12:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHXq-0006I4-LW for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 19:12:06 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05440 for ; Thu, 28 Jul 2005 19:12:02 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR6XH3IAJS8Y6TDY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 09:11:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0CF158000F; Fri, 29 Jul 2005 09:11:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8ECAD3C005; Fri, 29 Jul 2005 09:11:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6SNBQa12027 for dna-list; Fri, 29 Jul 2005 09:11:26 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6SNBPw12023 for ; Fri, 29 Jul 2005 09:11:25 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR6XGR9M8K99PNDP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 09:11:18 +1000 Received: by localhost (Postfix, from userid 510) id D7885AB542; Fri, 29 Jul 2005 09:11:17 +1000 (EST) Received: from [192.168.1.2] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 2C9E04FB04; Fri, 29 Jul 2005 09:11:17 +1000 (EST) Date: Fri, 29 Jul 2005 09:11:21 +1000 From: Brett Pentland Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <10e14db205072805295655762b@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Syam Madanapalli Cc: JinHyeock Choi , Greg Daley , dna@eng.monash.edu.au Message-id: <42E96619.8060002@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> <10e14db205072805295655762b@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: > Hi Brett, > > I am replying little late :) > > On 7/19/05, Brett Pentland wrote: > >>Hi JinHyeock, >> >>I just read over your update and have a few observations. >> >>I see you now have triggering as well as caching. Triggering seems >>to make good sense when the AR and Point of Attachment (PoA) are >>co-located, but when they are not it seems that you are just >>reinventing RS/RA. Compared to the host initiating the RS, you >>save one store-and-forward time in the PoA, but that doesn't seem >>like much of a saving for a new protocol. > > > We have implemented the sending RS from AP while an MN is associating > with it and found that the RA comes at MN faster than the cached RA > sent from AP. We have surprised with these results. It took ~700 micro > seconds (0.7 ms) for an RA to reach MN from the completion of association. > And it is very easy to implement. I don't quite understand this. How can sending an RS to the AR, getting back an RA and then forwarding that RA to the MN be faster than just forwarding a cached RA? How much faster is it than the MN soliciting itself? > > We were sending RA from the Router kernel to MN MAC. We are sending RA > from the router without random delay as AP sends unicast RS with TSLLAO > option. > > A host can also send an RS but it may need to employ a some logic to avoid > random delay. Surely the same logic is needed for the AP or there would be collisions if there are multiple routers on the link. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 20:42:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIxG-0006EP-Ml for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 20:42:26 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10283 for ; Thu, 28 Jul 2005 20:42:23 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR70M4XFKU8WY01B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 10:41:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 40A388000E; Fri, 29 Jul 2005 10:41:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DC1763C011; Fri, 29 Jul 2005 10:41:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T0ecc13312 for dna-list; Fri, 29 Jul 2005 10:40:38 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T0ebw13308 for ; Fri, 29 Jul 2005 10:40:38 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR70L6KIWI99Q7VB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 10:40:22 +1000 Received: by localhost (Postfix, from userid 510) id 5DEEBAB542; Fri, 29 Jul 2005 10:40:22 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by curly.its.monash.edu.au (Postfix) with ESMTP id 34F4A4FB02 for ; Fri, 29 Jul 2005 10:40:20 +1000 (EST) Received: by zproxy.gmail.com with SMTP id m22so460600nzf for ; Thu, 28 Jul 2005 17:40:20 -0700 (PDT) Received: by 10.36.177.1 with SMTP id z1mr2534531nze; Thu, 28 Jul 2005 17:39:41 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 28 Jul 2005 17:39:40 -0700 (PDT) Date: Fri, 29 Jul 2005 09:39:40 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D In-reply-to: <42E96619.8060002@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Syam Madanapalli , Greg Daley , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb050728173919475446@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jbYaE9vuTQ1QOejHxaLWpNYyJ13g2+goAiWraCUINhfPL/6DEveOAqxKa8tZyXtSztACh6H6W/+d0lcoscaz3o3cVcodPf2ZXFN7TXtN88MHjPo5xi9ZRsx0PwW8ZdaXOqKN0WwCJw8YTuU3/A8As2ECeOb1kjvAfIZNPnsrgBk= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <004b01c58bcb$5c0c9e80$291d9069@sisa.samsung.com> <92e919fb0507181814d7f98bf@mail.gmail.com> <42DC9A4C.9010601@eng.monash.edu.au> <10e14db205072805295655762b@mail.gmail.com> <42E96619.8060002@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > I don't quite understand this. How can sending an RS to the AR, getting > back an RA and then forwarding that RA to the MN be faster than just > forwarding a cached RA? We also have difficulty understanding this. But our guess is that the processing inside a box takes more time than we anticipated. > How much faster is it than the MN soliciting > itself? Main difference between MN soliciting and AP soliciting is that, with the latter, we can realize a scheme (similar to Hash based FastRA) in a simpler way. We can assume that an AP knows all the ARs in a link. So AP can send UNICAST RS (to remove random delay) and solicit ARs in turns (for load balancing). When a new host is attached to the AP, AP can sends an unicast RS to a chosen AR 1) with unspecified source address 2) with the host's MAC address in TSLLAO. Upon receiving the unicast RS, the AR can send an RA immediately (because it is solicited in unicast). in unicast (using TSLLAO) Also AP take turns to solicit ARs, such as this time AR1 next time AR2 to achieve load balancing. Hence no load balancing mechanism is needed in ARs. > Surely the same logic is needed for the AP or there would be collisions > if there are multiple routers on the link. Yes, AP needs some logic (but simpler one, in my opinion) and for hosts and routers, only TSLLAO is needed. Other than that there is nothing to change in them. How do you think of it? Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 21:06:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJKi-0004SI-GX for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 21:06:45 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11158 for ; Thu, 28 Jul 2005 21:06:37 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR71FFX4T68WY06G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 11:05:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F3F5380014; Fri, 29 Jul 2005 11:04:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id AA5D83C00E; Fri, 29 Jul 2005 11:04:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T14SI13602 for dna-list; Fri, 29 Jul 2005 11:04:28 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T14Rw13598 for ; Fri, 29 Jul 2005 11:04:27 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR71EY4XG08WY8VI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 11:04:22 +1000 Received: by localhost (Postfix, from userid 510) id 4945BAB543; Fri, 29 Jul 2005 11:04:22 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id C709B4FB07; Fri, 29 Jul 2005 11:04:20 +1000 (EST) Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6T145WP022228; Thu, 28 Jul 2005 21:04:05 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id A98F31E8B7F; Thu, 28 Jul 2005 20:54:40 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 9E42F1E81AC; Thu, 28 Jul 2005 20:54:40 -0400 (EDT) Received: from [68.36.161.46] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Thu, 28 Jul 2005 21:04:05 -0400 Date: Thu, 28 Jul 2005 21:04:05 -0400 From: Sathya Narayanan Subject: Re: [DNA] Re: Flash renumbering Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <2013623852.2385220136@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Erik - I have a question and a comment. What is your take on the likelihood of the number of prefixes on the link being large so that they cannot fit in a single CompleteRA? > > So, let me bring #prefixes back instead of the complete bit, here is > > what I propose when the prefixes don't fit in one RA: > > 1) Divide the prefixes into groups with atleast one common prefix so > > that each group will fit in a single RA. > > 2) Set the #prefixes field in the DNAO to the total number of prefixes > > (The semantics for this is "This is the number of prefixes on the link *I* know of"). > > I don't think #2 can work in a robust manner unless we apply normal > fragmentation/reassembly to such large RAs. And I don't think we need this complexity. I think I know why you say this. Anyway, #1 is still needed in the draft - we should include this in the issues list. thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 23:51:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyLtz-0006OT-6K for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 23:51:15 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17971 for ; Thu, 28 Jul 2005 23:51:11 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR77805G7Y8WY40U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 13:50:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 221C3AB545; Fri, 29 Jul 2005 13:50:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id DAA654FB07; Fri, 29 Jul 2005 13:50:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T3o3j15532 for dna-list; Fri, 29 Jul 2005 13:50:03 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T3o2w15528 for ; Fri, 29 Jul 2005 13:50:02 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR776YUN608WY40U@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 13:49:45 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2445CAB545; Fri, 29 Jul 2005 13:49:44 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 055644FB02; Fri, 29 Jul 2005 13:49:44 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 29 Jul 2005 13:49:44 +1000 Date: Fri, 29 Jul 2005 13:49:44 +1000 From: Greg Daley Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Brett Pentland , Syam Madanapalli , Greg Daley , dna@eng.monash.edu.au Message-id: <73cc5673bade.73bade73cc56@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, I've got my chair hat off and my blast goggles on: It looks like you've been doing some welding... ----- Original Message ----- [cut] > > How much faster is it than the MN soliciting > > itself? > > Main difference between MN soliciting and AP soliciting is that, > with the latter, we can realize a scheme (similar to Hash based > FastRA) in a simpler way. > > We can assume that an AP knows all the ARs in a link. > So AP can send UNICAST RS (to remove random delay) > and solicit ARs in turns (for load balancing). This would require (small) modification to RFC2461, as routers mandatorily perform 0-500ms backoff, regardless of the destination address of the RS. Also, you definitely need modified routers, but I guess that's handled by TSLLAO. > When a new host is attached to the AP, > AP can sends an unicast RS to a chosen AR > 1) with unspecified source address > 2) with the host's MAC address in TSLLAO. > > Upon receiving the unicast RS, > the AR can send an RA immediately > (because it is solicited in unicast). > in unicast (using TSLLAO) > > Also AP take turns to solicit ARs, > such as this time AR1 next time AR2 > to achieve load balancing. > > Hence no load balancing mechanism is needed > in ARs. This is actually using the hackiest part of TSLLAO ;) In some devices it won't be possible to modify the outbound MAC address of the packet on the router, but it seems in this environment, you could either discover the ones which handle the TSLLAO, or mandate modified routers. Should we leave that part in the TSLLAO draft for the moment then? :) > > Surely the same logic is needed for the AP or there would be > > collisions if there are multiple routers on the link. > > Yes, AP needs some logic (but simpler one, in my opinion) and > for hosts and routers, only TSLLAO is needed. > Other than that there is nothing to change in them. > > How do you think of it? I think that if protocols were in a beauty contest, it would be the ugliest cheetah around. It's really not possible to tell how much simpler it is, though. The APs need to track a list of all routers, some of which may not be trusted at L3 (Do they do SEND?). In each of the ARs, the RA delivery scheme needs to be modified (TSLLAO w/o Ncache, Delay removal for Unicast RS). In other schemes, ARs need to track other DNA routers. In each of the ARs, modifications to the RA delivery scheme are needed (TSLLAO, delay + scheduling modification, unicast response). Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jul 28 23:53:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyLwS-0006x0-6r for dna-archive@megatron.ietf.org; Thu, 28 Jul 2005 23:53:48 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18145 for ; Thu, 28 Jul 2005 23:53:44 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR77BTKV8I9ANCZ1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 13:53:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D4677AB546; Fri, 29 Jul 2005 13:53:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 895E34FB02; Fri, 29 Jul 2005 13:53:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T3rZD15596 for dna-list; Fri, 29 Jul 2005 13:53:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T3rZw15592 for ; Fri, 29 Jul 2005 13:53:35 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR77BQ80928Y6V9L@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 13:53:34 +1000 Received: by localhost (Postfix, from userid 510) id 781F7AB542; Fri, 29 Jul 2005 13:53:34 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4F88A4FB04; Fri, 29 Jul 2005 13:53:33 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKD00KJOET7FE@mailout2.samsung.com>; Fri, 29 Jul 2005 12:53:31 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKD00BRGET5PI@mmp1.samsung.com>; Fri, 29 Jul 2005 12:53:31 +0900 (KST) Date: Fri, 29 Jul 2005 09:19:33 +0530 From: Syam Madanapalli Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Syam Madanapalli Cc: Brett Pentland , JinHyeock Choi , Greg Daley , dna@eng.monash.edu.au Message-id: <04d401c593f0$8963cb60$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <70c9bc710217.71021770c9bc@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > Hi Syam, > > ----- Original Message ----- > [cut] >> >> We were sending RA from the Router kernel to MN MAC. We are >> sending RA from the router without random delay as AP sends >> unicast RS with TSLLAO option. > > Can I ask what the source address of the RS from the AP is? We are using unspecified source address. The otherway way we thought is to construct the link local address for the MN based on its MAC. > > I am interested in which features of TSLLAO are being used. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 00:40:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyMfx-000282-BZ for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 00:40:49 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20014 for ; Fri, 29 Jul 2005 00:40:45 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR78YA3YDM9APACC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 14:40:03 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A33BB80010; Fri, 29 Jul 2005 14:39:59 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4B4CA3C012; Fri, 29 Jul 2005 14:39:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T4dmB16125 for dna-list; Fri, 29 Jul 2005 14:39:48 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T4dlw16121 for ; Fri, 29 Jul 2005 14:39:47 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR78XZGBBY8WYDOY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 14:39:45 +1000 Received: by localhost (Postfix, from userid 510) id 892678000F; Fri, 29 Jul 2005 14:39:43 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by larry.its.monash.edu.au (Postfix) with ESMTP id 909753C011 for ; Fri, 29 Jul 2005 14:39:42 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so748386nzd for ; Thu, 28 Jul 2005 21:39:41 -0700 (PDT) Received: by 10.36.251.79 with SMTP id y79mr1548691nzh; Thu, 28 Jul 2005 21:39:09 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 28 Jul 2005 21:39:09 -0700 (PDT) Date: Fri, 29 Jul 2005 13:39:09 +0900 From: JinHyeock Choi Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <6f53a86ef2c7.6ef2c76f53a8@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Subba Reddy , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05072821395e6c0848@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CdVGhcdlbNo4fy8Qj95s/IvC2XfP53nUL6ZgvFCmpWa36QkKTk7SRNjIIeZD2/R66DIPf1IBKV8o97YlSQlPheHNO8jRht0v1wv4J9AW4L7oq2ZDvynkOuIPmKGJSUX3LW+KpDtqkrUAaLBpiHm4F7ejM5YNuhEOilzZEfFZAps= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <6f53a86ef2c7.6ef2c76f53a8@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > Link Identifiers > --------------------- > > A Host H, exists and moves around the Internet. > > On an link unvisited by the host, Link L, a prefix, P is > retracted by one of the routers Router1. Subsequent to this, > the actual lowest prefix on the link is Prefix Q. > > > Another router, Router2 fails to see the prefix retraction. > (Perhaps RAs are lost, or Router1 didn't comply with > section 6.2.6 of RFC2461). > > The prefix is then reassigned within its previous > lifetime to another link, link M, whose lowest prefix > was prefix T. Link M, has also not been visited by > host H. > > Link Identifiers are in use on both Link L and > Link M. On Link M, all routers advertise Prefix P > as current LinkID and Prefix T as OldLinkID. > > On Link L, Router2 advertises prefix P as Current LinkID. > > If the host H arrives on Link L, it may receive > Prefix P as LinkID even though it is no longer present > on-link. The host would configure Prefix Q (or a higher prefix) > which is advertised in a PIO. > > If the LinkID is not contradicted, for example if there are > no other advertising routers left on the link, when the host > moves to Link M, it will also receive an RA with prefix P as > the Current LinkID. The Old LinkID will be ignored (it hasn't > been seen before). > > In this case, no change will be detected upon arrival to > link M, and the previous prefix will remain configured. The above example gives a problem because a linkid prefix is reassigned to the other link within 3 hours. The draft recommends that a linkid prefix should not be reassigned to other link within 3 hours. If network administrator follows the recommendation, such a problem won't happen. So I don't think we need to worry about this problem. > I understand that LinkID is quite robust against change. > > The point I originally was making was that while it is robust, > All of the schemes are flawed to some extent. I can't deny the possibility but don't think your example showed such a flaw. The false detection comes from human error. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 00:41:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyMg7-0002BM-SK for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 00:41:01 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20035 for ; Fri, 29 Jul 2005 00:40:55 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR78YH4HX88Y6Q8B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 14:40:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 23633AB543; Fri, 29 Jul 2005 14:40:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id ADB8F4FB05; Fri, 29 Jul 2005 14:40:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T4e6I16169 for dna-list; Fri, 29 Jul 2005 14:40:06 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T4e2w16163 for ; Fri, 29 Jul 2005 14:40:05 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR78Y6EPHA8Y6Q8B@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 14:39:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E2BBBAB542; Fri, 29 Jul 2005 14:39:54 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id CDD9E4FB05; Fri, 29 Jul 2005 14:39:54 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 29 Jul 2005 14:39:54 +1000 Date: Fri, 29 Jul 2005 14:39:54 +1000 From: Greg Daley Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Syam Madanapalli , Brett Pentland , JinHyeock Choi , Greg Daley , dna@eng.monash.edu.au Message-id: <7420ca73d3c0.73d3c07420ca@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Syam, ----- Original Message ----- [cut] > > Can I ask what the source address of the RS from the AP is? > > We are using unspecified source address. The otherway way we thought > is to construct the link local address for the MN based on its MAC. No, you're doing it the better way (though it always seemed hacky to have the TSLLAO in an unspecified source RS). Some nodes won't ever configure an EUI-64 (they're not SEND securable). Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 00:47:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyMmQ-0003fY-QT for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 00:47:31 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20337 for ; Fri, 29 Jul 2005 00:47:26 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR797E5ED49APOYS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 14:47:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C2188000E; Fri, 29 Jul 2005 14:47:20 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 443D73C012; Fri, 29 Jul 2005 14:47:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T4lFa16310 for dna-list; Fri, 29 Jul 2005 14:47:15 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T4lEw16306 for ; Fri, 29 Jul 2005 14:47:14 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR796WC4NA8Y6VTW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 14:46:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B6CBF8000D; Fri, 29 Jul 2005 14:46:56 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id A1B2F3C00B; Fri, 29 Jul 2005 14:46:56 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 29 Jul 2005 14:46:56 +1000 Date: Fri, 29 Jul 2005 14:46:56 +1000 From: Greg Daley Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Subba Reddy , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <743021744ce8.744ce8743021@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Dear JinHyeock, ----- Original Message ----- [cut] > > > > In this case, no change will be detected upon arrival to > > link M, and the previous prefix will remain configured. > > The above example gives a problem because a linkid prefix is > reassigned to the other link within 3 hours. > > The draft recommends that a linkid prefix should not be reassigned > to other link within 3 hours. > > If network administrator follows the recommendation, such > a problem won't happen. So I don't think we need to worry about > this problem. In None of the cases, is there an error unless there is reassignment of the prefix within the lifetime of the RA, and the timeout of information over an interval (?? don't know if it is 3 hours) has been previously described as a minor modification to both CompleteRA and Landmarks. These were all assumed to apply the same technique. So if we wait 3 hours, they are all equally robust (perfectly so). This is the common case with all the examples presented thus far. What has been discussed recently on list was precisely the issue of operators reassigning prefixes without following recommendations. If you believe this is not an important issue, we can check if others think so too, and avoid inventing cases for it. Thanks for your help, Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 01:15:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyNDO-0001mk-CL for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 01:15:23 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21265 for ; Fri, 29 Jul 2005 01:15:20 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR7A5VOSX09APJGH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 15:14:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 88C77AB543; Fri, 29 Jul 2005 15:14:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 386244FB02; Fri, 29 Jul 2005 15:14:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T5Dua16604 for dna-list; Fri, 29 Jul 2005 15:13:56 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T5Dsw16599 for ; Fri, 29 Jul 2005 15:13:54 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR7A4ZFRF49APJGH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 15:13:38 +1000 Received: by localhost (Postfix, from userid 510) id BE18D8000E; Fri, 29 Jul 2005 15:13:38 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by larry.its.monash.edu.au (Postfix) with ESMTP id D4E093C011 for ; Fri, 29 Jul 2005 15:13:37 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so754641nzd for ; Thu, 28 Jul 2005 22:13:36 -0700 (PDT) Received: by 10.37.20.59 with SMTP id x59mr2594195nzi; Thu, 28 Jul 2005 22:13:01 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Thu, 28 Jul 2005 22:13:01 -0700 (PDT) Date: Fri, 29 Jul 2005 14:13:01 +0900 From: JinHyeock Choi Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <743021744ce8.744ce8743021@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Subba Reddy , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb050728221358416af8@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ECuOVI6C+nQoWHjSEyGKtfsJlBlW8x2xAclMO02jo2XZBSPGwWA2uD2Iyf+WHZy5j9JkaqCDBTWGakUMahET2cFnMu/pnYH9U7eTe4HFbTVagbdxBdXyEqL78jeGwZIyaSMdV64mSRx70/vkzy5kXyOpZ5x/jflvL1j77xb6DIY= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <743021744ce8.744ce8743021@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > In None of the cases, is there an error unless there is > reassignment of the prefix within the lifetime of the > RA, and the timeout of information over an interval > (?? don't know if it is 3 hours) has been previously > described as a minor modification to both CompleteRA and > Landmarks. > > These were all assumed to apply the same technique. > > So if we wait 3 hours, they are all equally robust > (perfectly so). This is the common case with all > the examples presented thus far. No, the above technique concerns only for "flash renumbering and early reassignment" but there were examples which were not related to "flash renumbering and early reassignment". > What has been discussed recently on list was precisely > the issue of operators reassigning prefixes without > following recommendations. The example I gave Erik has nothing to do with reassignment. I think you have a misconception. The synchronization issues raised so far don't concerns only "flash renubmering and early reassignment". They also deal with "flassping" or "Temporary lack of synchronization." Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 02:11:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyO5w-0000Cg-Fm for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 02:11:46 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04127 for ; Fri, 29 Jul 2005 02:11:39 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR7C3HGF1M8WYBAH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Jul 2005 16:10:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E3E3BAB54D; Fri, 29 Jul 2005 16:09:41 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 74DD24FB09; Fri, 29 Jul 2005 16:09:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6T69Pl17273 for dna-list; Fri, 29 Jul 2005 16:09:25 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6T69Ow17269 for ; Fri, 29 Jul 2005 16:09:24 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR7C2V5K4I9APNHV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Jul 2005 16:09:12 +1000 Received: by localhost (Postfix, from userid 510) id 28577AB545; Fri, 29 Jul 2005 16:09:12 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id F2FC84FB04; Fri, 29 Jul 2005 16:09:10 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKD0014YL37L2@mailout1.samsung.com>; Fri, 29 Jul 2005 15:09:07 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKD00BO9L34PI@mmp1.samsung.com>; Fri, 29 Jul 2005 15:09:07 +0900 (KST) Date: Fri, 29 Jul 2005 11:35:08 +0530 From: Syam Madanapalli Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , JinHyeock Choi Cc: Brett Pentland , Syam Madanapalli , Greg Daley , dna@eng.monash.edu.au Message-id: <056401c59403$7ab174b0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <73cc5673bade.73bade73cc56@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, [cut] >> >> We can assume that an AP knows all the ARs in a link. >> So AP can send UNICAST RS (to remove random delay) >> and solicit ARs in turns (for load balancing). > > This would require (small) modification to RFC2461, as > routers mandatorily perform 0-500ms backoff, regardless > of the destination address of the RS. The random delay is to avoid simultaneos access to the medium, in this case there is only one router that is sending an RA. However all implementations may not do that, in such cases we need the modification. > > Also, you definitely need modified routers, but I guess > that's handled by TSLLAO. Yes. Also TSLLAO is not required all the time, in such cases the router would send multicast RA. > >> When a new host is attached to the AP, >> AP can sends an unicast RS to a chosen AR >> 1) with unspecified source address >> 2) with the host's MAC address in TSLLAO. >> >> Upon receiving the unicast RS, >> the AR can send an RA immediately >> (because it is solicited in unicast). >> in unicast (using TSLLAO) >> >> Also AP take turns to solicit ARs, >> such as this time AR1 next time AR2 >> to achieve load balancing. >> >> Hence no load balancing mechanism is needed >> in ARs. > > This is actually using the hackiest part of TSLLAO ;) > In some devices it won't be possible to modify the > outbound MAC address of the packet on the router, but > it seems in this environment, you could either discover > the ones which handle the TSLLAO, or mandate modified > routers. > > Should we leave that part in the TSLLAO draft for > the moment then? :) > >> > Surely the same logic is needed for the AP or there would be >> > collisions if there are multiple routers on the link. >> >> Yes, AP needs some logic (but simpler one, in my opinion) and >> for hosts and routers, only TSLLAO is needed. >> Other than that there is nothing to change in them. >> >> How do you think of it? > > I think that if protocols were in a beauty contest, it would > be the ugliest cheetah around. > > It's really not possible to tell how much simpler it is, though. > The APs need to track a list of all routers, some of which may > not be trusted at L3 (Do they do SEND?). APs either can be manually configured or can be learnt from RAs. I am thinking that APs/Base Stations are more trustable nodes. Are you saying the APs may be trustable at L2 but not at L3? I do not know much about SEND, but I think it can be used if required. > In each of the ARs, > the RA delivery scheme needs to be modified (TSLLAO w/o Ncache, > Delay removal for Unicast RS). > > In other schemes, ARs need to track other DNA routers. In > each of the ARs, modifications to the RA delivery scheme are > needed (TSLLAO, delay + scheduling modification, unicast response). > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 10:53:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWFF-000114-09 for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 10:53:53 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14963 for ; Fri, 29 Jul 2005 10:53:49 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR7UDM1K2S8WYJQI@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 00:53:27 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8F5DA8000D; Sat, 30 Jul 2005 00:53:15 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4DEA23C00C; Sat, 30 Jul 2005 00:53:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TEksd23226 for dna-list; Sat, 30 Jul 2005 00:46:54 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TEkrw23222 for ; Sat, 30 Jul 2005 00:46:53 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR7U5D5YH28WYJPL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 00:46:37 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DB30F8000D; Sat, 30 Jul 2005 00:46:36 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id C4FA13C00C; Sat, 30 Jul 2005 00:46:36 +1000 (EST) Received: from [150.169.1.105] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 30 Jul 2005 00:46:36 +1000 Date: Sat, 30 Jul 2005 00:46:36 +1000 From: Greg Daley Subject: Re: [DNA] Revised FRD (Fast Router Discovery) I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: JinHyeock Choi , Brett Pentland , Syam Madanapalli , Greg Daley , dna@eng.monash.edu.au Message-id: <7609bb763ef0.763ef07609bb@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Syam, ----- Original Message ----- [cut] > > Also, you definitely need modified routers, but I guess > > that's handled by TSLLAO. > > Yes. Also TSLLAO is not required all the time, in such cases > the router would send multicast RA. I think that it's OK for the router to send a multicast RA, but it may be necessary to get a fast response from the router to use TSLLAO in the RS, otherwise the response is at the mercy of the MIN_DELAY_BETWEEN_RAS interval. [cut] > > > > It's really not possible to tell how much simpler it is, though. > > The APs need to track a list of all routers, some of which may > > not be trusted at L3 (Do they do SEND?). > > APs either can be manually configured or can be learnt from RAs. > I am thinking that APs/Base Stations are more trustable nodes. > Are you saying the APs may be trustable at L2 but not at L3? > I do not know much about SEND, but I think it can be used if > required. I was thinking the other way around: that the APs may need to be able to trust the routers, in order to select appropriate routers to solicit. Also I don't think APs are trustable, except if there's a particular reason to trust them - which could be described if need be (I was concentrating on trust of ARs though so this may not be necessary). Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 11:01:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWMX-000373-O6 for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 11:01:26 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15655 for ; Fri, 29 Jul 2005 11:01:22 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR7UNAK26W9APOX1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 01:01:09 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EE60D8000E; Sat, 30 Jul 2005 01:01:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 993D33C012; Sat, 30 Jul 2005 01:01:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TEtXO23337 for dna-list; Sat, 30 Jul 2005 00:55:33 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TEtXw23333 for ; Sat, 30 Jul 2005 00:55:33 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR7UG0II548WYJQR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 00:55:17 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F09198000E; Sat, 30 Jul 2005 00:55:11 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id CECD23C003; Sat, 30 Jul 2005 00:55:11 +1000 (EST) Received: from [150.169.1.105] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 30 Jul 2005 00:55:11 +1000 Date: Sat, 30 Jul 2005 00:55:11 +1000 From: Greg Daley Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Subba Reddy , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <75c83775f96d.75f96d75c837@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, I'll try to have a look back through the thread at the other issues described (and particularly the example mentioned below). I may not respond quickly due to the large number of messages on this topic... It would be good to see what the most critical subset of issues regarding synchronization are still contentious. Hopefully it is smaller than we originally thought. If that's the case, we may be ablem to start a new thread with just what is left (and make it easier for people to see the remnant issues). Does that sound like a plan? Greg ----- Original Message ----- From: JinHyeock Choi Date: Friday, July 29, 2005 3:13 pm Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix > Greg > > > In None of the cases, is there an error unless there is > > reassignment of the prefix within the lifetime of the > > RA, and the timeout of information over an interval > > (?? don't know if it is 3 hours) has been previously > > described as a minor modification to both CompleteRA and > > Landmarks. > > > > These were all assumed to apply the same technique. > > > > So if we wait 3 hours, they are all equally robust > > (perfectly so). This is the common case with all > > the examples presented thus far. > > No, the above technique concerns only for "flash renumbering > and early reassignment" but there were examples which were > not related to "flash renumbering and early reassignment". > > > What has been discussed recently on list was precisely > > the issue of operators reassigning prefixes without > > following recommendations. > > The example I gave Erik has nothing to do with > reassignment. > > I think you have a misconception. The synchronization issues > raised so far don't concerns only "flash renubmering and early > reassignment". They also deal with "flassping" or "Temporary > lack of synchronization." > > Best Regards > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 11:57:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXEM-0003Ci-3f for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 11:57:02 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18911 for ; Fri, 29 Jul 2005 11:56:58 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR7WLHEWDS9APRIA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 01:56:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7FD23AB543; Sat, 30 Jul 2005 01:56:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 27DFC4FB04; Sat, 30 Jul 2005 01:56:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TFpCh24050 for dna-list; Sat, 30 Jul 2005 01:51:12 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TFpBw24046 for ; Sat, 30 Jul 2005 01:51:11 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR7WE7OWY28WYJXA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 01:51:01 +1000 Received: by localhost (Postfix, from userid 510) id E635CAB543; Sat, 30 Jul 2005 01:51:00 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id DE37E4FB06; Sat, 30 Jul 2005 01:50:58 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6TFoscn012751; Fri, 29 Jul 2005 08:50:54 -0700 (PDT) Received: from [129.157.211.70] (dhcp-gnb07-211-70.France.Sun.COM [129.157.211.70]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6TFopxM732822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jul 2005 08:50:52 -0700 (PDT) Date: Fri, 29 Jul 2005 07:52:51 -0700 From: Erik Nordmark Subject: Re: [DNA] Re: Flash renumbering In-reply-to: <2013623852.2385220136@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Brett Pentland , greg.daley@eng.monash.edu.au, Syam Madanapalli , James Kempf , Dna Message-id: <42EA42C3.80902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <2013623852.2385220136@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Erik - > > I have a question and a comment. > > What is your take on the likelihood of the number of prefixes on the > link being large so that they cannot fit in a single CompleteRA? Two different answers: I guess the probability is 1.0 that somebody somewhere will configure such a link. I guess that this will be very unlikely in common operations, thus the probability of a link selected at random will have such a large number of prefixes could be very small. (As we understand it today, multiple prefixes help with graceful renumbering, and are used in scalable multihoming, but I don't today see an argument for this resulting in more than a handful of prefixes.) > I think I know why you say this. Anyway, #1 is still needed in the > draft - we should include this in the issues list. ok Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 15:46:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaoU-0004zN-QZ for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 15:46:34 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04544 for ; Fri, 29 Jul 2005 15:46:31 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR84M0G6Z49APNAI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 05:46:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B2055AB543; Sat, 30 Jul 2005 05:46:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 77C154FB09; Sat, 30 Jul 2005 05:46:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TJeHp26829 for dna-list; Sat, 30 Jul 2005 05:40:17 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TJeGw26825 for ; Sat, 30 Jul 2005 05:40:16 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR84E4PM4I8WYKMY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 05:40:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B49188000E for ; Sat, 30 Jul 2005 05:40:00 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8B0633C012 for ; Sat, 30 Jul 2005 05:39:59 +1000 (EST) Received: from [150.169.1.105] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 30 Jul 2005 05:39:59 +1000 Date: Sat, 30 Jul 2005 05:39:59 +1000 From: Greg Daley Subject: [DNA] Link Identification Scheme Comparison Powerpoint slides Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <765324765632.765632765324@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi, Here is a comparison of the different Link Identification features available in draft-pentland-dna-protocol and draft-jinchoi-dna- protocol2 It's aimed at providing a feature distinction, although there are also a couple of outstanding issues to be considered separately. http://www.ctie.monash.edu.au/dna/DNASolnComparison_28July2005.ppt Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 16:28:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybSZ-00088M-Ny for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 16:28:00 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07251 for ; Fri, 29 Jul 2005 16:27:56 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR86208R1C8Y70VY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 06:27:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EEB31AB543; Sat, 30 Jul 2005 06:27:29 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9641C4FB03; Sat, 30 Jul 2005 06:27:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TKM6Y27332 for dna-list; Sat, 30 Jul 2005 06:22:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TKM4w27328 for ; Sat, 30 Jul 2005 06:22:04 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR85U21IQ299Q9JZ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 06:21:52 +1000 Received: by localhost (Postfix, from userid 510) id 7BB3C8000D; Sat, 30 Jul 2005 06:21:52 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by larry.its.monash.edu.au (Postfix) with ESMTP id 75FDE3C012 for ; Sat, 30 Jul 2005 06:21:50 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so968383nzd for ; Fri, 29 Jul 2005 13:21:49 -0700 (PDT) Received: by 10.36.25.4 with SMTP id 4mr3439123nzy; Fri, 29 Jul 2005 13:21:12 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 29 Jul 2005 13:21:12 -0700 (PDT) Date: Sat, 30 Jul 2005 05:21:12 +0900 From: JinHyeock Choi Subject: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <42E8FF5E.6050109@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <92e919fb05072913215c0f15a0@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eh0GunM4vc0aucCEqg5T/9t3KadXCDZezMfodqRtNdiyDoIb1+ap/Kk0FdRcCARdamcQNltFDVq/LEYxUdJVOOtG/G6RPVyrtTnir5jm7W/q5/JkBTo/4BlklAlrOjl0KOf9Y8uJlGaBU8rWIvlY2Wh3nsOxvjJa7z6qgvc300Q= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E63568.2080503@sun.com> <92e919fb0507270815223243ee@mail.gmail.com> <42E8FF5E.6050109@sun.com> Content-Transfer-Encoding: 7BIT Erik > ok > But when taking that draft, what guarantees can you provide when you > need to use a combination of linkID and CPL/completeRA? > You end up with these combinations when > 1. Some but not all routers on the link are new (i.e., are doing linkID) > 2. The host moves to/from a link where not all routers on the link are new > My gut feel is that there are many places where you have to defer to > prefix comparisons, and if the prefix list you are comparing against is > based on CPL, then you have the CPL problem of needing reliably 'link > up' indications. But I haven't worked through all the cases to see if > this is indeed the case, or whether we can do better. If a host has 1) a linkid and 2) receives an RA with the prefix with I-bit set, it can make a decision properly. So even in the above two cases, hosts may satisfy these two conditions to properly check for link change without resorting to prefix comparison. But if either of two conditions is not satisfied, the host need to fall back on CPL. In this case, we need reliable "Link UP" indication. > So assume that linkA has R1 which uses linkID, and R2 which does not. > linkB has R3 which does not implement linkID. > > A host H is on linkB and moves to linkA. > Assume H receives the RA from R2 before the RA from R1. How can it tell > whether it should assume that R2 is on the same link as R3, or not? H should use CPL because it doesn't have any linkid prefix. > When it receives the RA from R2, the only thing it can rely on is the > link up notification (R3 and R3 do not advertise any common prefixes), > since R2 and R3 could be two old routers that are on the same link and > announce disjoint prefixes. It's not clear to me. What can Link UP say to host H? It can't say anything definite about whether link change happens or not. > Thus link up is at least needed "temporarily"; once the RA from R1 > arrives (which includes all the prefixes for linkA I assume), then the > host can tell that the prefixes it got from R3 are really not on the new > link; but until that RA is receives the host needs to rely on the link up. I still don't understand what kind of information can Link Up can provide to H. > Do you see a way around this? Sorry, I still don't catch the problem clearly. This is what I have in mind. After H moves from LinkB to LinkA, it receives a hint for a possible link change. To make Link UP presence the smallest, I assume H used the lack of RA from R3 as a hint. H missed 3 RAs from R3 and came to suspect a link change. Because H doesn't have a linkid prefix, it needs to use CPL. So H activates CPL module and sends an RS. Because H relies on CPL in this case, it needs Link UP. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 16:28:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybSe-0008A0-Ot for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 16:28:04 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07269 for ; Fri, 29 Jul 2005 16:28:01 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR861UDZJM9APBUP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 06:27:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 40C78AB545; Sat, 30 Jul 2005 06:27:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id EC7274FB07; Sat, 30 Jul 2005 06:27:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TKLou27320 for dna-list; Sat, 30 Jul 2005 06:21:50 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TKLmw27316 for ; Sat, 30 Jul 2005 06:21:48 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR85TWJN809APNPC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 06:21:45 +1000 Received: by localhost (Postfix, from userid 510) id 3BE96AB543; Sat, 30 Jul 2005 06:21:45 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by moe.its.monash.edu.au (Postfix) with ESMTP id 65C504FB03 for ; Sat, 30 Jul 2005 06:21:43 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so968350nzd for ; Fri, 29 Jul 2005 13:21:42 -0700 (PDT) Received: by 10.36.157.1 with SMTP id f1mr3359199nze; Fri, 29 Jul 2005 13:20:56 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 29 Jul 2005 13:20:56 -0700 (PDT) Date: Sat, 30 Jul 2005 05:20:56 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix In-reply-to: <42E8FCF4.1010304@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <92e919fb050729132020b0eca@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N5Kyz/ZbTi6i0p0uoQw4k4kZe3XOZU7toS3JmE6g4vS5KfaOGAvXDJHaDtGqrtMcewDVAEylTLTngxP2E9SSDLIUS9logOACvQJiM2QBi15Jl5+9nfqXAeVkctyROKBxtMKCR4bIY1JY5aBYqpd7HAsjnXq72PRMpKlM0LIrZqQ= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42DDA20F.2080400@eng.monash.edu.au> <92e919fb05072100096d56000f@mail.gmail.com> <42E3E751.1050009@sun.com> <92e919fb050725005475659f66@mail.gmail.com> <42E59B91.2050007@sun.com> <92e919fb05072521531fba472d@mail.gmail.com> <42E632D5.904@sun.com> <92e919fb050727004264c293e@mail.gmail.com> <42E8FCF4.1010304@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > > ok. From now on, I will use the term "flapping" only in the sense you > > describes. > > > > For the more general case I presented, I will use the term 'LOS (Lack > > of Synchronization). Is it ok? > > ok, but see below. > Also, I don't think "out of synch" can be determined in a distributed > system, since there is always a non-zero delay. Hence if R1 sends a RA > and R2 and R3 receives it, an observer can't tell which or R2 and R3 > updated the prefix list first (or whether they did it at exactly the > same time). This is intriguing. I didn't think "out of synch" in a distributed system point of view. Rather I naively assumed Newtonian absolute time and an omniscient observer. Let me think it over more. > > ok. I think it's also important that DNA solution cope gracefully with > > more general case of temporary LOS (Lack of Synchronization). If > > DNA solution can deal with LOS, I think it can deal with flapping > > automatically. > > I don't see using the LOS term as helpful here. > LOS captures the case when router1's list of prefixes is out of date > with router2's two list of prefixes, even if only for a nanosecond. > > What matters is the sequence of events that are observable. I am wondering whether LOS (at least the ones which cause problems) always entails flapping. This also let me think over more. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 16:28:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybSy-0008GY-1b for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 16:28:24 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07295 for ; Fri, 29 Jul 2005 16:28:20 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR862JWWRG8WYJZ0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 06:28:07 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72C7D8000D; Sat, 30 Jul 2005 06:27:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2FBD63C003; Sat, 30 Jul 2005 06:27:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TKMYv27343 for dna-list; Sat, 30 Jul 2005 06:22:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TKMYw27339 for ; Sat, 30 Jul 2005 06:22:34 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR85UM5GJY8WYJZ0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 06:22:19 +1000 Received: by localhost (Postfix, from userid 510) id A032CAB542; Sat, 30 Jul 2005 06:22:19 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by curly.its.monash.edu.au (Postfix) with ESMTP id CF77E4FB06 for ; Sat, 30 Jul 2005 06:22:17 +1000 (EST) Received: by zproxy.gmail.com with SMTP id z31so968485nzd for ; Fri, 29 Jul 2005 13:22:16 -0700 (PDT) Received: by 10.36.133.15 with SMTP id g15mr3375913nzd; Fri, 29 Jul 2005 13:21:38 -0700 (PDT) Received: by 10.36.4.7 with HTTP; Fri, 29 Jul 2005 13:21:38 -0700 (PDT) Date: Sat, 30 Jul 2005 05:21:38 +0900 From: JinHyeock Choi Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <75c83775f96d.75f96d75c837@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Subba Reddy , Erik Nordmark , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <92e919fb050729132174c795d8@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CMxjH7fSd6XDTNeX0f0i87HhbWfE5bHwdX4z/1cxptNYS2qRWvqbbvgKQJ+gUcizx0Mbjgnwj7a9JiO7gcRCCkUM0XPgiPO1ATh4X8zKPtyKSG3fOLTglVT/jhpl23/JNTmBSMcRucSUJSmrAQvV7RIWtjlqKY6ythYuFSeVJQg= X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <75c83775f96d.75f96d75c837@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg > It would be good to see what the most critical > subset of issues regarding synchronization > are still contentious. Hopefully it is smaller > than we originally thought. > > If that's the case, we may be ablem to start a new > thread with just what is left (and make it easier > for people to see the remnant issues). ok. Also I wish we make it clear how Landmark/ CompleteRA checks for link change. For example, Erik proposed that a known prefix in an RA would overrule the NO in Landmark option. But that is not reflected in the draft. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jul 29 19:14:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dye41-0004v3-S2 for dna-archive@megatron.ietf.org; Fri, 29 Jul 2005 19:14:49 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16143 for ; Fri, 29 Jul 2005 19:14:43 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR8BV4YWCU9APSIG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 09:14:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C1579AB545; Sat, 30 Jul 2005 09:14:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 755334FB06; Sat, 30 Jul 2005 09:14:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6TN6ft29333 for dna-list; Sat, 30 Jul 2005 09:06:41 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6TN6ew29329 for ; Sat, 30 Jul 2005 09:06:40 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR8BL2Q7MM9APQC1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 09:06:26 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10FBEAB543; Sat, 30 Jul 2005 09:06:26 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id F22C74FB02; Sat, 30 Jul 2005 09:06:25 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 30 Jul 2005 09:06:25 +1000 Date: Sat, 30 Jul 2005 09:06:25 +1000 From: Greg Daley Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Brett Pentland Cc: Dna Message-id: <764a3975f729.75f729764a39@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi JinHyeock, ----- Original Message ----- [cut] > > ok. Also I wish we make it clear how Landmark/ CompleteRA > checks for link change. For example, Erik proposed that > a known prefix in an RA would overrule the NO in Landmark > option. But that is not reflected in the draft. The issue and resolution was raised after the draft cut-off. I think Brett is travelling now, but I'll ask him to make a new issue to track this at: http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASolution1 Greg. From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 30 03:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DylvS-0003Qr-OU for dna-archive@megatron.ietf.org; Sat, 30 Jul 2005 03:38:31 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26689 for ; Sat, 30 Jul 2005 03:38:28 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR8TG5SA928Y74N4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 17:38:13 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E8B8DAB545; Sat, 30 Jul 2005 17:37:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A17B84FB08; Sat, 30 Jul 2005 17:37:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6U7WBY02530 for dna-list; Sat, 30 Jul 2005 17:32:11 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6U7WBw02526 for ; Sat, 30 Jul 2005 17:32:11 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR8T8U5G008Y74MC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 17:31:58 +1000 Received: by localhost (Postfix, from userid 510) id DA769AB542; Sat, 30 Jul 2005 17:31:57 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2E7F64FB07; Sat, 30 Jul 2005 17:31:56 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKF00LKPJL5LI@mailout2.samsung.com>; Sat, 30 Jul 2005 16:31:53 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IKF00ADBJL34J@mmp2.samsung.com>; Sat, 30 Jul 2005 16:31:53 +0900 (KST) Date: Sat, 30 Jul 2005 12:57:53 +0530 From: Subba Reddy Subject: Re: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Message-id: <015501c594d8$34029b40$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <718816719555.719555718816@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, It is good to see all the time/space requirements at one place. I have few questions and comments. > > Greg > > Parameters: > ----------- > > P number of distinct prefixes on a link > p_r number of distinct prefixes received in pios from router r > l_r number 0of learned prefixes received in pios from router r > N number of links visited recently. > > > > Discussion of issues and assumptions: > ------------------------------------- > > Schemes are described with individual sub components, > as well as when combined in compound solutions (as proposed > in drafts). This made building the analysis easier. > > Proposed schemes from the drafts are marked as: **** (Proposed Scheme) > > Ignores number of routers on link I think, if we consider no. of routers on link, then for each RS 1. In Landmark method, all the routers in the link needs to compare the landmark prefix with the DNAPrefix List. 2. In LinkID method, routers just sends RAs, so no comaprision is required at the router side. > > > > Router Side storage and processing requirements. > ================================================ > > CompleteRA: > ----------- > Additional Storage: O(P) keep DNAPrefixList > > RA build time: O(P) traverse DNAPrefixList. > > RA processing: O(p_r) insertion of prefixes into hash table. > > Timers: 1 Expiry timer (callback or operation based) > > > Prefix Landmarks: > ----------------- > Additional Storage: O(P) keep DNAprefixlist > > RA build time: O(1) comparison of landmark with DNAPrefixList. I don't know, which complexity (best case or average case or worst case?) you have considered. As per my understanding, Best case complexity is O(1) as you have mentioned. Average and Worst case complexities are O(P). Please correct me, if anything is wrong. > > RA processing: O(p_r) insertion of prefixes into hash table. > > Timers: 1 Expiry timer (callback or operation based) > > > CompleteRA+PrefixLandmarks **** (Proposed Scheme) > ------------------------------------------------- > Additional Storage: O(P) keep DNAprefixlist > > RA build time: O(1) comparison of landmark with DNAPrefixList. > OR > O(P) traverse DNAPrefixList. > > > RA processing: O(p_r) insertion of prefixes into hash table. > > Timers: 1 Expiry timer (callback or operation based) > > > > Prefix LinkID **** (Proposed Scheme): > --------------------------------------- > Additional Storage: O(1) keep LinkID and Old LinkID I think storage requirement is O(P). If LinkID prefix is removed from the link, routers need to select the next smaller prefix from prefix list. I think, here also, if you have considered only the cases, where LinkID will not change, O(1) is fine. > > RA Build time: O(1) selection of LinkID and Old LinkID > > > RA Processing: O(p_r) comparison of each prefix with LinkID > I think, this is O(1) because, only linkID in the RA needs to be compared with the LinkID at the host. > Timers: 1 expiry timer (callback or operation based) > > > Unmodified RFC 2461 Routers: > ---------------------------- > Additional Storage: zero > > RA Build time: O(1) (add pio processing time for own prefixes) > > RA processing: O(1) (RA consistency checks) > OR > zero > > Timers: 0 or 1 expiry timer (prefix retraction) > > > > > > > > > Host Side storage and processing requirements. > ============================================== > > CompleteRA: > ----------- > Storage: O(P) Prefix List of distinct prefixes on link > > RA Processing: O(P) = O(p_r+l_r) storage of prefixes in prefix list. > > RS build time: O(1), normal RS. > OR > zero, no RS. > > Learning time: 1 message > > > Prefix Landmark: > ---------------- > Storage: O(1) landmark prefix (minimum) > O(P) prefix list (maximum/robust). > > RA Processing: O(1) landmark inpsection > > RS build time: O(1), normal RS + selected landmark. > > Learning time: 1 message > > > CompleteRA+Prefix Landmark **** (Proposed Scheme -- see below for CPL): > -------------------------------------------------- > Storage: O(P) Prefix List of distinct prefixes on link > > RA Processing: O(1)landmark inspection > or > O(P) storage of prefixes in prefix list. > > RS build time: O(1), normal RS. > OR > O(1), normal RS + selected landmark > OR > zero, no RS. > > Learning time: 1 message ( more if Landmark:"NO" is incomplete) > > > > > Prefix LinkID **** (Proposed Scheme -- see below for CPL): > ------------------------------------- > Storage: O(1) Prefix LinkID (minimum) > O(N) set of linkIDs received recently on different IP links. > I think, here N is the number of different LinkIDs (if at all) advertised in the last 1.5hrs on the link. > > RA Processing: O(1) LinkID inspection, comparison to recent LinkIDs. > > RS build time: O(1), normal RS. > OR > zero, no RS. > > Learning time: 1 message. > Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 30 08:59:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyqwV-0004e6-NF for dna-archive@megatron.ietf.org; Sat, 30 Jul 2005 08:59:56 -0400 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08282 for ; Sat, 30 Jul 2005 08:59:53 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR94OUWON48WYNST@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Jul 2005 22:59:47 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9C2AAB545; Sat, 30 Jul 2005 22:59:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8F6674FB07; Sat, 30 Jul 2005 22:59:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6UCrgV06173 for dna-list; Sat, 30 Jul 2005 22:53:42 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6UCrew06169 for ; Sat, 30 Jul 2005 22:53:41 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR94HE02829APT35@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Jul 2005 22:53:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C88F2AB542; Sat, 30 Jul 2005 22:53:25 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id B57FE4FB04; Sat, 30 Jul 2005 22:53:25 +1000 (EST) Received: from [69.248.113.247] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 30 Jul 2005 22:53:25 +1000 Date: Sat, 30 Jul 2005 22:53:25 +1000 From: Greg Daley Subject: Re: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: dna@eng.monash.edu.au, syam.madanpalli@samsung.com, jinchoe@gmail.com Message-id: <7797aa775c2a.775c2a7797aa@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Subba, Thanks for your analysis. I've asked the draft authors for further clarification on the points you've raised. If you've got a reference to the text which indicates what you meant, we may be able to clear it up ourselves. ----- Original Message ----- [cut] > > I think, if we consider no. of routers on link, then for each RS > 1. In Landmark method, all the routers in the link needs to > compare the > landmark prefix > with the DNAPrefix List. > 2. In LinkID method, routers just sends RAs, so no comaprision is > requiredat the router side. Yes, this is the O(1) operation - hash table lookup for Landmark and for CompleteRA. This is constant time. It is also constant time to just send the RA in LinkID, as it has to lookup the LinkID (one operartion or two operations, if you include OldLinkID). [cut] > > Prefix Landmarks: > > ----------------- > > Additional Storage: O(P) keep DNAprefixlist > > > > RA build time: O(1) comparison of landmark with DNAPrefixList. > > I don't know, which complexity (best case or average case or worst > case?)you have considered. > As per my understanding, > Best case complexity is O(1) as you have mentioned. > Average and Worst case complexities are O(P). I'm looking at average case complexity. With a fair sized hash table, this is what you get. Of course there are pathological cases with badly built hashes, or small tables which are worse. Worst case therefore degenerates to linear, but you'd practically never get it if there was a well distributed hash, and the collision probabilities for a particular value were low enough. This is fairly well known for hash tables. [cut] > > > > Prefix LinkID **** (Proposed Scheme): > > --------------------------------------- > > Additional Storage: O(1) keep LinkID and Old LinkID > > I think storage requirement is O(P). If LinkID prefix is removed from > the link, routers need to select the next smaller prefix from > prefix list. > > I think, here also, if you have considered only the cases, where > LinkIDwill not change, O(1) is fine. This is mentioned in the assumptions at the top. I guess that if there's only going to be one prefix removed in a period, the next smaller prefix is all that's required. In the general case though, O(P) is correct. > > > > RA Build time: O(1) selection of LinkID and Old LinkID > > > > > > RA Processing: O(p_r) comparison of each prefix with LinkID > > > > I think, this is O(1) because, only linkID in the RA needs to be > comparedwith the LinkID at the host. No actually, the learned component of the RA isn't inspected, for robustness sake (described in the draft: Syam or JinHyeock may also correct me on this). This means all the PIOs need to be checked. [cut] > > > > Prefix LinkID **** (Proposed Scheme -- see below for CPL): > > ------------------------------------- > > Storage: O(1) Prefix LinkID (minimum) > > O(N) set of linkIDs received recently on different IP > links.> > > I think, here N is the number of different LinkIDs (if at all) > advertised in the last 1.5hrs on the link. Actually, I think this is the number of prefixes known on the host: From section 1.3: Paragraph4: "...the hosts track the list of linkid prefixes they've received in the last 1.5 hours to generate "the linkid prefix list (LinkidPrefixList)". Perhaps, there is confusion, because in most cases, the LinkIDPrefixList is cleared out by the host each time it moves link Is this the current thinking? In that case, then the maximum size is P, but the mean size is much lower (typically 1). I'll update the description of the assumptions with the ideas mentioned here. Greg From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 30 13:01:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyuik-0005Ka-4D for dna-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:01:58 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19358 for ; Sat, 30 Jul 2005 13:01:54 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR9D5A0RBS99Q96W@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 31 Jul 2005 03:01:51 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 476EE8000E; Sun, 31 Jul 2005 03:01:45 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id EC9903C00D; Sun, 31 Jul 2005 03:01:44 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6UGtJR09117 for dna-list; Sun, 31 Jul 2005 02:55:19 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6UGtHw09113 for ; Sun, 31 Jul 2005 02:55:18 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LR9CX65BD28WYRNX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 31 Jul 2005 02:55:13 +1000 Received: by localhost (Postfix, from userid 510) id 2CA7CAB545; Sun, 31 Jul 2005 02:55:13 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2B3964FB09; Sun, 31 Jul 2005 02:55:10 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6UGt61d002136; Sat, 30 Jul 2005 09:55:07 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6UGsndi116410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 30 Jul 2005 09:54:54 -0700 (PDT) Date: Sat, 30 Jul 2005 09:55:32 -0700 From: Erik Nordmark Subject: [DNA] Re: LinkID v.s. Landmark Prefix In-reply-to: <92e919fb05072913215c0f15a0@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <42EBB104.9090701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <05a101c58be0$6546c880$016115ac@dcml.docomolabsusa.com> <42E4D368.2010803@sun.com> <92e919fb05072519444d670456@mail.gmail.com> <42E5A520.8070502@sun.com> <92e919fb05072520046d018db1@mail.gmail.com> <42E5AC37.1090603@sun.com> <92e919fb050725212266de187e@mail.gmail.com> <42E63568.2080503@sun.com> <92e919fb0507270815223243ee@mail.gmail.com> <42E8FF5E.6050109@sun.com> <92e919fb05072913215c0f15a0@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > If a host has 1) a linkid and 2) receives an RA with the prefix with I-bit set, > it can make a decision properly. So even in the above two cases, hosts > may satisfy these two conditions to properly check for link change without > resorting to prefix comparison. > > But if either of two conditions is not satisfied, the host need to fall back > on CPL. In this case, we need reliable "Link UP" indication. ok >>When it receives the RA from R2, the only thing it can rely on is the >>link up notification (R3 and R3 do not advertise any common prefixes), >>since R2 and R3 could be two old routers that are on the same link and >>announce disjoint prefixes. > > > It's not clear to me. What can Link UP say to host H? It can't > say anything definite about whether link change happens or not. Link UP indicates to the host that the RA from R3 and R2 could come from different links. If we want something which doesn't rely on link UP, the host has to always treat each RA as potentially being from a different link, which would be problematic when 1) the routers don't have a common prefix, and 2) the routers don't support DNA because in the absence of relying on a link UP in this case, the host will end up assuming that each time it receives a RA, it has moved to a different link. > After H moves from LinkB to LinkA, it receives a hint for > a possible link change. > > To make Link UP presence the smallest, I assume H used > the lack of RA from R3 as a hint. H missed 3 RAs from R3 > and came to suspect a link change. But that would take 90 minutes by default, since the periodic RAs arrive with 30 minute average interval. Or are you suggesting that the host should always send 3 RSes when it receives a link UP, so that it can use this to retire any old prefixes? In any case, I think that is orthogonal to whether or not we can come up with a scheme which works reliably even when there are no link UP notifications, for mixed links as well as links with no DNA capable routers. > Because H doesn't have a linkid prefix, it needs to use CPL. > So H activates CPL module and sends an RS. > > Because H relies on CPL in this case, it needs Link UP. So it seems like until every link in the Internet supports DNA (it isn't clear to me whether all routers on every link needs to support DNA, or whether it is sufficient to have one per link support it), then the hosts MUST rely on a reliable link up notification in order to always be able to detect movement. Is that correct? Erik From dna-owner@webcamserver.eng.monash.edu.au Sat Jul 30 15:34:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyx5x-0001MH-C1 for dna-archive@megatron.ietf.org; Sat, 30 Jul 2005 15:34:10 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25958 for ; Sat, 30 Jul 2005 15:34:03 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR9IGHQYZY9APOBE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 31 Jul 2005 05:33:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 47F8F80010; Sun, 31 Jul 2005 05:33:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id F39B43C011; Sun, 31 Jul 2005 05:33:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6UJSF714764 for dna-list; Sun, 31 Jul 2005 05:28:15 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6UJSDw14760 for ; Sun, 31 Jul 2005 05:28:13 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LR9I9JLVDY99Q2I2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 31 Jul 2005 05:27:58 +1000 Received: by localhost (Postfix, from userid 510) id 49144AB543; Sun, 31 Jul 2005 05:27:58 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id E003E4FB05; Sun, 31 Jul 2005 05:27:56 +1000 (EST) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j6UJRh6g006183; Sat, 30 Jul 2005 15:27:43 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id A99071E8203; Sat, 30 Jul 2005 15:18:15 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 9F3DE1E8108; Sat, 30 Jul 2005 15:18:15 -0400 (EDT) Received: from [68.36.161.46] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Sat, 30 Jul 2005 15:27:42 -0400 Date: Sat, 30 Jul 2005 15:27:42 -0400 From: Sathya Narayanan Subject: Re: [DNA] Re: LinkID v.s. Landmark Prefix Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: JinHyeock Choi , Syam Madanapalli , Brett Pentland , greg.daley@eng.monash.edu.au, James Kempf , Dna Message-id: <2412d21396.213962412d@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:47.27223 C:17 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) Content-Transfer-Encoding: 7BIT Erik - > So it seems like until every link in the Internet supports DNA (it isn't > clear to me whether all routers on every link needs to support DNA, or > whether it is sufficient to have one per link support it), It isn't clear to me either. But, IMHO, we should select a solution which works well in a link with both DNA and non-DNA routers. > then the hosts MUST rely on a reliable link up notification in order to always be > able to detect movement. Is that correct? We discussed this when the comparison slide sent by Greg was prepared. A CompleteRA message from the DNA router can tie all the prefixes on the link together and hence the host need not depend on link-up notification. Also, with prefix-landmark, if the host sends an RS with a prefix advertised by a non-DNA router, a DNA router will still confirm the prefix's presence on the link. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 01:20:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz6Fe-0005Sg-8i for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 01:20:42 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15209 for ; Sun, 31 Jul 2005 01:20:39 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRA2Y0W9OI99Q7NP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 31 Jul 2005 15:20:29 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2FF598000F; Sun, 31 Jul 2005 15:20:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D68343C003; Sun, 31 Jul 2005 15:20:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6V5Eai21572 for dna-list; Sun, 31 Jul 2005 15:14:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6V5EZw21568 for ; Sun, 31 Jul 2005 15:14:35 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRA2QJWJC48WYVWT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 31 Jul 2005 15:14:21 +1000 Received: by localhost (Postfix, from userid 510) id C42728000D; Sun, 31 Jul 2005 15:14:20 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0B2C73C00B; Sun, 31 Jul 2005 15:14:19 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKH00A437VS97@mailout3.samsung.com>; Sun, 31 Jul 2005 14:14:16 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKH00HLO7VQFP@mmp1.samsung.com>; Sun, 31 Jul 2005 14:14:16 +0900 (KST) Date: Sun, 31 Jul 2005 10:40:14 +0530 From: Subba Reddy Subject: Re: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au, JinHyeock Choi , Syam Madanapalli Message-id: <021601c5958e$2409e4d0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <7797aa775c2a.775c2a7797aa@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > [cut] > > > > I think, if we consider no. of routers on link, then for each RS > > 1. In Landmark method, all the routers in the link needs to > > compare the > > landmark prefix > > with the DNAPrefix List. > > 2. In LinkID method, routers just sends RAs, so no comaprision is > > requiredat the router side. > > Yes, this is the O(1) operation - hash table lookup for > Landmark and for CompleteRA. This is constant time. > > It is also constant time to just send the RA in LinkID, > as it has to lookup the LinkID (one operartion or two > operations, if you include OldLinkID). > ok. > > [cut] > > > Prefix Landmarks: > > > ----------------- > > > Additional Storage: O(P) keep DNAprefixlist > > > > > > RA build time: O(1) comparison of landmark with DNAPrefixList. > > > > I don't know, which complexity (best case or average case or worst > > case?)you have considered. > > As per my understanding, > > Best case complexity is O(1) as you have mentioned. > > Average and Worst case complexities are O(P). > > I'm looking at average case complexity. With a fair sized hash > table, this is what you get. Of course there are pathological > cases with badly built hashes, or small tables which are worse. > Worst case therefore degenerates to linear, but you'd practically > never get it if there was a well distributed hash, and the > collision probabilities for a particular value were low enough. > > This is fairly well known for hash tables. > True. For a well distributed hash, O(1) is fine. > [cut] > > > > > > Prefix LinkID **** (Proposed Scheme): > > > --------------------------------------- > > > Additional Storage: O(1) keep LinkID and Old LinkID > > > > I think storage requirement is O(P). If LinkID prefix is removed from > > the link, routers need to select the next smaller prefix from > > prefix list. > > > > I think, here also, if you have considered only the cases, where > > LinkIDwill not change, O(1) is fine. > > This is mentioned in the assumptions at the top. I guess > that if there's only going to be one prefix removed in a period, > the next smaller prefix is all that's required. In the general > case though, O(P) is correct. > fine. > > > > > > RA Build time: O(1) selection of LinkID and Old LinkID > > > > > > > > > RA Processing: O(p_r) comparison of each prefix with LinkID > > > > > > > I think, this is O(1) because, only linkID in the RA needs to be > > comparedwith the LinkID at the host. From Section 4.2 (4th paragraph) of the LinkID draft(00/01) " When a host with a linkid prefix receives an RA, whether solicited or unsolicited, that includes a prefix with I-bit set, the host compares its LinkidPrefixList with the set of prefixes in the RA. " Host compares, its LinkID (stored in LinkIDPrefixList) with the LinkID advertised in RA (i.e, the prefix with I bit set. This prefix can be learned prefix or router's own prefix). So, only one comarision is required if the LinkIDPrefixList consists of only one prefix (Most of the time LinkIDPrefixList consists of only one prefix). So, I think it is O(1). > > No actually, the learned component of the RA isn't inspected, > for robustness sake (described in the draft: Syam or JinHyeock may > also correct me on this). This means all the PIOs need to be checked. > Routers will not consider the learned prefixes for the robustness sake, but not the hosts. From Section 3.2 (4th paragraph) of the LinkID draft(01), " From the received RAs, the router extracts only the valid prefixes in PIO and generate the "learned prefix list (LearnedPrefixList)". " From Section 3.2 (last paragraph) of the LinkID draft(01), " Take notice that, for prefix list generation, a router only takes the prefixes in PIO into consideratoin. " > > [cut] > > > > > > Prefix LinkID **** (Proposed Scheme -- see below for CPL): > > > ------------------------------------- > > > Storage: O(1) Prefix LinkID (minimum) > > > O(N) set of linkIDs received recently on different IP > > links.> > > > > I think, here N is the number of different LinkIDs (if at all) > > advertised in the last 1.5hrs on the link. > > > Actually, I think this is the number of prefixes known on the > host: > Most of the time LinkIDPrefixList consists of only one prefix i.e, LinkID. If LinkID of the link changes, because of addition/deletion of prefixes, then LinkIDPrefixList can contain more than 1 prefix. > From section 1.3: > > Paragraph4: > "...the hosts track the list of linkid prefixes they've > received in the last 1.5 hours to generate "the linkid prefix list > (LinkidPrefixList)". > > Perhaps, there is confusion, because in most cases, the > LinkIDPrefixList > is cleared out by the host each time it moves link > > Is this the current thinking? True. If a host changes its link, it will clear the LinkIDPrefixList. > > In that case, then the maximum size is P, but the mean size > is much lower (typically 1). True. I also think O(1) is fine. Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 09:39:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzE2O-0004Pj-1L for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 09:39:32 -0400 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24148 for ; Sun, 31 Jul 2005 09:39:28 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRAKDBR7DY8WZ1C9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 31 Jul 2005 23:39:21 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 971FFAB54A; Sun, 31 Jul 2005 23:39:04 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 468ED4FB02; Sun, 31 Jul 2005 23:39:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6VDcTn27205 for dna-list; Sun, 31 Jul 2005 23:38:29 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6VDcSw27201 for ; Sun, 31 Jul 2005 23:38:28 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAKC8ZA1M99QCMM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 31 Jul 2005 23:38:13 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 80E8D8000D; Sun, 31 Jul 2005 23:38:12 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 657363C003; Sun, 31 Jul 2005 23:38:12 +1000 (EST) Received: from [86.255.31.28] by mail-store-2.its.monash.edu.au (mshttpd); Sun, 31 Jul 2005 23:38:12 +1000 Date: Sun, 31 Jul 2005 23:38:12 +1000 From: Greg Daley Subject: Re: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy Cc: dna@eng.monash.edu.au, JinHyeock Choi , Syam Madanapalli Message-id: <7970007970e2.7970e2797000@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Subba, I think we're oscillating towards resolution. ----- Original Message ----- > > > > > > > > RA Build time: O(1) selection of LinkID and Old LinkID > > > > > > > > > > > > RA Processing: O(p_r) comparison of each prefix with LinkID > > > > > > > > > > I think, this is O(1) because, only linkID in the RA needs to be > > > comparedwith the LinkID at the host. > > From Section 4.2 (4th paragraph) of the LinkID draft(00/01) > > " > When a host with a linkid prefix receives an RA, whether > solicited or unsolicited, that includes a prefix with > I-bit set, the host compares its LinkidPrefixList with the > set of prefixes in the RA. > " > > Host compares, its LinkID (stored in LinkIDPrefixList) with the LinkID > advertised in RA (i.e, the prefix with I bit set. This prefix can be > learned prefix or router's own prefix). > So, only one comarision is required if the LinkIDPrefixList > consists of only one prefix (Most of the time LinkIDPrefixList > consists of only one prefix). > > So, I think it is O(1). OK. I get your point. Thinking about it another way though, each PIO and LPIO has to be checked for the LinkID flag, and then that LinkID has to be compared with the stored LinkID. > > > > No actually, the learned component of the RA isn't inspected, > > for robustness sake (described in the draft: Syam or JinHyeock may > > also correct me on this). This means all the PIOs need to be > checked.> > > Routers will not consider the learned prefixes for the robustness > sake, but not the hosts. > > From Section 3.2 (4th paragraph) of the LinkID draft(01), > > " > From the received RAs, the router extracts only the valid > prefixes in PIO and generate the "learned prefix list > (LearnedPrefixList). > " > > > From Section 3.2 (last paragraph) of the LinkID draft(01), > > " > Take notice that, for prefix list generation, a router only > takes the prefixes in PIO into consideratoin. > " Thanks for the references. I'll check this out further. > > > > [cut] > > > > > > > > Prefix LinkID **** (Proposed Scheme -- see below for CPL): > > > > ------------------------------------- > > > > Storage: O(1) Prefix LinkID (minimum) > > > > O(N) set of linkIDs received recently on different IP > > > links.> > > > > > > I think, here N is the number of different LinkIDs (if at all) > > > advertised in the last 1.5hrs on the link. > > > > > > Actually, I think this is the number of prefixes known on the > > host: > > > > Most of the time LinkIDPrefixList consists of only one prefix i.e, > LinkID.If LinkID of the link changes, because of addition/deletion > of prefixes, then LinkIDPrefixList can contain more than 1 prefix. OK this is worth noting in the assumptions. > > From section 1.3: > > > > Paragraph4: > > "...the hosts track the list of linkid prefixes they've > > received in the last 1.5 hours to generate "the linkid prefix > list> (LinkidPrefixList)". > > > > Perhaps, there is confusion, because in most cases, the > > LinkIDPrefixList > > is cleared out by the host each time it moves link > > > > Is this the current thinking? > > True. If a host changes its link, it will clear the LinkIDPrefixList. > > > > > In that case, then the maximum size is P, but the mean size > > is much lower (typically 1). > > True. I also think O(1) is fine. OK, I'll mention O(1), but also note the assumption as described above. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 12:50:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzH1H-0002c0-0W for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 12:50:35 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06785 for ; Sun, 31 Jul 2005 12:50:30 -0400 (EDT) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAR1ECPPC9APR2C@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Aug 2005 02:50:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 39B28AB54A; Mon, 01 Aug 2005 02:50:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D86DF4FB05; Mon, 01 Aug 2005 02:50:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6VGnZm29566 for dna-list; Mon, 01 Aug 2005 02:49:35 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6VGnYw29562 for ; Mon, 01 Aug 2005 02:49:34 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAR09OAV499OQUV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Aug 2005 02:49:22 +1000 Received: by localhost (Postfix, from userid 510) id 679B5AB542; Mon, 01 Aug 2005 02:49:22 +1000 (EST) Received: from tayrelbas01.tay.hp.com (tayrelbas01.tay.hp.com [161.114.80.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 630A74FB07 for ; Mon, 01 Aug 2005 02:49:19 +1000 (EST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 06CCAB1 for ; Sun, 31 Jul 2005 12:43:54 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 12:49:13 -0400 Date: Sun, 31 Jul 2005 12:49:11 -0400 From: "Bound, Jim" Subject: [DNA] Landmark vs Link-ID prefix solution Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <936A4045C332714F975800409DE09240B31553@tayexc14.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Landmark vs Link-ID prefix solution Thread-Index: AcWV78b0gCxptADyRbuGvMnpyWjRvg== Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 31 Jul 2005 16:49:13.0899 (UTC) FILETIME=[C83B77B0:01C595EF] Content-Transfer-Encoding: 7BIT I have tried to pereceive implementation pain and advantage from both Landmark and Link-ID views, and the complexity of the code and extensions required. I think this gets into the time vs. space issues we faced looking at OSI ES-IS vs ARP when defining ND years ago, only a much harder technical problem (I think its up there with SHIM6 work). I see similar positions and debates. Most of the mail for me has not been helpful to sway me one way or the other yet. It has shown me neither is complete yet. What I like about Landmark it is a pure extension to ND for IPv6, but what I don't like nor can support at least right now is modifying the current RA. Doing that is not good and I would at least like to see means to enhance or form new RA for particpating Landmark hosts and routers. What I like about the Link-ID is I believe it will converge quickly for one of my hot buttons for mobility and that is mesh networks (note not MANETs and I can get into the diff offline "only" with others, per Greg's mail to keep the focus here). I intend to do in depth technical review of both and ask some folks I know out of the IETF building mobile networks now for products with MIPv6 who want to be anonymous to help me review it as ghost persons, and I am building some to of course, so I have a bias clearly. Possibly there is a compromise and integration of ideas here. What I empatically do not agree with is James K's statement that we should stop work on Link-ID because it may use up a bit more time and white paper space than Landmark. That is not an engineering argument or technical rationale, but false bravado at this point I will assume for time-to-market reasons. I agree with need to ship something, but this is serious stuff, and unless Greg tells me we don't have more time I assume we can get this right? I am assuming on both sides of the architectures is that there is no IPR from any company as authors on either of these solutions? If there is and I missed it in the specs, and I will check again, please speak up now and tell us you have patents on what your proposing. This has to stop in the IETF and will probably kill CGA and other ideas that may never get widely used in the market. Most of us are quite sick of it and I consider it dishonorable if not presented up front immediately. /jim From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 13:17:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzHRV-0008Dp-U9 for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 13:17:48 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08062 for ; Sun, 31 Jul 2005 13:17:37 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAS05XRB69APSUO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Aug 2005 03:17:34 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C0B57AB543; Mon, 01 Aug 2005 03:17:31 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 78C9A4FB06; Mon, 01 Aug 2005 03:17:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6VHGQS29868 for dna-list; Mon, 01 Aug 2005 03:16:26 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6VHGQw29862 for ; Mon, 01 Aug 2005 03:16:26 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRARXOTZKK8Y7F1M@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Aug 2005 03:16:19 +1000 Received: by localhost (Postfix, from userid 510) id 26790AB543; Mon, 01 Aug 2005 03:16:19 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2EBFE4FB02 for ; Mon, 01 Aug 2005 03:16:18 +1000 (EST) Date: Sun, 31 Jul 2005 10:16:12 -0700 From: James Kempf Subject: Re: [DNA] Landmark vs Link-ID prefix solution Sender: owner-dna@ecselists.eng.monash.edu.au To: "Bound, Jim" , dna@eng.monash.edu.au Message-id: <05d401c595f3$8dd427d0$596015ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-Spam-Level: *** References: <936A4045C332714F975800409DE09240B31553@tayexc14.americas.cpqcorp.net> Content-Transfer-Encoding: 7BIT Jim > What I empatically do not agree with is James K's statement that we > should stop work on Link-ID because it may use up a bit more time and > white paper space than Landmark. That is not an engineering argument or > technical rationale, but false bravado at this point I will assume for > time-to-market reasons. I agree with need to ship something, but this > is serious stuff, and unless Greg tells me we don't have more time I > assume we can get this right? > I think I might not have been clear. What I intended to say was that I think backward compatibility is more important than whether one or another protocol has a few extra bytes. It sounds like that is what you are concerned with too. Or are you saying that you think size/time is more important? jak From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 15:24:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzJQe-0007JX-On for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 15:24:57 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14971 for ; Sun, 31 Jul 2005 15:24:53 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAWFZ3P7699Q6GA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Aug 2005 05:24:50 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A64DFAB545; Mon, 01 Aug 2005 05:24:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5BB5D4FB06; Mon, 01 Aug 2005 05:24:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6VJO8n31553 for dna-list; Mon, 01 Aug 2005 05:24:08 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6VJO7w31549 for ; Mon, 01 Aug 2005 05:24:07 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRAWET6VBK8WZ4D3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Aug 2005 05:23:52 +1000 Received: by localhost (Postfix, from userid 510) id 6637EAB542; Mon, 01 Aug 2005 05:23:52 +1000 (EST) Received: from tayrelbas04.tay.hp.com (tayrelbas04.tay.hp.com [161.114.80.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 9AD9E4FB05 for ; Mon, 01 Aug 2005 05:23:49 +1000 (EST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 4C55E20000C8; Sun, 31 Jul 2005 15:23:47 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 15:19:58 -0400 Date: Sun, 31 Jul 2005 15:19:54 -0400 From: "Bound, Jim" Subject: RE: [DNA] Landmark vs Link-ID prefix solution Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: dna@eng.monash.edu.au Message-id: <936A4045C332714F975800409DE09240B3155F@tayexc14.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Landmark vs Link-ID prefix solution Thread-Index: AcWV86J9/OLALM8GSBmIR8p16gulIQAEQxsg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) X-OriginalArrivalTime: 31 Jul 2005 19:19:58.0035 (UTC) FILETIME=[D6F51A30:01C59604] Content-Transfer-Encoding: 7BIT James, I do agree backwards compatibility is important and unless something is awfully good then I cannot see breaking code. Ergo both do that too currently. thanks /jim > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com] > Sent: Sunday, July 31, 2005 1:16 PM > To: Bound, Jim; dna@eng.monash.edu.au > Subject: Re: [DNA] Landmark vs Link-ID prefix solution > > Jim > > > What I empatically do not agree with is James K's statement that we > > should stop work on Link-ID because it may use up a bit > more time and > > white paper space than Landmark. That is not an > engineering argument or > > technical rationale, but false bravado at this point I will > assume for > > time-to-market reasons. I agree with need to ship > something, but this > > is serious stuff, and unless Greg tells me we don't have more time I > > assume we can get this right? > > > > I think I might not have been clear. What I intended to say > was that I think > backward compatibility is more important than whether one or another > protocol has a few extra bytes. It sounds like that is what you are > concerned with too. > Or are you saying that you think size/time is more important? > > jak > > > From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 16:39:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzKae-0003ht-PA for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 16:39:22 -0400 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17693 for ; Sun, 31 Jul 2005 16:39:17 -0400 (EDT) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRAZ13PIPY9APT5Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Aug 2005 06:39:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 84618AB544; Mon, 01 Aug 2005 06:39:06 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 40D444FB02; Mon, 01 Aug 2005 06:39:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j6VKcZF32396 for dna-list; Mon, 01 Aug 2005 06:38:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j6VKcYw32392 for ; Mon, 01 Aug 2005 06:38:34 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRAZ0C6AUQ8WZ1EU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Aug 2005 06:38:30 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A1548AB542; Mon, 01 Aug 2005 06:38:29 +1000 (EST) Received: from [172.19.242.5] (vpn-student-242-5.its.monash.edu.au [172.19.242.5]) by curly.its.monash.edu.au (Postfix) with ESMTP id 790F84FB0A; Mon, 01 Aug 2005 06:38:27 +1000 (EST) Date: Mon, 01 Aug 2005 06:38:24 +1000 From: Greg Daley Subject: Re: [DNA] Landmark vs Link-ID prefix solution In-reply-to: <936A4045C332714F975800409DE09240B31553@tayexc14.americas.cpqcorp.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Bound, Jim" Cc: dna@eng.monash.edu.au Message-id: <42ED36C0.7080101@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) References: <936A4045C332714F975800409DE09240B31553@tayexc14.americas.cpqcorp.net> Content-Transfer-Encoding: 7BIT Hi Jim, Bound, Jim wrote: [cut] > I see similar positions and debates. Most of the mail for me has not been > helpful to sway me one way or the other yet. It has shown me neither is > complete yet. Actually, I see things differently. In my personal opinion, most of the e-mails have been trying very hard to differentiate the protocols. Possibly we've been trying too hard - and that doesn't help people reading the threads. I guess this gives the impression that the protocol work is incomplete. Rather, I think the solutions may end up being over-engineered if we try to handle each of the smallest corner cases (just to show one as better than another). Given that we have two protocols which achieve primarily the same outcome (both have running code), what I think we need now is to generate a quick comparison (currently under development), show the WG the solutions and their summarized properties, and make a consensus call. [cut] > I intend to do in depth technical review of both and ask some folks > I know out of the IETF building mobile networks now for products with > MIPv6 who want to be anonymous to help me review it as ghost persons, > and I am building some to of course, so I have a bias clearly. > Possibly there is a compromise and integration of ideas here. Yes there's a compromise possible, but I think we should look at whether either is acceptable to the WG. Your review would be particularly welcome. Thursday may help clarify which document to review (but it may take a couple of weeks to get the consensus call comleted, if there's no clear sense of the room). > What I empatically do not agree with is James K's statement that we > should stop work on Link-ID because it may use up a bit more time and > white paper space than Landmark. That is not an engineering argument or > technical rationale, but false bravado at this point I will assume for > time-to-market reasons. I agree with need to ship something, but this > is serious stuff, and unless Greg tells me we don't have more time I > assume we can get this right? Personally, I'd like to get the WG document drafted in the coming month, so we've got a chance to get the documents finished this year. > I am assuming on both sides of the architectures is that there is no IPR > from any company as authors on either of these solutions? If there is > and I missed it in the specs, and I will check again, please speak up > now and tell us you have patents on what your proposing. This has to > stop in the IETF and will probably kill CGA and other ideas that may > never get widely used in the market. Most of us are quite sick of it > and I consider it dishonorable if not presented up front immediately. From my knowledge no contributor to the discussion of Link Identification has IPR. That doesn't mean someone else couldn't though (same as everything). People are reminded of the IETF Note Well statement regarding IPR: http://www.ietf.org/overview.html Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Jul 31 23:42:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzRBh-0000T5-5L for dna-archive@megatron.ietf.org; Sun, 31 Jul 2005 23:42:01 -0400 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04714 for ; Sun, 31 Jul 2005 23:41:57 -0400 (EDT) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRBDRUYLXS99Q4A6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Aug 2005 13:41:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9FEBC80010; Mon, 01 Aug 2005 13:41:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 618933C00B; Mon, 01 Aug 2005 13:41:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j713ejr04929 for dna-list; Mon, 01 Aug 2005 13:40:45 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j713ejw04925 for ; Mon, 01 Aug 2005 13:40:45 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRBDQMSAJK8Y7IVE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Aug 2005 13:40:33 +1000 Received: by localhost (Postfix, from userid 510) id 761A8AB544; Mon, 01 Aug 2005 13:40:33 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7D1894FB02; Mon, 01 Aug 2005 13:40:31 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKI0006PY7HAQ@mailout3.samsung.com>; Mon, 01 Aug 2005 12:40:29 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IKI00IFXY7E8T@mmp1.samsung.com>; Mon, 01 Aug 2005 12:40:29 +0900 (KST) Date: Mon, 01 Aug 2005 09:06:25 +0530 From: Subba Reddy Subject: Re: [DNA] Info: Computation Time/Space requirements for Link Identification schemes Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au, JinHyeock Choi , Syam Madanapalli Message-id: <024b01c5964a$330fb1a0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) References: <7970007970e2.7970e2797000@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, > > I think we're oscillating towards resolution. True. > > ----- Original Message ----- > > > > > > > > > > RA Build time: O(1) selection of LinkID and Old LinkID > > > > > > > > > > > > > > > RA Processing: O(p_r) comparison of each prefix with LinkID > > > > > > > > > > > > > I think, this is O(1) because, only linkID in the RA needs to be > > > > comparedwith the LinkID at the host. > > > > From Section 4.2 (4th paragraph) of the LinkID draft(00/01) > > > > " > > When a host with a linkid prefix receives an RA, whether > > solicited or unsolicited, that includes a prefix with > > I-bit set, the host compares its LinkidPrefixList with the > > set of prefixes in the RA. > > " > > > > Host compares, its LinkID (stored in LinkIDPrefixList) with the > LinkID > > advertised in RA (i.e, the prefix with I bit set. This prefix can be > > learned prefix or router's own prefix). > > So, only one comarision is required if the LinkIDPrefixList > > consists of only one prefix (Most of the time LinkIDPrefixList > > consists of only one prefix). > > > > So, I think it is O(1). > > OK. I get your point. > > Thinking about it another way though, each PIO and LPIO has to be > checked for the LinkID flag, and then that LinkID has to be compared > with the stored LinkID. > If the first prefix in the RA is LinkID prefix (if any), then only one comparision is enough. I feel, routers can maintain the LinkID prefix as the first prefix, in their prefix list. Because of this, routers can easily check (with O(1) complexity) the validity of LinkID at various point of times (like prefix life time changes, new prefix is added, LinkID prefix is a learned prefix and it has not been advertised in the last 1.5hrs). So, routers can easily include LinkID prefix as the first prefix in the RA. Also, maintaining the LinkID prefix as the first entry in the prefix list will not add any additional complexity (It is constant O(1)). Though, whatever I have mentioned is more implementation specific, IMHO O(1) is fine. > > > > > > No actually, the learned component of the RA isn't inspected, > > > for robustness sake (described in the draft: Syam or JinHyeock may > > > also correct me on this). This means all the PIOs need to be > > checked.> > > > > Routers will not consider the learned prefixes for the robustness > > sake, but not the hosts. > > > > From Section 3.2 (4th paragraph) of the LinkID draft(01), > > > > " > > From the received RAs, the router extracts only the valid > > prefixes in PIO and generate the "learned prefix list > > (LearnedPrefixList). > > " > > > > > > From Section 3.2 (last paragraph) of the LinkID draft(01), > > > > " > > Take notice that, for prefix list generation, a router only > > takes the prefixes in PIO into consideratoin. > > " > > Thanks for the references. I'll check this out further. > > > > > > > [cut] > > > > > > > > > > Prefix LinkID **** (Proposed Scheme -- see below for CPL): > > > > > ------------------------------------- > > > > > Storage: O(1) Prefix LinkID (minimum) > > > > > O(N) set of linkIDs received recently on different IP > > > > links.> > > > > > > > > I think, here N is the number of different LinkIDs (if at all) > > > > advertised in the last 1.5hrs on the link. > > > > > > > > > Actually, I think this is the number of prefixes known on the > > > host: > > > > > > > Most of the time LinkIDPrefixList consists of only one prefix i.e, > > LinkID.If LinkID of the link changes, because of addition/deletion > > of prefixes, then LinkIDPrefixList can contain more than 1 prefix. > > OK this is worth noting in the assumptions. > > > > > From section 1.3: > > > > > > Paragraph4: > > > "...the hosts track the list of linkid prefixes they've > > > received in the last 1.5 hours to generate "the linkid prefix > > list> (LinkidPrefixList)". > > > > > > Perhaps, there is confusion, because in most cases, the > > > LinkIDPrefixList > > > is cleared out by the host each time it moves link > > > > > > Is this the current thinking? > > > > True. If a host changes its link, it will clear the LinkIDPrefixList. > > > > > > > > In that case, then the maximum size is P, but the mean size > > > is much lower (typically 1). > > > > True. I also think O(1) is fine. > > OK, I'll mention O(1), but also note the assumption as described above. OK. > > Greg > Thanks & Regards, Subba Reddy