From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 7 11:45:57 2005 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 LAA15340 for ; Mon, 7 Feb 2005 11:45:56 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKJQ8YCVJA8ZIS33@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 08 Feb 2005 03:45:15 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6BBFCAB545; Tue, 08 Feb 2005 03:44:51 +1100 (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 194774FB08; Tue, 08 Feb 2005 03:44:51 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j17Ghac24559 for dna-list; Tue, 08 Feb 2005 03:43:36 +1100 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 j17GhW624555 for ; Tue, 08 Feb 2005 03:43:32 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKJQ7A3ANI8Y5WMR@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 08 Feb 2005 03:43:31 +1100 Received: by localhost (Postfix, from userid 510) id 97F87AB543; Tue, 08 Feb 2005 03:43:30 +1100 (EST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by curly.its.monash.edu.au (Postfix) with ESMTP id 23B2A4FB05; Tue, 08 Feb 2005 03:43:30 +1100 (EST) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CyBut-0003pV-Bs; Mon, 07 Feb 2005 11:39:15 -0500 Date: Mon, 07 Feb 2005 11:39:15 -0500 From: The IESG Subject: [DNA] Document Action: 'Detecting Network Attachment in IPv6 Goals' to Informational RFC Sender: owner-dna@ecselists.eng.monash.edu.au To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dna mailing list , dna chair , dna chair Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-test-idtracker: no X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT The IESG has approved the following document: - 'Detecting Network Attachment in IPv6 Goals ' as an Informational RFC This document is the product of the Detecting Network Attachment Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. During link identity detection, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure and of limited signaling. Working Group Summary This document is a work item fo the DNA WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 11 14:15:09 2005 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 OAA27713 for ; Fri, 11 Feb 2005 14:15:07 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPGN8Y73M8WW607@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 12 Feb 2005 06:14:51 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2ECE1AB545; Sat, 12 Feb 2005 06:14:48 +1100 (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 B028C4FB04; Sat, 12 Feb 2005 06:14:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1BJD4P23081 for dna-list; Sat, 12 Feb 2005 06:13:04 +1100 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 j1BJCu623075 for ; Sat, 12 Feb 2005 06:12:56 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPGKRVJ208WW607@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 12 Feb 2005 06:12:48 +1100 Received: by localhost (Postfix, from userid 510) id AEBC6AB544; Sat, 12 Feb 2005 06:12:48 +1100 (EST) Received: from rediffmail.com (unknown [202.54.124.151]) by curly.its.monash.edu.au (Postfix) with SMTP id 6464D4FB06 for ; Sat, 12 Feb 2005 06:12:45 +1100 (EST) Received: (qmail 12833 invoked by uid 510); Fri, 11 Feb 2005 19:14:11 +0000 Received: from unknown (150.169.1.251) by rediffmail.com via HTTP; Fri, 11 Feb 2005 19:14:11 +0000 Date: Fri, 11 Feb 2005 19:14:11 +0000 From: James Goldsmith Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: James Goldsmith Message-id: <20050211191411.12832.qmail@webmail6.rediffmail.com> MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_bBFUHIq+fPeEddx99AHQBw)" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: ** This is a multipart mime message --Boundary_(ID_bBFUHIq+fPeEddx99AHQBw) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: quoted-printable =0ADNA group has been very inactive for quite some time.=0A=0AThere are o= nly two messages in February - one is an IESG announcement, and another is = from the chair. There were no messages in January and only a few messages = in December all between Pekka and Jinkchok on the goals draft.=0A=0AIt appe= ars that people have lost interest in this group, and not many seem to care= any more about the work pursued in this group. There are only 3 or 4 peopl= e have any interest left in DNA group=92s continued activities. =0A=0AThis = is very rare for an IETF group where it is easy to see even a smallest work= ing group attract a few hundred people in meetings (and /or on mailing list= s). The main reason is that DNA group hasn=92t produced any thing useful = =96 goals and bcp drafts are just re-iteration of what already exist in IPv= 4 and IPv6 mobility architecture documents. =0A=0ABased on past proceedings= and discussions, it appears that DNA group cannot propose any solution wit= hout Layer 2 event modifications; something that is outside the scope of IE= TF. I don=92t see any interesting proposals being discussed in DNA WG. On = the other hand, there are over a dozen actively pursued proposals in IEEE 8= 02.21 =96 protocol independent handoff group. For Layer 3 solutions, I have= not seen any thing better than fast RA draft that exists from pre-DNA grou= p creation. =0A=0AYes, I know two or three active people in this group are = trying to create some sort of solution document, but it appears, based on r= ather poor traffic on the mailing list, that mobility community has already= given up. =0A=0AWhat is the point of creating a document in which most peo= ple seem to have lost the interest? In my opinion, the group should become = dormant or be closed until IEEE comes up with better event definitions for = layer 2 for facilitating faster hand-off. =0A=0AJames --Boundary_(ID_bBFUHIq+fPeEddx99AHQBw) Content-type: text/html; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: quoted-printable

=0A 
=0ADNA group has been very inactive for quite some time.=0A
=0AThere are only two messages in February - one is an IESG announ= cement, and another is from the chair.  There were no messages in Janu= ary and only a few messages in December all between Pekka and Jinkchok on t= he goals draft.
=0A
=0AIt appears that people have lost interest in t= his group, and not many seem to care any more about the work pursued in thi= s group. There are only 3 or 4 people have any interest left in DNA group= =92s continued activities.
=0A
=0AThis is very rare for an IETF grou= p where it is easy to see even a smallest working group attract a few hundr= ed people in meetings (and /or on mailing lists).  The main reason is = that DNA group hasn=92t produced any thing useful =96 goals and bcp drafts = are just re-iteration of what already exist in IPv4 and IPv6 mobility archi= tecture documents.
=0A
=0ABased on past proceedings and discussions,= it appears that DNA group cannot propose any solution without Layer 2 even= t modifications; something that is outside the scope of IETF.  I don= =92t see any interesting proposals being discussed in DNA WG. On the other = hand, there are over a dozen actively pursued proposals in IEEE 802.21 =96 = protocol independent handoff group. For Layer 3 solutions, I have not seen = any thing better than fast RA draft that exists from pre-DNA group creation= .
=0A
=0AYes, I know two or three active people in this group are tr= ying to create some sort of solution document, but it appears, based on rat= her poor traffic on the mailing list, that mobility community has already g= iven up.
=0A
=0AWhat is the point of creating a document in which mo= st people seem to have lost the interest? In my opinion, the group should b= ecome dormant or be closed until IEEE comes up with better event definition= s for layer 2 for facilitating faster hand-off.
=0A
=0AJames=0A

= =0A

=0A=0A --Boundary_(ID_bBFUHIq+fPeEddx99AHQBw)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 11 14:39:30 2005 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 OAA29853 for ; Fri, 11 Feb 2005 14:39:29 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPHHIW7E88WW60C@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 12 Feb 2005 06:39:15 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD9CEAB546; Sat, 12 Feb 2005 06:39:12 +1100 (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 4F6B44FB15; Sat, 12 Feb 2005 06:39:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1BJccI23363 for dna-list; Sat, 12 Feb 2005 06:38:38 +1100 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 j1BJcN623354 for ; Sat, 12 Feb 2005 06:38:24 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKPHG4UKEK8WWSI9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 12 Feb 2005 06:38:05 +1100 Received: by localhost (Postfix, from userid 510) id AAE9EAB546; Sat, 12 Feb 2005 06:38:05 +1100 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by moe.its.monash.edu.au (Postfix) with ESMTP id BBBEE4FB09 for ; Sat, 12 Feb 2005 06:38:02 +1100 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1BK8Il00653; Fri, 11 Feb 2005 12:08:18 -0800 Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpdKge9eG; Fri, 11 Feb 2005 12:08:07 -0800 (PST) Date: Fri, 11 Feb 2005 11:37:32 -0800 From: Vijay Devarapalli Subject: [DNA] Re: In-reply-to: <20050211191411.12832.qmail@webmail6.rediffmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Goldsmith Cc: dna@eng.monash.edu.au Message-id: <420D097C.2020805@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=windows-1252 Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en X-mProtect: <200502112008> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <20050211191411.12832.qmail@webmail6.rediffmail.com> Content-Transfer-Encoding: 7BIT James Goldsmith sounds so fictional. can you please identify yourself and your true affiliation. Vijay James Goldsmith wrote: > > DNA group has been very inactive for quite some time. > > There are only two messages in February - one is an IESG announcement, > and another is from the chair. There were no messages in January and > only a few messages in December all between Pekka and Jinkchok on the > goals draft. > > It appears that people have lost interest in this group, and not many > seem to care any more about the work pursued in this group. There are > only 3 or 4 people have any interest left in DNA groups continued > activities. > > This is very rare for an IETF group where it is easy to see even a > smallest working group attract a few hundred people in meetings (and /or > on mailing lists). The main reason is that DNA group hasnt produced > any thing useful  goals and bcp drafts are just re-iteration of what > already exist in IPv4 and IPv6 mobility architecture documents. > > Based on past proceedings and discussions, it appears that DNA group > cannot propose any solution without Layer 2 event modifications; > something that is outside the scope of IETF. I dont see any > interesting proposals being discussed in DNA WG. On the other hand, > there are over a dozen actively pursued proposals in IEEE 802.21  > protocol independent handoff group. For Layer 3 solutions, I have not > seen any thing better than fast RA draft that exists from pre-DNA group > creation. > > Yes, I know two or three active people in this group are trying to > create some sort of solution document, but it appears, based on rather > poor traffic on the mailing list, that mobility community has already > given up. > > What is the point of creating a document in which most people seem to > have lost the interest? In my opinion, the group should become dormant > or be closed until IEEE comes up with better event definitions for layer > 2 for facilitating faster hand-off. > > James > > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 11 15:22:18 2005 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 PAA04784 for ; Fri, 11 Feb 2005 15:22:17 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPIZPI5WG8WW60K@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 12 Feb 2005 07:22:10 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C749580003; Sat, 12 Feb 2005 07:22:06 +1100 (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 6AA243C007; Sat, 12 Feb 2005 07:22:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1BKLf123951 for dna-list; Sat, 12 Feb 2005 07:21:41 +1100 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 j1BKLZ623947 for ; Sat, 12 Feb 2005 07:21:38 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPIYXNW948WW60K@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 12 Feb 2005 07:21:29 +1100 Received: by localhost (Postfix, from userid 510) id 9D837AB542; Sat, 12 Feb 2005 07:21:29 +1100 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by curly.its.monash.edu.au (Postfix) with ESMTP id 10C7C4FB03 for ; Sat, 12 Feb 2005 07:21:27 +1100 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04649; Fri, 11 Feb 2005 15:21:23 -0500 (EST) Date: Fri, 11 Feb 2005 15:21:23 -0500 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-link-information-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: <200502112021.PAA04649@ietf.org> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_oWCQ7USPw+1bML3J0sHC+Q)" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) --Boundary_(ID_oWCQ7USPw+1bML3J0sHC+Q) 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, et al. Filename : draft-ietf-dna-link-information-01.txt Pages : 18 Date : 2005-2-11 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 draft 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-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-link-information-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-link-information-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_oWCQ7USPw+1bML3J0sHC+Q) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Jo/YRPci9slyVqELmlQQDg)" --Boundary_(ID_Jo/YRPci9slyVqELmlQQDg) Content-type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-11153821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-link-information-01.txt --Boundary_(ID_Jo/YRPci9slyVqELmlQQDg) Content-type: Message/External-body; name=draft-ietf-dna-link-information-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-link-information-01.txt Content-Type: text/plain Content-ID: <2005-2-11153821.I-D@ietf.org> --Boundary_(ID_Jo/YRPci9slyVqELmlQQDg)-- --Boundary_(ID_oWCQ7USPw+1bML3J0sHC+Q)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 11 16:06:56 2005 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 QAA13989 for ; Fri, 11 Feb 2005 16:06:55 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKPKJ13TLA8WWUC3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 12 Feb 2005 08:06:07 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1F2C9AB542; Sat, 12 Feb 2005 08:05:56 +1100 (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 AE1784FB06; Sat, 12 Feb 2005 08:05:55 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1BL5a324432 for dna-list; Sat, 12 Feb 2005 08:05:36 +1100 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 j1BL5Z624428 for ; Sat, 12 Feb 2005 08:05:36 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKPKI8DI748WW60V@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 12 Feb 2005 08:05:18 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 87CD4AB545; Sat, 12 Feb 2005 08:05:17 +1100 (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 6A0E64FB03; Sat, 12 Feb 2005 08:05:17 +1100 (EST) Received: from [211.28.185.4] by mail-store-2.its.monash.edu.au (mshttpd); Sat, 12 Feb 2005 08:05:17 +1100 Date: Sat, 12 Feb 2005 08:05:17 +1100 From: Greg Daley Subject: [DNA] Interest in DNA or not? (Re: ) Sender: owner-dna@ecselists.eng.monash.edu.au To: James Goldsmith Cc: dna@eng.monash.edu.au Message-id: <60fe596115d9.6115d960fe59@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) 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 James, ----- Original Message ----- From: James Goldsmith Date: Saturday, February 12, 2005 6:14 am > > DNA group has been very inactive for quite some time. > > There are only two messages in February - one is an IESG > announcement, and another is from the chair. I'm sorry, postings here have been pretty light, and it seems I'm taking more than my fair share. > There were no > messages in January and only a few messages in December all between > Pekka and Jinkchok on the goals draft. > > It appears that people have lost interest in this group, and not > many seem to care any more about the work pursued in this group. > There are only 3 or 4 people have any interest left in DNA group?s > continued activities. Certainly mailing list traffic has been light. This is of concern to both the Chairs and the Area Directors. There are, as you say, a small core of people actively driving work for this group. The number of people is probably about three times as large as you say, but the silence of the other Mailing list members should be explored. We really need to see if the (list) members are actually interested in the outputs of those currently spending cycles on the development. It is worth noticing that there are at least two implementations of ideas under discussion, and interest from manufacturers. > This is very rare for an IETF group where it is easy to see even a > smallest working group attract a few hundred people in meetings > (and /or on mailing lists). The main reason is that DNA group > hasn?t produced any thing useful ? goals and bcp drafts are just re- > iteration of what already exist in IPv4 and IPv6 mobility > architecture documents. At the last IETF session, we didn't have room for one of the A-D's to squeeze in (sorry!) Perhaps we have or will see a waning of interest. It's worth working out whether this is the case, though. The goals document is a distillation of the discussions which originated back in the days of MIPv6 development. At the time, the understanding of the problem was actually quite poor, and JinHyeock and I (and others) proposed some solutions which look naive now. A set of goals to measure solutions against is certainly worth having. Now that it has been approved, the work can move onto something closer to implementation. The BCPs are similar in that people have previously been able to design solutions which work in a some constrained environments (Eager Cell Switching, etc), but have significant drawbacks in others. the BCPs are to give something defined in the current standards which is useful, safe and reasonably fast. Personally (biased), I think that these documents aren't redundant. As far as I can see there weren't really any architecture documents for mobility in IPv6 :) Please be aware: this is not a mobility group. It's a connectivity group. Erik Nordmark (then an AD) said that he thought the problem was broader than movement detection. So while mobility documents may have had a go at defining mechanism for fast reconfiguration in a particular network, not everyine will have 50ms mean delay between RAs, nor FMIPv6. > Based on past proceedings and discussions, it appears that DNA > group cannot propose any solution without Layer 2 event > modifications; something that is outside the scope of IETF. This is not the case. There are several interesting and widely applicable ideas of how to do this at L3. By monday, a design discussion draft will be posted (one of the Design Team products), which will shed light on this. At this stage, DNA-DT discussions have been in-camera. Pekka and I aren't even on the list. It's not surprising that details aren't leaking out onto the DNA list yet then. While this is not aimed at secrecy, the DT have been doing a good job of effectively and efficiently evaluating various solutions. New ideas and knowledge have been uncovered. Please wait and see for this (only a few days more). > I > don?t see any interesting proposals being discussed in DNA WG. On > the other hand, there are over a dozen actively pursued proposals > in IEEE 802.21 ? protocol independent handoff group. For Layer 3 > solutions, I have not seen any thing better than fast RA draft that > exists from pre-DNA group creation. Well, that depends on your point of view. There are plenty of drafts in the repository. https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=-dna-&search_rfcnumber=&search_area_acronym=&search_button=SEARCH You'll notice: (In the existing protocol space) draft-ietf-dna-link-information (None) draft-narayanan-dna-hosts-bcp draft-narayanan-dna-routers-bcp draft-jinchoi-dna-cpl draft-hong-dna-if-l2 (in the proposal space) draft-narayanan-dna-rrd draft-daley-dna-det-fastra draft-daley-dna-nonce-resp draft-daley-dna-prob-fastra More drafts are expected on monday or by monday. As you know, a lot of the drafts come from a small core of people. If they're missing something, then people should contribute a more effective solution. > Yes, I know two or three active people in this group are trying to > create some sort of solution document, but it appears, based on > rather poor traffic on the mailing list, that mobility community > has already given up. Perhaps you are correct with regard to mailing list activity. It is certainly worth finding out if people are interested in the outputs of the group. Another alternative idea may be that while people are interested in the outputs, they are unable to devote time to the document and protocol development themselves (except for example at IETF). Perhaps we can poll people as to what their current level of interest is, and determine if some actions need to be taken. Certainly there needs to be more input on the ML for the IETF process to be fully effective. Lulls with furious activity around meeting times have the potential of blindsiding the group if new technical details come out too late to be fixed before a session. > What is the point of creating a document in which most people seem > to have lost the interest? In my opinion, the group should become > dormant or be closed until IEEE comes up with better event > definitions for layer 2 for facilitating faster hand-off. If people have lost interest and don't want to see a document, please speak up. If you're interested, but quiet, please indicate if this is so. Your advice on how best to advance the group is also welcome. (Chair Hat Off) Personally, being biased, I think that new trigger primitives are only half of the story. It may take a long time to upgrade or replace the majority of deployed link-layer equipment, especially those with a firmware or part hardware implementation. Software upgrades on host and routing infrastructure are either more common (for routers) or don't require co-ordination (for hosts). This may give L3 solutions earlier momentum than new L2 solutions. It's also worthwhile to remember that while IEEE's protocols are pervasive, they're not universal. Thanks again for having the courage to express an opinion. Greg From dna-owner@webcamserver.eng.monash.edu.au Sat Feb 12 19:48:58 2005 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 TAA14551 for ; Sat, 12 Feb 2005 19:48:56 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKR6LBP65U8WX62B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 13 Feb 2005 11:48:50 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F71B80003; Sun, 13 Feb 2005 11:48:30 +1100 (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 0FC203C002; Sun, 13 Feb 2005 11:48:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1D0l2c12928 for dna-list; Sun, 13 Feb 2005 11:47:02 +1100 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 j1D0l2612924 for ; Sun, 13 Feb 2005 11:47:02 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKR6JC0PGU8Y6A7X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sun, 13 Feb 2005 11:46:54 +1100 Received: by localhost (Postfix, from userid 510) id 347F380002; Sun, 13 Feb 2005 11:46:54 +1100 (EST) Received: from rediffmail.com (unknown [202.54.124.130]) by larry.its.monash.edu.au (Postfix) with SMTP id DB8223C006 for ; Sun, 13 Feb 2005 11:46:47 +1100 (EST) Received: (qmail 28752 invoked by uid 510); Sat, 12 Feb 2005 01:22:13 +0000 Received: from unknown (68.36.205.225) by rediffmail.com via HTTP; Sat, 12 Feb 2005 01:22:13 +0000 Date: Sat, 12 Feb 2005 01:22:13 +0000 From: James Goldsmith Subject: [DNA] Re: Interest in DNA or not? (Re: ) Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au Reply-to: James Goldsmith Message-id: <20050212012213.28751.qmail@webmail31.rediffmail.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_syDVwFBovC9MIJ+jxUfcTg)" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) This is a multipart mime message --Boundary_(ID_syDVwFBovC9MIJ+jxUfcTg) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT Greg: I am happy that you took this mail in good sprit. Here are my three comments: 1) Goals and BCP drafts are Ok for novices, but there are no fundamental advancement of knowledge in these drafts. So, they are just the place holders, similar to padding in the data frames to align on certain boundaries;-) 2) If you ignore Alper et. al's link hint draft which pre-exist before DNA group, all other drafts that you mentioned below have been co-authored by just the three authors - yourself, Jin-choi, and Narayna. That, by any definition, is extremely limited participation from the standardization point of view. 3) Honestly, I don't find any thing compelling in the solutions because all we have are variations of fast RA with various names such as det RA, probalistic RA or stochastic RA (waiting for it ;-). RA caching in light weight APs is big no. Unless, someone can prove near-optimality of a pure L3 solution, you are simply advancing something that will do more harm than good. Thats all that I have to say. James On Sat, 12 Feb 2005 Greg Daley wrote : > > DNA group has been very inactive for quite some time. > > > > There are only two messages in February - one is an IESG > > announcement, and another is from the chair. > >I'm sorry, postings here have been pretty light, >and it seems I'm taking more than my fair share. > > > There were no > > messages in January and only a few messages in December all between > > Pekka and Jinkchok on the goals draft. > > > > It appears that people have lost interest in this group, and not > > many seem to care any more about the work pursued in this group. > > There are only 3 or 4 people have any interest left in DNA group?s > > continued activities. > > >Certainly mailing list traffic has been light. > >This is of concern to both the Chairs and the Area >Directors. > >There are, as you say, a small core of people >actively driving work for this group. The number of >people is probably about three times as large >as you say, but the silence of the other >Mailing list members should be explored. >We really need to see if the (list) members are >actually interested in the outputs of those >currently spending cycles on the development. > >It is worth noticing that there are at least >two implementations of ideas under discussion, >and interest from manufacturers. > > > This is very rare for an IETF group where it is easy to see even a > > smallest working group attract a few hundred people in meetings > > (and /or on mailing lists). The main reason is that DNA group > > hasn?t produced any thing useful ? goals and bcp drafts are just re- > > iteration of what already exist in IPv4 and IPv6 mobility > > architecture documents. > >At the last IETF session, we didn't have room >for one of the A-D's to squeeze in (sorry!) > >Perhaps we have or will see a waning of interest. > >It's worth working out whether this is the case, >though. > >The goals document is a distillation of the >discussions which originated back in the days of >MIPv6 development. At the time, the understanding >of the problem was actually quite poor, and >JinHyeock and I (and others) proposed some >solutions which look naive now. > >A set of goals to measure solutions against >is certainly worth having. Now that it has >been approved, the work can move onto something >closer to implementation. > >The BCPs are similar in that people have previously >been able to design solutions which work in a >some constrained environments (Eager Cell Switching, >etc), but have significant drawbacks in others. >the BCPs are to give something defined in the >current standards which is useful, safe and >reasonably fast. > >Personally (biased), I think that these documents >aren't redundant. As far as I can see there >weren't really any architecture documents for >mobility in IPv6 :) > >Please be aware: this is not a mobility group. >It's a connectivity group. Erik Nordmark >(then an AD) said that he thought the problem was >broader than movement detection. > >So while mobility documents may have had a go at >defining mechanism for fast reconfiguration >in a particular network, not everyine will have >50ms mean delay between RAs, nor FMIPv6. > > > Based on past proceedings and discussions, it appears that DNA > > group cannot propose any solution without Layer 2 event > > modifications; something that is outside the scope of IETF. > >This is not the case. > >There are several interesting and widely applicable >ideas of how to do this at L3. > >By monday, a design discussion draft will be >posted (one of the Design Team products), which >will shed light on this. > >At this stage, DNA-DT discussions have been >in-camera. Pekka and I aren't even on the list. >It's not surprising that details aren't leaking >out onto the DNA list yet then. > >While this is not aimed at secrecy, the DT have >been doing a good job of effectively and efficiently >evaluating various solutions. New ideas and >knowledge have been uncovered. > >Please wait and see for this (only a few days more). > > > I > > don?t see any interesting proposals being discussed in DNA WG. On > > the other hand, there are over a dozen actively pursued proposals > > in IEEE 802.21 ? protocol independent handoff group. For Layer 3 > > solutions, I have not seen any thing better than fast RA draft that > > exists from pre-DNA group creation. > >Well, that depends on your point of view. > >There are plenty of drafts in the repository. > > >https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=-dna-&search_rfcnumber=&search_area_acronym=&search_button=SEARCH > >You'll notice: > >(In the existing protocol space) >draft-ietf-dna-link-information (None) > >draft-narayanan-dna-hosts-bcp >draft-narayanan-dna-routers-bcp >draft-jinchoi-dna-cpl >draft-hong-dna-if-l2 > >(in the proposal space) >draft-narayanan-dna-rrd >draft-daley-dna-det-fastra >draft-daley-dna-nonce-resp >draft-daley-dna-prob-fastra > >More drafts are expected on monday or by monday. > >As you know, a lot of the drafts >come from a small core of people. >If they're missing something, then people should >contribute a more effective solution. > > > > Yes, I know two or three active people in this group are trying to > > create some sort of solution document, but it appears, based on > > rather poor traffic on the mailing list, that mobility community > > has already given up. > >Perhaps you are correct with regard to mailing list activity. > >It is certainly worth finding out if people >are interested in the outputs of the group. > >Another alternative idea may be that while people >are interested in the outputs, they are unable >to devote time to the document and protocol >development themselves (except for example >at IETF). > >Perhaps we can poll people as to what their >current level of interest is, and determine if >some actions need to be taken. > >Certainly there needs to be more input on the ML >for the IETF process to be fully effective. >Lulls with furious activity around meeting times >have the potential of blindsiding the group if >new technical details come out too late to be fixed >before a session. > > > What is the point of creating a document in which most people seem > > to have lost the interest? In my opinion, the group should become > > dormant or be closed until IEEE comes up with better event > > definitions for layer 2 for facilitating faster hand-off. > >If people have lost interest and don't >want to see a document, please speak up. > >If you're interested, but quiet, please indicate >if this is so. > >Your advice on how best to advance the group >is also welcome. > >(Chair Hat Off) > >Personally, being biased, I think that new >trigger primitives are only half of the story. > >It may take a long time to upgrade or replace >the majority of deployed link-layer equipment, >especially those with a firmware or part hardware >implementation. > >Software upgrades on host and routing >infrastructure are either more common (for routers) >or don't require co-ordination (for hosts). >This may give L3 solutions earlier momentum >than new L2 solutions. > >It's also worthwhile to remember that while >IEEE's protocols are pervasive, they're not >universal. > >Thanks again for having the courage to >express an opinion. > >Greg --Boundary_(ID_syDVwFBovC9MIJ+jxUfcTg) Content-type: text/html; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT

Greg:

I am happy that you took this mail in good sprit. 

Here are my three comments:

1) Goals and BCP drafts are Ok for novices, but there are no fundamental advancement of knowledge in these drafts. So, they are just the place holders, similar to padding in the data frames to align on certain boundaries;-)

