From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 01 19:03:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNDs-0006HQ-MV for dna-archive@lists.ietf.org; Wed, 01 Aug 2007 19:03:20 -0400 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGNDr-0004HY-8g for dna-archive@lists.ietf.org; Wed, 01 Aug 2007 19:03:20 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM40046MAPFTDK0@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 09:03:15 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D6A1680002; Thu, 02 Aug 2007 09:03:14 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 43E0F3C003; Thu, 02 Aug 2007 09:03:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l71MxPd00919 for dna-list; Thu, 02 Aug 2007 08:59:25 +1000 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l71MxNF00915 for ; Thu, 02 Aug 2007 08:59:23 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM400L0153JT800@kenny.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Aug 2007 08:59:23 +1000 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM400FOQAIYYZL0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Thu, 02 Aug 2007 08:59:23 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 3559EAB543; Thu, 02 Aug 2007 08:59:22 +1000 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (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 290A54FB18 for ; Thu, 02 Aug 2007 08:59:20 +1000 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l71N2l66020219; Wed, 01 Aug 2007 18:02:47 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Aug 2007 17:59:16 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Aug 2007 17:59:16 -0500 Date: Wed, 01 Aug 2007 18:57:58 -0400 From: Suresh Krishnan Subject: [DNA] Reality Check - Implementer Feedback Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna , dna-ads@tools.ietf.org Message-id: <46B10FF6.5030602@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) User-Agent: Thunderbird 1.5 (X11/20060313) X-OriginalArrivalTime: 01 Aug 2007 22:59:16.0781 (UTC) FILETIME=[9625A5D0:01C7D48F] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Folks, We have heard comments from OS vendors that the dna protocol, as it exists, is too complex to implement. We already have one instance of an OS vendor (Apple) who has shipped their own version of DNAv6 (it is pretty much a version of DNAv4 adapted to IPv6). From talking to the people who had the complexity concerns, the chairs have inferred that the following issues with the current document are the main obstacles to deployment * Router changes are NECESSARY * Handling of corner cases adds complexity to most likely use cases * Some of the DNA Goals are not really necessary/useful We have a couple of options going forward a) Forward the current document to the IESG on the standardization path with no hope of deployment b) Simplify the current document - remove some of the DNA steps - spin off Tentative options to a separate document and then put it on the standardization path, and again risk lack of deploymen c) Come up with a much simpler scheme which is probabilistic but works decently given a set of assumptions(however limited they may be). Then send it up on the standards track. This has the highest probability of deployment. d) Do both b) and c) We would like to hear the opinions of the WG on these options. Cheers Suresh & Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 02 00:15:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGS5o-0002IY-RB for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 00:15:20 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGS5n-00020s-CS for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 00:15:20 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM400FUPP5DJW60@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 14:15:14 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0971880006; Thu, 02 Aug 2007 14:15:12 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B66083C011; Thu, 02 Aug 2007 14:15:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l724C7L02202 for dna-list; Thu, 02 Aug 2007 14:12:07 +1000 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l724C5F02198 for ; Thu, 02 Aug 2007 14:12:05 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM400701OC4R100@kyle.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Aug 2007 14:12:06 +1000 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM4006QDP062N10@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Thu, 02 Aug 2007 14:12:06 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 4C33FAB544; Thu, 02 Aug 2007 14:12:06 +1000 (EST) Received: from bay0-omc1-s29.bay0.hotmail.com (bay0-omc1-s29.bay0.hotmail.com [65.54.246.101]) by moe.its.monash.edu.au (Postfix) with ESMTP id AA8DE4FB08 for ; Thu, 02 Aug 2007 14:12:04 +1000 (EST) Received: from hotmail.com ([207.46.8.90]) by bay0-omc1-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 01 Aug 2007 21:12:01 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 01 Aug 2007 21:12:02 -0700 Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 02 Aug 2007 04:11:59 +0000 (GMT) Date: Wed, 01 Aug 2007 21:11:59 -0700 From: Bernard Aboba Subject: RE: [DNA] Reality Check - Implementer Feedback In-reply-to: <46B10FF6.5030602@ericsson.com> X-Originating-IP: [71.197.208.131] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: suresh.krishnan@ericsson.com, dna@eng.monash.edu.au, dna-ads@tools.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 02 Aug 2007 04:12:02.0087 (UTC) FILETIME=[47241B70:01C7D4BB] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 FWIW, I'd vote for (c). DNAv6 is by nature an optimization, and the first rule of optimization is "optimize for the common case". As a result, it doesn't make much sense to pay a great deal of attention to corner cases. The goal should be to guarantee that DNAv6 will do no harm in corner cases, and will provide meaningful optimization for common cases. The most meaningful common case is where IPv6 routers are deployed as is, with no changes. >From: Suresh Krishnan >To: Dna , dna-ads@tools.ietf.org >Subject: [DNA] Reality Check - Implementer Feedback >Date: Wed, 01 Aug 2007 18:57:58 -0400 > >Hi Folks, > We have heard comments from OS vendors that the dna protocol, as it >exists, is too complex to implement. We already have one instance of an >OS vendor (Apple) who has shipped their own version of DNAv6 (it is >pretty much a version of DNAv4 adapted to IPv6). From talking to the >people who had the complexity concerns, the chairs have inferred that >the following issues with the current document are the main obstacles to >deployment > >* Router changes are NECESSARY >* Handling of corner cases adds complexity to most likely use cases >* Some of the DNA Goals are not really necessary/useful > >We have a couple of options going forward > >a) Forward the current document to the IESG on the standardization path >with no hope of deployment >b) Simplify the current document > - remove some of the DNA steps > - spin off Tentative options to a separate document > and then put it on the standardization path, and again risk lack of > deploymen >c) Come up with a much simpler scheme which is probabilistic but works > decently given a set of assumptions(however limited they may be). > Then send it up on the standards track. This has the highest > probability of deployment. >d) Do both b) and c) > >We would like to hear the opinions of the WG on these options. > >Cheers >Suresh & Greg > > From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 02 18:29:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGjAw-0004PE-8t for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 18:29:46 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGjAu-0003xw-Rl for dna-archive@lists.ietf.org; Thu, 02 Aug 2007 18:29:46 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM600A793TE02D0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 08:29:39 +1000 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9985AAB544; Fri, 03 Aug 2007 08:29:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 731F04FB0C; Fri, 03 Aug 2007 08:29:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l72MQC406990 for dna-list; Fri, 03 Aug 2007 08:26:12 +1000 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l72MQAF06986 for ; Fri, 03 Aug 2007 08:26:10 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM60080131IEV00@cartman.its.monash.edu.au> (original mail from sathya@njit.edu) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Aug 2007 08:26:10 +1000 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM6006VE3NMDY30@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 03 Aug 2007 08:26:10 +1000 (EST) Received: by localhost (Postfix, from userid 510) id A6749AB545; Fri, 03 Aug 2007 08:26:10 +1000 (EST) Received: from faramir.csumb.edu (faramir.csumb.edu [198.189.237.217]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8C5C84FB10 for ; Fri, 03 Aug 2007 08:26:09 +1000 (EST) Received: from [127.0.0.1] (cm1-142-42.reznet.csumb.edu [207.62.142.42]) by faramir.csumb.edu (Spam Firewall) with ESMTP id 3D1AE147F2; Thu, 02 Aug 2007 15:26:06 -0700 (PDT) Date: Thu, 02 Aug 2007 15:26:05 -0700 From: Sathya Narayanan Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <46B10FF6.5030602@ericsson.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Suresh Krishnan Cc: Dna , dna-ads@tools.ietf.org Message-id: <46B259FD.1000306@njit.edu> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-ASG-Debug-ID: 1186093563-37d100020002-jNwQtm X-Barracuda-URL: http://198.189.237.217:8000/cgi-bin/mark.cgi X-Barracuda-Connect: cm1-142-42.reznet.csumb.edu[207.62.142.42] X-Barracuda-Start-Time: 1186093563 X-ASG-Orig-Subj: Re: [DNA] Reality Check - Implementer Feedback X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at csumb.edu References: <46B10FF6.5030602@ericsson.com> User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I vote for (d). I don't see the point in losing all the work/discussions that has gone in to creating the current document. Sathya Suresh Krishnan wrote: > > Hi Folks, > We have heard comments from OS vendors that the dna protocol, as it > exists, is too complex to implement. We already have one instance of an > OS vendor (Apple) who has shipped their own version of DNAv6 (it is > pretty much a version of DNAv4 adapted to IPv6). From talking to the > people who had the complexity concerns, the chairs have inferred that > the following issues with the current document are the main obstacles to > deployment > > * Router changes are NECESSARY > * Handling of corner cases adds complexity to most likely use cases > * Some of the DNA Goals are not really necessary/useful > > We have a couple of options going forward > > a) Forward the current document to the IESG on the standardization path > with no hope of deployment > b) Simplify the current document > - remove some of the DNA steps > - spin off Tentative options to a separate document > and then put it on the standardization path, and again risk lack of > deploymen > c) Come up with a much simpler scheme which is probabilistic but works > decently given a set of assumptions(however limited they may be). > Then send it up on the standards track. This has the highest > probability of deployment. > d) Do both b) and c) > > We would like to hear the opinions of the WG on these options. > > Cheers > Suresh & Greg > > From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 03 16:28:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3ku-0007Oe-2g for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 16:28:16 -0400 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH3kt-0001H7-Jq for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 16:28:16 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM7003MRSV051I0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Aug 2007 06:28:12 +1000 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F04F0AB542; Sat, 04 Aug 2007 06:28:11 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B60A74FB03; Sat, 04 Aug 2007 06:28:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l73KOev12725 for dna-list; Sat, 04 Aug 2007 06:24:40 +1000 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l73KOdF12721 for ; Sat, 04 Aug 2007 06:24:39 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM700201MBB5O00@stan.its.monash.edu.au> (original mail from jari.arkko@piuha.net) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Aug 2007 06:24:39 +1000 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM7003TKSP250I0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 04 Aug 2007 06:24:39 +1000 (EST) Received: by localhost (Postfix, from userid 510) id A8FACAB543; Sat, 04 Aug 2007 06:24:39 +1000 (EST) Received: from isolokki.dnainternet.net (isolokki.dnainternet.net [87.94.96.112]) by curly.its.monash.edu.au (Postfix) with ESMTP id 710F24FB0D for ; Sat, 04 Aug 2007 06:24:38 +1000 (EST) Received: from [62.78.106.1] (eukaryote1.gprs.dnafinland.fi [62.78.106.1]) by isolokki.dnainternet.net (Postfix) with ESMTP id 7DA5DF316; Fri, 03 Aug 2007 23:22:16 +0300 (EEST) Date: Fri, 03 Aug 2007 23:26:06 +0300 From: Jari Arkko Subject: Re: [DNA] Reality Check - Implementer Feedback Sender: owner-dna@ecselists.eng.monash.edu.au Cc: smadanapalli@gmail.com, suresh.krishnan@ericsson.com, dna@eng.monash.edu.au, dna-ads@tools.ietf.org Reply-to: Jari Arkko Message-id: MIME-version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id l73KOdF12722 X-Mailer: EPOC Email Version 2.10 Content-type: text/plain; charset=ISO-8859-1 Content-language: i-default Content-transfer-encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Spam-Level: X-Spam-Score: 1.6 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 I would really like to see us produce something that gets used in the real world. I.e., please consider aligning to what is starting to be implemented by major host and router vendors. Jari From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 03 17:42:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH4uN-0008Op-5t for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 17:42:07 -0400 Received: from kyle.its.monash.edu.au ([130.194.13.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH4uM-00038Q-7j for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 17:42:07 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM700F71IAUKRC0@kyle.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Aug 2007 02:40:07 +1000 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 42C09AB544; Sat, 04 Aug 2007 02:40:06 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5FE6D4FB08; Sat, 04 Aug 2007 02:40:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l73GbOS11488 for dna-list; Sat, 04 Aug 2007 02:37:24 +1000 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l73GbOF11484 for ; Sat, 04 Aug 2007 02:37:24 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM700B01I0AD200@kyle.its.monash.edu.au> (original mail from sathya@njit.edu) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Aug 2007 02:37:24 +1000 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM700FKKI6BKPC0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 04 Aug 2007 02:37:24 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 9ECE3AB542; Sat, 04 Aug 2007 02:37:24 +1000 (EST) Received: from faramir.csumb.edu (faramir.csumb.edu [198.189.237.217]) by moe.its.monash.edu.au (Postfix) with ESMTP id A43B74FB0C for ; Sat, 04 Aug 2007 02:37:23 +1000 (EST) Received: from [127.0.0.1] (cm1-142-42.reznet.csumb.edu [207.62.142.42]) by faramir.csumb.edu (Spam Firewall) with ESMTP id 1C6F814CC9; Fri, 03 Aug 2007 09:37:20 -0700 (PDT) Date: Fri, 03 Aug 2007 09:37:16 -0700 From: Sathya Narayanan Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Suresh Krishnan , Dna , dna-ads@tools.ietf.org Message-id: <46B359BC.60908@njit.edu> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-ASG-Debug-ID: 1186159033-388b00060002-jNwQtm X-Barracuda-URL: http://198.189.237.217:8000/cgi-bin/mark.cgi X-Barracuda-Connect: cm1-142-42.reznet.csumb.edu[207.62.142.42] X-Barracuda-Start-Time: 1186159033 X-ASG-Orig-Subj: Re: [DNA] Reality Check - Implementer Feedback X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at csumb.edu References: <46B10FF6.5030602@ericsson.com> <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Syam Madanapalli wrote: > I am not sure how option d works. I understand that we did lot of work > on the existing draft that does not mean that we should continue progressing > it if does not going to be useful, especially when you are planning for a > (new) simpler solution. > > Also we need to look into the current draft and see if one of the mechanisms > (CompleteRA, Landmark and LinkID) can be recommended instead of all three > (if the changes in the router is OK). > IMHO, the current draft not being implemented because people think the complex goals (agreed to earlier) do not justify the complexity in the solution. So, we should produce a simpler document that achieves a simpler goal (probabilistic). But, I still believe it makes sense to do (d) because, we could standardize the current document as a solution to the original DNA goals (RFC 4135) and close that loop. If in the future it was felt that the new simpler goals are too simple, the work done until now need not be repeated. I will agree to doing only (c) if lot more work needs to be done before the current draft can be finished, but IMO that is not the case. The current document is a good technical ready-to-go solution to the goals stated in RFC4315. Lets document it for the records quickly while moving onto a simpler goal/solution. I don't see any reason why we cannot take mechanisms out of the current draft into any future solutions if necessary. Sathya > If we do not want any changes on the router side, I am not sure if we can > do better than CPL. > > - Syam > > On 8/2/07, Suresh Krishnan wrote: > >> Hi Folks, >> We have heard comments from OS vendors that the dna protocol, as it >> exists, is too complex to implement. We already have one instance of an >> OS vendor (Apple) who has shipped their own version of DNAv6 (it is >> pretty much a version of DNAv4 adapted to IPv6). From talking to the >> people who had the complexity concerns, the chairs have inferred that >> the following issues with the current document are the main obstacles to >> deployment >> >> * Router changes are NECESSARY >> * Handling of corner cases adds complexity to most likely use cases >> * Some of the DNA Goals are not really necessary/useful >> >> We have a couple of options going forward >> >> a) Forward the current document to the IESG on the standardization path >> with no hope of deployment >> b) Simplify the current document >> - remove some of the DNA steps >> - spin off Tentative options to a separate document >> and then put it on the standardization path, and again risk lack of >> deploymen >> c) Come up with a much simpler scheme which is probabilistic but works >> decently given a set of assumptions(however limited they may be). >> Then send it up on the standards track. This has the highest >> probability of deployment. >> d) Do both b) and c) >> >> We would like to hear the opinions of the WG on these options. >> >> Cheers >> Suresh & Greg >> >> >> >> From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 03 18:01:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH5D5-0000jG-O4 for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 18:01:27 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH5D4-0003RW-Od for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 18:01:27 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM700HUEX6DKY80@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Aug 2007 08:01:25 +1000 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D8CACAB543; Sat, 04 Aug 2007 08:01:24 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A77424FB05; Sat, 04 Aug 2007 08:01:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l73LwR613133 for dna-list; Sat, 04 Aug 2007 07:58:27 +1000 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l73LwQF13129 for ; Sat, 04 Aug 2007 07:58:26 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM700I01PRGHN00@kyle.its.monash.edu.au> (original mail from smadanapalli@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Aug 2007 07:58:27 +1000 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM700FY0X1EKPK0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 04 Aug 2007 07:58:27 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 62F4AAB542; Sat, 04 Aug 2007 07:58:27 +1000 (EST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by moe.its.monash.edu.au (Postfix) with ESMTP id 20B584FB09 for ; Sat, 04 Aug 2007 07:58:25 +1000 (EST) Received: by wa-out-1112.google.com with SMTP id m34so1103440wag for ; Fri, 03 Aug 2007 14:58:23 -0700 (PDT) Received: by 10.115.18.1 with SMTP id v1mr3405321wai.1186178303213; Fri, 03 Aug 2007 14:58:23 -0700 (PDT) Received: by 10.114.75.16 with HTTP; Fri, 03 Aug 2007 14:58:23 -0700 (PDT) Date: Sat, 04 Aug 2007 03:28:23 +0530 From: Syam Madanapalli Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <46B359BC.60908@njit.edu> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Suresh Krishnan , Dna , dna-ads@tools.ietf.org Message-id: <10e14db20708031458i2dc80036tcb5f7e7c5b100e54@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cDHqi4Bg4Q5POfRRFOXSdXKs9AUQg67eop4wwIf/lmoofzG1TSOII5Y/vSrwtWyP3NpDz6E2zZZuN0kuVTiAL5gYIzc9BSv87w9HKXZ1Kixo4Vxp+g1oT2NYubCZO2Hi6XGMBEbpQWyEweRZfW5Ph7qm+uv+D8G2NLWGi9LvFiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qhzmm8975lH8auCDEX4HOLvlCjHFaDaOeF2wSK9UeXx8NlAWbf89bWTSRF7gCLxiDdav32HQ6fum0HuH0CfXLs/FGkwDcMqC1TLrte2pjBNgbve4hH9C3/wuydOW399wUOaV1/6F443ml71b9EMU56DGJuotkAXluOpyUA1qxek= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <46B10FF6.5030602@ericsson.com> <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> <46B359BC.60908@njit.edu> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Satya, the problem I see is if we progress the current draft in standards track, we would have two standard documents (second standard as part of option C), which may be confusing for the implementers in the future. Thanks, Syam On 8/3/07, Sathya Narayanan wrote: > Syam Madanapalli wrote: > > I am not sure how option d works. I understand that we did lot of work > > on the existing draft that does not mean that we should continue progressing > > it if does not going to be useful, especially when you are planning for a > > (new) simpler solution. > > > > Also we need to look into the current draft and see if one of the mechanisms > > (CompleteRA, Landmark and LinkID) can be recommended instead of all three > > (if the changes in the router is OK). > > > IMHO, the current draft not being implemented because people think the > complex goals (agreed to earlier) do not justify the complexity in the > solution. So, we should produce a simpler document that achieves a > simpler goal (probabilistic). But, I still believe it makes sense to do > (d) because, we could standardize the current document as a solution to > the original DNA goals (RFC 4135) and close that loop. If in the future > it was felt that the new simpler goals are too simple, the work done > until now need not be repeated. I will agree to doing only (c) if lot > more work needs to be done before the current draft can be finished, but > IMO that is not the case. The current document is a good technical > ready-to-go solution to the goals stated in RFC4315. Lets document it > for the records quickly while moving onto a simpler goal/solution. > > I don't see any reason why we cannot take mechanisms out of the current > draft into any future solutions if necessary. > > Sathya > > > > If we do not want any changes on the router side, I am not sure if we can > > do better than CPL. > > > > - Syam > > > > On 8/2/07, Suresh Krishnan wrote: > > > >> Hi Folks, > >> We have heard comments from OS vendors that the dna protocol, as it > >> exists, is too complex to implement. We already have one instance of an > >> OS vendor (Apple) who has shipped their own version of DNAv6 (it is > >> pretty much a version of DNAv4 adapted to IPv6). From talking to the > >> people who had the complexity concerns, the chairs have inferred that > >> the following issues with the current document are the main obstacles to > >> deployment > >> > >> * Router changes are NECESSARY > >> * Handling of corner cases adds complexity to most likely use cases > >> * Some of the DNA Goals are not really necessary/useful > >> > >> We have a couple of options going forward > >> > >> a) Forward the current document to the IESG on the standardization path > >> with no hope of deployment > >> b) Simplify the current document > >> - remove some of the DNA steps > >> - spin off Tentative options to a separate document > >> and then put it on the standardization path, and again risk lack of > >> deploymen > >> c) Come up with a much simpler scheme which is probabilistic but works > >> decently given a set of assumptions(however limited they may be). > >> Then send it up on the standards track. This has the highest > >> probability of deployment. > >> d) Do both b) and c) > >> > >> We would like to hear the opinions of the WG on these options. > >> > >> Cheers > >> Suresh & Greg > >> > >> > >> > >> > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 03 18:09:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH5Ko-0000Qi-Vj for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 18:09:26 -0400 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH5Ko-0003aH-4q for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 18:09:26 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM600F21XAA6C61@cartman.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 19:06:11 +1000 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5505CAB543; Fri, 03 Aug 2007 19:06:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2AC634FB0A; Fri, 03 Aug 2007 19:06:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l7393H709520 for dna-list; Fri, 03 Aug 2007 19:03:17 +1000 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l7393GF09516 for ; Fri, 03 Aug 2007 19:03:16 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM600D01WXFIH00@cartman.its.monash.edu.au> (original mail from smadanapalli@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Aug 2007 19:03:16 +1000 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM600FVJX5F6C51@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 03 Aug 2007 19:03:16 +1000 (EST) Received: by localhost (Postfix, from userid 510) id A9CFAAB542; Fri, 03 Aug 2007 19:03:16 +1000 (EST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by moe.its.monash.edu.au (Postfix) with ESMTP id CD1644FB0C for ; Fri, 03 Aug 2007 19:03:15 +1000 (EST) Received: by rv-out-0910.google.com with SMTP id c27so708208rvf for ; Fri, 03 Aug 2007 02:03:13 -0700 (PDT) Received: by 10.114.160.1 with SMTP id i1mr2728794wae.1186131793764; Fri, 03 Aug 2007 02:03:13 -0700 (PDT) Received: by 10.114.75.16 with HTTP; Fri, 03 Aug 2007 02:03:13 -0700 (PDT) Date: Fri, 03 Aug 2007 14:33:13 +0530 From: Syam Madanapalli Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <46B10FF6.5030602@ericsson.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Suresh Krishnan Cc: Dna , dna-ads@tools.ietf.org Message-id: <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FQDuKWzlsV5400ulsZbRoWF4pvvps5Ee+M3jdzee355qG1BhCDmJdlfOERLQKWCprDvwxKrRyaA9cc5XET+YaxyDlKrWXxyKzPG+LgePcFJoHu2GO96AymGdROFrUbpNAU4LYW/x9COzcHW409uTHohzkJGGVT/dup48ZU3PnFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=shfWxRcFljoZ3o6SOTzSFn8XxXQzpGVvbgRGlwAuwy2FEuXNV8OSJWeABSZAX34iRO5fuaxV9VqvHE0cp+fJlUBXHDvtOpnOR5WP0zdf0Wi5QrfPyXNfAQGqk0NHT7/B+CSYVkcq6fGETc/1wG6xzv/NkVbIEj7x61pERAIKQ2Y= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) References: <46B10FF6.5030602@ericsson.com> X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 I am not sure how option d works. I understand that we did lot of work on the existing draft that does not mean that we should continue progressing it if does not going to be useful, especially when you are planning for a (new) simpler solution. Also we need to look into the current draft and see if one of the mechanisms (CompleteRA, Landmark and LinkID) can be recommended instead of all three (if the changes in the router is OK). If we do not want any changes on the router side, I am not sure if we can do better than CPL. - Syam On 8/2/07, Suresh Krishnan wrote: > Hi Folks, > We have heard comments from OS vendors that the dna protocol, as it > exists, is too complex to implement. We already have one instance of an > OS vendor (Apple) who has shipped their own version of DNAv6 (it is > pretty much a version of DNAv4 adapted to IPv6). From talking to the > people who had the complexity concerns, the chairs have inferred that > the following issues with the current document are the main obstacles to > deployment > > * Router changes are NECESSARY > * Handling of corner cases adds complexity to most likely use cases > * Some of the DNA Goals are not really necessary/useful > > We have a couple of options going forward > > a) Forward the current document to the IESG on the standardization path > with no hope of deployment > b) Simplify the current document > - remove some of the DNA steps > - spin off Tentative options to a separate document > and then put it on the standardization path, and again risk lack of > deploymen > c) Come up with a much simpler scheme which is probabilistic but works > decently given a set of assumptions(however limited they may be). > Then send it up on the standards track. This has the highest > probability of deployment. > d) Do both b) and c) > > We would like to hear the opinions of the WG on these options. > > Cheers > Suresh & Greg > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 03 19:20:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH6RL-0001ea-Gf for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 19:20:15 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH6RK-0004bS-2V for dna-archive@lists.ietf.org; Fri, 03 Aug 2007 19:20:15 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM700FKRBN4Q4H0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Aug 2007 00:16:17 +1000 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 517F7AB543; Sat, 04 Aug 2007 00:16:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5F7A34FB0A; Sat, 04 Aug 2007 00:16:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l73ECgB10832 for dna-list; Sat, 04 Aug 2007 00:12:42 +1000 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l73ECfF10828 for ; Sat, 04 Aug 2007 00:12:41 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JM700B017N6KH00@stan.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Aug 2007 00:12:42 +1000 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JM7003WBBH65080@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 04 Aug 2007 00:12:42 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 452B180003; Sat, 04 Aug 2007 00:12:42 +1000 (EST) Received: from bay0-omc2-s26.bay0.hotmail.com (bay0-omc2-s26.bay0.hotmail.com [65.54.246.162]) by larry.its.monash.edu.au (Postfix) with ESMTP id D789D3C00D for ; Sat, 04 Aug 2007 00:12:40 +1000 (EST) Received: from hotmail.com ([207.46.8.118]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 03 Aug 2007 07:12:38 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 03 Aug 2007 07:12:38 -0700 Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 03 Aug 2007 14:12:33 +0000 (GMT) Date: Fri, 03 Aug 2007 07:12:33 -0700 From: Bernard Aboba Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> X-Originating-IP: [71.197.208.131] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: smadanapalli@gmail.com, suresh.krishnan@ericsson.com Cc: dna@eng.monash.edu.au, dna-ads@tools.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 03 Aug 2007 14:12:38.0004 (UTC) FILETIME=[58A26B40:01C7D5D8] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed >If we do not want any changes on the router side, I am not sure if we can >do better than CPL. We can do better than CPL, if only because existing implementations are already superior. That is why CPL as it stands won't be implemented either. From dna-owner@webcamserver.eng.monash.edu.au Mon Aug 06 02:39:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwFL-0008Ul-VF for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 02:39:19 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHwFL-00058C-CK for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 02:39:19 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMC00KUCAHA1CE0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 16:39:10 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 03D6980003; Mon, 06 Aug 2007 16:39:10 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 303E03C006; Mon, 06 Aug 2007 16:39:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l766Ywe29263 for dna-list; Mon, 06 Aug 2007 16:34:58 +1000 Date: Thu, 02 Aug 2007 17:59:35 -0500 From: Basavaraj Patil Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <46B259FD.1000306@njit.edu> Sender: owner-dna@ecselists.eng.monash.edu.au To: ext Sathya Narayanan , Suresh Krishnan Cc: Dna , dna-ads@tools.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-topic: [DNA] Reality Check - Implementer Feedback Thread-index: AcfVWMtrCcJRaEFMEdy1KAARJNUNiA== X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Nokia-AV: Clean User-Agent: Microsoft-Entourage/11.3.6.070618 X-OriginalArrivalTime: 02 Aug 2007 22:59:33.0939 (UTC) FILETIME=[CAC98030:01C7D558] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Option C would probably be the best if we want to see it being adopted. -Raj On 8/2/07 5:26 PM, "ext Sathya Narayanan" wrote: > I vote for (d). > > I don't see the point in losing all the work/discussions that has gone > in to creating the current document. > > Sathya > > Suresh Krishnan wrote: >> >> Hi Folks, >> We have heard comments from OS vendors that the dna protocol, as it >> exists, is too complex to implement. We already have one instance of an >> OS vendor (Apple) who has shipped their own version of DNAv6 (it is >> pretty much a version of DNAv4 adapted to IPv6). From talking to the >> people who had the complexity concerns, the chairs have inferred that >> the following issues with the current document are the main obstacles to >> deployment >> >> * Router changes are NECESSARY >> * Handling of corner cases adds complexity to most likely use cases >> * Some of the DNA Goals are not really necessary/useful >> >> We have a couple of options going forward >> >> a) Forward the current document to the IESG on the standardization path >> with no hope of deployment >> b) Simplify the current document >> - remove some of the DNA steps >> - spin off Tentative options to a separate document >> and then put it on the standardization path, and again risk lack of >> deploymen >> c) Come up with a much simpler scheme which is probabilistic but works >> decently given a set of assumptions(however limited they may be). >> Then send it up on the standards track. This has the highest >> probability of deployment. >> d) Do both b) and c) >> >> We would like to hear the opinions of the WG on these options. >> >> Cheers >> Suresh & Greg >> >> > > From dna-owner@webcamserver.eng.monash.edu.au Mon Aug 06 03:22:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwvJ-0002Q7-KH for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 03:22:41 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHwvI-0005rV-EJ for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 03:22:41 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMC00KNHCHQ1JG0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 17:22:39 +1000 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76BA6AB544; Mon, 06 Aug 2007 17:22:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 753514FB03; Mon, 06 Aug 2007 17:22:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l767KRN29496 for dna-list; Mon, 06 Aug 2007 17:20:27 +1000 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l767KQF29492 for ; Mon, 06 Aug 2007 17:20:26 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JMC00J01A44RF00@cartman.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Aug 2007 17:20:27 +1000 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMC002ZJCE265M0@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 06 Aug 2007 17:20:27 +1000 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C124CAB543; Mon, 06 Aug 2007 17:20:26 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9CAFD4FB05; Mon, 06 Aug 2007 17:20:26 +1000 (EST) Received: from [203.94.130.102] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 06 Aug 2007 17:20:25 +1000 Date: Mon, 06 Aug 2007 17:20:25 +1000 From: Greg Daley Subject: Re: [DNA] Reality Check - Implementer Feedback In-reply-to: <10e14db20708031458i2dc80036tcb5f7e7c5b100e54@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: Sathya Narayanan , Suresh Krishnan , Dna , dna-ads@tools.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: en References: <46B10FF6.5030602@ericsson.com> <10e14db20708030203p70b51eb4vb18eb8e04b387878@mail.gmail.com> <46B359BC.60908@njit.edu> <10e14db20708031458i2dc80036tcb5f7e7c5b100e54@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Hi Syam, It is important that we have something implemented, but I think we should delineate carefully where the simplified solution is limited. As one example, it is possible that change detection works well with unmodified routers, so long as Link-local addresses are statistically unique across a single link transition, and the same prefixes are advertised in each RA. This would constrain the network to work where Routers advertise different Link-local addresses out each interface, and where routers' prefix advertisements aren't disjoint on a particular link. The simplified system could be described with applicability statements, and any environment where the assumptions do not hold face sub-optimal performance. The existing DNA document may be applicable for those environments where these constraints to not hold (for example, if RA prefix omission becomes important as an optimization). If so, the important thing is to make sure that routers and hosts which implement one or the other scheme are compatible, in the sense that the performance is the same. The WG needs to determine if a one or two document strategy is applicable in that case. What I think is important at this stage, is that we capture the "running code" feedback in a document. I've been trying to do that, and will work with Suresh to make sure we have something to concrete to review. Then we can let the WG get into the finer points of which documents to submit to the IESG. Greg. ----- Original Message ----- From: Syam Madanapalli Date: Saturday, August 4, 2007 8:01 am Subject: Re: [DNA] Reality Check - Implementer Feedback To: Sathya Narayanan Cc: Suresh Krishnan , Dna , dna-ads@tools.ietf.org > Satya, the problem I see is if we progress the current draft in > standards track, we would have two standard documents (second > standard as part of option C), which may be confusing for the > implementers in the future. > > Thanks, > Syam > > On 8/3/07, Sathya Narayanan wrote: > > Syam Madanapalli wrote: > > > I am not sure how option d works. I understand that we did lot > of work > > > on the existing draft that does not mean that we should > continue progressing > > > it if does not going to be useful, especially when you are > planning for a > > > (new) simpler solution. > > > > > > Also we need to look into the current draft and see if one of > the mechanisms > > > (CompleteRA, Landmark and LinkID) can be recommended instead of > all three > > > (if the changes in the router is OK). > > > > > IMHO, the current draft not being implemented because people > think the > > complex goals (agreed to earlier) do not justify the complexity > in the > > solution. So, we should produce a simpler document that achieves a > > simpler goal (probabilistic). But, I still believe it makes > sense to do > > (d) because, we could standardize the current document as a > solution to > > the original DNA goals (RFC 4135) and close that loop. If in the > future> it was felt that the new simpler goals are too simple, the > work done > > until now need not be repeated. I will agree to doing only (c) if > lot> more work needs to be done before the current draft can be > finished, but > > IMO that is not the case. The current document is a good technical > > ready-to-go solution to the goals stated in RFC4315. Lets > document it > > for the records quickly while moving onto a simpler goal/solution. > > > > I don't see any reason why we cannot take mechanisms out of the > current> draft into any future solutions if necessary. > > > > Sathya > > > > > > > If we do not want any changes on the router side, I am not sure > if we can > > > do better than CPL. > > > > > > - Syam > > > > > > On 8/2/07, Suresh Krishnan wrote: > > > > > >> Hi Folks, > > >> We have heard comments from OS vendors that the dna > protocol, as it > > >> exists, is too complex to implement. We already have one > instance of an > > >> OS vendor (Apple) who has shipped their own version of DNAv6 > (it is > > >> pretty much a version of DNAv4 adapted to IPv6). From talking > to the > > >> people who had the complexity concerns, the chairs have > inferred that > > >> the following issues with the current document are the main > obstacles to > > >> deployment > > >> > > >> * Router changes are NECESSARY > > >> * Handling of corner cases adds complexity to most likely use > cases> >> * Some of the DNA Goals are not really necessary/useful > > >> > > >> We have a couple of options going forward > > >> > > >> a) Forward the current document to the IESG on the > standardization path > > >> with no hope of deployment > > >> b) Simplify the current document > > >> - remove some of the DNA steps > > >> - spin off Tentative options to a separate document > > >> and then put it on the standardization path, and again risk > lack of > > >> deploymen > > >> c) Come up with a much simpler scheme which is probabilistic > but works > > >> decently given a set of assumptions(however limited they > may be). > > >> Then send it up on the standards track. This has the highest > > >> probability of deployment. > > >> d) Do both b) and c) > > >> > > >> We would like to hear the opinions of the WG on these options. > > >> > > >> Cheers > > >> Suresh & Greg > > >> > > >> > > >> > > >> > > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Aug 06 03:23:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwvl-0002Qj-T8 for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 03:23:09 -0400 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHwvl-0005s2-7m for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 03:23:09 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMC00KODCIJ1JG0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 06 Aug 2007 17:23:08 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DDDB80004; Mon, 06 Aug 2007 17:23:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1FF163C009; Mon, 06 Aug 2007 17:23:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l767LQ929504 for dna-list; Mon, 06 Aug 2007 17:21:26 +1000 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l767LPF29500 for ; Mon, 06 Aug 2007 17:21:25 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JMC00201A0CM300@kyle.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 06 Aug 2007 17:21:26 +1000 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMC00JVSCFQRBA0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 06 Aug 2007 17:21:26 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8A32280004 for ; Mon, 06 Aug 2007 17:21:26 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 724F83C004 for ; Mon, 06 Aug 2007 17:21:26 +1000 (EST) Received: from [203.94.130.102] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 06 Aug 2007 17:21:25 +1000 Date: Mon, 06 Aug 2007 17:21:25 +1000 From: Greg Daley Subject: [DNA] draft-ietf-dna-link-information-06.txt passes AUTH48 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: en X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Hi, Just an update, The Link Information draft has passed authors' final approval and is being readied for publication by the RFC editor. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Aug 07 20:42:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZce-0001TV-77 for dna-archive@lists.ietf.org; Tue, 07 Aug 2007 20:42:00 -0400 Received: from stan.its.monash.edu.au ([130.194.13.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIZcc-0000HI-Oe for dna-archive@lists.ietf.org; Tue, 07 Aug 2007 20:42:00 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMF002XLJ9QYVB0@stan.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Aug 2007 10:41:51 +1000 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5941BAB545; Wed, 08 Aug 2007 10:41:50 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D79B14FB09; Wed, 08 Aug 2007 10:41:44 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l780b5f07829 for dna-list; Wed, 08 Aug 2007 10:37:05 +1000 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l780b5F07825 for ; Wed, 08 Aug 2007 10:37:05 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JMF00I01I0A5B00@kyle.its.monash.edu.au> (original mail from rfc-editor@rfc-editor.org) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Aug 2007 10:37:05 +1000 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JMF00MLCJ1CR3W0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 08 Aug 2007 10:36:51 +1000 (EST) Received: by localhost (Postfix, from userid 510) id 06C4380005; Wed, 08 Aug 2007 10:36:50 +1000 (EST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by larry.its.monash.edu.au (Postfix) with ESMTP id 142703C008 for ; Wed, 08 Aug 2007 10:36:50 +1000 (EST) Received: by bosco.isi.edu (Postfix, from userid 70) id 32DADDF44C; Tue, 07 Aug 2007 17:36:26 -0700 (PDT) Date: Tue, 07 Aug 2007 17:36:26 -0700 (PDT) From: rfc-editor@rfc-editor.org Subject: [DNA] RFC 4957 on Link-Layer Event Notifications for Detecting Network Attachments Sender: owner-dna@ecselists.eng.monash.edu.au To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org, dna@eng.monash.edu.au Message-id: <20070808003626.32DADDF44C@bosco.isi.edu> X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 A new Request for Comments is now available in online RFC libraries. RFC 4957 Title: Link-Layer Event Notifications for Detecting Network Attachments Author: S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed. Status: Informational Date: August 2007 Mailbox: suresh.krishnan@ericsson.com, nicolas.montavont@enst-bretagne.fr, eric.njedjou@orange-ftgroup.com, sivav@qualcomm.com, a.yegin@partner.samsung.com Pages: 18 Characters: 41840 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dna-link-information-06.txt URL: http://www.rfc-editor.org/rfc/rfc4957.txt Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. This memo provides information for the Internet community. This document is a product of the Detecting Network Attachment Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From dna-owner@webcamserver.eng.monash.edu.au Tue Aug 28 04:00:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPw0H-00028w-Fn for dna-archive@lists.ietf.org; Tue, 28 Aug 2007 04:00:49 -0400 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPw0F-0003ds-Dm for dna-archive@lists.ietf.org; Tue, 28 Aug 2007 04:00:49 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JNH003MZ4WCH340@cartman.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Aug 2007 18:00:41 +1000 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 65EAB80002; Tue, 28 Aug 2007 18:00:40 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D1A873C00B; Tue, 28 Aug 2007 18:00:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l7S7uNS08111 for dna-list; Tue, 28 Aug 2007 17:56:23 +1000 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l7S7uMF08107 for ; Tue, 28 Aug 2007 17:56:22 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JNH002012M6P700@kenny.its.monash.edu.au> (original mail from Hideshi.Enokihara@jp.yokogawa.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Aug 2007 17:56:20 +1000 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JNH00HQX4PWVR90@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 28 Aug 2007 17:56:20 +1000 (EST) Received: by localhost (Postfix, from userid 510) id B32B0AB543; Tue, 28 Aug 2007 17:56:19 +1000 (EST) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8A0B44FB02 for ; Tue, 28 Aug 2007 17:56:16 +1000 (EST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7S7uDve024272 for ; Tue, 28 Aug 2007 16:56:13 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7S7uDPm024267 for ; Tue, 28 Aug 2007 16:56:13 +0900 (JST) Date: Tue, 28 Aug 2007 16:56:10 +0900 From: Hideshi.Enokihara@jp.yokogawa.com Subject: [DNA] DAD in using DHCPv6 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <0260031F55435342859BFB2CCA6773D81B898C29@EXCHANGE03.jp.ykgw.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/mixed; boundary="----_=_NextPart_001_01C7E948.E60C40E6" Content-class: urn:content-classes:message Thread-topic: DAD in using DHCPv6 Thread-index: AcfpSOYGKstZCvGASQ2EzsfCIjmiqw== X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E948.E60C40E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I've asked following question to DHC wg and IPv6 WG. Then, they recommended to ask to this WG. Could you give me your thought, please? And I attached the emails that I've received in the WGs. --------------------- In the situation in which DHCPv6 clinet transmits a Conform message for its Global address, should the DHCPv6 Client do DAD for GA? When the DAD NS should be transmitted, if it is required to transmit a DAD NS from DHCPv6 Client? Should the DAD NS be transmitted after sending the Conform messge and/or receiving the Reply? Or before sending the Conform message? ----------------------- Thank you for your cooperation. Best regards, Hideshi ------_=_NextPart_001_01C7E948.E60C40E6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: from zex001-0m9005.jp.ykgw.net ([10.0.11.15]) by EXCHANGE03.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 12:44:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Received: from zml001-0m9021.jp.ykgw.net ([10.0.8.30]) by zex001-0m9005.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 12:37:26 +0900 Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.mitaka.yokogawa.co.jp [10.8.17.13]) by zml001-0m9021.jp.ykgw.net (8.13.7+Sun/8.13.7) with ESMTP id l7L3bQfh009524 for ; Tue, 21 Aug 2007 12:37:26 +0900 (JST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7L3bLve029415 for ; Tue, 21 Aug 2007 12:37:21 +0900 (JST) Received: from zml001-0m9012.yokogawa.co.jp ([10.8.17.14]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7L3bJPm029357 for ; Tue, 21 Aug 2007 12:37:19 +0900 (JST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by zml001-0m9012.yokogawa.co.jp (Spam Firewall) with ESMTP id 078072AE903 for ; Tue, 21 Aug 2007 12:36:56 +0900 (JST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Aug 2007 23:36:52 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7L3aqbc029768; Mon, 20 Aug 2007 23:36:52 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7L3apmd008646; Tue, 21 Aug 2007 03:36:51 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 23:36:51 -0400 Content-class: urn:content-classes:message Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 21 Aug 2007 03:36:51.0631 (UTC) FILETIME=[830F53F0:01C7E3A4] X-Virus-Scanned: by Spam Firewall at yokogawa.co.jp X-IronPort-AV: i="4.19,286,1183348800"; d="scan'208"; a="129410449:sNHT57400222" Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (sig from cisco.com/rtpdkim2001 verified; ); DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1431; t=1187667412; x=1188531412;c=relaxed/simple; s=rtpdkim2001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=volz@cisco.com;z=From:=20=22Bernie=20Volz=20\(volz\)=22=20|Subject:=20RE=3A=20Is=20a=20DNS=20NS=20required,when=20a=20DHCPv6=20Client=20transmits=20a=20Conform=20message?=20|Sender:=20|To:=20,=20;bh=MerbJvl2kETumtlYkLK34xmUXhU/1kfPWtBuCnEg4BE=;b=t2wTx3tnitqMofd0AvCeLr9Oj3p7dmtEDtd9BgzlYfzE2wW+/vuutPzUb1i/xIf8pesenPRv+INj9vqTXeh9mVA7VzFpaVR0qLy2Dzy2uDAPJO/3bX1jjGKhMmfmT8HR; Subject: RE: Is a DNS NS required,when a DHCPv6 Client transmits a Conform message? Date: Tue, 21 Aug 2007 12:36:50 +0900 Message-ID: <8E296595B6471A4689555D5D725EBB2104D4B11F@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898C13@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is a DNS NS required,when a DHCPv6 Client transmits a Conform message? Thread-Index: AcfjmqWo6+MgFrvIRz2RPMwLaZmuGQACO9tg X-Message-Flag: =?iso-2022-jp?B?GyRCJDQ7MjlNJF4kRyRLGyhC?= From: To: , Cc: Hideshi: There are really two parts to this: 1. Is DAD for the link-local done when an interface "reconnect" is detected? This may be required before multicasting the Confirm. 2. Is DAD for done for the global addresses (AFTER a successful indication from a DHCPv6 Confirm is received, since there's no point to do it before as the client doesn't know yet whether the addresses are invalid)? I'm not sure that this is a DHCP question ... Probably should be directed at the IPv6 WG? - Bernie -----Original Message----- From: Hideshi.Enokihara@jp.yokogawa.com [mailto:Hideshi.Enokihara@jp.yokogawa.com] Sent: Monday, August 20, 2007 10:26 PM To: dhcwg@ietf.org Cc: ipv6@ietf.org Subject: Is a DNS NS required,when a DHCPv6 Client transmits a Conform message? Hello all, In the situation in which DHCPv6 clinet transmits a Conform message for its Global address, should the DHCPv6 Client do DAD? When the DAD NS should be transmitted, if it is required to transmit a DAD NS from DHCPv6 Client? Should the DAD NS be transmitted after sending the Conform messge and receiving the Reply? Or before sending the Conform message? I'm waiting for your valuable replies. Best regards, Hideshi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C7E948.E60C40E6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from zex001-0m9005.jp.ykgw.net ([10.0.11.15]) by EXCHANGE03.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 16:29:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Received: from zml001-0m9021.jp.ykgw.net ([10.0.8.30]) by zex001-0m9005.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 16:29:14 +0900 Received: from zns001-0m9004.yokogawa.co.jp (zns001-0m9004.jp.ykgw.net [10.8.30.26]) by zml001-0m9021.jp.ykgw.net (8.13.7+Sun/8.13.7) with ESMTP id l7L7TEY9028811 for ; Tue, 21 Aug 2007 16:29:14 +0900 (JST) Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7L7T773021122 for ; Tue, 21 Aug 2007 16:29:07 +0900 (JST) Received: from zml001-0m9012.yokogawa.co.jp ([10.8.17.14]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7L7T7AU021119 for ; Tue, 21 Aug 2007 16:29:07 +0900 (JST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by zml001-0m9012.yokogawa.co.jp (Spam Firewall) with ESMTP id 32B5C2BB5AF for ; Tue, 21 Aug 2007 16:29:07 +0900 (JST) Received: from jmb.local (unknown [IPv6:2001:200:1b1:101a:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A21D17301F; Tue, 21 Aug 2007 16:28:57 +0900 (JST) Return-Path: X-OriginalArrivalTime: 21 Aug 2007 07:29:14.0494 (UTC) FILETIME=[F9A761E0:01C7E3C4] User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) X-Virus-Scanned: by Spam Firewall at yokogawa.co.jp Content-class: urn:content-classes:message Subject: Re: [dhcwg] RE: Is a DNS NS required, when a DHCPv6 Client transmits a Conform message? Date: Tue, 21 Aug 2007 16:28:50 +0900 Message-ID: In-Reply-To: <8E296595B6471A4689555D5D725EBB2104D4B11F@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: Is a DNS NS required, when a DHCPv6 Client transmits a Conform message? Thread-Index: AcfjxPpVNaHLSV9pQZG2sdIioVwJ2Q== X-Message-Flag: =?iso-2022-jp?B?GyRCJDQ7MjlNJF4kRyRLGyhC?= References: <0260031F55435342859BFB2CCA6773D81B898C13@EXCHANGE03.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB2104D4B11F@xmb-rtp-20a.amer.cisco.com> From: To: Cc: , , At Mon, 20 Aug 2007 23:36:50 -0400, "Bernie Volz (volz)" wrote: > There are really two parts to this: > 1. Is DAD for the link-local done when an interface "reconnect" is > detected? This may be required before multicasting the Confirm. > 2. Is DAD for done for the global addresses (AFTER a successful > indication from a DHCPv6 Confirm is received, since there's no point to > do it before as the client doesn't know yet whether the addresses are > invalid)? > > I'm not sure that this is a DHCP question ... Probably should be > directed at the IPv6 WG? I don't think it's a DHCPv6 question, either. The real question is whether a host should perform DAD when it detects a possible change of attached link. Referring to Section 18.1.2 of RFC3315, those case would include: o The host (client) reboots. o The host (client) is physically connected to a wired connection. o The host (client) returns from sleep mode. o The host (client) using a wireless technology changes access points. I think it's reasonable to perform DAD for at least some of these cases, but as far as I know no specification explicitly requires that. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ------_=_NextPart_001_01C7E948.E60C40E6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from zex001-0m9005.jp.ykgw.net ([10.0.11.15]) by EXCHANGE03.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 21:44:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Received: from zml001-0m9006.jp.ykgw.net ([10.0.8.11]) by zex001-0m9005.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Aug 2007 21:44:02 +0900 Received: from zns001-0m9003.yokogawa.co.jp (zns001-0m9003.jp.ykgw.net [10.8.30.25]) by zml001-0m9006.jp.ykgw.net (8.13.7+Sun/8.13.7) with ESMTP id l7LCi2Qe004051 for ; Tue, 21 Aug 2007 21:44:02 +0900 (JST) Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7LCi1ik027964 for ; Tue, 21 Aug 2007 21:44:01 +0900 (JST) Received: from zml001-0m9013.yokogawa.co.jp ([10.8.17.15]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l7LCi1Yf027958 for ; Tue, 21 Aug 2007 21:44:01 +0900 (JST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by zml001-0m9013.yokogawa.co.jp (Spam Firewall) with ESMTP id 3A91125592C for ; Tue, 21 Aug 2007 21:44:00 +0900 (JST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7LChxhR020569 for ; Tue, 21 Aug 2007 08:43:59 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7LChxJA212136 for ; Tue, 21 Aug 2007 06:43:59 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7LChwf3019677 for ; Tue, 21 Aug 2007 06:43:59 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-203-58.wecm.ibm.com [9.67.203.58]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7LChvXr019601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 06:43:58 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l7LChZx4004223; Tue, 21 Aug 2007 08:43:35 -0400 Return-Path: X-OriginalArrivalTime: 21 Aug 2007 12:44:02.0572 (UTC) FILETIME=[F3D35CC0:01C7E3F0] X-Virus-Scanned: by Spam Firewall at yokogawa.co.jp Comments: In-reply-to "Bernie Volz \(volz\)" message dated "Mon, 20 Aug 2007 23:36:50 -0400." X-ASG-Debug-ID: 1187700240-20960-29-0 X-Barracuda-URL: http://10.8.17.15:8000/cgi-bin/mark.cgi X-ASG-Orig-Subj: Re: [dhcwg] RE: Is a DNS NS required, when a DHCPv6 Client transmits a Conform message? X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=5.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.51390Rule breakdown below pts rule name description---- ---------------------- -------------------------------------------------- Content-class: urn:content-classes:message Subject: Re: [dhcwg] RE: Is a DNS NS required, when a DHCPv6 Client transmits a Conform message? Date: Tue, 21 Aug 2007 21:43:35 +0900 Message-ID: <200708211243.l7LChZx4004223@cichlid.raleigh.ibm.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2104D4B11F@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: Is a DNS NS required, when a DHCPv6 Client transmits a Conform message? Thread-Index: Acfj8QOi8P3tyq+UT7OmKRqZV8l93A== X-Message-Flag: =?iso-2022-jp?B?GyRCJDQ7MjlNJF4kRyRLGyhC?= References: <8E296595B6471A4689555D5D725EBB2104D4B11F@xmb-rtp-20a.amer.cisco.com> From: To: Cc: , , > I'm not sure that this is a DHCP question ... Probably should be > directed at the IPv6 WG? Or perhaps DNA, which is grappling with the general issue of how to deal (quickly) with reattachments to the same link, and what should done in such cases. Thomas ------_=_NextPart_001_01C7E948.E60C40E6--