From dna-owner@webcamserver.eng.monash.edu.au Mon Apr 4 13:30:37 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 NAA02446 for ; Mon, 4 Apr 2005 13:30:35 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMPY23O1TK8YHNVP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 03:30:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 24A0780003; Tue, 05 Apr 2005 03:30:11 +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 D5AA23C006; Tue, 05 Apr 2005 03:30:10 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j34HT2N06060 for dna-list; Tue, 05 Apr 2005 03:29:02 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j34HT2606056 for ; Tue, 05 Apr 2005 03:29:02 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMPY0HJ86I9AMEZ1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 03:28:53 +1000 Received: by localhost (Postfix, from userid 510) id CB342AB543; Tue, 05 Apr 2005 03:28:52 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id EF1504FB10 for ; Tue, 05 Apr 2005 03:28:50 +1000 (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 j34HSnHU020458 for ; Mon, 04 Apr 2005 13:28:49 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 641FC3C8195 for ; Mon, 04 Apr 2005 13:26:11 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 4C8AC3C8193for ; Mon, 04 Apr 2005 13:26:11 -0400 (EDT) Date: Mon, 04 Apr 2005 13:28:46 -0400 From: Sathya Narayanan Subject: [DNA] Hosts BCP Issues Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <4251794E.5050002@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:3.10733 C:19 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Erik & Greg - I created three issues on the issues tracker for the DNA hosts BCP, based on the discussions on the list. Please verify their accuracy - http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNABCP Erik - I beleive the three issues put together cover your suggestion of re-structuring the draft. Hence, I didn't capture that suggestion as a separate issue. Is that alright? Instead of dumping a lot of the email text in the description I took few lines, hope they don't sound too much out of context. I will launch separate emails to discuss the issues. thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Mon Apr 4 14:01:28 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 OAA05140 for ; Mon, 4 Apr 2005 14:01:27 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMPZ4O4EKS93D07D@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 04:01:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DE77EAB548; Tue, 05 Apr 2005 04:01:16 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 967944FB06; Tue, 05 Apr 2005 04:01:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j34I16t06473 for dna-list; Tue, 05 Apr 2005 04:01:06 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j34I15606469 for ; Tue, 05 Apr 2005 04:01:05 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMPZ4AWURM9AMEZQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 04:01:00 +1000 Received: by localhost (Postfix, from userid 510) id DB6C1AB550; Tue, 05 Apr 2005 04:00:16 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9C0874FB06 for ; Tue, 05 Apr 2005 04:00:14 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.85.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j34I08X8015722; Mon, 04 Apr 2005 12:00:13 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j34I087J685883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 04 Apr 2005 11:00:08 -0700 (PDT) Date: Mon, 04 Apr 2005 10:59:49 -0700 From: Erik Nordmark Subject: Re: [DNA] Hosts BCP Issues In-reply-to: <4251794E.5050002@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <42518095.7010102@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: <4251794E.5050002@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Erik & Greg - > > I created three issues on the issues tracker for the DNA hosts BCP, > based on the discussions on the list. Please verify their accuracy - > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNABCP > > Erik - I beleive the three issues put together cover your suggestion of > re-structuring the draft. Hence, I didn't capture that suggestion as a > separate issue. Is that alright? Did you find the suggested outline useful? It makes sense having an explicit discussion about the outline, but that doesn't mean it needs to be an issue in the tracker. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Apr 4 14:14:58 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 OAA07992 for ; Mon, 4 Apr 2005 14:14:57 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMPZKF7LK693D07D@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 04:14:06 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CE6DCAB544; Tue, 05 Apr 2005 04:13:58 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1B2634FB10; Tue, 05 Apr 2005 04:13:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j34IDhx06821 for dna-list; Tue, 05 Apr 2005 04:13:43 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j34IDc606812 for ; Tue, 05 Apr 2005 04:13:38 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMPZJVWS0693BPLK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 04:13:33 +1000 Received: by localhost (Postfix, from userid 510) id ECEB4AB544; Tue, 05 Apr 2005 04:13:32 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0FA2C4FB0A for ; Tue, 05 Apr 2005 04:13:30 +1000 (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 j34IDToZ022443 for ; Mon, 04 Apr 2005 14:13:29 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 026BA3C8196 for ; Mon, 04 Apr 2005 14:10:52 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id E28EC3C8195for ; Mon, 04 Apr 2005 14:10:51 -0400 (EDT) Date: Mon, 04 Apr 2005 14:13:26 -0400 From: Sathya Narayanan Subject: [DNA] Host BCP Issue 1: Same link vs Link change Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <425183C6.4000102@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:38.78330 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) Content-Transfer-Encoding: 7BIT Issue 1: Same link vs Link change Should the BCP make recommedations to the host only to find if there is a link-change? If the host is on the same link - is it OK if the host doesn't find out that it is on the same link efficiently? This question I think shows up both on the BCP and on the solutions work. From the goals: G1: DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration. They should recognize and determine whether a link change has occurred and initiate the process of acquiring a new configuration if necessary. The first sentence makes it sound like the goal is to 'detect identity' irrespective of whether the link has changed or not. The second sentence makes it sound like our focus is only to detect 'link-change' and initiate the process of ... FWIW, I think DNA should not differentiate between same-link and link-change. DNA should define efficient mechanisms (in BCP and Soln.) for the hosts to quickly identify its current link, whether it be the same or different link. What do others think? - Sathya From dna-owner@webcamserver.eng.monash.edu.au Mon Apr 4 14:16:42 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 OAA08278 for ; Mon, 4 Apr 2005 14:16:41 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMPZN96XY28YHFAR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 04:16:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D40DBAB542; Tue, 05 Apr 2005 04:16:15 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id E2AA64FB10; Tue, 05 Apr 2005 04:16:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j34IG6R06891 for dna-list; Tue, 05 Apr 2005 04:16:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j34IG4606887 for ; Tue, 05 Apr 2005 04:16:04 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMPZMP3SWK99DI6P@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 04:15:49 +1000 Received: by localhost (Postfix, from userid 510) id 06C42AB542; Tue, 05 Apr 2005 04:15:48 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 403CB4FB06 for ; Tue, 05 Apr 2005 04:15:47 +1000 (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 j34IFkAk022512; Mon, 04 Apr 2005 14:15:46 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 110D13C818E; Mon, 04 Apr 2005 14:13:09 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id EF1243C815C; Mon, 04 Apr 2005 14:13:08 -0400 (EDT) Date: Mon, 04 Apr 2005 14:15:43 -0400 From: Sathya Narayanan Subject: Re: [DNA] Hosts BCP Issues In-reply-to: <42518095.7010102@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Dna Message-id: <4251844F.80805@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: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) References: <4251794E.5050002@Research.Panasonic.COM> <42518095.7010102@sun.com> Content-Transfer-Encoding: 7BIT Erik - > Did you find the suggested outline useful? It makes sense having an > explicit discussion about the outline, but that doesn't mean it needs > to be an issue in the tracker. Yes. Based on a little bit more of discussion for my own clarification, I plan to re-structure the draft using your outline and create a version soon. Your comments on my emails to follow will be very much appreciated. thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Mon Apr 4 20:20:22 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 UAA28891 for ; Mon, 4 Apr 2005 20:20:21 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMQCC4EB3K93D4ZX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 10:19:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B3AFAB54A; Tue, 05 Apr 2005 10:19:07 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5AF5B4FB11; Tue, 05 Apr 2005 10:19:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j350IR210109 for dna-list; Tue, 05 Apr 2005 10:18:27 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j350IR610105 for ; Tue, 05 Apr 2005 10:18:27 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMQCB5P3F093D4ZX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 10:18:21 +1000 Received: by localhost (Postfix, from userid 510) id 37E40AB54A; Tue, 05 Apr 2005 10:18:21 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id 105554FB18 for ; Tue, 05 Apr 2005 10:18:17 +1000 (EST) Received: by rproxy.gmail.com with SMTP id b11so1389325rne for ; Mon, 04 Apr 2005 17:18:16 -0700 (PDT) Received: by 10.38.160.52 with SMTP id i52mr5771558rne; Mon, 04 Apr 2005 17:18:15 -0700 (PDT) Received: by 10.38.125.23 with HTTP; Mon, 04 Apr 2005 17:18:15 -0700 (PDT) Date: Tue, 05 Apr 2005 09:18:15 +0900 From: JinHyeock Choi Subject: Re: [DNA] Host BCP Issue 1: Same link vs Link change In-reply-to: <425183C6.4000102@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Reply-to: JinHyeock Choi Message-id: <92e919fb05040417183997792d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=okj5ju52HtJVOe30Kbf1ceGR+a1l+bEi5BGidQlgPWtOmR5W/RpYgK0xQwE7UVU9MzaVaOXm7SrKpoHVfNrOHJw5g8mqNxhzWoPmm/U548jb4Ssm8SkbCD/y9D/IxRZENeyF7Xw0hhOUgqOjul/IPkcAo6fqGQlHClU9hRZJUtw= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <425183C6.4000102@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > Issue 1: Same link vs Link change > Should the BCP make recommedations to the host only to find if there is > a link-change? If the host is on the same link - is it OK if the host > doesn't find out that it is on the same link efficiently? This question > I think shows up both on the BCP and on the solutions work. > > From the goals: > G1: DNA schemes should detect the identity of the currently attached > link to ascertain the validity of the existing IP configuration. They > should recognize and determine whether a link change has occurred and > initiate the process of acquiring a new configuration if necessary. > > The first sentence makes it sound like the goal is to 'detect identity' > irrespective of whether the link has changed or not. The second sentence > makes it sound like our focus is only to detect 'link-change' and > initiate the process of ... The first and second sentence are intended to mean the same. > FWIW, I think DNA should not differentiate between same-link and > link-change. DNA should define efficient mechanisms (in BCP and Soln.) > for the hosts to quickly identify its current link, whether it be the > same or different link. I agree that DNA should detect link identity EFFICIENTLY, whether link change or not. But I don't think that implies that a host needs to QUICKLY find out that it still remains at the same link. In case of a link change, it's important for a host to quickly check for link change lest there should be service disruption. But in case of no link change, I can't think of any harm from a little DNA delay. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Apr 5 03:09:52 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 DAA16786 for ; Tue, 5 Apr 2005 03:09:51 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMQQIU8PSQ936EFY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Apr 2005 17:06:27 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A0641ABCF9; Tue, 05 Apr 2005 16:55:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 58F014FB0E; Tue, 05 Apr 2005 16:55:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j356sjT13632 for dna-list; Tue, 05 Apr 2005 16:54:45 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j356si613628 for ; Tue, 05 Apr 2005 16:54:44 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMQQ4I6C5K99DKCJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Apr 2005 16:54:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7F2B80675; Tue, 05 Apr 2005 16:09:22 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 86A933C007; Tue, 05 Apr 2005 16:09:22 +1000 (EST) Date: Tue, 05 Apr 2005 16:09:22 +1000 From: Greg Daley Subject: Re: [DNA] Host BCP Issue 1: Same link vs Link change In-reply-to: <92e919fb05040417183997792d@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Sathya Narayanan , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <42522B92.80408@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: <425183C6.4000102@Research.Panasonic.COM> <92e919fb05040417183997792d@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: [chop prior text] > > I agree that DNA should detect link identity EFFICIENTLY, whether > link change or not. > > But I don't think that implies that a host needs to QUICKLY find out > that it still remains at the same link. > > In case of a link change, it's important for a host to quickly check > for link change lest there should be service disruption. > > But in case of no link change, I can't think of any harm from > a little DNA delay. Indeed. In some networks, forwarding state will need to be updated by transmitting MAC frames (with a matching MAC to that perviously used) onto the medium. This may need to be done, perhaps with an RS, but the response from the router needn't arrive before packets start flowing. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Apr 5 10:30:26 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 KAA25395 for ; Tue, 5 Apr 2005 10:30:24 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMR61HGLLS8YHCST@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 06 Apr 2005 00:29:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98E9480006; Wed, 06 Apr 2005 00:29:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4AE9C3C00B; Wed, 06 Apr 2005 00:29:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j35ESTl17581 for dna-list; Wed, 06 Apr 2005 00:28:29 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j35EST617577 for ; Wed, 06 Apr 2005 00:28:29 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMR5YW3EBO9AMFVI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 06 Apr 2005 00:28:14 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 378AB80002 for ; Wed, 06 Apr 2005 00:28:14 +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 175C23C00F for ; Wed, 06 Apr 2005 00:28:12 +1000 (EST) Received: from [211.28.76.8] by mail-store-2.its.monash.edu.au (mshttpd); Wed, 06 Apr 2005 00:28:12 +1000 Date: Wed, 06 Apr 2005 00:28:12 +1000 From: Greg Daley Subject: [DNA] Preliminary Minutes for IETF62 (please check) Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <12f2d9812f3549.12f354912f2d98@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 Here are the preliminary minutes from IETF 62. Thanks to those who took notes. Attendees: There are some paraphrases and some unknown speakers. Please check that what you said is accurate. The minutes have to be submitted by friday, with presentation slides. If you've not sent in your slides please do so. Greg Monday Minutes taken by John Loughney and Christian Vogt ============================================================ DNA Working Group Meeting March 7, 2005, 15:30pm to 17:30pm IETF 62, Minneapolis ============================================================ CHAIRS: Greg Daley Pekka Nikander ------------------------------------------------------------ Agenda ------------------------------------------------------------ 1. Introduction, Status Update Chairs 2. L2 Event Notifications draft-ietf-dna-link-information-01 Alper Yegin 3. Media Independent Handover Services and Interoperability Ajay Rajkumar 4. DNA with unmodified routers: Prefix List based approach JinHyeock Choi 5. BCP For Hosts Sathya Narayanan 6. BCP For Routers Sathya Narayanan 7. DNA Design Team Update draft-dnadt-dna-discussion-00 Brett Pentland 8. Conclusion Greg Daley, Pekka Nikander ------------------------------- - 10 min wg status and summary overview of the agenda overview of WG status 3 items are late Goals draft in RFC editor's queue Send-CGA has just passed AUTH-48, SEND-ndopt is currently in AUTH-48. ---------------------------------- - 20 min link information draft Alper Yegin draft-ietf-dna-link-information-01.txt ---------------------------------- New version of ietf-dna-link-information-01. New text with respect to 802.11 ad-hoc mode. New text on 802.3, Greg would like someone to review. Comments from John Laughey will lead to clarifications affecting the GSM, GPRS, and UMTS parts of the document. John Loughney: Terminology is not so good. I volunteer for enhancing this. John Loughney: Notifications can be spoofed; this might lead to DoS attacks. Volunteer for text on this, too. Reviews from Pekka Savola & Bernard Aboba will be sent to the draft. - 20 min 802.21 status and liaison ------------------------------------------------------------ Media Independent Handover Services and Interoperability Ajay Rajkumar 802.21 Chair ------------------------------------------------------------ Media Independent Handover: IEEE 802.21 considers handovers between the following technologies - between 802.xx and 802.yy - between 802.xx and Cellular (3GPP, 3GPP2) - between 802.11 ESS where x,y = 3, 11, 15, 16. Won't specify the mobility protocol used. All scenarios but the last are handovers between different technologies. In all scenarios including the last, the question of whether a node has changed IP attachment when it changes its AP is a critical one. Session continuity is important, so that there is service continuity at the application layer. Session continuity has three components - adaptation to new link at layer two - address continuity at layer 3 - service continuity at application layer Lots of info that is required to move from interface to interface and maintain session continuity. A basic list was shown. active work items: - MIH model - event-trigger service model - information service - Should MIH a layer, should an API be defined, should the transport mechanism be defined? - How should the APIs to upper and lower layers be defined? - Should the transports be defined for remote, local triggers? define these in a RAN & in the MN MIH model Modelling mobile terminals is easy: Assume PHY, MAC, LLC in every mobile terminal except in cellular ones. But within the network, things are more complicated, because a certain layer is usually implemented in different entities. signaling diagram for the MIH model is shown. See slide. signaling diagram for cellular side is a bit different than for the 802.xx version Keith Moore: (paraphrase) objects to the statement "no overlap/no switching" is possible, thinks its because 802.21 has scoped it outside of the presentation. Example: MN has 802.11 and cellular interface. When 802.11 interface recognizes fading signal, it signals this information to the MIH layer. MIH layer looks for alternative interfaces and initiates scanning at those. Alper Yegin: asked about the cellular diagram - is it between 2 IP nodes? Ajay Rajkumar: this is open, not specified. It could be over IP. Alper Yegin: What are the endpoints for MIH signaling? Can such signaling be over the air? Ajay Rajkumar: Yes, it could. Alper Yegin: Is IEEE 802.21 developing a special MIH signaling protocol? Ajay Rajkumar: This has been discussed. Alper Yegin: could have some signaling between different networks. Alper Yegin: resembles 'smart networks' like cellular Ajay Rajkumar: that is one scenario, but MN might have the policy Pekka Nikander: What will be carried within the MIH signaling? Ajay Rajkumar: I can give examples, no slides, though. Pekka Nikander: I would prefer to not specify the transport. The reason is that L2 information must provided early to/by MIH. But you have to exchange 15-20 messages for L2 attachment with 802.11 or 802.11i. This, in turn, prohibits using IP as a transport in some cases. So, it needs to be carefully considered which transport to use. Ajay Rajkumar: Pekka Nikander: It seems that you require all interfaces of a MN to belong to the same operator. This business model may not be feasible in all situations. Someone: CS cellular or PS? Ajay Rajkumar: (paraphrase) only PS, no CS. Gabriel Montenegro: How much information do you want to carry in the MIH protocol? Too much information could be an issue with certain link layers.. E.g., the maximum payload that can be carried in IEEE 802.15.4 frames is 102 bytes. Ajay Rajkumar: IEEE 802.15 is not currently directly addressed. The group is chartered for it, so this may be done at a later point. Stefano Faccin: (answering to Gabriel) The information carried in the transport is modular. Different link layers use different modules, so the information that would be exchanged over 802.15.4 would be such that it fits the maximum frame size. Things can also be sent in multiple messages/round trips. Event-trigger service model - Local triggers - Peer-to-peer remote triggers Local triggers - link up - link down Should be generic enough to function over different access technologies. Other triggers are specific to some bearers. How to limit the amount of possible triggers? Peer-to-peer remote triggers - authentication done Several modes of transport; granularity issues being discussed Alper Yegin: What kind of triggers are being defined? Ajay Rajkumar: link up, link down, pre-authentication, post-authentication. still being discussed. large number is being discussed. Information Services - Security mechanisms - location - cost of link Call for proposal issued on September 28, 2004. Initial draft text due in May 2005. Stefano Faccin: IEEE has not the power to define a L3 transport. This needs to be done in the IETF. Someone 3: IAB l2 draft question? will it be handled in DNA? Pekka Nikander: It is an IAB draft, will discuss with Bernard S3: Thinks that the solution for the MIH signaling should be done in the IETF Pekka Nikander: I think we agree that IEEE and IETF need to closer co-operate with respect to 802.21. Alper Yegin: 802.21 folks may want to take a look at the CARD protocol. This protocol can also carry information to mobile terminals about potential new attachment points. S3: yes, it will be considered. ----------------------------------------- - 10 min DNAv6 with unmodified routers: Prefix List Approach JinHyeock Choi draft-jinchoi-dna-cpl-01.txt ----------------------------------------- JinHyeock Choi: The DNA WG is working on efficient mechanisms for L3-handover detection that may also be applicable to link changes between DNA links and non-DNA links. E.g., look at the Complete Prefix List proposal: discussion of goals basic idea: a host collects all prefix on a link & makes a list. When it moves to a new link, it creates a new list. If the lists are disjoint, then its on a new link. Only RA is needed for movement detection. someone 4: ans: there is a kind of hint, then you need a trigger to start DNA process. greg explains mechanism better. Keith Moore: (paraphrased) thinks the mechanism is broken, if you see some of the same set of prefixes on multiple links, then you have different links. You actually can have the same prefix advertised on two links. Links can be bridged. JinHyeock Choi: If two links are bridged, then we consider it one L3 link-- even if this L3 link consists of two L2 links. (For a definition of L2 links and L3 links, see DNA documents and mailing-list discussions.) Keith Moore: A prefix may move from one link to another. This is an example (though a rare one) of where the prefix is not necessarily tied to one link. Keith Moore: Its hazardous that if you see one of the same prefixes, then you think two links are the same. Keith Moore: (paraphrased) some discussion on this, thinks you need to have some explicit mechanism to do effectively Samita Chakrabati: We have an implementation of this on the wired network. Keith Moore: thinks this is not reasonable assumption Pekka Nikander: draft should cover Keith's scenario Keith Moore: thinks it is reasonable that the group looks into the problem, but not that the problem is solved WG document? We want to facilitate its adoption to existing Mobile IPv6 code. Kent Leung: (paraphrased): didn't read the draft. What's different from Mobile IPv6 movement detection? JinHyeock Choi: Mobile IPv6 uses three RA's separated by one second to check whether an old router is still available. This takes three seconds. CPL is much faster. someone 4: How long do you need to watch? JinHyeock Choi: look for 2 RA's on a link Pekka Nikander: How may people are willing to read the document and make comments before we recommend the document to the IESG? -- 10 or some more. ==> Accepted as WG doc. ----------------------------------------------- - 20 min DNA hosts bcp draft, with discussion Sathya Narayanan draft-narayanan-dna-hosts-bcp-00.txt ----------------------------------------------- issues presented Question (from author): The draft makes the assumption that a mobile node, when it returns to a previous link within the DAD complete time, it may claim the previous IP address by sending a NA. Is this alright? (Discussion delegated to the mailing list.) Pekka Nikander: We are chartered to produce a document that describes what you can do with the current protocols. In Washington, we decided that we would do two documents -- what you can do as a host, and what you can do as a router. The question is whether this draft can be used as a starting point for a WG document ? How many people would be willing to review the document? -- 5 people. ==> Enough, but we will need all of these five. (Adopted) ------------------------------------------------ - 20 min DNA routers bcp draft, with discussion Sathya Narayanan draft-narayanan-dna-routers-bcp-00.txt ------------------------------------------------ issues presented. Pekka Nikander: we are chartered to create a bcp on what to do with existing protocols. How many are interested in on working on this? about 4 hands, so we will work on this. - 5 min dt update Brett Pentland draft-dnadt-dna-discussion-00.txt The design team consists of JinHyeock Choi, Tero Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark, and Brett Pentland. Now its time to think whether there is something that we forgot and that needs to be put into the design draft. Comment from the audience: I think that the assumptions that routers on the same link can hear each other is valid. Brett Pentland: That's probably one thing that needs to be further discussed. Two basic problems - checking for a link change - getting the RA fast First can be achieved by means of a link ID that is put into RA's. Second could be Fast Router Discovery. Design team has produced a discusssion document that talks about the advantages and disadvantages of different approaches. And we still need more discussion on everthing. Someone: doesn't think that routers on a link can hear each other is not a good assumption. Someone: question if one solution is reasonable. ans: design team said that this is a possibility, but just a suggestion. JinHyeock Choi: clarify the concept link in document. Question to the audience: Where to go? Pekka Nikander: Defer all technical questions to Thursday. If you have a non-technical questions, go ahead. ------------------------------------------------------------ 8. Conclusion Chairs ------------------------------------------------------------ Thursday's session will focus on draft-dnadt-dna-discussion-00. Folks are hence encouraged to read the document and discuss it with design team members. The design team has identified a large number of options, and the goal is to eliminate some of these options. It would be good if you read the design-team document critically and make comments, so that we can eliminate some of the current options. ============================================================ DNA Working Group Meeting March 7, 2005, 15:30pm to 17:30pm IETF 62, Minneapolis ============================================================ CHAIRS: Greg Daley Pekka Nikander Minute Takers: Pekka Niknder (??) Topic DNA discussion 05-03-10 Presentation by Bret Pettland Clarifying questions: X: Are you assuming every router can hear Shared media like Ethernet There are other cases, such as access routers connected through ppp or similar to an access point. JinHyeock Choi: We are assuming any two access routers in the same link can hear each other X: This link definition is different from what I know Brett: Equivalent to Broadcast domains. Multicast should be received by all nodes including routers. X: There is this assumption? Brett Pentland: Yes Erik Nordmark: Assumption is that if somebody sends a packet to the all hosts multicast address then all nodes in the link will receive it. If you think of IPv4 you would call it subnet. In IPv6 you call it link. If for somereason people do link partition. Brett Pentland: definition in 2461 X: The access routers connected to the same access point switch point-to-point connection. These form a subnet. But the access routers don't hear each other. Erik Nordmark: Then you have two links that happen to share the same access points. Must be differentiated by the link layer or otherwise it doesn't work. You articifically partition it. There are choices when you want to have two separate link but you have to carry it out with VLAN tags or SSID or whatever you want it to be. Weeding out discussion X: basestation includes a beacon. Isn't it sufficient? Brett Pentland: If it is viable, maybe? JinHyeock Choi: Link identifier is not SSID. Greg Daley: Beacon's don't have enough information to identify links Potential security holes in Explicit link ID? Someone could explicitly block. Brett Pentland: A rogue node could come along and change the link ID. Greg Daley: Yes. Brett Pentland: Vulnerabilities in all if you are not using SEND. Must be considered. Erik Nordmark: These has been discussed in the design team extensively but not written down, may make it hard for outsiders to understand better. Greg Daley: Implemented two of the ideas: probabilistic and hash ordered RA. There is some experience within the working group Vijay Devarapalli: Nice to have implementation experience. Get feedback from MIPv6 working group. Brett Pentland: Get written down. Erik Nordmark: Get feedback from Ipv6 working group. Understand the combinations hard? Vijay Devarapalli: 12 combinations is too many to give feedback. James Kempf: Make JinHyeock's draft (fast ra discovery) WG informational. Proposal to 802.21, we can't really do it in the IETF. Lots of issues with different link layers. Reduce the number of proposals at the WG. Suresh Krishnan: Missing? Brett Pentland: Collect the set of prefixes? Erik Nordmark: You need to have a link detection mechanism and a fast advertisement things Suresh Krishnan: Some are not really combinaritorical Only 8 combinations, leave fast RA out. Sathya Narayanan: Landmark is an option. Do you want. Only 6 independent combinations Whether you add something on RA on RS. Orthogonal. Benefits from both RA and RS side. If you do that you are down to three. Suresh Krishnan: Not that many combinations. We can decide. Greg Daley: Helpful if I posted code? Charlie Chef, Motorola: Tremendous disconnection between 802.21 and DNA. Very marchy handcap here. We assume that there is very little information here. In 802.21 looking for techical solutions, still all individual prosals. 20 some proposed. Not all of them will become supported. Way beyond what we assume here. If we assume even a small fraction of those would tremendously simplify. Coordination. More informed assumptions Greg (chairing): Good comment. .21 will simplify things thing tremendously, if you have got .21 interfaces on the network/host side. Not every device or network will have .21 interfaces. We want to follow it closesly, feed requirements to .21. Very much interested in collaborating. Charlie Perkins: Been involved. Only value if being used. User for .21 is IETF. Greg Daley: At this time it is important what we are actually using. Other groups have other requirements. If we had triggers available, mechanisms for identifying links. Will revisit this, separate document that follows that. Charlie Perkins: Put together here a wish list. Greg Daley: Be careful here. (don't want to tell other SDOs things we don't want) Erik Nordmark: Will .21 carry layer 3 information Greg Daley: James Kempf: Way that .21 works today. No connection between L2 and L3. Maybe some time when .21 is completed it may change. ESS. .21 is not chartered for intra-ESS handovers. John Loughney: DT document rough going. Move things that should be remove to an annex. Provide main body additional information, maybe actual code, experiments. Would be good to see. Greg Daley: My experiments not done yet. Minor variations to be. Nail down if there are any protocol issues. If we need to specify behavour changes. Greg (next steps): New version of the design team document. Additional information. Next few weeks. Read it again. Might be shorter to read next time. Good idea: 10 hands. Not sufficient? Erik Nordmark: More information about the proposals that don't have indivudal drafts. Make very short drafts of the right side. Example that could be put into the design team document. Vijay Devarapalli: More detailed specs of each one of the ones on plate. Weed out if we don't get them. Plans to experiment some of these. Greg Daley: Would be nice to know soon. Good to have as individual submissions. Vijay Devarapalli: Detailed enough? Greg Daley: Promised to implement afterwards Suresh Krishnan: IPR considerations needed. Greg Daley: Must be careful. (BCP 79 referencing) Erik Nordmark: Rules are there for arhived stuff like RFCs. Greg Daley: Could have a note with an RFC editor note. Brett Pentland: DT document designes basic concepts. More detail needed. Erik Nordmark: Maybe the design team could settle with 2 ways, one ipr one without. A possibility. Sathya Narayanan: Some consensus on one and a little bit of controversy. Erik Nordmark: That doesn't stop the WG from saying that we don't like. James Kempf: Do two documents. Implement. Measure. Have a comparison. JinHyeock Choi: Do something with IPR if clear technical advance. Greg (personal): I will supply test results wrt. main perfomance, delay, packet loss levels. Provide at the mailing list. Greg Daley: Clear way ahead with DT, clear enough to implement. Will remain individual submissions. Sense of room: Useful to record the DT considerations: 10 hands, no: no hands DNA solutions framework: Not to loose the MLD and DAD stuff James Kempf: Probably be BCP? Erik Nordmark: Changes protocol behaviour even though. Greg Daley: Could go to the exiting mile stone. Discuss on the list. JinHyeock Choi: Also applies to solutions? Greg Daley: Solutions will probably refer to the BCPs. Erik Nordmark: Willing to update Greg Daley: Some to move to host BCP? Erik Nordmark: Host BCP stuff that someone wants to implement in one place. Some DNA and other things there. Greg Daley: Update the framework. Text to move to BCP, ask on the mailing list. Don't want to loose the information. Design team considerations: Brett and Sathya will collect. EoM. From dna-owner@webcamserver.eng.monash.edu.au Tue Apr 5 12:04:10 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 MAA03918 for ; Tue, 5 Apr 2005 12:04:10 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMR9B8N1Q293DDFK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 06 Apr 2005 02:03:59 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E57BFAB546; Wed, 06 Apr 2005 02:03:41 +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 8EDC24FB03; Wed, 06 Apr 2005 02:03:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j35G3HH18521 for dna-list; Wed, 06 Apr 2005 02:03:17 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j35G3G618517 for ; Wed, 06 Apr 2005 02:03:16 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMR9ADCTPI8YI1WX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 06 Apr 2005 02:03:00 +1000 Received: by localhost (Postfix, from userid 510) id 255A1AB542; Wed, 06 Apr 2005 02:03:00 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 519F54FB0A for ; Wed, 06 Apr 2005 02:02:58 +1000 (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 j35G2vgW007697 for ; Tue, 05 Apr 2005 12:02:57 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 15EE73C819E for ; Tue, 05 Apr 2005 12:00:19 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id F36713C8173for ; Tue, 05 Apr 2005 12:00:18 -0400 (EDT) Date: Tue, 05 Apr 2005 12:02:54 -0400 From: Sathya Narayanan Subject: [DNA] Host BCP Issue 2: Reachability testing Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <4252B6AE.9020908@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:34.75265 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 Erik & Greg - By reading through the email exchange between you two, I am getting the feeling that there is agreement between you to remove any dependency on reachability testing from the BCP. Is my understanding correct? - Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Apr 5 15:03:52 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 PAA19382 for ; Tue, 5 Apr 2005 15:03:51 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMRFLCD5AC9AMG20@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 06 Apr 2005 05:03:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D459AB543; Wed, 06 Apr 2005 05:03: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 B54DA4FB05; Wed, 06 Apr 2005 05:03:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j35J28t20268 for dna-list; Wed, 06 Apr 2005 05:02:08 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j35J20620264 for ; Wed, 06 Apr 2005 05:02:01 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMRFIZDIBK8YI4E1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 06 Apr 2005 05:01:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72992AB542 for ; Wed, 06 Apr 2005 05:01:44 +1000 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8D55E4FB04 for ; Wed, 06 Apr 2005 05:01:42 +1000 (EST) Received: from [128.9.168.94] (max.isi.edu [128.9.168.94]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j35J0b605597 for ; Tue, 05 Apr 2005 12:00:37 -0700 (PDT) Date: Tue, 05 Apr 2005 12:00:34 -0700 From: Yushun Wang Subject: Re: [DNA] Host BCP Issue 1: Same link vs Link change In-reply-to: <42522B92.80408@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <4252E052.9070204@isi.edu> MIME-version: 1.0 Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms030107020705020602060502 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: yushunwa@isi.edu References: <425183C6.4000102@Research.Panasonic.COM> <92e919fb05040417183997792d@mail.gmail.com> <42522B92.80408@eng.monash.edu.au> This is a cryptographically signed message in MIME format. --------------ms030107020705020602060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Some questions below... <...> >> I agree that DNA should detect link identity EFFICIENTLY, whether >> link change or not. >> >> But I don't think that implies that a host needs to QUICKLY find out >> that it still remains at the same link. >> In case of a link change, it's important for a host to quickly check >> for link change lest there should be service disruption. >> But in case of no link change, I can't think of any harm from a little >> DNA delay. I am not sure I understand the above statement, so here's the dumb question: how does a host know the link has changed or not before finding out if the link has changed or not? I tend to agree with Sathya's suggestion: > FWIW, I think DNA should not differentiate between same-link and > link-change. DNA should define efficient mechanisms (in BCP and Soln.) > for the hosts to quickly identify its current link, whether it be the > same or different link. This is of course from the host's bcp perspective. Regards, yushun -- Yu-Shun Wang http://www.isi.edu/~yushunwa USC Information Sciences Institute --------------ms030107020705020602060502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAw4K/TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTn ssgn3J00Mbb7NiBsaUnnnXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y 6JKoTOHDdLmgWbHy9L5EGUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuU D3yolypb0TKrUFWo8RUz2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421 dOlKsAmlA6gL1NmXw0bC8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY 6m1KAnGJzCz406bbDCxkRuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC 7vomxYXs2NfhoDt/cgado9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxR nPRYY+m+rU4n9bma6bdovN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAxcwggKAoAMCAQICAw4K /TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTnssgn3J00Mbb7NiBsaUnn nXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y6JKoTOHDdLmgWbHy9L5E GUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuUD3yolypb0TKrUFWo8RUz 2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421dOlKsAmlA6gL1NmXw0bC 8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY6m1KAnGJzCz406bbDCxk RuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC7vomxYXs2NfhoDt/cgad o9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxRnPRYY+m+rU4n9bma6bdo vN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID Dgr9MAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MDQwNTE5MDAzNFowIwYJKoZIhvcNAQkEMRYEFDs2S5KZzvGpWEsT41sO8qjx vANqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOCv0wegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDDgr9MA0GCSqGSIb3DQEBAQUABIIBAKPbBhcNGy6ZBywhNwes+hegxD5DSpXwH+jB oCDD6/6ej8FvVBI9TeP8r86n/pS+GM2hIFySq5qUQ20HPnMBXCDAEdLklQl2E+wgqonaWO/K mwzMNtdq7ruzy4Z/sT/8E7e1PB1/nex654998KBHCSty/RW/Q7+FFTVapvZNt1TPECLaWMFG EtdVGpJ3iYH2SQn1VTGDN7ubzCnOr7jCRZSqZdfGSVEG1zIMaDbml1H45jnZUvw9L6a42j5h xHRa+TDPkF7tW2pT3lQ/jHBWwR03cTn5Vzu1rRJCO20/tzkxST+oxhheTmoHz+qshIF1zCNo U+P4VmoTV845uw3mlloAAAAAAAA= --------------ms030107020705020602060502-- From dna-owner@webcamserver.eng.monash.edu.au Thu Apr 7 14:42:13 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 OAA25255 for ; Thu, 7 Apr 2005 14:42:12 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMU7EHRL4K8YIKA5@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Apr 2005 04:41:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 11313AB545; Fri, 08 Apr 2005 04:41:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 243774FB0B; Fri, 08 Apr 2005 04:41:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j37Ic9K11244 for dna-list; Fri, 08 Apr 2005 04:38:09 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j37Ic2611240 for ; Fri, 08 Apr 2005 04:38:02 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMU7A3DL608YIHWX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Apr 2005 04:37:53 +1000 Received: by localhost (Postfix, from userid 510) id 58889AB542; Fri, 08 Apr 2005 04:37:53 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7C9864FB03 for ; Fri, 08 Apr 2005 04:37:51 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j37IbmJx017876; Thu, 07 Apr 2005 11:37:49 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j37Ibh1Z922214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 07 Apr 2005 11:37:46 -0700 (PDT) Date: Thu, 07 Apr 2005 11:37:29 -0700 From: Erik Nordmark Subject: Re: [DNA] Host BCP Issue 2: Reachability testing In-reply-to: <4252B6AE.9020908@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <42557DE9.5090107@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: <4252B6AE.9020908@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Erik & Greg - > > By reading through the email exchange between you two, I am getting the > feeling that there is agreement between you to remove any dependency on > reachability testing from the BCP. Is my understanding correct? That's what I would like to see. Don't know about Greg. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Apr 8 00:11: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 AAA09912 for ; Fri, 8 Apr 2005 00:11:57 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMURAKDI408YHOV7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Apr 2005 14:11:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC9E2AB544; Fri, 08 Apr 2005 14:10:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 72C934FB08; Fri, 08 Apr 2005 14:10:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j384AOk15819 for dna-list; Fri, 08 Apr 2005 14:10:24 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j384AN615815 for ; Fri, 08 Apr 2005 14:10:23 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMUR9UGFSI8YIAZM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Apr 2005 14:10:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 03D2D80002; Fri, 08 Apr 2005 14:10:21 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 90C6B3C008; Fri, 08 Apr 2005 14:10:20 +1000 (EST) Date: Fri, 08 Apr 2005 14:10:20 +1000 From: Greg Daley Subject: Re: [DNA] Host BCP Issue 2: Reachability testing In-reply-to: <42557DE9.5090107@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Sathya Narayanan , Dna Reply-to: greg.daley@eng.monash.edu.au Message-id: <4256042C.2030809@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: <4252B6AE.9020908@Research.Panasonic.COM> <42557DE9.5090107@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Sathya Narayanan wrote: > >> Erik & Greg - >> >> By reading through the email exchange between you two, I am getting >> the feeling that there is agreement between you to remove any >> dependency on reachability testing from the BCP. Is my understanding >> correct? > > > That's what I would like to see. Don't know about Greg. Let's see if things look complete like that. A couple of words describing that ND handles this or a caveat about bad links may be sufficient. Does that sound OK? Greg > Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Apr 8 02:59:52 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 CAA11357 for ; Fri, 8 Apr 2005 02:59:51 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LMUX6M0FAA99DW6X@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 08 Apr 2005 16:59:35 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 692E6AB543; Fri, 08 Apr 2005 16:59:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1BD9F4FB08; Fri, 08 Apr 2005 16:59:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j386x0W17310 for dna-list; Fri, 08 Apr 2005 16:59:00 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id j386wx617306 for ; Fri, 08 Apr 2005 16:59:00 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMUX5IVNLE8YI6PT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 08 Apr 2005 16:58:40 +1000 Received: by localhost (Postfix, from userid 510) id D396880003; Fri, 08 Apr 2005 16:58:39 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id CFEEB3C00C; Fri, 08 Apr 2005 16:58:37 +1000 (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 j386wZrO029007; Thu, 07 Apr 2005 23:58:35 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j386wY3N403998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 07 Apr 2005 23:58:35 -0700 (PDT) Date: Thu, 07 Apr 2005 23:58:18 -0700 From: Erik Nordmark Subject: Re: [DNA] Host BCP Issue 2: Reachability testing In-reply-to: <4256042C.2030809@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: Sathya Narayanan , Dna Message-id: <42562B8A.5070603@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: <4252B6AE.9020908@Research.Panasonic.COM> <42557DE9.5090107@sun.com> <4256042C.2030809@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Let's see if things look complete like that. > > A couple of words describing that ND handles this > or a caveat about bad links may be sufficient. > > Does that sound OK? works for me Erik