2) If you ignore Alper et. al's link hint draft which pre-exist before DNA group, all other drafts that you mentioned below have been co-authored by just the three authors - yourself, Jin-choi, and  Narayna. That, by any definition, is extremely limited participation from the standardization point of view.

3) Honestly, I don't find any thing compelling in the solutions because  all we have are variations of fast RA with various names such as det RA, probalistic RA or stochastic RA (waiting for it ;-). RA caching in light weight APs is big no. Unless, someone can prove near-optimality of a pure L3 solution, you are simply advancing something that will do more harm than good.

Thats all that I have to say.

James


On Sat, 12 Feb 2005 Greg Daley wrote :
> > DNA group has been very inactive for quite some time.
> >
> > There are only two messages in February - one is an IESG
> > announcement, and another is from the chair.
>
>I'm sorry, postings here have been pretty light,
>and it seems I'm taking more than my fair share.
>
> > There were no
> > messages in January and only a few messages in December all between
> > Pekka and Jinkchok on the goals draft.
> >
> > It appears that people have lost interest in this group, and not
> > many seem to care any more about the work pursued in this group.
> > There are only 3 or 4 people have any interest left in DNA group?s
> > continued activities.
>
>
>Certainly mailing list traffic has been light.
>
>This is of concern to both the Chairs and the Area
>Directors.
>
>There are, as you say, a small core of people
>actively driving work for this group.  The number of
>people is probably about three times as large
>as you say, but the silence of the other
>Mailing list members should be explored.
>We really need to see if the (list) members are
>actually interested in the outputs of those
>currently spending cycles on the development.
>
>It is worth noticing that there are at least
>two implementations of ideas under discussion,
>and interest from manufacturers.
>
> > This is very rare for an IETF group where it is easy to see even a
> > smallest working group attract a few hundred people in meetings
> > (and /or on mailing lists).  The main reason is that DNA group
> > hasn?t produced any thing useful ? goals and bcp drafts are just re-
> > iteration of what already exist in IPv4 and IPv6 mobility
> > architecture documents.
>
>At the last IETF session, we didn't have room
>for one of the A-D's to squeeze in (sorry!)
>
>Perhaps we have or will see a waning of interest.
>
>It's worth working out whether this is the case,
>though.
>
>The goals document is a distillation of the
>discussions which originated back in the days of
>MIPv6 development.  At the time, the understanding
>of the problem was actually quite poor, and
>JinHyeock and I (and others) proposed some
>solutions which look naive now.
>
>A set of goals to measure solutions against
>is certainly worth having.  Now that it has
>been approved, the work can move onto something
>closer to implementation.
>
>The BCPs are similar in that people have previously
>been able to design solutions which work in a
>some constrained environments (Eager Cell Switching,
>etc), but have significant drawbacks in others.
>the BCPs are to give something defined in the
>current standards which is useful, safe and
>reasonably fast.
>
>Personally (biased), I think that these documents
>aren't redundant. As far as I can see there
>weren't really any architecture documents for
>mobility in IPv6 :)
>
>Please be aware: this is not a mobility group.
>It's a connectivity group.  Erik Nordmark
>(then an AD) said that he thought the problem was
>broader than movement detection.
>
>So while mobility documents may have had a go at
>defining mechanism for fast reconfiguration
>in a particular network, not everyine will have
>50ms mean delay between RAs, nor FMIPv6.
>
> > Based on past proceedings and discussions, it appears that DNA
> > group cannot propose any solution without Layer 2 event
> > modifications; something that is outside the scope of IETF.
>
>This is not the case.
>
>There are several interesting and widely applicable
>ideas of how to do this at L3.
>
>By monday, a design discussion draft will be
>posted (one of the Design Team products), which
>will shed light on this.
>
>At this stage, DNA-DT discussions have been
>in-camera.  Pekka and I aren't even on the list.
>It's not surprising that details aren't leaking
>out onto the DNA list yet then.
>
>While this is not aimed at secrecy, the DT have
>been doing a good job of effectively and efficiently
>evaluating various solutions.  New ideas and
>knowledge have been uncovered.
>
>Please wait and see for this (only a few days more).
>
> >  I
> > don?t see any interesting proposals being discussed in DNA WG. On
> > the other hand, there are over a dozen actively pursued proposals
> > in IEEE 802.21 ? protocol independent handoff group. For Layer 3
> > solutions, I have not seen any thing better than fast RA draft that
> > exists from pre-DNA group creation.
>
>Well, that depends on your point of view.
>
>There are plenty of drafts in the repository.
>
>
>https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=-dna-&search_rfcnumber=&search_area_acronym=&search_button=SEARCH
>
>You'll notice:
>
>(In the existing protocol space)
>draft-ietf-dna-link-information (None)
>
>draft-narayanan-dna-hosts-bcp
>draft-narayanan-dna-routers-bcp
>draft-jinchoi-dna-cpl
>draft-hong-dna-if-l2
>
>(in the proposal space)
>draft-narayanan-dna-rrd
>draft-daley-dna-det-fastra
>draft-daley-dna-nonce-resp
>draft-daley-dna-prob-fastra
>
>More drafts are expected on monday or by monday.
>
>As you know, a lot of the drafts
>come from a small core of people.
>If they're missing something, then people should
>contribute a more effective solution.
>
>
> > Yes, I know two or three active people in this group are trying to
> > create some sort of solution document, but it appears, based on
> > rather poor traffic on the mailing list, that mobility community
> > has already given up.
>
>Perhaps you are correct with regard to mailing list activity.
>
>It is certainly worth finding out if people
>are interested in the outputs of the group.
>
>Another alternative idea may be that while people
>are interested in the outputs, they are unable
>to devote time to the document and protocol
>development themselves (except for example
>at IETF).
>
>Perhaps we can poll people as to what their
>current level of interest is, and determine if
>some actions need to be taken.
>
>Certainly there needs to be more input on the ML
>for the IETF process to be fully effective.
>Lulls with furious activity around meeting times
>have the potential of blindsiding the group if
>new technical details come out too late to be fixed
>before a session.
>
> > What is the point of creating a document in which most people seem
> > to have lost the interest? In my opinion, the group should become
> > dormant or be closed until IEEE comes up with better event
> > definitions for layer 2 for facilitating faster hand-off.
>
>If people have lost interest and don't
>want to see a document, please speak up.
>
>If you're interested, but quiet, please indicate
>if this is so.
>
>Your advice on how best to advance the group
>is also welcome.
>
>(Chair Hat Off)
>
>Personally, being biased, I think that new
>trigger primitives are only half of the story.
>
>It may take a long time to upgrade or replace
>the majority of deployed link-layer equipment,
>especially those with a firmware or part hardware
>implementation.
>
>Software upgrades on host and routing
>infrastructure are either more common (for routers)
>or don't require co-ordination (for hosts).
>This may give L3 solutions earlier momentum
>than new L2 solutions.
>
>It's also worthwhile to remember that while
>IEEE's protocols are pervasive, they're not
>universal.
>
>Thanks again for having the courage to
>express an opinion.
>
>Greg



--Boundary_(ID_syDVwFBovC9MIJ+jxUfcTg)-- From dna-owner@webcamserver.eng.monash.edu.au Sun Feb 13 19:27:40 2005 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 TAA09678 for ; Sun, 13 Feb 2005 19:27:38 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKSK4RD98Q8Y6C79@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 14 Feb 2005 11:27:02 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5EA60AB54A; Mon, 14 Feb 2005 11:26:48 +1100 (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 198834FB04; Mon, 14 Feb 2005 11:26:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1E0Q1d28152 for dna-list; Mon, 14 Feb 2005 11:26:01 +1100 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 j1E0Q1628148 for ; Mon, 14 Feb 2005 11:26:01 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKSK3EVZMS8Y6C79@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 14 Feb 2005 11:25:44 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 47EF3AB546; Mon, 14 Feb 2005 11:25:43 +1100 (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 21C1D4FB04; Mon, 14 Feb 2005 11:25:43 +1100 (EST) Date: Mon, 14 Feb 2005 11:25:42 +1100 From: Greg Daley Subject: Re: [DNA] Re: Interest in DNA or not? (Re: ) In-reply-to: <20050212012213.28751.qmail@webmail31.rediffmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Goldsmith Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <420FF006.1090005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <20050212012213.28751.qmail@webmail31.rediffmail.com> Content-Transfer-Encoding: 7BIT Hi James, James Goldsmith wrote: > Greg: > > I am happy that you took this mail in good sprit. > > Here are my three comments: > > 1) Goals and BCP drafts are Ok for novices, but there are no fundamental > advancement of knowledge in these drafts. So, they are just the place > holders, similar to padding in the data frames to align on certain > boundaries;-) Indeed. That's what RFC's are basically for. They're not for the Illuminati of a particular technology to pore over, but for deployers or implementers, some of which won't know why certain steps were taken. Not everyone will read the goals document. It has been mostly useful to those people in the group considering the problems. The BCPs will be less relevant if people make modifications to protocols (using things like a DNA solution). There aren't really specifications of this today for the person who doesn't read RFC2461 regularly. The latest versions of the BCP draft provide usual case performance statistics though, for triggered RS/RA exchanges. The figures there are telling (though predictable): You can't use RFC2461 RS/RA, the primary routing discovery mechanism in IPv6, to support real-time voice (or video or user sessions or...). So something has to be done. If that doesn't mean standards track, it's still worth documenting (IMO). > 2) If you ignore Alper et. al's link hint draft which pre-exist before > DNA group, all other drafts that you mentioned below have been > co-authored by just the three authors - yourself, Jin-choi, and > Narayna. That, by any definition, is extremely limited participation > from the standardization point of view. I try not to ignore the link information draft. It's pretty important, in terms of IETF interest in sub-L3 issues. There are other drafts, some of which predate DNA and are mobileip or IPv6 titled. Also, please be aware that there are co-authors on the list of publications which you mentioned, which are making important contributions. You're right though, that there are some people putting a lot of time into DNA work. It's pretty amazing that people can be employed for a while (like me) to never send a packet which is forwarded by a router :) You may be pleased to know that I'm not a member of the DNA design team. I've been following their progress through reports, and they're doing well. There are new ideas coming out of the (sub)group. So maybe an idea which wasn't proposed by the three authors you mention will be the focus of DNA standardization. > 3) Honestly, I don't find any thing compelling in the solutions because > all we have are variations of fast RA with various names such as det RA, > probalistic RA or stochastic RA (waiting for it ;-). RA caching in light > weight APs is big no. Unless, someone can prove near-optimality of a > pure L3 solution, you are simply advancing something that will do more > harm than good. Well, we've already had more harm than good advanced in RFC3775 :) In Mobile IPv6, there wasn't time, space or inclination to do movement detection for mobile hosts correctly. So some of the Router Advertisement timers were modified. I was there at the time, and contributed text. It certainly wasn't any person's favourite specification (the RA timers/MD), but there wasn't any way of indicating succinctly how to use triggers, or which circumstances things could be done in (at L3). I'm pretty sure that the next draft isn't going to be stochastic RA (unless you submit it - it's getting pretty close to April 1). As you say, most of the drafts on the list cover RA delivery. There are three main areas where I think DNA may be able to contribute: * When and how to initiate checks. * How to identify from a single received message that change has occurred * How to receive change information reliably and quickly. These are being covered, and probably have the same level of attention (considering link-hints, BCP, prefix lists, draft-pentland-mobileip-linkid). These may not have the same architectural challenges as IPv6 multihoming, but are relatively achieveable, and potentially useful. If changes at L2 or in deployed networks make this unuseful, we'll take a serious look at that, and whether there should be a DNA group. It's going to be possible to prove the optimality and safety of L3 change detection solutions, though. It's also going to be possible to ask L2 designers: please give L3 the information and choice, the host is capable of deciding. Perhaps less per-technology focus will be needed by L2 designers, and they can concentrate on shipping frames fast. How this is achieved in reality may be different though, with wireless issues potentially dominating anything which can be done at L3. > Thats all that I have to say. > > James Well, your opinions are definitely sought. Sometimes the light of reason shines through someone saying "Wait a minute!". Feel free to discuss some more of these ideas (if you have the time or inclination). Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Feb 13 20:25:51 2005 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 UAA13218 for ; Sun, 13 Feb 2005 20:25:50 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKSM6B46V48Y6FHW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 14 Feb 2005 12:25:28 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E42B4AB544; Mon, 14 Feb 2005 12:25:18 +1100 (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 91C144FB04; Mon, 14 Feb 2005 12:25:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1E1OXI28862 for dna-list; Mon, 14 Feb 2005 12:24:33 +1100 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 j1E1OW628858 for ; Mon, 14 Feb 2005 12:24:32 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKSM587R9Y8WW6EI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 14 Feb 2005 12:24:27 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 20618AB542 for ; Mon, 14 Feb 2005 12:24:27 +1100 (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 03CC74FB05 for ; Mon, 14 Feb 2005 12:24:26 +1100 (EST) Date: Mon, 14 Feb 2005 12:24:26 +1100 From: Greg Daley Subject: [DNA] [Fwd: I-D ACTION:draft-narayanan-dna-hosts-bcp-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: <420FFDCA.7070705@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT A new draft BCP for hosts performing DNA has been added to the repository. This document was originated with draft-narayanan-dna-bcp-01 and has been broken into two components (hosts and routers) based on feedback at IETF61. This new document focusses on host issues for DNA, using existing protocols. Please read this document, and comment on-list. Greg -------- Original Message -------- Date: Fri, 11 Feb 2005 15:24:52 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-narayanan-dna-hosts-bcp-00.txt Sender: i-d-announce-bounces@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Detecting Network Attachment in IPv6 - Best Current Practices for hosts Author(s) : S. Narayanan, et al. Filename : draft-narayanan-dna-hosts-bcp-00.txt Pages : 0 Date : 2005-2-11 Hosts experiencing rapid link-layer changes may require further configuration change detection procedures than more 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narayanan-dna-hosts-bcp-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. [cut] From dna-owner@webcamserver.eng.monash.edu.au Sun Feb 13 20:27:45 2005 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 UAA13352 for ; Sun, 13 Feb 2005 20:27:45 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKSM8LMHW88Y6FHW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 14 Feb 2005 12:27:16 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F120AB544; Mon, 14 Feb 2005 12:27:10 +1100 (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 E6EA24FB03; Mon, 14 Feb 2005 12:27:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1E1Qv528915 for dna-list; Mon, 14 Feb 2005 12:26:57 +1100 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 j1E1Qv628911 for ; Mon, 14 Feb 2005 12:26:57 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKSM7ZF9S88WXH6B@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 14 Feb 2005 12:26:40 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 69481AB54B for ; Mon, 14 Feb 2005 12:26:40 +1100 (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 4443E4FB05 for ; Mon, 14 Feb 2005 12:26:40 +1100 (EST) Date: Mon, 14 Feb 2005 12:26:39 +1100 From: Greg Daley Subject: [DNA] [Fwd: I-D ACTION:draft-narayanan-dna-routers-bcp-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: <420FFE4F.2020505@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT A new draft BCP for network deployments supporting DNA has been added to the repository. This document was originated with draft-narayanan-dna-bcp-01 and has been broken into two components (hosts and routers) based on feedback at IETF61. This new document focusses on router and network side issues for networks which support host DNA operation. Please read this document, and comment on-list. Greg -------- Original Message -------- Date: Fri, 11 Feb 2005 15:25:20 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-narayanan-dna-routers-bcp-00.txt Sender: i-d-announce-bounces@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Detecting Network Attachment in IPv6 - Best Current Practices for Routers Author(s) : S. Narayanan, et al. Filename : draft-narayanan-dna-routers-bcp-00.txt Pages : 23 Date : 2005-2-11 Hosts experiencing rapid link-layer changes may require more frequent configuration change detection procedures than traditional fixed hosts. This document describes practices available to network deployers in order to support hosts Detecting Network Attachment in IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narayanan-dna-routers-bcp-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. [cut] From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 14 10:23:54 2005 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 KAA13403 for ; Mon, 14 Feb 2005 10:23:53 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKTFFFA6M28Y68WL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Feb 2005 02:23:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4695080003; Tue, 15 Feb 2005 02:23:25 +1100 (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 E6DBD3C00A; Tue, 15 Feb 2005 02:23:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1EFM2N05987 for dna-list; Tue, 15 Feb 2005 02:22:02 +1100 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 j1EFM0605983 for ; Tue, 15 Feb 2005 02:22:01 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKTFDC3LPO8WXO7X@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Feb 2005 02:21:44 +1100 Received: by localhost (Postfix, from userid 510) id 6C319AB545; Tue, 15 Feb 2005 02:21:44 +1100 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by moe.its.monash.edu.au (Postfix) with ESMTP id ABD694FB08; Tue, 15 Feb 2005 02:21:41 +1100 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFE6D212FE1; Mon, 14 Feb 2005 17:21:37 +0200 (EET) Date: Mon, 14 Feb 2005 17:22:05 +0200 From: Pekka Nikander Subject: Re: [DNA] Re: Interest in DNA or not? (Re: ) In-reply-to: <20050212012213.28751.qmail@webmail31.rediffmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Goldsmith Cc: dna@eng.monash.edu.au, Greg Daley Message-id: <59825f268250a52038f9d93cbd72fd95@nomadiclab.com> MIME-version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id j1EFM1605984 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <20050212012213.28751.qmail@webmail31.rediffmail.com> Content-Transfer-Encoding: 8BIT Dear James, > 3) Honestly, I don't find any thing compelling in the solutions > because  all we have are variations of fast RA with various names such > as det RA, probalistic RA or stochastic RA (waiting for it ;-). RA > caching in light weight APs is big no. Unless, someone can prove > near-optimality of a pure L3 solution, you are simply advancing > something that will do more harm than good. Firstly, I appreciate you voicing your opinion. Critic is what strives you for better. That said, would you please elaborate? What is the reason that you see them as doing any harm in the first place? How does that harm exceed the good that you see? If you are sincere with your critic, I'd like to see you back it up. On the other hand, if you are just expressing your frustration about the silence on the list, we may expect that to change soon. The design team document was submitted today, and should appear shortly. Either Greg or I will announce it here as soon as it appears. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 00:56:18 2005 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 AAA01590 for ; Tue, 15 Feb 2005 00:56:17 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKU9VX2I148WW4Z3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 15 Feb 2005 16:55:46 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D0044AB543; Tue, 15 Feb 2005 16:55:42 +1100 (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 8B82E4FB05; Tue, 15 Feb 2005 16:55:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1F5sq215664 for dna-list; Tue, 15 Feb 2005 16:54:52 +1100 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 j1F5sp615660 for ; Tue, 15 Feb 2005 16:54:51 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKU9UMWVVW8WXUNP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 15 Feb 2005 16:54:41 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CBE32AB547 for ; Tue, 15 Feb 2005 16:54:40 +1100 (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 611714FB05 for ; Tue, 15 Feb 2005 16:54:40 +1100 (EST) Date: Tue, 15 Feb 2005 16:54:40 +1100 From: Greg Daley Subject: [DNA] Relevant drafts to 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: <42118EA0.7080501@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Hi, Since the -00 deadline has just passed, I'm interested in collecting a list of documents relevant to DNA. If you've got documents which are relevant (even if they're not DNA keyworded) please indicate what they are, and how to get them (if they've not reached the repository yet). Greg. Link-Layer Hints ---------------- draft-ietf-dna-link-information-01.txt Related to Current Practice --------------------------- draft-hong-dna-if-l2-00.txt draft-jinchoi-dna-cpl-01.txt draft-narayanan-dna-hosts-bcp-00.txt draft-narayanan-dna-routers-bcp-00.txt draft-narayanan-dna-bcp-01.txt (superceded) Solution Space --------------- draft-jinchoi-dna-soln-frame-01 (expired) Router Advertisement delivery ----------------------------- draft-daley-dna-det-fastra-01.txt draft-daley-dna-prob-fastra-00.txt draft-jinchoi-dna-frd-01 (expired) Link Identifiers ---------------- draft-pentland-mobileip-linkid-03.txt draft-narayanan-dna-rrd-00.txt Response Matching ----------------- draft-daley-dna-nonce-resp-00.txt RFC-EDITOR QUEUE ---------------- draft-ietf-dna-goals-04.txt Other Working Groups: --------------------- draft-ietf-dhc-dna-ipv4-09.txt draft-daley-ipv6-tsllao-01.txt Documents Referencing DNA ------------------------- draft-ietf-dhc-dual-stack-02.txt draft-ietf-multi6-failure-detection-00.txt From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 19:56:31 2005 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 TAA07014 for ; Tue, 15 Feb 2005 19:56:30 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKVDNU9SHE8Y6MEM@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 11:54:37 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 21E8680006; Wed, 16 Feb 2005 11:54:31 +1100 (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 9AC3A3C007; Wed, 16 Feb 2005 11:54:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G0qx629462 for dna-list; Wed, 16 Feb 2005 11:52:59 +1100 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 j1G0qx629458 for ; Wed, 16 Feb 2005 11:52:59 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKVDLOX1V08WW78O@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 16 Feb 2005 11:52:48 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9A968AB548 for ; Wed, 16 Feb 2005 11:52:47 +1100 (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 78DD44FB0B for ; Wed, 16 Feb 2005 11:52:47 +1100 (EST) Date: Wed, 16 Feb 2005 11:52:47 +1100 From: Greg Daley Subject: [DNA] Design team discussion document available Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <4212995F.8020806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Dear WG, The DNA design team put out a Discussion document which outlines the principles as to the design of DNA solutions. It covers the pros and cons of each technology and also provides some new ideas which were developed within the Design Team. Performance measures are made for each of the protocols, for comparison purposes. It outlines how example technologies may be combined to form a complete DNA protocol and matches these against the DNA goals. I have been informed that this document is intended to support decisions made by the working group in choosing a DNA solution. Please comment with your opinions or questions after you have read the document. http://www.ietf.org/internet-drafts/draft-dnadt-dna-discussion-00.txt For your reference, the design team consists of: JinHyeock Choi, Tero Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark, and Brett Pentland. Greg (Not a design team member). From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 20:02:18 2005 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 UAA07719 for ; Tue, 15 Feb 2005 20:02:17 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVDX7NRRQ8Y6MN7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 12:02:13 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D0335AB546; Wed, 16 Feb 2005 12:02:04 +1100 (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 757634FB0D; Wed, 16 Feb 2005 12:02:04 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G11t329591 for dna-list; Wed, 16 Feb 2005 12:01:55 +1100 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 j1G11s629587 for ; Wed, 16 Feb 2005 12:01:55 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVDWVNSZ08WY3GI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Feb 2005 12:01:49 +1100 Received: by localhost (Postfix, from userid 510) id DDF46AB542; Wed, 16 Feb 2005 12:01:48 +1100 (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 B2E244FB08 for ; Wed, 16 Feb 2005 12:01:46 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1G11i5P027932 for ; Tue, 15 Feb 2005 20:01:44 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 62E0F3C8176 for ; Tue, 15 Feb 2005 19:59:21 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 548E43C8174for ; Tue, 15 Feb 2005 19:59:21 -0500 (EST) Date: Tue, 15 Feb 2005 20:01:44 -0500 From: Sathya Narayanan Subject: [DNA] DNA Hosts BCP In-reply-to: <42118EA0.7080501@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <42129B78.40302@Research.Panasonic.COM> Organization: Panasonic Technologies Company 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 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:1 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.2 (2004-11-16) References: <42118EA0.7080501@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT In the interest of initiating a discussion on the hosts BCP, I have tried to summarize the hosts BCP draft upto Section 6 below. Reference: http://www.ietf.org/internet-drafts/draft-narayanan-dna-hosts-bcp-00.txt The two steps for DNA recommended by the draft are: 1) Validation of current configuration (to identify link change) Example configurations are: the current IPv6 prefix and address, default router information and neighbour cache entries. Issues: Use of link local addresses and subset of prefixes in RA messages Suggested solutions: Confirmation of existing configuration based on received RA with current prefix and/or current router address. CPL - Complete Prefix list Confirmation of Neighbor cache entry for a global address (SHOULD). Use confirmation - DO NOT initiate this for validation test. Recommendations We have most of them as SHOULDs. May be that is too conservative. Please look at section 5.3 in the draft 2) Reachability detection Partial reachability confirmation with the current default router is REQUIRED, while bi-directional is RECOMMENDED for wireless environments. Issues: Dependence on long timeouts Suggested solutions: Neighbor discovery test (NS-NA message exchange) Router discovery test (RS-RA message exchange) Hybrid - both NS and RS parallely ??? Require authorization of the router. Recommendations: Again, please comment on the SHOULDs and MAYs. Section 6.3 Please post comments. -Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 20:33:34 2005 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 UAA10776 for ; Tue, 15 Feb 2005 20:33:33 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVEZF29HS8WY3ZS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 12:33:22 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04BB68000A; Wed, 16 Feb 2005 12:32:06 +1100 (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 A80663C006; Wed, 16 Feb 2005 12:32:05 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G1VuU29926 for dna-list; Wed, 16 Feb 2005 12:31:56 +1100 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 j1G1Vt629922 for ; Wed, 16 Feb 2005 12:31:55 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKVEYTGNXG8Y6OVY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 16 Feb 2005 12:31:37 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 06CBCAB543 for ; Wed, 16 Feb 2005 12:31:37 +1100 (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 982B24FB0A for ; Wed, 16 Feb 2005 12:31:36 +1100 (EST) Date: Wed, 16 Feb 2005 12:31:36 +1100 From: Greg Daley Subject: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <4212A278.9050409@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii 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 DT, Was there a reason that Tentative Source Link-Layer Address options were recommended for acting as the sequence ordering mechanism in unnegotiated detfastra? I would have thought that the inbound Router Solicitation's source address would work just as well to xor against the hash (probably in reverse or reverse byte order, to be less predictable) to get the ordering. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 21:32:44 2005 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 VAA17693 for ; Tue, 15 Feb 2005 21:32:43 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVH2OLMG08Y6NAJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 13:32:30 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E7B9C80006; Wed, 16 Feb 2005 13:31:59 +1100 (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 7FF8D3C011; Wed, 16 Feb 2005 13:31:59 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G2VbF30579 for dna-list; Wed, 16 Feb 2005 13:31:37 +1100 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 j1G2Vb630575 for ; Wed, 16 Feb 2005 13:31:37 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVH26OWJG8WY48W@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Feb 2005 13:31:36 +1100 Received: by localhost (Postfix, from userid 510) id 169DB80005; Wed, 16 Feb 2005 13:31:36 +1100 (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 DABF03C012; Wed, 16 Feb 2005 13:31:33 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.84.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j1G2VWvB000659; Tue, 15 Feb 2005 18:31:32 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1G2VVWg694620; Tue, 15 Feb 2005 18:31:31 -0800 (PST) Date: Tue, 15 Feb 2005 18:30:53 -0800 From: Erik Nordmark Subject: Re: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA In-reply-to: <4212A278.9050409@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: <4212B05D.4060600@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 (X11/20041208) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <4212A278.9050409@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Dear DT, Did you intend to send this on the DT list or the WG list? > Was there a reason that Tentative Source Link-Layer Address > options were recommended for acting as the sequence > ordering mechanism in unnegotiated detfastra? > > I would have thought that the inbound Router Solicitation's > source address would work just as well to xor against the hash > (probably in reverse or reverse byte order, to be less > predictable) to get the ordering. Since you can't assume that your link-local address is unique should you have moved, you need to run the optimistic DAD procedure. While doing so, the RS must have the unspecified source address. Hence all RSes from different hosts will all look identical, except for a TSLLAO. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 15 23:18:59 2005 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 XAA13703 for ; Tue, 15 Feb 2005 23:18:58 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKVKSUFRPY8WW7Q8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 15:18:44 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BCF380005; Wed, 16 Feb 2005 15:18:36 +1100 (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 963013C004; Wed, 16 Feb 2005 15:18:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G4I7O31919 for dna-list; Wed, 16 Feb 2005 15:18:07 +1100 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 j1G4I6631915 for ; Wed, 16 Feb 2005 15:18:06 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVKS41DOK8WY522@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Feb 2005 15:18:02 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE3BFAB542; Wed, 16 Feb 2005 15:18:00 +1100 (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 8A36C4FB0D; Wed, 16 Feb 2005 15:18:00 +1100 (EST) Date: Wed, 16 Feb 2005 15:18:00 +1100 From: Greg Daley Subject: Re: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA In-reply-to: <4212B05D.4060600@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: <4212C978.9070508@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <4212A278.9050409@eng.monash.edu.au> <4212B05D.4060600@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Dear DT, > > > Did you intend to send this on the DT list or the WG list? I intended it to the WG mailing list. Since the document is out there (DNA list), I guess it's OK to discuss components on-list. I wasn't sure if my email to DNA-DT would bounce anyway. >> Was there a reason that Tentative Source Link-Layer Address >> options were recommended for acting as the sequence >> ordering mechanism in unnegotiated detfastra? >> >> I would have thought that the inbound Router Solicitation's >> source address would work just as well to xor against the hash >> (probably in reverse or reverse byte order, to be less >> predictable) to get the ordering. > > > Since you can't assume that your link-local address is unique should you > have moved, you need to run the optimistic DAD procedure. > While doing so, the RS must have the unspecified source address. > Hence all RSes from different hosts will all look identical, except for > a TSLLAO. Optimistic DAD doesn't require unspecified source addresses on RSs. It requires that (non-tentative) SLLAOs aren't included in RSs while optimistic. (section 2.2 of draft-ietf-ipv6-optimistic-dad-05: "... * Never using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified address, may be used, or the RS may be sent without a SLLAO. An address collision with a router may cause neighboring router's IsRouter flags for that address to be cleared. However, routers do not appear to use the IsRouter flag for anything, and the NA sent in response to the collision will reassert the IsRouter flag. ..." ) section 3.2: "... * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with a SLLAO from an Optimistic Address. Router Solicitations SHOULD be sent from a non-Optimistic or the Unspecified Address, however they MAY be sent from an Optimistic Address as long as the SLLAO is not included. ..." ) There was previously some concern over the use of RS, since it clears the IsRouter flag in the case of colliding with a router (V.low probability). It was found that the DAD defence from the collided address would reset it less than 1 second later, though. In most cases, I guess that the host will have to choose between sending RS with Unspecified Source or Optimistic Address. There's no protocol impediment to using the Optimistic Address though. I'd guess that really we'll see people using the Optimistic Address in most cases, in order to allow for a unicast response (at L3). If that's the case, source addresses are sufficient. Relying on TSLLAO excludes legacy devices which are more likely to use unspecified source addresses anyway. In the case that an RS arrives with an address and no TSLLAO (or even with an SLLAO one), it may be valuable to send an RS fast anyway. Just an idea. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 16 00:41:31 2005 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 AAA21641 for ; Wed, 16 Feb 2005 00:41:30 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKVNNV3F428Y6ROP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 16:40:58 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76F96AB54E; Wed, 16 Feb 2005 16:40:52 +1100 (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 2E2994FB02; Wed, 16 Feb 2005 16:40:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G5eQ300366 for dna-list; Wed, 16 Feb 2005 16:40:26 +1100 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 j1G5eP600362 for ; Wed, 16 Feb 2005 16:40:26 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVNKG74PK8Y6NG0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Feb 2005 16:38:08 +1100 Received: by localhost (Postfix, from userid 510) id 6DC6EAB542; Wed, 16 Feb 2005 16:38:07 +1100 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by curly.its.monash.edu.au (Postfix) with ESMTP id 29BEE4FB04; Wed, 16 Feb 2005 16:38:06 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.85.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j1G5c5Wx011641; Tue, 15 Feb 2005 21:38:05 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1G5c48V727547; Tue, 15 Feb 2005 21:38:04 -0800 (PST) Date: Tue, 15 Feb 2005 21:37:28 -0800 From: Erik Nordmark Subject: Re: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA In-reply-to: <4212C978.9070508@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: <4212DC18.5090009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <4212A278.9050409@eng.monash.edu.au> <4212B05D.4060600@sun.com> <4212C978.9070508@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Optimistic DAD doesn't require unspecified source addresses on RSs. That's a bit odd, since RFC 2461 has a SHOULD include SLLAO when the source address isn't unspecified. And when using optimistic dad the source address would presumably need to be unspecified to avoid polluting the caches with optimistic information. > It requires that (non-tentative) SLLAOs aren't included in RSs while > optimistic. > > (section 2.2 of draft-ietf-ipv6-optimistic-dad-05: > > "... > * Never using an Optimistic Address as the source address of a Router > Solicitation with a SLLAO. Another address, or the unspecified > address, may be used, or the RS may be sent without a SLLAO. Hmm - sending a RS with the optimistic address as a source and without SLLAO doesn't seem any more useful then sending with with an unspecified source address. Can you recall why optimistic DAD explicitly wants to allow this? > In most cases, I guess that the host will have to choose between sending > RS with Unspecified Source or Optimistic Address. There's no protocol > impediment to using the Optimistic Address though. > > I'd guess that really we'll see people using the Optimistic Address > in most cases, in order to allow for a unicast response (at L3). > If that's the case, source addresses are sufficient. But you wouldn't get a single unicast response unless the router has a neighbor cache entries which requires either a NS/NA exchange triggered by the router before the RA can be unicast, or TSLLAO. Optimizing for the former 4 packet exchange doesn't seem useful, since the multicast RA is actually as efficient if not more efficient. > Relying on TSLLAO excludes legacy devices which are more likely to use > unspecified source addresses anyway. In the case that an RS arrives > with an address and no TSLLAO (or even with an SLLAO one), it may be > valuable to send an RS fast anyway. I assume that by "legacy devices" you mean devices that implement RFC 2461/62. Such devices, after moving from one link to another, will retain the old information for an extremely long time. For instance, addresses autoconfigured from the prefix of the old link will remain preferred for new communication for *7 days* when the default lifetimes are used. And as long as these are retained some communication (the ones that pick that preferred source address based on the default address selection algorithm) will just. So given that legacy host will be hosed for 7 days by default, I'm not concerned about being able to give them a RA a few seconds faster. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 16 01:45:14 2005 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 BAA27361 for ; Wed, 16 Feb 2005 01:45:13 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVPVPTJ2W8Y6OTC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 16 Feb 2005 17:45:07 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35389AB543; Wed, 16 Feb 2005 17:44:28 +1100 (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 EB4074FB0B; Wed, 16 Feb 2005 17:44:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1G6hul01075 for dna-list; Wed, 16 Feb 2005 17:43:56 +1100 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 j1G6ht601071 for ; Wed, 16 Feb 2005 17:43:55 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKVPUOHM168Y6OTC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 16 Feb 2005 17:43:40 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E1198AB545; Wed, 16 Feb 2005 17:43:37 +1100 (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 9C1F14FB0C; Wed, 16 Feb 2005 17:43:37 +1100 (EST) Date: Wed, 16 Feb 2005 17:43:37 +1100 From: Greg Daley Subject: Re: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA In-reply-to: <4212DC18.5090009@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: <4212EB99.8000503@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: <4212A278.9050409@eng.monash.edu.au> <4212B05D.4060600@sun.com> <4212C978.9070508@eng.monash.edu.au> <4212DC18.5090009@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, This is getting interesting, but will probably settle down soon. Erik Nordmark wrote: > Greg Daley wrote: > >> Optimistic DAD doesn't require unspecified source addresses on RSs. > > > That's a bit odd, since RFC 2461 has a SHOULD include SLLAO when the > source address isn't unspecified. And when using optimistic dad the > source address would presumably need to be unspecified to avoid > polluting the caches with optimistic information. As you say, SHOULD, not MUST include the SLLAO. We certainly don't want to include SLLAO, but an optimistic neighbour advertisement or a TSLLAO won't override existing neighbour cache entries (and any DAD defending NA will). So there's really change in having RS's not include the SLLAO, since routers have already had to deal with the case (albeit it maybe not optimally). >> It requires that (non-tentative) SLLAOs aren't included in RSs while >> optimistic. >> >> (section 2.2 of draft-ietf-ipv6-optimistic-dad-05: >> >> "... >> * Never using an Optimistic Address as the source address of a >> Router >> Solicitation with a SLLAO. Another address, or the unspecified >> address, may be used, or the RS may be sent without a SLLAO. > > > Hmm - sending a RS with the optimistic address as a source and without > SLLAO doesn't seem any more useful then sending with with an unspecified > source address. * It is useful if the router performs neighbour discovery on the address, and then sends unicast (which is what at least RADVD on Linux does, if it isn't sending an immediate Multicast RA). * It is useful also if the router has an existing neighbour cache entry for the address (likely in the non-movement case for DNA). * It's useful if there's TSLLAO in the RS. * It doesn't hurt if there's no way to make a unicast response, since a multicast will be scheduled. Rate-limitation of multicast RAs is likely to induce delays in some cases. This (the chance multicast delay) is calculated for various advertisement intervals in draft-narayanan-dna-routers-bcp-00. Sending a specified source address and allowing the router to choose whether it delays with a multicast or solicits and sends an NS (or if it has TSLLAO sends a unicast) makes sense if you want a (even moderately) fast response. > Can you recall why optimistic DAD explicitly wants to allow this? I'm not sure that Optimistic DAD specifically wanted to allow this, but it's a good feature to keep if it's supported, since routers modified to support TSLLAO are likely to be the ones optimized for DNA. >> In most cases, I guess that the host will have to choose between sending >> RS with Unspecified Source or Optimistic Address. There's no protocol >> impediment to using the Optimistic Address though. >> >> I'd guess that really we'll see people using the Optimistic Address >> in most cases, in order to allow for a unicast response (at L3). >> If that's the case, source addresses are sufficient. > > > But you wouldn't get a single unicast response unless the router has a > neighbor cache entries which requires either a NS/NA exchange triggered > by the router before the RA can be unicast, or TSLLAO. > Optimizing for the former 4 packet exchange doesn't seem useful, since > the multicast RA is actually as efficient if not more efficient. Indeed. It's not optimized for the 4 packet exchange. It's optimized for the two packet exchange, when TSLLAO is present. I'm not encouraging people to leave out TSLLAO, I'm encouraging the optimization to not rely on TSLLAO. As I said earlier, an RS won't perform worse by having a specified source address (with SLLAO, TSLLAO or no LLAO). Router discovery can perform worse if there's an unspecified source address, if TSLLAO isn't supported by the router. >> Relying on TSLLAO excludes legacy devices which are more likely to use >> unspecified source addresses anyway. In the case that an RS arrives >> with an address and no TSLLAO (or even with an SLLAO one), it may be >> valuable to send an RS fast anyway. > > > I assume that by "legacy devices" you mean devices that implement RFC > 2461/62. Such devices, after moving from one link to another, will > retain the old information for an extremely long time. For instance, > addresses autoconfigured from the prefix of the old link will remain > preferred for new communication for *7 days* when the default lifetimes > are used. And as long as these are retained some communication (the ones > that pick that preferred source address based on the default address > selection algorithm) will just. So given that legacy host will be hosed > for 7 days by default, I'm not concerned about being able to give them a > RA a few seconds faster. I actually mean anyone not running optimistic DAD. :) This includes a lot of RFC3775 implementations today. The legacy unspecified source address devices won't get a fast response if you use the source address for fast responses. Even with TSLLAO though, it's not possible in every implementation to send unicast MAC responses when there's an RS from the unspecified source address. Any responses would then have to be treated as multicast. Specified source addresses get around this issue. They also create neighbour cache entries on the router, which an unspecified address RS cannot. It's worth considering that unspecified source address RS cannot be secured with SEND. We may not want to give fast responses to devices which don't have to do any work in generating solicitations. What I'm saying is not that RS's should be sent without SLLAOs or TSLLAOs, but that on optimized transmissions the hosts are likely to have specified source addresses AND TSLLAOs. So an unspecified source addresses really shouldn't be the focus of optimization. One of the purposes of optimistic DAD is to allow use of addresses while optimistic. It would be a shame to waste the opportunity of using this feature, when there are so many problems with RS's from unspecified source addresses. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 18 06:24:42 2005 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 GAA19892 for ; Fri, 18 Feb 2005 06:24:40 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKYS94MK6G8WW6CV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 18 Feb 2005 22:24:16 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B0E5AAB544; Fri, 18 Feb 2005 22:24:08 +1100 (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 6CD8A4FB05; Fri, 18 Feb 2005 22:24:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1IBMbN04429 for dna-list; Fri, 18 Feb 2005 22:22:37 +1100 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 j1IBMb604425 for ; Fri, 18 Feb 2005 22:22:37 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKYS6YQSQA8Y77KW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 18 Feb 2005 22:22:24 +1100 Received: by localhost (Postfix, from userid 510) id 3D919AB545; Fri, 18 Feb 2005 22:22:24 +1100 (EST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5B9744FB07 for ; Fri, 18 Feb 2005 22:22:21 +1100 (EST) Received: from speedy (speedy.comnets.uni-bremen.de [134.102.155.154]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id j1IBMIq28087 for ; Fri, 18 Feb 2005 12:22:19 +0100 Date: Fri, 18 Feb 2005 12:22:21 +0100 From: Stefan Aust Subject: [DNA] Question about Make before Break Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: aust@comnets.uni-bremen.de Message-id: <000901c515ac$1d4ed130$9a9b6686@speedy> Organization: ComNets MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_qpCkLF+/960ZE2iAwE5jkA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Authentication-warning: bugs.comnets.uni-bremen.de: Host speedy.comnets.uni-bremen.de [134.102.155.154] claimed to be speedy This is a multi-part message in MIME format. --Boundary_(ID_qpCkLF+/960ZE2iAwE5jkA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear DNA WG, =20 I have a question regarding the draft http://www.ietf.org/internet-drafts/draft-hong-dna-if-l2-00.txt =20 Chapter 3.4 describes the Make before Break approach for Multiple = Interfaces and contains the following statement: =20 =85To support the make before break method on multiple interfaces, each link-layer technology must be the same. =20 I guess that this is not the case for mobile terminals which have more = than one wireless interface for different bearer technologies, e.g., WLAN, = GPRS and UMTS. Especially for seamless roaming in overlay networks you will need access = to different link-layer technologies. =20 What is the idea behind this statement in the draft? =20 Regards, Stefan =20 ----- =20 Universit=E4t Bremen / University of Bremen FB 1 - ikom/ComNets Dipl.-Ing. Stefan Aust Otto-Hahn-Allee NW1 28359 Bremen - Germany =20 Tel: +49 421 218 8264 Fax: +49 421 218 3601 Mail: aust@comnets.uni-bremen.de Web: www.comnets.uni-bremen.de/~aust =20 =20 =20 =20 --Boundary_(ID_qpCkLF+/960ZE2iAwE5jkA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Dear DNA WG,

 

I have a question regarding the = draft

= http://www.ietf.org/internet-drafts/draft-hong-dna-if-l2-00.txt

 

Chapter 3.4 describes the Make before Break = approach for Multiple Interfaces and contains the following = statement:

 

…To support the make before break method = on multiple interfaces, each link-layer technology must be the = same.

 

I guess that this is not the case for mobile terminals which have more than one wireless interface for different = bearer technologies, e.g., WLAN, GPRS and UMTS.

Especially for seamless roaming in overlay = networks you will need access to different link-layer = technologies.

 

What is the idea behind this statement in the = draft?

 

Regards,

Stefan

 

-----

 

Universit=E4t Bremen / University of = Bremen

FB 1 - ikom/ComNets

Dipl.-Ing. Stefan Aust

Otto-Hahn-Allee NW1

28359 Bremen - Germany

 

Tel: +49 421 218 8264

Fax: +49 421 218 3601

Mail: aust@comnets.uni-bremen.de

Web: www.comnets.uni-bremen.de/~a= ust

 

 

 

 

--Boundary_(ID_qpCkLF+/960ZE2iAwE5jkA)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 18 18:38:26 2005 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 SAA21823 for ; Fri, 18 Feb 2005 18:38:25 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKZHV8QTMG8Y6ZBR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 19 Feb 2005 10:38:16 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADD81AB543; Sat, 19 Feb 2005 10:38:11 +1100 (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 6818A4FB07; Sat, 19 Feb 2005 10:38:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1INbSe12801 for dna-list; Sat, 19 Feb 2005 10:37:28 +1100 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 j1INbR612797 for ; Sat, 19 Feb 2005 10:37:27 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LKZHU46IUU8WW92I@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 19 Feb 2005 10:37:17 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3AA24AB542 for ; Sat, 19 Feb 2005 10:37:17 +1100 (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 177B04FB09 for ; Sat, 19 Feb 2005 10:37:17 +1100 (EST) Date: Sat, 19 Feb 2005 10:37:16 +1100 From: Greg Daley Subject: [DNA] Members' interest in 802.21? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42167C2C.4040900@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Hi, There has been some informal discussion of the importance of DNA to 802.21 and 802.21 to DNA. Does anyone have an opinion of how the groups interact, or how they could be made to interact? Put another way, if there are synergies between the groups, what's the best way for the groups to contribute to each others' work? Particularly if you're attending both 802.21 and DNA, that would be interesting to know. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 18 23:21:41 2005 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 XAA21976 for ; Fri, 18 Feb 2005 23:21:40 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKZRQKISC08WZ21Y@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 19 Feb 2005 15:21:33 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6EE6DAB546; Sat, 19 Feb 2005 15:20:45 +1100 (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 216C14FB0B; Sat, 19 Feb 2005 15:20:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1J4KDY15683 for dna-list; Sat, 19 Feb 2005 15:20:13 +1100 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 j1J4KC615679 for ; Sat, 19 Feb 2005 15:20:12 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LKZRPJMZGI8WZ21Y@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 19 Feb 2005 15:19:56 +1100 Received: by localhost (Postfix, from userid 510) id 16A3E80002; Sat, 19 Feb 2005 15:19:56 +1100 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id C7F923C003; Sat, 19 Feb 2005 15:19:53 +1100 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC5007015D3PX@mailout2.samsung.com>; Sat, 19 Feb 2005 13:19:51 +0900 (KST) 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 <0IC500L6S5D2W9@mailout2.samsung.com>; Sat, 19 Feb 2005 13:19:50 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC50066H5CZO1@mmp1.samsung.com>; Sat, 19 Feb 2005 13:19:50 +0900 (KST) Date: Sat, 19 Feb 2005 13:22:03 +0900 From: Soohong Daniel Park Subject: RE: [DNA] Members' interest in 802.21? In-reply-to: <42167C2C.4040900@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg, I know several people already are attending both .21 and DNA. Both groups are able to use them as a reporter. Just my comments Thanks Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of Greg Daley > Sent: Saturday, February 19, 2005 8:37 AM > To: dna@eng.monash.edu.au > Subject: [DNA] Members' interest in 802.21? > > > Hi, > > There has been some informal discussion of the > importance of DNA to 802.21 and 802.21 to DNA. > > Does anyone have an opinion of how the groups > interact, or how they could be made to interact? > > Put another way, if there are synergies between the > groups, what's the best way for the groups to > contribute to each others' work? > > Particularly if you're attending both 802.21 > and DNA, that would be interesting to know. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 21 01:46:12 2005 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 BAA29476 for ; Mon, 21 Feb 2005 01:46:10 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL2PD6EZ8S8Y7TQV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 21 Feb 2005 17:45:35 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A4B0AB545; Mon, 21 Feb 2005 17:45:04 +1100 (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 D8AB84FB04; Mon, 21 Feb 2005 17:45:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1L6hX819127 for dna-list; Mon, 21 Feb 2005 17:43:33 +1100 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 j1L6hW619123 for ; Mon, 21 Feb 2005 17:43:32 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL2PB0BF4S8Y7A8O@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 21 Feb 2005 17:43:19 +1100 Received: by localhost (Postfix, from userid 510) id 8009CAB547; Mon, 21 Feb 2005 17:43:19 +1100 (EST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by moe.its.monash.edu.au (Postfix) with ESMTP id 810934FB0B for ; Mon, 21 Feb 2005 17:43:13 +1100 (EST) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6hAvt029173; Mon, 21 Feb 2005 15:43:10 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h9fN014080; Mon, 21 Feb 2005 15:43:09 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h8p4014055; Mon, 21 Feb 2005 15:43:08 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h88h026462; Mon, 21 Feb 2005 15:43:08 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h7YB026452; Mon, 21 Feb 2005 15:43:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h7AP009496; Mon, 21 Feb 2005 15:43:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h6dE011122; Mon, 21 Feb 2005 15:43:07 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (imd0.m.ecl.ntt.co.jp [129.60.5.142]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1L6h6r6011119; Mon, 21 Feb 2005 15:43:06 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id PAA02870; Mon, 21 Feb 2005 15:43:06 +0900 (JST) Date: Mon, 21 Feb 2005 15:39:45 +0900 From: Takeshi Ogawa Subject: [DNA] draft-ogawa-fhopt-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, mobopts@irtf.org, dhcwg@ietf.org Message-id: <200502210643.PAA02870@imd.m.ecl.ntt.co.jp> MIME-version: 1.0 X-Mailer: EdMax Ver2.85.3F Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi, all, I posted a new draft to dhc WG, "DHCPv6 Options for Fast Handovers", draft-ogawa-fhopt-00.txt". It can be found at: http://www.ietf.org/internet-drafts/draft-ogawa-fhopt-00.txt With great effort of many researchers, the protocol design of FMIP is to be completed. However, I think there are 4 issues to apply current FMIP to real networks. In the draft, the issues are discussed briefly, and new DHCP options (Fast Handover Options) and their protocol is proposed as an alternative to current FMIP. The main functions of this protocol are ported from FMIP and some new functions are added. With the protocol, fast handover function including fast "Detecting Network Attachment" function is deployed in DHCP servers and MNs but not in every router, so plain access routers (if they have the DHCP relay function) can be used. For example, Cisco's current routers, which support the DHCPv6 relay function, can be used. We are currently implementing the protocol in Linux. I plan to check the basic protocol functions on real equipment by the end of March. I would very appreciate it if you would give me some comment for the draft. Thanks in advance. - Takeshi. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 21 18:04:38 2005 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 SAA25940 for ; Mon, 21 Feb 2005 18:04:37 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL3NK3HDQ68Y780T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 22 Feb 2005 10:04:14 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 73B08AB544; Tue, 22 Feb 2005 10:04:10 +1100 (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 2BEB44FB0C; Tue, 22 Feb 2005 10:04:10 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1LN3Sq30208 for dna-list; Tue, 22 Feb 2005 10:03:28 +1100 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 j1LN3R630204 for ; Tue, 22 Feb 2005 10:03:27 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL3NJ46U9O8Y80WD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 22 Feb 2005 10:03:24 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1DC3CAB542 for ; Tue, 22 Feb 2005 10:03:23 +1100 (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 F1A6F4FB07 for ; Tue, 22 Feb 2005 10:03:22 +1100 (EST) Date: Tue, 22 Feb 2005 10:03:21 +1100 From: Greg Daley Subject: [DNA] IETF62 Detecting Network Attachment session agenda proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <421A68B9.4070400@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Hi, Here's the proposed session agenda for Minneapolis. Please indicate if you think any additions or modifications are required. Tue 1300-1500 - 10 min wg status and summary - 20 min link information draft draft-ietf-dna-link-information-01.txt - 20 min 802.21 liason - 20 min DNA hosts bcp draft, with discussion draft-narayanan-dna-hosts-bcp-00.txt - 20 min DNA routers bcp draft, with discussion draft-narayanan-dna-routers-bcp-00.txt - 30 min new individual drafts for presentation, if any? Thu 1530-1745 - 30 min dt report draft-dnadt-dna-discussion-00.txt - any related individual drafts? (5 min each) - 60 min discussion (with 15 minute break) - 10 min next steps Please note that there is a lot of time devoted to DNA this time, so we can resolve some of the issues on milestone documents. It is important to read the current version of any document listed next to an agenda item before you arrive. Relevant Documents ------------------ Link-Layer Hints ---------------- draft-ietf-dna-link-information-01.txt Related to Current Practice --------------------------- draft-jinchoi-dna-cpl-01.txt draft-narayanan-dna-hosts-bcp-00.txt draft-narayanan-dna-routers-bcp-00.txt draft-narayanan-dna-bcp-01.txt (superceded) Solution Space --------------- draft-jinchoi-dna-soln-frame-01 (expired) DNA Design Team summary ----------------------- draft-dnadt-dna-discussion-00.txt Router Advertisement delivery ----------------------------- draft-daley-dna-det-fastra-01.txt draft-daley-dna-prob-fastra-00.txt draft-jinchoi-dna-frd-01 (expired) Link Identifiers ---------------- draft-pentland-mobileip-linkid-03.txt draft-narayanan-dna-rrd-00.txt Response Matching ----------------- draft-daley-dna-nonce-resp-00.txt Multiple Interface Issues ------------------------- draft-hong-dna-if-l2-00.txt draft-iponair-dna-polimand-02 (expired? new version?) RFC-EDITOR QUEUE! ---------------- draft-ietf-dna-goals-04.txt Other Working Groups: --------------------- draft-ietf-dhc-dna-ipv4-09.txt draft-daley-ipv6-tsllao-01.txt Documents Referencing DNA ------------------------- draft-ietf-dhc-dual-stack-02.txt draft-ietf-multi6-failure-detection-00.txt From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 21 21:10:19 2005 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 VAA14897 for ; Mon, 21 Feb 2005 21:10:17 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL3U22FF468Y7A2C@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 22 Feb 2005 13:09:55 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 75ADD8000C; Tue, 22 Feb 2005 13:09:40 +1100 (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 2A15E3C00A; Tue, 22 Feb 2005 13:09:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1M296Z32111 for dna-list; Tue, 22 Feb 2005 13:09:06 +1100 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 j1M295632107 for ; Tue, 22 Feb 2005 13:09:05 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL3U10K4908Y7U2J@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 22 Feb 2005 13:08:50 +1100 Received: by localhost (Postfix, from userid 510) id 234D880002; Tue, 22 Feb 2005 13:08:50 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 864AB3C005; Tue, 22 Feb 2005 13:08:48 +1100 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICA00M01J9GQV@mailout3.samsung.com>; Tue, 22 Feb 2005 11:08:04 +0900 (KST) 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 <0ICA003OQJ9G23@mailout3.samsung.com>; Tue, 22 Feb 2005 11:08:04 +0900 (KST) Received: from jinchoe ([75.2.43.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ICA00C87J9GRX@mmp1.samsung.com>; Tue, 22 Feb 2005 11:08:04 +0900 (KST) Date: Tue, 22 Feb 2005 11:08:03 +0900 From: JinHyeock Choi Subject: Re: [DNA] IETF62 Detecting Network Attachment session agenda proposal Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Message-id: <00bf01c51883$5795baa0$e82b024b@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.2 (2004-11-16) References: <421A68B9.4070400@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Greg Kindly allow a 10 min slot for CPL. CPL was around for a while and we'd like to ask WG to accept it as a WG item. We think it is mature enough and the DT discussion draft cites CPL as a backup scheme. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 22 18:36:47 2005 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 SAA09093 for ; Tue, 22 Feb 2005 18:36:45 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL52Z1R3XA8Y89T2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 23 Feb 2005 10:36:15 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 97664AB544; Wed, 23 Feb 2005 10:36:07 +1100 (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 4AE924FB07; Wed, 23 Feb 2005 10:36:07 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1MNX3s15181 for dna-list; Wed, 23 Feb 2005 10:33:03 +1100 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 j1MNX3615177 for ; Wed, 23 Feb 2005 10:33:03 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL52V5N2UC8X07RA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 23 Feb 2005 10:32:59 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F378AB545 for ; Wed, 23 Feb 2005 10:32:59 +1100 (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 1A0B94FB14 for ; Wed, 23 Feb 2005 10:32:59 +1100 (EST) Date: Wed, 23 Feb 2005 10:32:58 +1100 From: Greg Daley Subject: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <421BC12A.70204@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 last IETF, it was made an action point to follow up getting ethernet related text for the link information draft. Due to time delays and people being busy, this hasn't been incorporated into the draft before the deadline. So I thought I'd have a go at it. Below is a rough version of some text which may be applicable to link hints in 802.3/802.1d. Everyone is asked to read and comment on the text. People with expertise in MAC implementation and especially bridging are welcome to review/comment/trash this. Greg ----------------------------------------------- The following text requires two references: ieee 802.3 (2002) [802.3] ieee 802.1d (2004) [802.1d] please note that this 802.3 2002 contains phy specs for ethernet up to 1G. please note that this 802.1d 2004 contains RSTP. Text follows: ------------------------------------------------- Ethernet is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by both a physical layer/medium access control (MAC) layer specification [802.3], and a bridging specification used for connecting different ethernet LAN segments together [802.1d]. In Ethernet networks, hosts are connected by wires or by optic fibre to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub), or directly to another ethernet device. Interfaces are symmetric, in that while many different physical laters may be present, medium access control is uniform for all devices. Ethernet specifies its own link monitoring mechanism, which indicates when both the local physical and MAC layer are capable of transferring frames. The Link Integrity Test operation is used to identify when packets are able to be received on an ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in copper, light levels in fibre). The status of the link as determined by the Link Integrity Test is stored in the variable 'link_status'. Changes to the value of link_status (for example due to Link Integrity Test failure) will generate link indications if the technology dependent interface is implemented on an ethernet device [802.3]. The link_status has possible values of FAIL, READY and OK. When an interface is in FAIL state, Link Integrity Tests have failed. Where status is READY, the link segment has passed integrity tests, but autonegotiation has not completed. OK state indicates that the medium is able to send and receive packets. Upon transition to a particular state the Physical Medium Attachment subsystems generates a PMA_LINK.indicate(link_status). Indications of OK state may be used as Link-Up indications for DNA. PMA_LINK.indicate(FAIL) may be used as a Link-Down indication reliably by DNA[802.3]. Ethernet networks are commonly bridged and hosts are unable to tell a-priori whether the LAN segment they connect to is bridged. In any case where bridges are in operation, they rely upon a spanning tree protocol, to ensure there are no bridging loops. For these technologies, even though the link-layer is available, no forwarding will occur until the network is satisfied that the host is not another bridge port. Until this time, no packets will be received except for Bridge Protocol Data Unit (BPDU) configuration frames. Reception of a PMA_LINK.indicate(OK) is therefore insufficient in most cases to ensure that packets can be sent across the bridged network. After reception of an OK indication, a host may be able to monitor received BPDU frames to determine the delay required before packets may be bridged. with the Spanning Tree Protocol (STP) this is twice the ForwardDelay parameter specified in the frame (default 2 * 15 seconds)[802.1d]. If the switch is performing Rapid Spanning Tree Protocols (RSTP), it instead waits "Bridge Max Age" (advertised in the BPDU's Max Age field, default: 20 seconds), before forwarding. For ports which are known to be point-to-point through autonegotiation, this delay is abbreviated to 3 seconds after autonegotiation completes[802.1d]. Upon learning that an adjacent port is running STP or RSTP, the host may send a Link-Up indication with a 'forwarding available' parameter upon expiry of calculated delays to indicate that general packet transfer is available across the LAN. ----------------------------------------------------------------------- From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 22 19:03:18 2005 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 TAA11380 for ; Tue, 22 Feb 2005 19:03:17 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL53VSFSD28Y87JC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 23 Feb 2005 11:02:47 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 61774AB549; Wed, 23 Feb 2005 11:02:31 +1100 (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 032F14FB06; Wed, 23 Feb 2005 11:02:31 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1N02MH15528 for dna-list; Wed, 23 Feb 2005 11:02:22 +1100 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 j1N02L615524 for ; Wed, 23 Feb 2005 11:02:21 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL53VENRNI8Y7HAA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 23 Feb 2005 11:02:13 +1100 Received: by localhost (Postfix, from userid 510) id 0FB32AB546; Wed, 23 Feb 2005 11:02:13 +1100 (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 000BF4FB04 for ; Wed, 23 Feb 2005 11:02:10 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1N01tfw027163 for ; Tue, 22 Feb 2005 19:01:55 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id AE9253C818F for ; Tue, 22 Feb 2005 18:59:44 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id A12603C8178for ; Tue, 22 Feb 2005 18:59:44 -0500 (EST) Date: Tue, 22 Feb 2005 19:02:43 -0500 From: Sathya Narayanan Subject: [DNA] RRD & Prob. Fast RA Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <421BC823.5080306@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hello Everybody - I would like to bring to the attention of the WG that there are some IPR claims attached to the RRD and Prob. Fast RA internet-drafts. The prob. fastra claim covers the corresponding section in the design team document. With respect to the RRD, priority/hybrid landmark schemes may be covered. I have been working hard to have a clean licensing terms notice sent to IETF. It will be very useful for me in doing this if I can get a sense of the WG interest in these ideas. I, obviously, feel a combination of priority landmark with prob. fastra makes for a good DNA solution. I am sure others may have different choices. Looking forward to a spirited debate ;-). But, a measure of the general interest level in these ideas from the WG will help me in getting an IPR statement acceptable to the WG done soon so that we can move on with the technical discussion. Please comment. thanks & regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 23 12:11:08 2005 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 MAA12888 for ; Wed, 23 Feb 2005 12:11:05 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL63S3JUWI8Y8G65@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 24 Feb 2005 04:10:38 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6013480003; Thu, 24 Feb 2005 04:10:20 +1100 (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 A044D3C009; Thu, 24 Feb 2005 04:10:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1NH7VW27494 for dna-list; Thu, 24 Feb 2005 04:07:31 +1100 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 j1NH7Q627487 for ; Thu, 24 Feb 2005 04:07:26 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL63OEH0NE8Y889S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 24 Feb 2005 04:07:22 +1100 Received: by localhost (Postfix, from userid 510) id BCDDCAB543; Thu, 24 Feb 2005 04:07:21 +1100 (EST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1713F4FB02; Thu, 24 Feb 2005 04:07:18 +1100 (EST) Received: from speedy (speedy.comnets.uni-bremen.de [134.102.155.154]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id j1NH7Aq03446; Wed, 23 Feb 2005 18:07:10 +0100 Date: Wed, 23 Feb 2005 18:07:07 +0100 From: Stefan Aust Subject: [DNA] Draft submission: Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: "=?iso-8859-1?Q?Prof._G=F6rg?=" , Cornel Pampu , greg.daley@eng.monash.edu.au, pekka.nikander@nomadiclab.com, aust@comnets.uni-bremen.de Reply-to: aust@comnets.uni-bremen.de Message-id: <000001c519ca$1b4b8730$9a9b6686@speedy> Organization: ComNets MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_B1WZq8zmS4BMB7QgZ2uR2Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Authentication-warning: bugs.comnets.uni-bremen.de: Host speedy.comnets.uni-bremen.de [134.102.155.154] claimed to be speedy This is a multi-part message in MIME format. --Boundary_(ID_B1WZq8zmS4BMB7QgZ2uR2Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Dear DNA WG, Please find the current I-D of at the following link: http://www.comnets.uni-bremen.de/~aust/draft-iponair-dna-polimand-02.txt The IETF I-D announcement of this draft is available at: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg04365.html Comments are welcome. Regards, Stefan Abstract: A handover is the process during which a mobile node is handed over between access networks. Especially for vertical handovers in overlay networks the mobile node changes the access network using multiple interfaces including different link layers, e.g., WLAN, GPRS, and UMTS. Handovers occur as a consequence of lower layer (i.e., link-layer) handovers that signify a switch of the physical connection to a new location. For the duration of a handover, a mobile node is unable to send or receive traffic. The length of this disruption is considered critical because it affects the performance of the communication. An additional factor is the link layer selection. It implies the selection of the most suitable link layer from which a mobile node should receive services. With the help of DNA it is possible on one side to provide proactive handover decision for mobility protocols (e.g., for MIPv6) and on the other side to select the best link layer including multiple interface support. This draft describes a method that allows seamless handovers and optimal link layer selection using a proactive handover decision that is based on a policy. The policy considers L2 information and DNA assumptions. ----- --Boundary_(ID_B1WZq8zmS4BMB7QgZ2uR2Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

Dear DNA WG,

 

Please find the current I-D of <draft-iponair-dna-polimand-02.txt> at the following link:

 

http://www.comnets.uni-bremen.de/~aust/draft-iponair-dna-polimand-02.txt

 

The IETF I-D announcement of this draft is available at:

 

http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg04365.html

 

Comments are welcome.

 

Regards,

Stefan

 

Abstract:

 

A handover is the process during which a mobile node is handed over between access networks. Especially for vertical handovers in overlay networks the mobile node changes the access network using multiple interfaces including different link layers, e.g., WLAN, GPRS, and UMTS. Handovers occur as a consequence of lower layer (i.e., link-layer) handovers that signify a switch of the physical connection to a new location. For the duration of a handover, a mobile node is unable to send or receive traffic. The length of this disruption is considered critical because it affects the performance of the communication. An additional factor is the link layer selection. It implies the selection of the most suitable link layer from which a mobile node should receive services. 
With the help of DNA it is possible on one side to provide proactive handover decision for mobility protocols (e.g., for MIPv6) and on the other side to select the best link layer including multiple interface support. This draft describes a method that allows seamless handovers and optimal link layer selection using a proactive handover decision that is based on a policy. The policy considers L2 information and DNA assumptions.

 

-----

 

 

 

 

--Boundary_(ID_B1WZq8zmS4BMB7QgZ2uR2Q)-- From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 23 20:45:48 2005 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 UAA19840 for ; Wed, 23 Feb 2005 20:45:46 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL6LRFPTN08Y7L0T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 24 Feb 2005 12:45:21 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0C3DB8000C; Thu, 24 Feb 2005 12:45:12 +1100 (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 B56343C006; Thu, 24 Feb 2005 12:45:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1O1hsg00530 for dna-list; Thu, 24 Feb 2005 12:43:54 +1100 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 j1O1hs600526 for ; Thu, 24 Feb 2005 12:43:54 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL6LPS0R2I8WWAUC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 24 Feb 2005 12:43:52 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EF894AB543; Thu, 24 Feb 2005 12:43:51 +1100 (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 B96D14FB06; Thu, 24 Feb 2005 12:43:51 +1100 (EST) Date: Thu, 24 Feb 2005 12:43:51 +1100 From: Brett Pentland Subject: [DNA] Scope of solutions discussion document Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <421D3157.5050404@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en Content-Transfer-Encoding: 7BIT Hi DNA WG, Does anyone who's had a chance to look at the DT solutions discussion document have an opinion on the coverage of the topic? http://www.ietf.org/internet-drafts/draft-dnadt-dna-discussion-00.txt I was hoping to find out if there are any large areas (or small ones) that we did not consider but should have. For those that want the short version: The basic asssumptions that we made were that: - hints from layer 2 would be available to trigger router solicitations - link-scope multicast packets are able to reach all routers on a link with a loss probability < 1. - hosts with interfaces that can connect to more than one link at once are able to distinguish packets from those different links. It was felt that the information required for configuration change, if required is carried in an RA, so in genereal an RS/RA exchange will be needed and it is possible that this is all that will be needed. There are then two parts to DNA: 1. Crafting the information in the RS/RA so that a host can accurately determine whether its existing IP configuration is valid, and if not, have enough information to start reconfiguration. 2. Getting an RA as fast as possible. A number of techniques are discussed to address each of these parts. 1. a) Adding explicit link identfiers to RAs - both the random kind and those that are, or are based on prefixes in use on the link. b) Including all prefixes in use on a link into RAs, with appropriate flags, etc. to ensure that prefixes that are not explicitly configured on a router are not used as though they are. c) Getting hosts to include some feature of a link (prefix, router address, etc) in the RS and allowing routers to include flags in the RA that indicate whether this feature is present on the link. d) Getting hosts to include their current default router address in the RS and requiring that that router respond immediately if present. 2. a) Allowing link access devices (like APs) to cache RAs and deliver them as soon as they detect a host connecting to the link. b) Allowing one of the routers on a link to respond immediately to RSs. c) Allowing the routers on a link to negotiate amongst themselves an ordering for responding to RSs, and having them respond sequentially at fixed intervals starting from no delay. d) Allowing routers to respond sequentially as in c) but based on some function of the addresses of the other routers and some feature of the RS. e) Allowing routers to respond to RSs with small randomised slotted delays that are based on the number of other routers detected on the link. The document discusses some of the pros and cons of these techniques as well as dealing with routers that behave as per RFC2461, putting the pieces together and some discussion of security concerns. There is also an assumption that DNA is complete when the host has decided whether its current IP configuration is likely to be valid or not (link change has occured or not). It should then have enough information to go on with SAA or to initiate DHCP, and possibly go on with other authentication required to reach the global Internet, if necessary. All comments appreciated. Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 23 22:50:25 2005 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 WAA06481 for ; Wed, 23 Feb 2005 22:50:24 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL6Q52N29C8Y7KQS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 24 Feb 2005 14:49:59 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 20FA3AB557; Thu, 24 Feb 2005 14:49:55 +1100 (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 B90794FB05; Thu, 24 Feb 2005 14:49:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1O3nRo01902 for dna-list; Thu, 24 Feb 2005 14:49:27 +1100 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 j1O3nR601898 for ; Thu, 24 Feb 2005 14:49:27 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL6Q3EXP6I8Y8JDD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 24 Feb 2005 14:49:10 +1100 Received: by localhost (Postfix, from userid 510) id 5247180026; Thu, 24 Feb 2005 14:48:13 +1100 (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 2DD773C005; Thu, 24 Feb 2005 14:48:10 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1O3lN8O007613; Wed, 23 Feb 2005 22:47:23 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id C21983C8166; Wed, 23 Feb 2005 22:45:43 -0500 (EST) 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 B86A93C815C; Wed, 23 Feb 2005 22:45:43 -0500 (EST) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Wed, 23 Feb 2005 22:48:09 -0500 Date: Wed, 23 Feb 2005 22:48:09 -0500 From: Sathya Narayanan Subject: Re: [DNA] Scope of solutions discussion document Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: <25db520a78.20a7825db5@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-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Brett - > The basic asssumptions that we made were that: > - hints from layer 2 would be available to trigger router solicitations I was thinking about this particular assumption we made while driving to work today. I checked 2461 and in section 6.3.7, the following statements are made: "To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds." and " Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure." What does 'initial solicitation' mean in ,'Before a host sends an initial solicitation ...'? - does this refer to the RS sent when 'The interface is initialized at system startup time' or 'The host re-attaches to a link after being detached for some time'? The values for these three variables are: MAX_RTR_SOLICITATION_DELAY 1 second RTR_SOLICITATION_INTERVAL 4 seconds MAX_RTR_SOLICITATIONS 3 transmissions The MAX_RTR_SOLICITATIONS limit is alright. But, the requirment to delay between 0..1 seconds before sending RS, and maintain inter-RS delay of 4 seconds, I think, will have a negative impact on rapid DNA. BTW, both the restrictions are 'SHOULD's. Does it make sense to consider relaxing these conditions? 0..1 seconds delay restriction is useful though in avoiding congestion if many hosts change their points of attachment at the same time. with regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 23 23:20:48 2005 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 XAA16444 for ; Wed, 23 Feb 2005 23:20:46 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL6R71RWYQ8Y7LDR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 24 Feb 2005 15:20:39 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D56B3AB548; Thu, 24 Feb 2005 15:20:33 +1100 (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 885BA4FB07; Thu, 24 Feb 2005 15:20:33 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1O4KOr02293 for dna-list; Thu, 24 Feb 2005 15:20:24 +1100 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 j1O4KN602289 for ; Thu, 24 Feb 2005 15:20:23 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL6R6THBTW8Y7KFO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 24 Feb 2005 15:20:23 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 84B40AB549; Thu, 24 Feb 2005 15:20:22 +1100 (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 4D6EC4FB04; Thu, 24 Feb 2005 15:20:22 +1100 (EST) Date: Thu, 24 Feb 2005 15:20:21 +1100 From: Brett Pentland Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <421D5605.9010905@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en References: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, I seem to remember some discussion on this on the old mobile-ip list some time ago, but I don't think there were any concrete conclusions. As you say, they are all "SHOULDs" so there's no immediate show stoppers, but all should be considered carefully. MAX_RTR_SOLICITATIONS is not really an issue, since the section also says later: Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host where the "above events" include attaching to a link for the first time. RTR_SOLICITATION_INTERVAL could potentially slow things down if a host is moving rapidly between links (less than 4 sec on a link), however the text doesn't seem to say that "a host can never send RSs spaced closer RTR_SOLICITATION_INTERVAL". The implication seems to be that when a host is trying to get an RA on a link, it should space its RSs by RTR_SOLICITATION_INTERVAL until it gets an RA and then stop. If it got a hint that it had moved to a new link, it could start the whole process again. At least that's my interpretation. MAX_RTR_SOLICITATION_DELAY is a trickier one. As you note it is a "SHOULD" delay. Perhaps on power-up a host might delay, but not when movement is detected, but still doesn't address the issue of a whole lot of mobile nodes in a fast moving vehicle. I think Greg has done some simulations on groups of nodes moving at once and may have some comment to add. Cheers, Brett. Sathya Narayanan wrote: > Brett - > > > >> The basic asssumptions that we made were that: - hints from layer 2 >> would be available to trigger router solicitations > > I was thinking about this particular assumption we made while driving > to work today. I checked 2461 and in section 6.3.7, the following > statements are made: > > "To obtain Router Advertisements quickly, a host SHOULD transmit up > to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated > by at least RTR_SOLICITATION_INTERVAL seconds." > > and " Before a host sends an initial solicitation, it SHOULD delay > the transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when > many hosts start up on a link at the same time, such as might happen > after recovery from a power failure." > > What does 'initial solicitation' mean in ,'Before a host sends an > initial solicitation ...'? - does this refer to the RS sent when 'The > interface is initialized at system startup time' or 'The host > re-attaches to a link after being detached for some time'? > > The values for these three variables are: MAX_RTR_SOLICITATION_DELAY > 1 second RTR_SOLICITATION_INTERVAL 4 seconds > MAX_RTR_SOLICITATIONS 3 transmissions > > The MAX_RTR_SOLICITATIONS limit is alright. But, the requirment to > delay between 0..1 seconds before sending RS, and maintain inter-RS > delay of 4 seconds, I think, will have a negative impact on rapid > DNA. BTW, both the restrictions are 'SHOULD's. > > Does it make sense to consider relaxing these conditions? 0..1 > seconds delay restriction is useful though in avoiding congestion if > many hosts change their points of attachment at the same time. > > with regards, Sathya > From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 10:50:06 2005 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 KAA05299 for ; Thu, 24 Feb 2005 10:50:04 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7F8PYE0W8Y8LKH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 02:49:48 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2C416AB544; Fri, 25 Feb 2005 02:49:06 +1100 (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 C7B1A4FB04; Fri, 25 Feb 2005 02:49:05 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1OFmTX09609 for dna-list; Fri, 25 Feb 2005 02:48:29 +1100 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 j1OFmS609605 for ; Fri, 25 Feb 2005 02:48:29 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7F7L2S4M8X0NRL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 02:48:12 +1100 Received: by localhost (Postfix, from userid 510) id AB76FAB542; Fri, 25 Feb 2005 02:48:11 +1100 (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 7C2A14FB06; Fri, 25 Feb 2005 02:48:09 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1OFl8IB022966; Thu, 24 Feb 2005 10:47:08 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D5A353C815C; Thu, 24 Feb 2005 10:45:41 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id B5E763C8158; Thu, 24 Feb 2005 10:45:41 -0500 (EST) Date: Thu, 24 Feb 2005 10:47:51 -0500 From: Sathya Narayanan Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <421D5605.9010905@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: <421DF727.7060105@Research.Panasonic.COM> Organization: Panasonic Technologies Company 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 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:19 M:1 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.2 (2004-11-16) References: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> <421D5605.9010905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hello Brett - I agree - they are all 'SHOULDs' - but some information on the implementations will be useful? The problem with RTR_SOLICITATION_INTERVAL is not only when a node is moving rapidly between links, it will also cause problems when there is packet loss. If the packet loss probability is p, then the prob of a 4 second delay being added will be (p + p^NR) where NR is the number of routers on the link that can respond. If NR is 1, the prob is 2p. I don't know if this is acceptable, so we can ignore this. My gut feeling is that we can not. We must be a bit more resilient to packet loss problems, 4 seconds is too much. I think it will be useful to differentiate the delay between re-transmission of RS becasue RA was not received, from delay between RS with a corresponding RA and another following RS due to link trigger. In the later case, 4 second delay could avoid too many RS message due to fluctuating wireless link signal. And, I agree, MAX_RTR_SOLICITATION_DELAY is the trickier one. rgds, Sathya Brett Pentland wrote: > Hi Sathya, > > I seem to remember some discussion on this on the old mobile-ip list > some time ago, but I don't think there were any concrete conclusions. > > As you say, they are all "SHOULDs" so there's no immediate show > stoppers, but all should be considered carefully. > > MAX_RTR_SOLICITATIONS is not really an issue, since the section also > says later: > > Once the host sends a Router Solicitation, and receives a valid > Router Advertisement with a non-zero Router Lifetime, the host MUST > desist from sending additional solicitations on that interface, until > the next time one of the above events occurs. Moreover, a host > > where the "above events" include attaching to a link for the first time. > > RTR_SOLICITATION_INTERVAL could potentially slow things down if a host > is moving rapidly between links (less than 4 sec on a link), however the > text doesn't seem to say that "a host can never send RSs spaced closer > RTR_SOLICITATION_INTERVAL". The implication seems to be that when a > host is trying to get an RA on a link, it should space its RSs by > RTR_SOLICITATION_INTERVAL until it gets an RA and then stop. If it > got a hint that it had moved to a new link, it could start the whole > process again. At least that's my interpretation. > > MAX_RTR_SOLICITATION_DELAY is a trickier one. As you note it is a > "SHOULD" delay. Perhaps on power-up a host might delay, but not when > movement is detected, but still doesn't address the issue of a whole > lot of mobile nodes in a fast moving vehicle. I think Greg has done > some simulations on groups of nodes moving at once and may have some > comment to add. > > Cheers, > Brett. > > Sathya Narayanan wrote: > >> Brett - >> >> >> >>> The basic asssumptions that we made were that: - hints from layer 2 >>> would be available to trigger router solicitations >> >> >> I was thinking about this particular assumption we made while driving >> to work today. I checked 2461 and in section 6.3.7, the following >> statements are made: >> >> "To obtain Router Advertisements quickly, a host SHOULD transmit up >> to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated >> by at least RTR_SOLICITATION_INTERVAL seconds." >> >> and " Before a host sends an initial solicitation, it SHOULD delay >> the transmission for a random amount of time between 0 and >> MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when >> many hosts start up on a link at the same time, such as might happen >> after recovery from a power failure." >> >> What does 'initial solicitation' mean in ,'Before a host sends an >> initial solicitation ...'? - does this refer to the RS sent when 'The >> interface is initialized at system startup time' or 'The host >> re-attaches to a link after being detached for some time'? >> >> The values for these three variables are: MAX_RTR_SOLICITATION_DELAY >> 1 second RTR_SOLICITATION_INTERVAL 4 seconds >> MAX_RTR_SOLICITATIONS 3 transmissions >> >> The MAX_RTR_SOLICITATIONS limit is alright. But, the requirment to >> delay between 0..1 seconds before sending RS, and maintain inter-RS >> delay of 4 seconds, I think, will have a negative impact on rapid >> DNA. BTW, both the restrictions are 'SHOULD's. >> >> Does it make sense to consider relaxing these conditions? 0..1 >> seconds delay restriction is useful though in avoiding congestion if >> many hosts change their points of attachment at the same time. >> >> with regards, Sathya >> From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 18:55:02 2005 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 SAA09693 for ; Thu, 24 Feb 2005 18:55:01 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL7W7KYBYY8Y7KOY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 10:54:44 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E7BAAB54D; Fri, 25 Feb 2005 10:54:33 +1100 (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 4D09C4FB06; Fri, 25 Feb 2005 10:54:33 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1ONrgv15018 for dna-list; Fri, 25 Feb 2005 10:53:42 +1100 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 j1ONrg615014 for ; Fri, 25 Feb 2005 10:53:42 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7W65BZUM8X0KHG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 10:53:25 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 656B68000C for ; Fri, 25 Feb 2005 10:53:24 +1100 (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 3BA583C012 for ; Fri, 25 Feb 2005 10:53:24 +1100 (EST) Date: Fri, 25 Feb 2005 10:53:23 +1100 From: Greg Daley Subject: [DNA] [Fwd: 2004/05 NomCom Selections] Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <421E68F3.6080201@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us Content-Transfer-Encoding: 7BIT Dear WG, Please join me in congratulating our chair, Pekka Nikander, on being selected for the Internet Architecture Board. Greg -------- Original Message -------- Date: Thu, 24 Feb 2005 12:13:43 -0500 From: Danny McPherson Subject: 2004/05 NomCom Selections To: IETF-Announce@ietf.org I am pleased to announce the results of the 2004-2005 NomCom selection process. The IAB has approved the IESG candidates and the ISOC board has approved the IAB candidates. Please welcome them in their roles: IESG ---- IETF Chair/General Area Director - Brian Carpenter Applications Area Director - Ted Hardie Internet Area Director - Mark Townsley Operations and Management Area Director - David Kessens Security Area Director - Russ Housley Routing Area Director - Bill Fenner Transport Area Director - Jon Peterson IAB --- Bernard Aboba Loa Andersson Kurtis Lindqvist Dave Meyer Pekka Nikander Lixia Zhang Many people deserve to be thanked. First, thanks are due to all of those who volunteered to serve on the NomCom, and especially to those who were randomly selected and served as voting members of the NomCom. They contributed considerable time from their busy schedules to participate in several calls a week, to conduct interviews, to read questionnaires and lots of email, and of course, to make the difficult selection of candidates. Likewise, all the liaisons for providing guidance to the NomCom team. Finally, to Rich Draves (and all past NomCom chairs), for providing considerable guidance and foundation on which to base our efforts. We offer our sincere apologies to all those affected by our tardiness - all I can say is that our latent delivery was resultant of certain "non-group think" and considerable due diligence on a huge slate of excellent nominees, and we do believe our careful consideration was in the best interest of the IETF. Thanks to those in the community who volunteered to serve on the IESG and the IAB, both to those who were selected and those not chosen this time around. Thanks very much for completing the questionnaires and participating in interview process. Thanks are also due to the IETF community as a whole for providing input to the process through nominations, recommendations, and feedback on potential candidates. Voting Members: Alia Atlas Andrew Lange Chris Liljenstolpe Juha Wiljakka Lakshminath Dondeti Magnus Westerlund Markus Isomaki Matt Larson Russ White Stewart Bryant Non-voting Members: Eric Rescorla (IAB Liaison) Alex Zinin (IESG Liaison) Steve Crocker (ISOC Liaison) Richard Draves (Previous Chair/Advisor) Danny McPherson (Chair) Thanks, -danny (On behalf of the 2004/05 NomCom) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 19:44:17 2005 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 TAA13020 for ; Thu, 24 Feb 2005 19:44:16 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7XWASOD88X0R1S@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 11:44:03 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AB7D5AB547; Fri, 25 Feb 2005 11:43:30 +1100 (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 5B2EC4FB07; Fri, 25 Feb 2005 11:43:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P0hHN15566 for dna-list; Fri, 25 Feb 2005 11:43:17 +1100 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 j1P0hG615562 for ; Fri, 25 Feb 2005 11:43:17 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7XUQF4ZM8Y8RYK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 11:42:15 +1100 Received: by localhost (Postfix, from userid 510) id 1E9B2AB546; Fri, 25 Feb 2005 11:42:15 +1100 (EST) Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by moe.its.monash.edu.au (Postfix) with ESMTP id CC9AC4FB0D; Fri, 25 Feb 2005 11:42:11 +1100 (EST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BB26931BC; Thu, 24 Feb 2005 19:42:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 19:42:09 -0500 Date: Thu, 24 Feb 2005 19:42:16 -0500 From: "Bound, Jim" Subject: RE: [DNA] [Fwd: 2004/05 NomCom Selections] Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B087EDE2F@tayexc13.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] [Fwd: 2004/05 NomCom Selections] Thread-Index: AcUazFFtLcBY76AoSzCuYKR2ggs1sAABnA0Q Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 25 Feb 2005 00:42:09.0621 (UTC) FILETIME=[D6A04850:01C51AD2] Content-Transfer-Encoding: 7BIT well deserved and I don't say congrats to often but in this single case I feel real good about Pekka on the IAB and wonderful news. /jim > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley > Sent: Thursday, February 24, 2005 6:53 PM > To: dna@eng.monash.edu.au > Subject: [DNA] [Fwd: 2004/05 NomCom Selections] > > Dear WG, > > Please join me in congratulating our chair, > Pekka Nikander, on being selected for the > Internet Architecture Board. > > Greg > > -------- Original Message -------- > Date: Thu, 24 Feb 2005 12:13:43 -0500 > From: Danny McPherson > Subject: 2004/05 NomCom Selections > To: IETF-Announce@ietf.org > > > I am pleased to announce the results of the 2004-2005 > NomCom selection process. The IAB has approved the IESG > candidates and the ISOC board has approved the IAB > candidates. Please welcome them in their roles: > > IESG > ---- > IETF Chair/General Area Director - Brian Carpenter > Applications Area Director - Ted Hardie > Internet Area Director - Mark Townsley > Operations and Management Area Director - David Kessens > Security Area Director - Russ Housley > Routing Area Director - Bill Fenner > Transport Area Director - Jon Peterson > > IAB > --- > Bernard Aboba > Loa Andersson > Kurtis Lindqvist > Dave Meyer > Pekka Nikander > Lixia Zhang > > Many people deserve to be thanked. First, thanks are due to > all of those who volunteered to serve on the NomCom, and > especially to those who were randomly selected and served as > voting members of the NomCom. They contributed considerable > time from their busy schedules to participate in several calls a > week, to conduct interviews, to read questionnaires and lots of > email, and of course, to make the difficult selection of > candidates. Likewise, all the liaisons for providing guidance to > the NomCom team. Finally, to Rich Draves (and all past > NomCom chairs), for providing considerable guidance and > foundation on which to base our efforts. > > We offer our sincere apologies to all those affected by our > tardiness - all I can say is that our latent delivery was > resultant of certain "non-group think" and considerable due > diligence on a huge slate of excellent nominees, and we do > believe our careful consideration was in the best interest of > the IETF. > > Thanks to those in the community who volunteered to serve on > the IESG and the IAB, both to those who were selected and > those not chosen this time around. Thanks very much for > completing the questionnaires and participating in interview process. > > Thanks are also due to the IETF community as a whole for > providing input to the process through nominations, > recommendations, and feedback on potential candidates. > > Voting Members: > > Alia Atlas > Andrew Lange > Chris Liljenstolpe > Juha Wiljakka > Lakshminath Dondeti > Magnus Westerlund > Markus Isomaki > Matt Larson > Russ White > Stewart Bryant > > Non-voting Members: > > Eric Rescorla (IAB Liaison) > Alex Zinin (IESG Liaison) > Steve Crocker (ISOC Liaison) > Richard Draves (Previous Chair/Advisor) > Danny McPherson (Chair) > > Thanks, > > -danny (On behalf of the 2004/05 NomCom) > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 20:10:44 2005 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 UAA15445 for ; Thu, 24 Feb 2005 20:10:42 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL7YS8R9D28WWBBC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 12:08:36 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C2333AB56B; Fri, 25 Feb 2005 12:08:24 +1100 (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 33FB24FB11; Fri, 25 Feb 2005 12:08:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P184N15855 for dna-list; Fri, 25 Feb 2005 12:08:04 +1100 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 j1P184615851 for ; Fri, 25 Feb 2005 12:08:04 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL7YRI7IDS8Y8S1P@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 12:07:55 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3764AB57B; Fri, 25 Feb 2005 12:07:35 +1100 (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 8797F4FB03; Fri, 25 Feb 2005 12:07:35 +1100 (EST) Date: Fri, 25 Feb 2005 12:07:35 +1100 From: Greg Daley Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <421DF727.7060105@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Brett Pentland , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <421E7A57.2090204@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> <421D5605.9010905@eng.monash.edu.au> <421DF727.7060105@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, RFC2461bis seems to indicate that in the furture it may be possible to ignore MAX_RTR_SOLICITATION_DELAY. It's really our task to guess or show if/where it can be done. Sathya Narayanan wrote: > Hello Brett - > > I agree - they are all 'SHOULDs' - but some information on the > implementations will be useful? > > The problem with RTR_SOLICITATION_INTERVAL is not only when a node is > moving rapidly between links, it will also cause problems when there is > packet loss. If the packet loss probability is p, then the prob of a 4 > second delay being added will be (p + p^NR) where NR is the number of > routers on the link that can respond. If NR is 1, the prob is 2p. I > don't know if this is acceptable, so we can ignore this. My gut feeling > is that we can not. We must be a bit more resilient to packet loss > problems, 4 seconds is too much. I think it will be useful to > differentiate the delay between re-transmission of RS becasue RA was not > received, from delay between RS with a corresponding RA and another > following RS due to link trigger. In the later case, 4 second delay > could avoid too many RS message due to fluctuating wireless link signal. > > And, I agree, MAX_RTR_SOLICITATION_DELAY is the trickier one. Here's the text (page 3: draft-ietf-ipv6-2461bis-02.txt): "... In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link layer hints and is outside the scope of this specification. Note that using this mechanism inappropriately (e.g. based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously. ..." So there has to be management of link-layer indication->RS requirement within the host, and potential application of delays on certain link layers. Below is a rough overview of some work I did a while ago using a locally created OMNeT++ 802.11 simulation (the simulation has since been published, but doesn't have the test scenario). I have to apologise that I've left this on the side for a while and don't have published results to display. From my experience with simulations of up to 30 alike MNs simultaneously changing cell (hard handover threshold, super-imposed hosts receiving an 802.11 beacon below the threshold), there were MAC collision bands for RS's sent to the network. In a lot of these cases, there were L2 probing collisions when scanning channels, which meant that some of the MNs didn't know about the base station's presence because they were unaware of the collision (the probe is a multicast frame, with no ACK). These devices found the same base station (since no other valid one was nearby) on the second probe pass. This meant that there were tiers of successful probe responses, and subsequent authentication and association. It is notable that probe responses weren't being snooped regardless of MAC address. This would have tightened things up considerably. Across all the tiers, there was a lot of contention in the MAC and delay was experienced in responses to the RS's. Each bridged RS received a unicast RA. Mostly the cause of the delay in RA responses through the AP was the nodes still attempting to get onto the link through 802.11 procedures. This caused a queue backlog issue to arise so that around 20ms delay was experienced for the RTT for the RS/RA pairs. The spread in delays of hosts changing cells increased fairly steadily until 30 nodes. Here's the 30 hosts incidence plot for the delay after RS that an RA was received using one millisecond buckets. The incidences were summed over the simulation runs. Please be aware that the values are for the middle of the millisecond range (so it works for box plots). The actual delay for beginning to probe until the reception of the RA was much more spread out. I can send similar data to individuals in order to get an impression, but I'd prefer not to send larger attachments. As you can see, this data is not really ready for publication, but may give an indication of what occurs on one of the interesting link-layers. There's a lot more to actually test (for example the effect on other hosts within a cell). The (rough) impression I got was that there wasn't much harm in having no additional RS serialization delay in 802.11b. Greg RS/RA exchange delay ------------------- 0.004500 1 0.005500 2 0.006500 2 0.007500 2 0.014500 1 0.015500 12 0.016500 2 0.017500 3 0.018500 153 0.019500 855 From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 20:52:42 2005 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 UAA19180 for ; Thu, 24 Feb 2005 20:52:40 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL80B53F1E8WWBQ1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 12:52:05 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BAA3FAB543; Fri, 25 Feb 2005 12:51:57 +1100 (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 655574FB03; Fri, 25 Feb 2005 12:51:57 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P1olB16332 for dna-list; Fri, 25 Feb 2005 12:50:47 +1100 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 j1P1ok616328 for ; Fri, 25 Feb 2005 12:50:46 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL809MSA3U8X0U39@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 12:50:45 +1100 Received: by localhost (Postfix, from userid 510) id DBFD5AB546; Fri, 25 Feb 2005 12:50:44 +1100 (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 AF7A14FB0F; Fri, 25 Feb 2005 12:50:41 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1P1nSPA008127; Thu, 24 Feb 2005 20:49:28 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 9FEF63C815C; Thu, 24 Feb 2005 20:48:13 -0500 (EST) 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 952353C8158; Thu, 24 Feb 2005 20:48:13 -0500 (EST) Received: from [68.39.6.87] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Thu, 24 Feb 2005 20:50:39 -0500 Date: Thu, 24 Feb 2005 20:50:39 -0500 From: Sathya Narayanan Subject: Re: [DNA] Scope of solutions discussion document Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Brett Pentland , Dna Message-id: <28cbf257fc.257fc28cbf@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-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg - I am not sure I understood the data itself. But, I get your point. It may a good idea for you to make a short presentation on this in MN meeting. ;-) We could try to come to conclusion on the issue of 'serialization of RS messages' - becos our next step is likely to be very different based on our decision. Its good that 2461bis is already relaxing the MAX_RTR_SOLICITATION_DELAY constraint. May be its better to reduce the value from 1 second to say 10 or 20 milli-sec rather than completely getting rid of it. On a related point, as part of the solutions - do we plan on keeping the RA response as unicast response. We could possibly avoid multiple RS messages being sent on the the link by using multicast RA response. Hosts that were random-delaying for the RS message could cancel the RS message if it receives the required information in a multicast-RA message. thanks & regards, Sathya ----- Original Message ----- From: Greg Daley Date: Thursday, February 24, 2005 8:07 pm Subject: Re: [DNA] Scope of solutions discussion document > Hi Sathya, > > > RFC2461bis seems to indicate that in the furture it > may be possible to ignore MAX_RTR_SOLICITATION_DELAY. > It's really our task to guess or show if/where it can be done. > > Sathya Narayanan wrote: > > Hello Brett - > > > > I agree - they are all 'SHOULDs' - but some information on the > > implementations will be useful? > > > > The problem with RTR_SOLICITATION_INTERVAL is not only when a > node is > > moving rapidly between links, it will also cause problems when > there is > > packet loss. If the packet loss probability is p, then the prob > of a 4 > > second delay being added will be (p + p^NR) where NR is the > number of > > routers on the link that can respond. If NR is 1, the prob is > 2p. I > > don't know if this is acceptable, so we can ignore this. My gut > feeling > > is that we can not. We must be a bit more resilient to packet > loss > > problems, 4 seconds is too much. I think it will be useful to > > differentiate the delay between re-transmission of RS becasue RA > was not > > received, from delay between RS with a corresponding RA and > another > > following RS due to link trigger. In the later case, 4 second > delay > > could avoid too many RS message due to fluctuating wireless link > signal.> > > And, I agree, MAX_RTR_SOLICITATION_DELAY is the trickier one. > > > Here's the text (page 3: draft-ietf-ipv6-2461bis-02.txt): > > "... > > In some cases, the random delay MAY be omitted if necessary. For > instance, a mobile node, using [MIPv6], moving to a new link would > need to discover such movement as soon as possible to minimize the > amount of packet losses resulting from the change in its > topological movement. Router Solicitations provide a useful > tool for movement > detection in Mobile IPv6 as they allow mobile nodes to determine > movement to new links. Hence, if a mobile node received link layer > information indicating that movement might have taken place, > it MAY > send a Router Solicitation immediately, without random delays. The > strength of such indications should be assessed by the mobile > node's implementation depending on the level of certainty of > the link layer > hints and is outside the scope of this specification. Note > that using > this mechanism inappropriately (e.g. based on weak or transient > indications) may result in Router Solicitation storms. > Furthermore, simultaneous mobility of a large number of mobile > nodes that use this > mechanism can result in a large number of solicitations sent > simultaneously. > > ..." > > > So there has to be management of link-layer indication->RS requirement > within the host, and potential application of delays on certain link > layers. > > Below is a rough overview of some work I did a while ago using a > locallycreated OMNeT++ 802.11 simulation (the simulation has since > beenpublished, but doesn't have the test scenario). > > I have to apologise that I've left this on the side for a while and > don't have published results to display. > > From my experience with simulations of up to 30 alike MNs > simultaneouslychanging cell (hard handover threshold, super- > imposed hosts receiving > an 802.11 beacon below the threshold), there were MAC collision bands > for RS's sent to the network. > > In a lot of these cases, there were L2 probing collisions when > scanningchannels, which meant that some of the MNs didn't know > about the base > station's presence because they were unaware of the collision (the > probeis a multicast frame, with no ACK). > > These devices found the same base station (since no other valid > one was > nearby) on the second probe pass. This meant that there were > tiers of > successful probe responses, and subsequent authentication and > association.It is notable that probe responses weren't being > snooped regardless of > MAC address. This would have tightened things up considerably. > > Across all the tiers, there was a lot of contention in the MAC and > delay was experienced in responses to the RS's. Each bridged RS > received a unicast RA. > > Mostly the cause of the delay in RA responses through the AP was the > nodes still attempting to get onto the link through 802.11 procedures. > This caused a queue backlog issue to arise so that around 20ms delay > was experienced for the RTT for the RS/RA pairs. > > The spread in delays of hosts changing cells increased fairly steadily > until 30 nodes. > > Here's the 30 hosts incidence plot for the delay after RS that an RA > was received using one millisecond buckets. The incidences were > summed over the simulation runs. Please be aware that the values > are for > the middle of the millisecond range (so it works for box plots). > > The actual delay for beginning to probe until the reception of the RA > was much more spread out. I can send similar data to individuals > in order to get an impression, but I'd prefer not to send larger > attachments. > > As you can see, this data is not really ready for publication, > but may give an indication of what occurs on one of the > interesting > link-layers. > > There's a lot more to actually test (for example the effect on other > hosts within a cell). > > The (rough) impression I got was that there wasn't much harm in having > no additional RS serialization delay in 802.11b. > > Greg > > > > RS/RA exchange delay > ------------------- > 0.004500 1 > 0.005500 2 > 0.006500 2 > 0.007500 2 > 0.014500 1 > 0.015500 12 > 0.016500 2 > 0.017500 3 > 0.018500 153 > 0.019500 855 > From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 24 20:55:23 2005 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 UAA19483 for ; Thu, 24 Feb 2005 20:55:22 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL80F3XEH48Y7K04@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 12:55:14 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADC77AB547; Fri, 25 Feb 2005 12:55:09 +1100 (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 583A94FB08; Fri, 25 Feb 2005 12:55:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P1t3R16414 for dna-list; Fri, 25 Feb 2005 12:55:03 +1100 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 j1P1t3616410 for ; Fri, 25 Feb 2005 12:55:03 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL80ETSO1W8X0U39@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 25 Feb 2005 12:54:56 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 216ABAB546; Fri, 25 Feb 2005 12:54:56 +1100 (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 E52484FB0C; Fri, 25 Feb 2005 12:54:55 +1100 (EST) Date: Fri, 25 Feb 2005 12:54:55 +1100 From: Brett Pentland Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <421DF727.7060105@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <421E856F.5010603@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en References: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> <421D5605.9010905@eng.monash.edu.au> <421DF727.7060105@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, Using your approximation, then the order of magnitude of the probability of encountering the 4 second delay is the same as the probablility of packet loss. Whether this is a problem or not depends on what cost is applied to a slow detection. What's a reasonable packet loss rate to consider? 10^-3? A slow detection every thousand or so. Is that too bad? It may be for some applications; I'm not sure. As Greg mentioned, there may be scope to modify the behavior. Perhaps some kind of exponential backoff rather than a fixed 4 second delay? Brett. Sathya Narayanan wrote: > Hello Brett - > > I agree - they are all 'SHOULDs' - but some information on the > implementations will be useful? > > The problem with RTR_SOLICITATION_INTERVAL is not only when a node is > moving rapidly between links, it will also cause problems when there is > packet loss. If the packet loss probability is p, then the prob of a 4 > second delay being added will be (p + p^NR) where NR is the number of > routers on the link that can respond. If NR is 1, the prob is 2p. I > don't know if this is acceptable, so we can ignore this. My gut feeling > is that we can not. We must be a bit more resilient to packet loss > problems, 4 seconds is too much. I think it will be useful to > differentiate the delay between re-transmission of RS becasue RA was not > received, from delay between RS with a corresponding RA and another > following RS due to link trigger. In the later case, 4 second delay > could avoid too many RS message due to fluctuating wireless link signal. > > And, I agree, MAX_RTR_SOLICITATION_DELAY is the trickier one. > > rgds, > Sathya > > Brett Pentland wrote: > >> Hi Sathya, >> >> I seem to remember some discussion on this on the old mobile-ip list >> some time ago, but I don't think there were any concrete conclusions. >> >> As you say, they are all "SHOULDs" so there's no immediate show >> stoppers, but all should be considered carefully. >> >> MAX_RTR_SOLICITATIONS is not really an issue, since the section also >> says later: >> >> Once the host sends a Router Solicitation, and receives a valid >> Router Advertisement with a non-zero Router Lifetime, the host MUST >> desist from sending additional solicitations on that interface, until >> the next time one of the above events occurs. Moreover, a host >> >> where the "above events" include attaching to a link for the first time. >> >> RTR_SOLICITATION_INTERVAL could potentially slow things down if a host >> is moving rapidly between links (less than 4 sec on a link), however the >> text doesn't seem to say that "a host can never send RSs spaced closer >> RTR_SOLICITATION_INTERVAL". The implication seems to be that when a >> host is trying to get an RA on a link, it should space its RSs by >> RTR_SOLICITATION_INTERVAL until it gets an RA and then stop. If it >> got a hint that it had moved to a new link, it could start the whole >> process again. At least that's my interpretation. >> >> MAX_RTR_SOLICITATION_DELAY is a trickier one. As you note it is a >> "SHOULD" delay. Perhaps on power-up a host might delay, but not when >> movement is detected, but still doesn't address the issue of a whole >> lot of mobile nodes in a fast moving vehicle. I think Greg has done >> some simulations on groups of nodes moving at once and may have some >> comment to add. >> >> Cheers, >> Brett. >> >> Sathya Narayanan wrote: >> >>> Brett - >>> >>> >>> >>>> The basic asssumptions that we made were that: - hints from layer 2 >>>> would be available to trigger router solicitations >>> >>> >>> >>> I was thinking about this particular assumption we made while driving >>> to work today. I checked 2461 and in section 6.3.7, the following >>> statements are made: >>> >>> "To obtain Router Advertisements quickly, a host SHOULD transmit up >>> to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated >>> by at least RTR_SOLICITATION_INTERVAL seconds." >>> >>> and " Before a host sends an initial solicitation, it SHOULD delay >>> the transmission for a random amount of time between 0 and >>> MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when >>> many hosts start up on a link at the same time, such as might happen >>> after recovery from a power failure." >>> >>> What does 'initial solicitation' mean in ,'Before a host sends an >>> initial solicitation ...'? - does this refer to the RS sent when 'The >>> interface is initialized at system startup time' or 'The host >>> re-attaches to a link after being detached for some time'? >>> >>> The values for these three variables are: MAX_RTR_SOLICITATION_DELAY >>> 1 second RTR_SOLICITATION_INTERVAL 4 seconds >>> MAX_RTR_SOLICITATIONS 3 transmissions >>> >>> The MAX_RTR_SOLICITATIONS limit is alright. But, the requirment to >>> delay between 0..1 seconds before sending RS, and maintain inter-RS >>> delay of 4 seconds, I think, will have a negative impact on rapid >>> DNA. BTW, both the restrictions are 'SHOULD's. >>> >>> Does it make sense to consider relaxing these conditions? 0..1 >>> seconds delay restriction is useful though in avoiding congestion if >>> many hosts change their points of attachment at the same time. >>> >>> with regards, Sathya >>> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@eng.monash.edu.au CTIE - Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University, VIC, 3800, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-3454 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 25 00:08:48 2005 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 AAA06983 for ; Fri, 25 Feb 2005 00:08:46 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL875CB8VK8WWB76@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 16:08:14 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 639D7AB54B; Fri, 25 Feb 2005 16:08:06 +1100 (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 93C984FB0D; Fri, 25 Feb 2005 16:08:05 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P57SS18445 for dna-list; Fri, 25 Feb 2005 16:07:28 +1100 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 j1P57S618441 for ; Fri, 25 Feb 2005 16:07:28 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL873MEZMO8WWB73@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 25 Feb 2005 16:06:44 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B913AB547; Fri, 25 Feb 2005 16:06:43 +1100 (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 3944C4FB14; Fri, 25 Feb 2005 16:06:43 +1100 (EST) Date: Fri, 25 Feb 2005 16:06:42 +1100 From: Greg Daley Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <28cbf257fc.257fc28cbf@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Brett Pentland , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <421EB262.9070205@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <28cbf257fc.257fc28cbf@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Hi Sathya, Sathya Narayanan wrote: > Greg - > > I am not sure I understood the data itself. But, I get your point. > It may a good idea for you to make a short presentation on this > in MN meeting. ;-) We could try to come to conclusion on the > issue of 'serialization of RS messages' - becos our next step > is likely to be very different based on our decision. Well, I'll see what I can do to see if there's more results i can produce. It's not likely that I'll make a separate presentation, but may have some slides (graphics) to show. The test scenario was quite limited, so the applicability may not be wide. > Its good that 2461bis is already relaxing the MAX_RTR_SOLICITATION_DELAY > constraint. May be its better to reduce the value from 1 second to say > 10 or 20 milli-sec rather than completely getting rid of it. Actually, I think hysteresis on hint actiosn is likely to be useful, rather than induced delay in the event of our own handover. Certainly on some media it may be useful to keep the delays in some form, but I hope not to have delays in general. > On a related point, as part of the solutions - do we plan on keeping > the RA response as unicast response. We could possibly avoid multiple > RS messages being sent on the the link by using multicast RA response. > Hosts that were random-delaying for the RS message could cancel > the RS message if it receives the required information in a multicast-RA message. I think I see your point. In some cases, I think the packets were queued at MAC for a while, and can't be recalled. Those packets will go out anyway. The random delay does help in this case, but the host knows nothing about the network. RS affects (hoepfully, if multicast snoop filters work on base-stations) only a single cell, whereas an RA consumes bandwidth on all cells in the link uniformly (and may wake sleeping nodes). for multi-cell environments, it's probably better to control things from the router side. Just my ideas at the moment. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 25 01:15:31 2005 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 BAA13492 for ; Fri, 25 Feb 2005 01:15:30 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL89H0NSDM8Y8N28@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 17:15:06 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76E34AB542; Fri, 25 Feb 2005 17:14:47 +1100 (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 3220C4FB02; Fri, 25 Feb 2005 17:14:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P6EOI19204 for dna-list; Fri, 25 Feb 2005 17:14:24 +1100 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 j1P6EN619200 for ; Fri, 25 Feb 2005 17:14:24 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL89G5OL6M8Y7O82@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 25 Feb 2005 17:14:06 +1100 Received: by localhost (Postfix, from userid 510) id BFA63AB546; Fri, 25 Feb 2005 17:14:05 +1100 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id E6BA44FB09; Fri, 25 Feb 2005 17:14:03 +1100 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICG00905ENEJF@mailout2.samsung.com>; Fri, 25 Feb 2005 15:14:02 +0900 (KST) 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 <0ICG009C9ENA7P@mailout2.samsung.com>; Fri, 25 Feb 2005 15:13:58 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ICG0058BEN8LU@mmp1.samsung.com>; Fri, 25 Feb 2005 15:13:58 +0900 (KST) Date: Fri, 25 Feb 2005 11:38:37 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: [DNA] Scope of solutions discussion document Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Dna Reply-to: Radhakrishnan Suryanarayanan Message-id: <00d301c51b00$736cd770$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 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.2 (2004-11-16) References: <421D3157.5050404@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Bret, Just 1 comment at first look. > The basic asssumptions that we made were that: > - hints from layer 2 would be available to trigger router solicitations => Shouldnt this be under section 4 in the draft instead of mentioning it in para 2 of section 1. From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 25 01:29:18 2005 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 BAA14787 for ; Fri, 25 Feb 2005 01:29:17 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL89Y5YH5E8Y7NOD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 17:28:40 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E991D80006; Fri, 25 Feb 2005 17:28:36 +1100 (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 9E4283C014; Fri, 25 Feb 2005 17:28:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P6SKI19396 for dna-list; Fri, 25 Feb 2005 17:28:20 +1100 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 j1P6SK619392 for ; Fri, 25 Feb 2005 17:28:20 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL89XO37SY8WWBMB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 25 Feb 2005 17:28:13 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B538FAB54B; Fri, 25 Feb 2005 17:28:12 +1100 (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 685F24FB0E; Fri, 25 Feb 2005 17:28:12 +1100 (EST) Date: Fri, 25 Feb 2005 17:28:11 +1100 From: Brett Pentland Subject: Re: [DNA] Scope of solutions discussion document In-reply-to: <00d301c51b00$736cd770$3a476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Radhakrishnan Suryanarayanan Cc: Dna Message-id: <421EC57B.7000800@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en References: <421D3157.5050404@eng.monash.edu.au> <00d301c51b00$736cd770$3a476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Radhakrishnan Suryanarayanan wrote: > Hi Bret, > Just 1 comment at first look. > > >>The basic asssumptions that we made were that: >>- hints from layer 2 would be available to trigger router solicitations > > => Shouldnt this be under section 4 in the draft instead of mentioning it in > para 2 of section 1. > Yes it should. I noticed that it was another assumption when I was writing my summary of the summary for the email. :) Thanks, Brett. From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 25 02:03:57 2005 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 CAA21344 for ; Fri, 25 Feb 2005 02:03:56 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LL8B40EBUO8Y8MEJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 25 Feb 2005 18:02:27 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 33A89AB549; Fri, 25 Feb 2005 18:01:34 +1100 (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 D74F04FB0D; Fri, 25 Feb 2005 18:01:33 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1P71Ou19753 for dna-list; Fri, 25 Feb 2005 18:01:24 +1100 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 j1P71N619749 for ; Fri, 25 Feb 2005 18:01:23 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL8B3FMS368Y7NQT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 25 Feb 2005 18:01:13 +1100 Received: by localhost (Postfix, from userid 510) id 012608000C; Fri, 25 Feb 2005 18:01:05 +1100 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5F9FA3C009; Fri, 25 Feb 2005 18:01:04 +1100 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICG00201GTQN8@mailout1.samsung.com>; Fri, 25 Feb 2005 16:01:02 +0900 (KST) 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 <0ICG00BBJGTPT9@mailout1.samsung.com>; Fri, 25 Feb 2005 16:01:01 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ICG00EFKGTLUK@mmp2.samsung.com>; Fri, 25 Feb 2005 16:01:01 +0900 (KST) Date: Fri, 25 Feb 2005 12:25:38 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: [DNA] Scope of solutions discussion document Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Sathya Narayanan Cc: Dna Reply-to: Radhakrishnan Suryanarayanan Message-id: <012f01c51b07$05edd1c0$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 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.2 (2004-11-16) References: <25db520a78.20a7825db5@pintlmail.MITL.Research.Panasonic.COM> <421D5605.9010905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Satya,Greg, > RTR_SOLICITATION_INTERVAL could potentially slow things down if a host > is moving rapidly between links (less than 4 sec on a link), however the > text doesn't seem to say that "a host can never send RSs spaced closer > RTR_SOLICITATION_INTERVAL". The implication seems to be that when a > host is trying to get an RA on a link, it should space its RSs by > RTR_SOLICITATION_INTERVAL until it gets an RA and then stop. If it > got a hint that it had moved to a new link, it could start the whole > process again. At least that's my interpretation. => IMHO, thats quite a valid interpretation. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 28 18:05:15 2005 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 SAA18289 for ; Mon, 28 Feb 2005 18:05:13 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LLDFIIZX4I8Y9NON@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 01 Mar 2005 10:05:06 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE436AB55B; Tue, 01 Mar 2005 10:01:44 +1100 (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 6D4B64FB03; Tue, 01 Mar 2005 10:01:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j1SN0I315064 for dna-list; Tue, 01 Mar 2005 10:00:18 +1100 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 j1SN0H615060 for ; Tue, 01 Mar 2005 10:00:17 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LLDFGG9ET88Y7XF3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 01 Mar 2005 10:00:06 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 374BB80015 for ; Tue, 01 Mar 2005 10:00:04 +1100 (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 118573C00D for ; Tue, 01 Mar 2005 10:00:04 +1100 (EST) Date: Tue, 01 Mar 2005 10:00:03 +1100 From: Greg Daley Subject: [DNA] DNA WG session agenda for IETF 62 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <4223A273.10006@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii 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 submitted these, so there may be some the agenda becoming available. Greg Here is the content of the submission: Tue 1300-1500 - 10 min wg status and summary - 20 min link information draft draft-ietf-dna-link-information-01.txt - 20 min 802.21 status and liaison - 20 min DNA hosts bcp draft, with discussion draft-narayanan-dna-hosts-bcp-00.txt - 20 min DNA routers bcp draft, with discussion draft-narayanan-dna-routers-bcp-00.txt - 10 min DNAv6 with unmodified routers: Prefix List Approach draft-jinchoi-dna-cpl-01.txt Thu 1530-1745 - 30 min dt report draft-dnadt-dna-discussion-00.txt - 10 min Solution Framework draft-jinchoi-dna-soln-frame-00.txt (expired) Charter item - 60 min discussion (with 15 minute break) - 10 min next steps Note to attendees: ------------------ Please note that there is a lot of time devoted to DNA this time, so we can resolve some of the issues on milestone documents. It is important to read the current version of any document listed next to an agenda item before you arrive. Relevant Documents ------------------ Link-Layer Hints ---------------- draft-ietf-dna-link-information-01.txt Related to Current Practice --------------------------- draft-jinchoi-dna-cpl-01.txt draft-narayanan-dna-hosts-bcp-00.txt draft-narayanan-dna-routers-bcp-00.txt draft-narayanan-dna-bcp-01.txt (superceded) Solution Space --------------- draft-jinchoi-dna-soln-frame-00 (expired) DNA Design Team summary ----------------------- draft-dnadt-dna-discussion-00.txt Router Advertisement delivery ----------------------------- draft-daley-dna-det-fastra-01.txt draft-daley-dna-prob-fastra-00.txt draft-jinchoi-dna-frd-01 (expired) Link Identifiers ---------------- draft-pentland-mobileip-linkid-03.txt draft-narayanan-dna-rrd-00.txt Response Matching ----------------- draft-daley-dna-nonce-resp-00.txt Multiple Interface Issues ------------------------- draft-hong-dna-if-l2-00.txt draft-iponair-dna-polimand-02 RFC-EDITOR QUEUE! ---------------- draft-ietf-dna-goals-04.txt Other Working Groups: --------------------- draft-ietf-dhc-dna-ipv4-09.txt draft-daley-ipv6-tsllao-01.txt Documents Referencing DNA ------------------------- draft-ietf-dhc-dual-stack-02.txt draft-ietf-multi6-failure-detection-00.txt From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 28 22:39:13 2005 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 WAA10049 for ; Mon, 28 Feb 2005 22:39:12 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LLDP5KZJ4M8Y81B0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 1 Mar 2005 14:37:51 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 774018110E; Tue, 01 Mar 2005 14:37:37 +1100 (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 3AD4C3C006; Tue, 01 Mar 2005 14:37:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j213b2r18060 for dna-list; Tue, 01 Mar 2005 14:37:02 +1100 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 j213b1618056 for ; Tue, 01 Mar 2005 14:37:01 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LLDP3Z8N9Y8Y83OA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 01 Mar 2005 14:36:22 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 12AC4AB66B; Tue, 01 Mar 2005 14:24:45 +1100 (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 898F84FB08; Tue, 01 Mar 2005 14:24:44 +1100 (EST) Date: Tue, 01 Mar 2005 14:24:44 +1100 From: Greg Daley Subject: Re: [DNA] DNA WG session agenda for IETF 62 In-reply-to: <4223A273.10006@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: greg.daley@eng.monash.edu.au Message-id: <4223E07C.6090707@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <4223A273.10006@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT If people don't have any objection, I've been asked to move the CPL discussion up the list to before the BCP documents. Does that sound OK? Greg Greg Daley wrote: > Hi, > > I've just submitted these, so there may be > some the agenda becoming available. > > Greg > > Here is the content of the submission: > > > > Tue 1300-1500 > - 10 min wg status and summary > > - 20 min link information draft > draft-ietf-dna-link-information-01.txt > > - 20 min 802.21 status and liaison > > - 20 min DNA hosts bcp draft, with discussion > draft-narayanan-dna-hosts-bcp-00.txt > > - 20 min DNA routers bcp draft, with discussion > draft-narayanan-dna-routers-bcp-00.txt > > - 10 min DNAv6 with unmodified routers: Prefix List Approach > draft-jinchoi-dna-cpl-01.txt > > Thu 1530-1745 > > - 30 min dt report > draft-dnadt-dna-discussion-00.txt > - 10 min Solution Framework > draft-jinchoi-dna-soln-frame-00.txt (expired) > Charter item > - 60 min discussion > (with 15 minute break) > > - 10 min next steps > > Note to attendees: > > ------------------ > Please note that there is a lot of time devoted to DNA > this time, so we can resolve some of the issues on > milestone documents. > > It is important to read the current version of any > document listed next to an agenda item before you arrive. > > > > Relevant Documents > ------------------ > > Link-Layer Hints > ---------------- > draft-ietf-dna-link-information-01.txt > > Related to Current Practice > --------------------------- > draft-jinchoi-dna-cpl-01.txt > draft-narayanan-dna-hosts-bcp-00.txt > draft-narayanan-dna-routers-bcp-00.txt > draft-narayanan-dna-bcp-01.txt (superceded) > > Solution Space > --------------- > draft-jinchoi-dna-soln-frame-00 (expired) > > DNA Design Team summary > ----------------------- > draft-dnadt-dna-discussion-00.txt > > Router Advertisement delivery > ----------------------------- > draft-daley-dna-det-fastra-01.txt > draft-daley-dna-prob-fastra-00.txt > draft-jinchoi-dna-frd-01 (expired) > > Link Identifiers > ---------------- > draft-pentland-mobileip-linkid-03.txt > draft-narayanan-dna-rrd-00.txt > > Response Matching > ----------------- > draft-daley-dna-nonce-resp-00.txt > > Multiple Interface Issues > ------------------------- > draft-hong-dna-if-l2-00.txt > draft-iponair-dna-polimand-02 > > RFC-EDITOR QUEUE! > ---------------- > draft-ietf-dna-goals-04.txt > > Other Working Groups: > --------------------- > draft-ietf-dhc-dna-ipv4-09.txt > draft-daley-ipv6-tsllao-01.txt > > Documents Referencing DNA > ------------------------- > draft-ietf-dhc-dual-stack-02.txt > draft-ietf-multi6-failure-detection-00.txt >