From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 00:47:32 2004 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 AAA10329 for ; Mon, 1 Nov 2004 00:47:31 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQ6O3G3KS8ZI05C@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Nov 2004 16:46:10 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 996C680008; Mon, 01 Nov 2004 16:45:52 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 22BFA3C003; Mon, 01 Nov 2004 16:45:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA15jc913665 for dna-list; Mon, 01 Nov 2004 16:45:38 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA15jc613661 for ; Mon, 01 Nov 2004 16:45:38 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQ6NFUSR68X1CDH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Nov 2004 16:45:21 +1100 Received: by localhost (Postfix, from userid 510) id 14AC280008; Mon, 01 Nov 2004 16:45:21 +1100 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 66AC53C003 for ; Mon, 01 Nov 2004 16:45:19 +1100 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1COV0G-000GeM-9F; Mon, 01 Nov 2004 00:45:16 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA15jE626327; Sun, 31 Oct 2004 21:45:14 -0800 Date: Sun, 31 Oct 2004 21:45:14 -0800 (PST) From: Bernard Aboba Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT > There may be some problems related to link layer addresses, etc, > but someone should really point us to the right documents, or better, > write a problem statement draft of the situation, trying to clarify > the current plans of running IPv6 over make-before-break CDMA (and > other such radio links). I don't see much use to argue about this > until we properly understand the details, and at least I can't > possibly claim understanding them. I don't even know what documents > I should read; sorry about my ignorance. I must admit that I am also finding this conversation hard to follow. As noted in Multi-Net (see http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm) it is quite possible for a single radio and single MAC address to be used to construct multiple virtual interfaces, each connected to a distinct network. In this case, DNA would be run on each virtual interface, with no interactions between them. It is also possible for a single radio to be used to construct multiple virtual interfaces, each connected to the same network, as long as distinct MAC addresses are used on each virtual interface. Again, in this case, DNA would be run on each virtual interface with no interactions between them. DNA is fundamentally about optimizing the problem of address assignment. This is quite distinct from the problem of determining the outgoing or incoming interface for packets, which is a routing problem. Where the host is multi-homed, routing behavior is determined by whether the host implements the strong or weak end-system model, the state of the routing table, the state of Mobile IP (if present) and the dictates of the application. The link layer influences this behavior primarily through its influence on the routing table. Through constructs such as dial-on-demand or idle timeout, and link-aware routing, it is possible for the state of one interface to influence whether packets are routed out another interface. And of course, link indications such as "Link Down" can result in removal of routes, and "Link Up" can result in insertion of routes. Yet none of these phenomena introduce the need for link layers to interace with respect to DNA. Or is there something I'm missing? From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 01:00:45 2004 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 BAA10903 for ; Mon, 1 Nov 2004 01:00:44 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQ71NTY2O8ZEXXE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 1 Nov 2004 16:56:57 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CDE2EAB55B; Mon, 01 Nov 2004 16:56:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 66A1D4FB06; Mon, 01 Nov 2004 16:56:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA15uT713808 for dna-list; Mon, 01 Nov 2004 16:56:29 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA15uR613804 for ; Mon, 01 Nov 2004 16:56:27 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQ70R5T228ZEXXA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 01 Nov 2004 16:56:07 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DD357AB545; Mon, 01 Nov 2004 16:56:04 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 982CC4FB0C; Mon, 01 Nov 2004 16:56:04 +1100 (EST) Date: Mon, 01 Nov 2004 16:56:04 +1100 From: Greg Daley Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna , JinHyeock Choi , YGHONG , ??? , JinHyeock Choi , JinHyeock Choi , ??? Reply-to: greg.daley@eng.monash.edu.au Message-id: <4185CFF4.2000409@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Hi Pekka, Pekka Nikander wrote: >>> Purely DNA point of view, it would be better if CDMA doesn't support >>> 'make-before-break' at all. It would make DNA much simpler. >> >> >> I know this was a throw-away line, but it's hard to throw away. >> >> I think that MBB will have to be supported, in DNA. This is especially >> the case where Unreachability is to be determined from certain tests. >> >> We mainly need to be clear about which tests are applicable and >> what inference is taken from received messages. I think this >> is still in coverage for the BCP and Goals though. > > > I have to admit that I am totally confused now. Maybe I just > don't know the facts. So, let me ask some stupid questions: > > 1. Are people planning to use make-before-break with CDMA > with PPP or not? Or both? (If PPP is used, I see no > problem wrt. DNA as PPP is then the link layer to IPv6, > and the situation has to be handled below the IPv6 layer.) Indeed, PPP simplifies things. Most cases we'll be looking at situations with PPP in CDMA. > 2. Assuming no PPP is used, are there any actual plans of > supporting make-before-break between networks that actually > have different IPv6 configuration at different base stations? > (If not, again, I don't see what we have to worry about.) From my understanding, Flarion's wireless technology supports Make-before break and has a multicast capable MAC. I believe that these (and other?) technologies are contributing to 802.20. The Flarion white-papers though, describe a combined base-station/router. This simplifies DNA configuration change testing. I'm not sure about 802.20, it looks like this is a MAC/PHY group, so it's conceivable that networks may be bridged to 802.20 in the future. > 3. Assuming no PPP is used and make-before-break is supported > between base stations that potentially have different > network configuration, is there any reason why the link > layer cannot model the situation as two different interfaces? At the moment, I can't see why not. It significantly simplifies neighbour resolution, for the case where the wired network is bridged behind pairs of base-stations. > That is, even in the case that the CDMA link layer does not use > PPP but is directly visible to IPv6, if we can model the radio > layer connections to different base stations as different interfaces, > as seen by IPv6, I don't see any problem. The worst that can there > happen is that the two interfaces, corresponding to the two radio > layer connections, are connected to the same IPv6 network. But that > is a case that we have to handle otherwise, too. > > There may be some problems related to link layer addresses, etc, > but someone should really point us to the right documents, or better, > write a problem statement draft of the situation, trying to clarify > the current plans of running IPv6 over make-before-break CDMA (and > other such radio links). I don't see much use to argue about this > until we properly understand the details, and at least I can't > possibly claim understanding them. I don't even know what documents > I should read; sorry about my ignorance. I don't believe there's any ignorance in the matter, but there are MBB technologies which are multi-access and have different L3 configurations under trial. The only issue when using different interfaces is that DNA is likely to be done per-interface, and it may not be possible to get reliable link-down indications on the 'about to break' interface, even if it's possible to get link-ups on the 'just made' interface. Sorry to cause consternation by not thinking through and clarifying statements. The problem statement draft is a good idea. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 02:04:31 2004 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 CAA17767 for ; Mon, 1 Nov 2004 02:04:29 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQ9DS9PYC8ZEHRO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 1 Nov 2004 18:03:57 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DEE4BAB557; Mon, 01 Nov 2004 18:03:50 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 758954FB10; Mon, 01 Nov 2004 18:03:50 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA173LD14528 for dna-list; Mon, 01 Nov 2004 18:03:21 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA173K614524 for ; Mon, 01 Nov 2004 18:03:20 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQ9D06W9W8X8TK5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 01 Nov 2004 18:03:15 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AB306AB555; Mon, 01 Nov 2004 18:03:13 +1100 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 8B5B24FB0B; Mon, 01 Nov 2004 18:03:13 +1100 (EST) Date: Mon, 01 Nov 2004 18:03:13 +1100 From: Brett Pentland Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Pekka Nikander , Dna Message-id: <4185DFB1.3080602@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > It is also possible for a single radio to be used to construct multiple > virtual interfaces, each connected to the same network, as long as > distinct MAC addresses are used on each virtual interface. Again, in this > case, DNA would be run on each virtual interface with no interactions > between them. > > DNA is fundamentally about optimizing the problem of address assignment. > This is quite distinct from the problem of determining the outgoing or > incoming interface for packets, which is a routing problem. I agree, assuming I'm understanding the point correctly. DNA is about detecting, for a given link, which link that is and obtaining an address that can be used on that link. It's another process to decide whether or not to use that link for, say, a default router. Say a host is connected both a fixed Etherenet (eth0) and a wireless LAN (wlan0). DNA might tell the host that wlan0 has just connected to a new network, and that it can use address X on that network, but it's active connection on eth0, which is where it's default router currently is, is unaffected and so it shouldn't change anything. I think that the decision to not change default router (or to change to one on wlan0 if DNA on eth0 indicates that it has just gone down), is not really part of DNA. Perhaps it should be? I'm not sure. Any thoughts? Brett. PS. I realise that I've diverted from the discussion of make-before-break interfaces, but if the virtual interface abstraction can be made then I think this all still applies. This would be a very useful abstraction too, because if an interface can be connected to two links simultaneously, then it difficult to say what DNA for that interface should pass to the routing decision making component. From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 02:53:43 2004 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 CAA02982 for ; Mon, 1 Nov 2004 02:53:41 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQB0CPHX08X8NBG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 1 Nov 2004 18:51:00 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 652E1AB545; Mon, 01 Nov 2004 18:50:15 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 13D0B4FB06; Mon, 01 Nov 2004 18:50:15 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA17o3515162 for dna-list; Mon, 01 Nov 2004 18:50:03 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA17o3615158 for ; Mon, 01 Nov 2004 18:50:03 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQAZVU0PG8X8QVH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 01 Nov 2004 18:49:55 +1100 Received: by localhost (Postfix, from userid 510) id DDEBDAB555; Mon, 01 Nov 2004 18:49:54 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 20DED4FB11; Mon, 01 Nov 2004 18:49:53 +1100 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6H00701PPC7O@mailout3.samsung.com>; Mon, 01 Nov 2004 16:48:48 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6H00ILGPPBVR@mailout3.samsung.com>; Mon, 01 Nov 2004 16:48:48 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6H00LG5PPBT6@mmp2.samsung.com>; Mon, 01 Nov 2004 16:48:47 +0900 (KST) Date: Mon, 01 Nov 2004 16:48:47 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Dna Cc: YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: <018c01c4bfe7$384e9080$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear Pekka > I have to admit that I am totally confused now. Maybe I just > don't know the facts. So, let me ask some stupid questions: > > 1. Are people planning to use make-before-break with CDMA > with PPP or not? Or both? (If PPP is used, I see no > problem wrt. DNA as PPP is then the link layer to IPv6, > and the situation has to be handled below the IPv6 layer.) I don't know about the plan but your point looks reasonable. > 2. Assuming no PPP is used, are there any actual plans of > supporting make-before-break between networks that actually > have different IPv6 configuration at different base stations? > (If not, again, I don't see what we have to worry about.) As Greg wrote, Flarion wireless technology, Flash OFDM, can support make-before-break. Right now they are contemplating only v4 but, I'd like DNA schemes be future proof. > 3. Assuming no PPP is used and make-before-break is supported > between base stations that potentially have different > network configuration, is there any reason why the link > layer cannot model the situation as two different interfaces? It seems that the link-layer can do that but we need to check it out. > That is, even in the case that the CDMA link layer does not use > PPP but is directly visible to IPv6, if we can model the radio > layer connections to different base stations as different interfaces, > as seen by IPv6, I don't see any problem. The worst that can there > happen is that the two interfaces, corresponding to the two radio > layer connections, are connected to the same IPv6 network. But that > is a case that we have to handle otherwise, too. I guess that 'two interface approach' will handle the situation. However, I think we need to sort out a few the operational details. For example, if we model two link-layer connection as two (virtual) interfaces, shall we assign the same link-layer address to two interfaces? That may bring forth trouble if it happens that two link-layer connections belong to the same link. Though, right now, no problem seems insurmountable but we'd better think it over. > There may be some problems related to link layer addresses, etc, > but someone should really point us to the right documents, or better, > write a problem statement draft of the situation, trying to clarify > the current plans of running IPv6 over make-before-break CDMA (and > other such radio links). It would be nice. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 03:14:56 2004 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 DAA01059 for ; Mon, 1 Nov 2004 03:14:54 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQBTA0M6O8ZEX0C@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 1 Nov 2004 19:13:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C7BD4AB555; Mon, 01 Nov 2004 19:13:36 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 737084FB0A; Mon, 01 Nov 2004 19:13:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA18DFg15451 for dna-list; Mon, 01 Nov 2004 19:13:15 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA18DD615447 for ; Mon, 01 Nov 2004 19:13:13 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQBSPYDBG8ZEX0C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 01 Nov 2004 19:13:10 +1100 Received: by localhost (Postfix, from userid 510) id DFF0FAB544; Mon, 01 Nov 2004 19:13:09 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2DBD84FB02; Mon, 01 Nov 2004 19:13:08 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id C4025220005; Mon, 01 Nov 2004 10:13:00 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 840768; Mon, 01 Nov 2004 10:13:01 +0200 (EET) Date: Mon, 01 Nov 2004 10:13:01 +0200 From: Pekka Nikander Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <018c01c4bfe7$384e9080$eb5b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Dna , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> <018c01c4bfe7$384e9080$eb5b024b@jinchoe> Content-Transfer-Encoding: 7BIT >> That is, even in the case that the CDMA link layer does not use >> PPP but is directly visible to IPv6, if we can model the radio >> layer connections to different base stations as different interfaces, >> as seen by IPv6, I don't see any problem. The worst that can there >> happen is that the two interfaces, corresponding to the two radio >> layer connections, are connected to the same IPv6 network. But that >> is a case that we have to handle otherwise, too. > > I guess that 'two interface approach' will handle the situation. > > However, I think we need to sort out a few the operational details. > > For example, if we model two link-layer connection as two (virtual) > interfaces, > shall we assign the same link-layer address to two interfaces? That is a good question, but strictly speaking it is outside the scope of the DNA WG. I'm not saying we can't discuss it here, but if the discussion diverted too much from DNA, it would be better to move the discussion elsewhere. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 03:17:34 2004 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 DAA01430 for ; Mon, 1 Nov 2004 03:17:33 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQBWEA1GG8X27PL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Nov 2004 19:16:19 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5D38580006; Mon, 01 Nov 2004 19:16:07 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 02CD03C00B; Mon, 01 Nov 2004 19:16:07 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA18G4J15520 for dna-list; Mon, 01 Nov 2004 19:16:04 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA18G4615516 for ; Mon, 01 Nov 2004 19:16:04 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGQBW1ZDSO8ZEX0C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 01 Nov 2004 19:15:51 +1100 Received: by localhost (Postfix, from userid 510) id 29875AB542; Mon, 01 Nov 2004 19:15:51 +1100 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7CE804FB09; Mon, 01 Nov 2004 19:15:49 +1100 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6H00L0DQWJ7Q@mailout1.samsung.com>; Mon, 01 Nov 2004 17:14:43 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6H00BD9QWFFO@mailout1.samsung.com>; Mon, 01 Nov 2004 17:14:40 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6H000HDQWFQH@mmp2.samsung.com>; Mon, 01 Nov 2004 17:14:39 +0900 (KST) Date: Mon, 01 Nov 2004 17:14:39 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Bernard Aboba Cc: Pekka Nikander , Dna Message-id: <021201c4bfea$d574a360$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> <4185DFB1.3080602@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett > > It is also possible for a single radio to be used to construct multiple > > virtual interfaces, each connected to the same network, as long as > > distinct MAC addresses are used on each virtual interface. Again, in this > > case, DNA would be run on each virtual interface with no interactions > > between them. > > > > DNA is fundamentally about optimizing the problem of address assignment. > > This is quite distinct from the problem of determining the outgoing or > > incoming interface for packets, which is a routing problem. > > > I agree, assuming I'm understanding the point correctly. DNA is about > detecting, for a given link, which link that is and obtaining an address > that can be used on that link. I need to point that obtaining an address is outside of DNA scope. It's DNA job to determine that a host need a new address. However, it's not DNA job to actually obtain a new address. We ruled out DAD optimization while DNA chartering. > It's another process to decide whether > or not to use that link for, say, a default router. Agree. > Say a host is connected both a fixed Etherenet (eth0) and a wireless LAN > (wlan0). DNA might tell the host that wlan0 has just connected to a new > network, and that it can use address X on that network, but it's active > connection on eth0, which is where it's default router currently is, is > unaffected and so it shouldn't change anything. ok except that DNA presenting a new valid address. However, DNA may present a valid prefix to form a new address. > I think that the decision to not change default router (or to change to > one on wlan0 if DNA on eth0 indicates that it has just gone down), is > not really part of DNA. Perhaps it should be? I'm not sure. Any > thoughts? Agree. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 03:32:41 2004 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 DAA03094 for ; Mon, 1 Nov 2004 03:32:40 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQCGEO9Y68X230X@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Nov 2004 19:31:40 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BADFBAB554; Mon, 01 Nov 2004 19:31:28 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6F3F34FB0D; Mon, 01 Nov 2004 19:31:28 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA18VHi15864 for dna-list; Mon, 01 Nov 2004 19:31:17 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA18VH615860 for ; Mon, 01 Nov 2004 19:31:17 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQCFSYQGK8ZI9NU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Nov 2004 19:30:59 +1100 Received: by localhost (Postfix, from userid 510) id ABF24AB542; Mon, 01 Nov 2004 19:30:59 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1E2974FB07; Mon, 01 Nov 2004 19:30:58 +1100 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6H00E2NRM3A4@mailout3.samsung.com>; Mon, 01 Nov 2004 17:30:03 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6H008DQRKQDD@mailout3.samsung.com>; Mon, 01 Nov 2004 17:29:14 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6H00G2ORKQRH@mmp2.samsung.com>; Mon, 01 Nov 2004 17:29:14 +0900 (KST) Date: Mon, 01 Nov 2004 17:29:14 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: <025201c4bfec$deb557b0$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> <018c01c4bfe7$384e9080$eb5b024b@jinchoe> Content-Transfer-Encoding: 7BIT > > I guess that 'two interface approach' will handle the situation. > > > > However, I think we need to sort out a few the operational details. > > > > For example, if we model two link-layer connection as two (virtual) > > interfaces, > > shall we assign the same link-layer address to two interfaces? > > That is a good question, but strictly speaking it is outside > the scope of the DNA WG. I'm not saying we can't discuss it here, > but if the discussion diverted too much from DNA, it would be > better to move the discussion elsewhere. Strictly speaking No. This may be under RFC 2461 revision, 'how to run IPv6 over make-before-break technologies'. Also I don't want too much diversion here but, at least, we need to contemplate how this would affect DNA schemes. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 1 18:39:12 2004 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 SAA21292 for ; Mon, 1 Nov 2004 18:39:11 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGR82NROI28X8KIS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 2 Nov 2004 10:36:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 50421AB557; Tue, 02 Nov 2004 10:36:39 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 087084FB05; Tue, 02 Nov 2004 10:36:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA1NZUn26723 for dna-list; Tue, 02 Nov 2004 10:35:30 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA1NZS626719 for ; Tue, 02 Nov 2004 10:35:28 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGR813A20K8ZID13@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 02 Nov 2004 10:35:24 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A39FAB542; Tue, 02 Nov 2004 10:35:23 +1100 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 497954FB0A; Tue, 02 Nov 2004 10:35:23 +1100 (EST) Date: Tue, 02 Nov 2004 10:35:22 +1100 From: Brett Pentland Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <021201c4bfea$d574a360$eb5b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Bernard Aboba , Pekka Nikander , Dna Message-id: <4186C83A.6060800@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> <4185DFB1.3080602@eng.monash.edu.au> <021201c4bfea$d574a360$eb5b024b@jinchoe> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > I need to point that obtaining an address is outside of DNA scope. > It's DNA job to determine that a host need a new address. > However, it's not DNA job to actually obtain a new address. > We ruled out DAD optimization while DNA chartering. > > >>Say a host is connected both a fixed Etherenet (eth0) and a wireless LAN >>(wlan0). DNA might tell the host that wlan0 has just connected to a new >>network, and that it can use address X on that network, but it's active >>connection on eth0, which is where it's default router currently is, is >>unaffected and so it shouldn't change anything. > > > ok except that DNA presenting a new valid address. However, DNA > may present a valid prefix to form a new address. > Yes, you are correct. I should have said the DNA could tell the host a prefix X on that network from which an address can be formed (and yes, testing for uniqueness is outside of DNA). Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 2 10:32:29 2004 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 KAA01274 for ; Tue, 2 Nov 2004 10:32:28 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGS5EFSC0Y8X2JQR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 03 Nov 2004 02:31:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0927BAB555; Wed, 03 Nov 2004 02:31:26 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B1F924FB09; Wed, 03 Nov 2004 02:31:25 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA2FU6J06040 for dna-list; Wed, 03 Nov 2004 02:30:06 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA2FU5606036 for ; Wed, 03 Nov 2004 02:30:05 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGS5CN903S8X8YRX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 03 Nov 2004 02:29:59 +1100 Received: by localhost (Postfix, from userid 510) id 798D880002; Wed, 03 Nov 2004 02:29:59 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5062D3C00A for ; Wed, 03 Nov 2004 02:29:57 +1100 (EST) Received: by rproxy.gmail.com with SMTP id 75so292253rnk for ; Tue, 02 Nov 2004 07:29:56 -0800 (PST) Received: by 10.38.72.20 with SMTP id u20mr1534615rna; Tue, 02 Nov 2004 07:29:56 -0800 (PST) Received: by 10.38.125.23 with HTTP; Tue, 02 Nov 2004 07:29:56 -0800 (PST) Date: Wed, 03 Nov 2004 00:29:56 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA BCP Submission In-reply-to: <416E9819.1020705@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0411020729543f090a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=AWn3xEqm0TCc/ZOrUxqfoN9nz6kbPsAvy9RGrN6wwComv6sN0Daw3AEpwu6XBnzDhkxByLl/Z1muNnRbxpv11IzKdeZOC0+k3ko637MgRSSeBPsi+CKUccV0h/h6aWtS5buDXLJtZpVoOWKbBTA+xe57qTnSNJShFtCKH/3564A= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <416E9819.1020705@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya I looked through the BCP draft and here are my comments. First, about DNA definition, there seems a difference between goals & BCP drafts. in BCP Abstract, you wrote "Detecting Network Attachment is a set of strategies for determining configuration validity in wireless or rapidly changing environments." whereas goals draft said "The process by which a host collects the appropriate information and detects the identity of its currently attached link to ascertains the validity of its IP configuration, is called Detecting Network Attachment (DNA)." In goals, DNA is supposed to detect the identity of currently attached link to verify all the configuration at a stroke. In BCP draft, DNA is supposed to verify configurations one by one. I don't think it's wise to confuse what DNA is supposed to accomplish as above. Second, if you recommend DNA to verify configuraitons separately, instead of link identity detection, I would like you to clearly pinpoint what configurations DNA is supposed to verify. In DNA point of view, IMO, it seems to sufficient to verify 1) (paritical) reachability of existing default routers 2) validity of exisitng IP addresses If you think that DNA needs to verify other configurations, clearly enumerate them. Then we can discuss about them. Right now, it's difficult for me to grasp what configurations you suggest DNA would verify. For example, I can't see why DNA needs to keen about reachability confirmation. I agree that Reachability confirmaiton is crucial for Internet connectivity but so does DAD, which we decided to rule out from DNA. Third, it would be helpful if you present why, right now, it's difficult to verify a specific configuration and how we can overcome the difficulties. For example, to verify the (partial) reachability of existing default routers, two difficulties come into my mind. 1) How to confirm (partial) reachability with link-local address Because router address is link-local scope, a host can't be sure that it's default router is still (partially) reachable, even if a reply from the same link-local address arrives. 2) How to quickly detects unreachability It will take substantial time to detect something is not there. NUD will take 3 secs but BCP draft just says that it may be better to reduce the number of NS/ NA exchange as belows. " However, if the host has indication that the link may have changed, this delay may be reduced without significant damage for the network by reducing the number of retries." Moreover, if we reduce the number to one, it still will take 1 sec. If you present how we can solve the above two under RFC 2461, it would be of help. Overall I would like the draft be more focused & organized. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 2 12:08:16 2004 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 MAA12718 for ; Tue, 2 Nov 2004 12:08:14 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGS8MHHOB28ZEZBP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 3 Nov 2004 04:03:29 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BF0F28000D; Wed, 03 Nov 2004 04:03:25 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 74A603C004; Wed, 03 Nov 2004 04:03:25 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA2H2xb07267 for dna-list; Wed, 03 Nov 2004 04:02:59 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA2H2v607263 for ; Wed, 03 Nov 2004 04:02:57 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGS8LL46RA8X2LZD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 03 Nov 2004 04:02:42 +1100 Received: by localhost (Postfix, from userid 510) id 610F68002D; Wed, 03 Nov 2004 04:02:31 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id C17E23C008 for ; Wed, 03 Nov 2004 04:02:28 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA2H2R5I030271; Tue, 02 Nov 2004 12:02:27 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D55E43C80E2; Tue, 02 Nov 2004 12:00:32 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id C56EB3C80E1; Tue, 02 Nov 2004 12:00:32 -0500 (EST) Date: Tue, 02 Nov 2004 12:02:11 -0500 From: Sathya Narayanan Subject: Re: [DNA] DNA BCP Submission In-reply-to: <92e919fb0411020729543f090a@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <4187BD93.70505@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 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.0-rc2 (2004-08-15) References: <416E9819.1020705@Research.Panasonic.COM> <92e919fb0411020729543f090a@mail.gmail.com> Content-Transfer-Encoding: 7BIT Dear JinHyeock - Thanks for your comment. Please find my responses inline. >First, about DNA definition, there seems a difference >between goals & BCP drafts. > >in BCP Abstract, you wrote > >"Detecting Network Attachment is a set of strategies for >determining configuration validity in wireless or rapidly changing >environments." > >whereas goals draft said > >"The process by which a host collects the appropriate information and >detects the identity of its currently attached link to ascertains the >validity of its IP configuration, is called Detecting Network >Attachment (DNA)." > >In goals, DNA is supposed to detect the identity of currently attached >link to verify all the configuration at a stroke. In BCP draft, DNA is >supposed to verify configurations one by one. > > I understand, we will change the definition part to match with goals draft. But, this also brings up the question that was raised before - should the BCP be restricted in scope by the goals document. I don't think so. So, in the abstract we will include something like " This document details best current practice for using Neighbor Discovery procedures to Detect Network Attachment in IPv6 hosts and other supporting procedure to verify relevant configurations". >I don't think it's wise to confuse what DNA is supposed to accomplish >as above. > >Second, if you recommend DNA to verify configuraitons separately, >instead of link identity detection, I would like you to clearly pinpoint >what configurations DNA is supposed to verify. > >In DNA point of view, IMO, it seems to sufficient to verify >1) (paritical) reachability of existing default routers >2) validity of exisitng IP addresses > > We have mentioned these two configurations, in sections 4, 5 & 6 basically focuses on these two verifications as the heart of DNA procedures. >If you think that DNA needs to verify other configurations, clearly >enumerate them. Then we can discuss about them. > >Right now, it's difficult for me to grasp what configurations you >suggest DNA would verify. > > OK - I guess I understand the confusion - Its the title of the section 5 - "Validity of current configurations". From the section description you can see we are only thinking about the current IP address and the current default router address. But, point well taken. We will enumerate them in -02. >For example, I can't see why DNA needs to keen about reachability >confirmation. I agree that Reachability confirmaiton is crucial for >Internet connectivity but so does DAD, which we decided to rule >out from DNA. > > You seem to be contradicting yourself. You mentioned 'reachability of existing default routers' as one of the verifications above. Please clarify. Ofcourse, we don't have to do everything required for Internet connectivity, but I think reachability confiirmation is crucial to DNA - any form of link-identification used for DNA is going to be derived from the default router - so assuming network attachment to be succesful without verifying reachability to the default router doesn't make sense - while I can understand DAD to be a step after network attachment before Internet connectivity becomes active. >Third, it would be helpful if you present why, right now, it's difficult >to verify a specific configuration and how we can overcome the >difficulties. > >For example, to verify the (partial) reachability of existing default >routers, two difficulties come into my mind. > >1) How to confirm (partial) reachability with link-local address >Because router address is link-local scope, a host can't be >sure that it's default router is still (partially) reachable, even if >a reply from the same link-local address arrives. > >2) How to quickly detects unreachability >It will take substantial time to detect something is not there. >NUD will take 3 secs but BCP draft just says that it may be >better to reduce the number of NS/ NA exchange as belows. > >" However, if the host has indication that the link may >have changed, this delay may be reduced without significant damage >for the network by reducing the number of retries." > >Moreover, if we reduce the number to one, it still will take 1 sec. > >If you present how we can solve the above two under RFC 2461, it >would be of help. > > I would like to talk with you about these two comments - lets discuss this at IETF61. >Overall I would like the draft be more focused & organized. > > Two parallel responses: 1) The way we look at the draft right now is - upto section 6 is focused DNA BCP - with some additional information in section 5 and 6 - from section 7 to 11 are additional information for some specific topics/issues - and section 12 is the security considerations. We do believe the text in there right now is all needed in the BCP. 2) If you could be more specific it will be very useful. We went through couple of iterations re-organizing the draft and removing some text since -00. If you could point to sections which you think are redundant or out-of-focus, or, if you could suggest some form of re-orgnaization, it will be great. Once again, thanks for your comments. with regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 2 12:43:12 2004 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 MAA16333 for ; Tue, 2 Nov 2004 12:43:11 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGSA03EPGQ8ZIKUC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 03 Nov 2004 04:42:55 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7629C80003; Wed, 03 Nov 2004 04:42:38 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C94FD3C002; Wed, 03 Nov 2004 04:42:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA2HgDT07825 for dna-list; Wed, 03 Nov 2004 04:42:13 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA2HgA607814 for ; Wed, 03 Nov 2004 04:42:10 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGS9Y910RM8X91EO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 03 Nov 2004 04:41:56 +1100 Received: by localhost (Postfix, from userid 510) id 7D7BE80003; Wed, 03 Nov 2004 04:41:56 +1100 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by larry.its.monash.edu.au (Postfix) with ESMTP id CB09F3C008 for ; Wed, 03 Nov 2004 04:41:53 +1100 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 02 Nov 2004 18:41:50 +0100 Date: Tue, 02 Nov 2004 18:41:48 +0100 From: NJEDJOU Eric RD-RESA-REN Subject: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: DNA link hints document Thread-Index: AcS/4UPZ8db7hbsnRna3UvBGJpyUKwBHGC4w Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 02 Nov 2004 17:41:50.0518 (UTC) FILETIME=[3BC70D60:01C4C103] Content-Transfer-Encoding: 7BIT Hello dna folks, There is an issue with respect to the 3GPP section of draft-ietf-dna-link-information-00.txt i would like to raise up on this list for discussion in DC. In section 2.1 of the document, (GPRS/3GPP) it is said; " Successful establishment of a PDP Context on a GPRS attached MN signifies the availability of IP service to the MT. Therefore, this link-layer event must generate a link up event notification sent to IP-layer. The auxiliary information carried along with this notification must be the IP address of the MT which is obtained as part of the PDP Context." Actually from an IP layer perspective on an MN, the GPRS link equals to a ppp connection. Therefore activation of a PDP context is seen by an IP node as the establishment of a ppp connection (because 3GPP specifies that an IP node interfaces to the GPRS mobile station via PPP). I guess the dna process would want to get more information on the real underlying link than just ppp parameters. Am i wrong? If i am, then the question is: do we need to talk about GPRS/UMTS as the link up event generated to IP when such a link comes up is not specific to GPRS/UMTS but rather of PPP general type?. If i am not, then, we may want to add in the precedent text that mechanisms (to be defined out of dna scope) are needed to generate a link up event to IP upon successful establishment of a PDP context. As of today specification of GPRS/UMTS, such a mechanim does not exist and PPP(IPCP and LCP) messages are the only available link-layer events. The problem being that such messages do not identify the underlying link. Remark: the PPP link established as a consequence of the activation of a PDP context brings to the IP layer the configuration parameters carried by the PDP context activate accept messsage received on the mobile station from the GPRS network). Hooping to hear from the list on this Eric Njedjou regards From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 3 00:03:52 2004 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 AAA27213 for ; Wed, 3 Nov 2004 00:03:50 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGSXQBYXXS8ZIOUE@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 03 Nov 2004 16:02:55 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9390EAB546; Wed, 03 Nov 2004 16:02:44 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1DA174FB16; Wed, 03 Nov 2004 16:02:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA3525715087 for dna-list; Wed, 03 Nov 2004 16:02:05 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA3523615083 for ; Wed, 03 Nov 2004 16:02:03 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGSXPBCF7K8ZF0EC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 03 Nov 2004 16:01:56 +1100 Received: by localhost (Postfix, from userid 510) id E16DDAB543; Wed, 03 Nov 2004 16:01:55 +1100 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8900D4FB0E for ; Wed, 03 Nov 2004 16:01:54 +1100 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6L00JLG7B3A8@mailout1.samsung.com> for dna@eng.monash.edu.au; Wed, 03 Nov 2004 14:01:51 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6L00DM27ABUF@mailout1.samsung.com> for dna@eng.monash.edu.au; Wed, 03 Nov 2004 14:01:23 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6L00H8G7AB9E@mmp2.samsung.com> for dna@eng.monash.edu.au; Wed, 03 Nov 2004 14:01:23 +0900 (KST) Date: Wed, 03 Nov 2004 14:01:18 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA BCP Submission Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <004001c4c162$2a62cb90$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <416E9819.1020705@Research.Panasonic.COM> <92e919fb0411020729543f090a@mail.gmail.com> <4187BD93.70505@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > Thanks for your comment. Please find my responses inline. > > >First, about DNA definition, there seems a difference > >between goals & BCP drafts. > > > >in BCP Abstract, you wrote > > > >"Detecting Network Attachment is a set of strategies for > >determining configuration validity in wireless or rapidly changing > >environments." > > > >whereas goals draft said > > > >"The process by which a host collects the appropriate information and > >detects the identity of its currently attached link to ascertains the > >validity of its IP configuration, is called Detecting Network > >Attachment (DNA)." > > > >In goals, DNA is supposed to detect the identity of currently attached > >link to verify all the configuration at a stroke. In BCP draft, DNA is > >supposed to verify configurations one by one. > > > > > I understand, we will change the definition part to match with goals > draft. Thanks. Also kindly clarify what this draft's stance w.r.t link identity detection. The above phrase gave me an impression that it tries to present a way for DNA WITHOUT link identity detection. Am I right? > But, this also brings up the question > that was raised before - > should the BCP be restricted in scope by the > goals document. I don't > think so. So, in the abstract we will include something like " This > document details best current practice for > using Neighbor Discovery procedures to Detect Network Attachment in > IPv6 hosts and other supporting > procedure to verify relevant configurations". I don't think it's wise to include other helpful, but not relevant to DNA, features in DNA BCP draft. For example, I hardly see how Sec 8.6 is relevant to DNA. I think all it says w.r.t. DNA is "after a link change, MN should get CoA & send BU". In my opinion, DNA BCP draft would better focus on DNA procedure. Wiht link identity detection, how to check for link change & Without link identity detection, how to ensure 1) default router (partial) reachability & 2) existing IP address (prefix) validity. > >I don't think it's wise to confuse what DNA is supposed to accomplish > >as above. > > > >Second, if you recommend DNA to verify configuraitons separately, > >instead of link identity detection, I would like you to clearly pinpoint > >what configurations DNA is supposed to verify. > > > >In DNA point of view, IMO, it seems to sufficient to verify > >1) (paritical) reachability of existing default routers > >2) validity of exisitng IP addresses > > > > > We have mentioned these two configurations, in sections 4, 5 & 6 > basically focuses on these two > verifications as the heart of DNA procedures. Correct me if I am wrong, but Sec 4, 5 & 6 hardly tell about 'how to verify the existing IP address'. I failed to find it and the content list is of little help. Also kindly bear in mind that I mean 'to verify the validity of existing IP address' as 'to verify that the prefix of existing IP address is supported on the currently attached link'. IP address can be called really valid only after DAD completion but it's not my intention to include DAD in DNA. Neither they tell enough of how to confirm (partial) reachability in the presence of link-local router address, where there are plenty about bi-directional reachability confirmation. > >If you think that DNA needs to verify other configurations, clearly > >enumerate them. Then we can discuss about them. > > > >Right now, it's difficult for me to grasp what configurations you > >suggest DNA would verify. > > > > > OK - I guess I understand the confusion - Its the title of the section 5 > - "Validity of current > configurations". From the section description you can see we are only > thinking about the current > IP address and the current default router address. But, point well > taken. We will enumerate them > in -02. Actually, the two seem the only confirmations that are relevant to DNA. Right now, I don't see any other configuration that need to be verified for DNA. > >For example, I can't see why DNA needs to keen about reachability > >confirmation. I agree that Reachability confirmaiton is crucial for > >Internet connectivity but so does DAD, which we decided to rule > >out from DNA. > > > > > You seem to be contradicting yourself. You mentioned 'reachability of > existing default routers' as one > of the verifications above. Please clarify. Kindly, take notice (partial) Reachability, NOT bi-directional one. In goals draft-00, I wrote as below. Hence, to determine the need of a further configuration, a host needs to check at least that: 1) Whether it knows a (partially) reachable default router. 2) Whether it possesses a valid IP address. Partial reachability indicates that the host is able to receive packets from the router, but not necessarily vice versa. > Of course, we don't have to do everything required for Internet > connectivity, but I think reachability confiirmation > is crucial to DNA - any form of link-identification used for DNA is > going to be derived from the default router - so > assuming network attachment to be succesful without verifying > reachability to the default router doesn't make sense > - while I can understand DAD to be a step after network attachment > before Internet connectivity becomes active. IMO, w.r.t DNA, it's enough for a host to detect that it can hear from the existing default router. In DNA point of view, bi-directional reachability is 'nice to have' feature, NOT 'need to have' one. If necessary, after DNA completion, ND (RFC 2461) can kick in to establish bi-directional reachability. Neither do I agree with 'any form of link-identification used for DNA is going to be derived from the default router'. What do you suggest a host would do if prefix information & router information conflicts each other, such as a host receives an RA that has the same link-local router address but includes only new Prefix Information Options? > >Third, it would be helpful if you present why, right now, it's difficult > >to verify a specific configuration and how we can overcome the > >difficulties. > > > >For example, to verify the (partial) reachability of existing default > >routers, two difficulties come into my mind. > > > >1) How to confirm (partial) reachability with link-local address > >Because router address is link-local scope, a host can't be > >sure that it's default router is still (partially) reachable, even if > >a reply from the same link-local address arrives. > > > >2) How to quickly detects unreachability > >It will take substantial time to detect something is not there. > >NUD will take 3 secs but BCP draft just says that it may be > >better to reduce the number of NS/ NA exchange as belows. > > > >" However, if the host has indication that the link may > >have changed, this delay may be reduced without significant damage > >for the network by reducing the number of retries." > > > >Moreover, if we reduce the number to one, it still will take 1 sec. > > > >If you present how we can solve the above two under RFC 2461, it > >would be of help. > > > > > I would like to talk with you about these two comments - lets discuss > this at IETF61. ok. However, the above I gave only an example to underline my point. We need to enumerate other difficulties w.r.t. IP address (prefix) verification. > >Overall I would like the draft be more focused & organized. > > > > > Two parallel responses: > 1) The way we look at the draft right now is - upto section 6 is focused > DNA BCP - with some > additional information in section 5 and 6 - from section 7 to 11 are > additional information for some > specific topics/issues - and section 12 is the security considerations. > We do believe the text in there right now > is all needed in the BCP. First, I wish the draft talk more about link identity detection. It's not clear to me what the draft, especially Sec 5, suggests w.r.t. link identity detection. Does it recommend CPL based link identity detection? If so, DNA needs not concern default router reachability confirmation, irrespective of partial or bi-directional. CPL will complete DNA, and current protocols can mop up to verify configurations, such as DAD. If the draft is intended to present DNA schemes without link identity detection, such as verifying IP configuration one by one, I think more operational detail is needed. It's my opinion that it would be better to present a way how to verify 1) (partial) reachability of default router & 2) validity of existing IP address (without DAD) in detail. > 2) If you could be more specific it will be very useful. We went through > couple of iterations re-organizing the > draft and removing some text since -00. If you could point to sections > which you think are redundant or > out-of-focus, or, if you could suggest some form of re-orgnaization, it > will be great. It's my opinion that additional configuration process after DNA completion, such as bi-directional reachability confirmation or DAD, is non-crucial. It seems to me that, in this draft, many non-crucial parts are mixed with the crucial parts that make the draft a difficult read. I would like them to put in appendix or better in another draft. DNA wrapped with DAD inside bi-directional reachability is hard to see! :-( Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 3 01:40:49 2004 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 BAA03724 for ; Wed, 3 Nov 2004 01:40:48 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGT0ZHYUBY8WXVHV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 03 Nov 2004 17:36:35 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ECCFB80006; Wed, 03 Nov 2004 17:35:38 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9542D3C01B; Wed, 03 Nov 2004 17:35:38 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA36ZH916231 for dna-list; Wed, 03 Nov 2004 17:35:17 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA36ZG616227 for ; Wed, 03 Nov 2004 17:35:16 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGT0YVHOD88ZILK8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 03 Nov 2004 17:35:09 +1100 Received: by localhost (Postfix, from userid 510) id C15F6AB544; Wed, 03 Nov 2004 17:35:08 +1100 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 3198E4FB09 for ; Wed, 03 Nov 2004 17:35:07 +1100 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CPEjY-000NcQ-6I; Wed, 03 Nov 2004 01:35:04 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA36Z0P26604; Tue, 02 Nov 2004 22:35:00 -0800 Date: Tue, 02 Nov 2004 22:34:59 -0800 (PST) From: Bernard Aboba Subject: Re: [DNA] DNA link hints document In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN Cc: Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT > Actually from an IP layer perspective on an MN, the GPRS link equals to > a ppp connection. Therefore activation of a PDP context is seen by an IP > node as the establishment of a ppp connection (because 3GPP specifies > that an IP node interfaces to the GPRS mobile station via PPP). Actually, activation will express itself via completion of the PPP NCP negotiation. Data may be sent after NCP negotiation is complete, so that is when the link can be considered "up" for IPv4. For IPv6, I think that isn't true; RS/RA also needs to be completed to enable address assignment. Similarly, an LCP-terminate would bring the link "down" for any network protocol. > the dna process would want to get more information on the real > underlying link than just ppp parameters. Am i wrong? I see no reason why DNA should care about the link technology operating under PPP. All that is relevant is the PPP state machine and IPv6 RS/RA protocol. > Today specification of GPRS/UMTS, such a mechanim does not exist and > PPP(IPCP and LCP) messages are the only available link-layer events. The > problem being that such messages do not identify the underlying link. Correct. From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 3 14:11:38 2004 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 OAA09540 for ; Wed, 3 Nov 2004 14:11:36 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGTRD8WE4K8ZF0PT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 4 Nov 2004 06:11:19 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 789DCAB544; Thu, 04 Nov 2004 06:11:11 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EBA5E4FB07; Thu, 04 Nov 2004 06:11:07 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA3J9d024893 for dna-list; Thu, 04 Nov 2004 06:09:39 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA3J9P624885 for ; Thu, 04 Nov 2004 06:09:26 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGTRAPN84C8X2B2G@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 04 Nov 2004 06:09:09 +1100 Received: by localhost (Postfix, from userid 510) id 32F37AB542; Thu, 04 Nov 2004 06:09:09 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id BC43F4FB0B for ; Thu, 04 Nov 2004 06:09:06 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA3J94P6024655; Wed, 03 Nov 2004 14:09:04 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 343E43C80B4; Wed, 03 Nov 2004 14:07:09 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 9892D3C80E1; Wed, 03 Nov 2004 14:07:06 -0500 (EST) Date: Wed, 03 Nov 2004 14:08:44 -0500 From: Sathya Narayanan Subject: Re: [DNA] DNA BCP Submission In-reply-to: <004001c4c162$2a62cb90$eb5b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <41892CBC.8000808@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <416E9819.1020705@Research.Panasonic.COM> <"92e919fb0411020729543f 090a"@mail.gmail.com> <4187BD93.70505@Research.Panasonic.COM> <004001c4c162$2a62cb90$eb5b024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear JinHyeock - I have clipped some of the portions. Please find my responses inline. >>I understand, we will change the definition part to match with goals >>draft. >> >> >Thanks. Also kindly clarify what this draft's stance w.r.t link identity detection. >The above phrase gave me an impression that it tries to present a way for >DNA WITHOUT link identity detection. Am I right? > > No. We are not trying to present a way for DNA without link identity detection. On the other hand, we are not trying to define a unique 'link identifier' in this document either, except in the CPL section. (Greg, Nocolas - if you disagree with my understanding, please correct me). As Pekka pointed out during an earlier discussion, we could achive link identification without having a specific identifier assigned to each link - in other words, two node in the same link can have different identification mechanism, for ex. one using CPL while another could wait for a RA with its current active prefix. Both mechanisms, have their own efficiency versus accuracy ratio. >I don't think it's wise to include other helpful, but not relevant to DNA, features >in DNA BCP draft. For example, I hardly see how Sec 8.6 is relevant to DNA. >I think all it says w.r.t. DNA is "after a link change, MN should get CoA & send >BU". > > ;-) I agree, 8.6 could possibly go - it is more of a place holder right now and we may cut it later. But, what about all the other sub-sections in 8, and 7, 9,11 etc. 10 could possibly move to an appendix. During the last meeting, I got the sense that the working group wanted to keep BCP as the place were lot of the additional issues like MLD, ND cache etc. are discussed. If the group feels otherwise, we could either cut them or move them to the appendix. >In my opinion, DNA BCP draft would better focus on DNA procedure. >Wiht link identity detection, how to check for link change & >Without link identity detection, how to ensure 1) default router (partial) >reachability & 2) existing IP address (prefix) validity. > > I don't know if DNA is possible without link identification conceptually whether or not a unique (for all nodes) 'identifier' is used. See my response below: >Correct me if I am wrong, but Sec 4, 5 & 6 hardly tell about >'how to verify the existing IP address'. I failed to find it and >the content list is of little help. > >Also kindly bear in mind that I mean > >'to verify the validity of existing IP address' > >as > >'to verify that the prefix of existing IP address is supported on >the currently attached link'. > >IP address can be called really valid only after DAD completion >but it's not my intention to include DAD in DNA. > >Neither they tell enough of how to confirm (partial) reachability >in the presence of link-local router address, where there are >plenty about bi-directional reachability confirmation. > > I don't think it is reasonable for me to argue that sections 4, 5 & 6 are answering the question 'how to verify the exiting IP address', if you (as a reader) don't agree ;-) I will note this as part of the issues and try to do a better job in -02. >Actually, the two seem the only confirmations that are relevant to >DNA. Right now, I don't see any other configuration that need to >be verified for DNA. > > Again, other configurations like MLD, ND etc., are not directly relevant to DNA - and the question is back to whether the focus of BCP must be restricted by the goals or not. I will raise this question during the meeting to get some consensus from the group. >Kindly, take notice (partial) Reachability, NOT bi-directional one. In goals >draft-00, I wrote as below. > > I understand. >IMO, w.r.t DNA, it's enough for a host to detect that it can hear from >the existing default router. In DNA point of view, bi-directional reachability >is 'nice to have' feature, NOT 'need to have' one. If necessary, after DNA >completion, ND (RFC 2461) can kick in to establish bi-directional reachability. > > I agree. Don't you think, if bi-directional reachability can be confirmed without additional cost as part of DNA procedure, it makes sense to do so? I thought the goals draft allows (with a may) 'the collection of some of the necessary information for new IP configuration' as part of the DNA procedure, to reduce handoff delay. Same logic should apply here, if another 'nice to have' feature can be achieved with little or no additional cost. >Neither do I agree with 'any form of link-identification used for DNA is >going to be derived from the default router'. > >What do you suggest a host would do if prefix information & router information >conflicts each other, such as a host receives an RA that has the same link-local >router address but includes only new Prefix Information Options? > > My mistake - I didn't make myself clear - the way I look at it, in your example the new prefix options are still derived from the router and the link-identification depends on the information from the router. >DNA wrapped with DAD inside bi-directional reachability is hard to see! >:-( > > This is not an accurate description of the draft. If you don't read the additional information sections, you will not come across DAD. I agree that as the second step in DNA process we have presented bi-directional reachability. We will have to take a closer look at it. But primarily, I think, your concerns with the draft are because of a fundamental direction issue for the BCP. Do we to a large extent restrict the scope of BCP based on the goals draft or not? I think this question must be answered in the next meeting. thanks & regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 3 21:38:04 2004 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 VAA16209 for ; Wed, 3 Nov 2004 21:38:03 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGU6YDTE1A8X94YM@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 4 Nov 2004 13:37:23 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6CB57AB555; Thu, 04 Nov 2004 13:37:20 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 14FDD4FB09; Thu, 04 Nov 2004 13:37:20 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA42adc30429 for dna-list; Thu, 04 Nov 2004 13:36:39 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA42ac630425 for ; Thu, 04 Nov 2004 13:36:38 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGU6XA9REC8X94YM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 04 Nov 2004 13:36:27 +1100 Received: by localhost (Postfix, from userid 510) id 34BFD8000A; Thu, 04 Nov 2004 13:36:26 +1100 (EST) Received: from sm.sait.samsung.co.kr (unknown [202.20.142.15]) by larry.its.monash.edu.au (Postfix) with ESMTP id 791AC3C00B for ; Thu, 04 Nov 2004 13:36:22 +1100 (EST) Received: from sm.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 133C4E5DB7; Thu, 04 Nov 2004 11:35:39 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Thu, 04 Nov 2004 11:35:38 +0900 (KST) Received: from jinchoe (unknown [75.2.91.235]) by sm.sait.samsung.co.kr (Postfix) with SMTP id:8A492E5DB2; Thu, 04 Nov 2004 11:35:38 +0900 (KST) Date: Thu, 04 Nov 2004 11:36:19 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA BCP Submission Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <006701c4c217$112302c0$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <416E9819.1020705@Research.Panasonic.COM> <"92e919fb0411020729543f 090a"@mail.gmail.com> <4187BD93.70505@Research.Panasonic.COM> <004001c4c162$2a62cb90$eb5b024b@jinchoe> <41892CBC.8000808@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya > >Thanks. Also kindly clarify what this draft's stance w.r.t link identity detection. > >The above phrase gave me an impression that it tries to present a way for > >DNA WITHOUT link identity detection. Am I right? > > > > > No. We are not trying to present a way for DNA without link identity > detection. On the other hand, we are > not trying to define a unique 'link identifier' in this document either, > except in the CPL section. (Greg, Nocolas - > if you disagree with my understanding, please correct me). As Pekka > pointed out during an earlier discussion, > we could achive link identification without having a specific identifier > assigned to each link - in other words, two > node in the same link can have different identification mechanism, for > ex. one using CPL while another could wait > for a RA with its current active prefix. Both mechanisms, have their own > efficiency versus accuracy ratio. "An RA with its current active prefix" can't represent a link change properly. Hence, it can't be a link identifier, unless a host adopts CPL technique. I am afraid we have a different notion about what link identifier is. With a link identifier, a host can properly determine whether it still remains at the same link or not. If a host sees the same link identifier, it means that it still remains at the same link. If it sees a different link identifier, it means that it is attached to a different link. We wrote, in "DNA solution framework" draft, ............................... Each link has its unique Link Identifier and all routers in the link advertise the same Link Identifier in RAs. With a Link Identifier, an RA can represent a link identity and hosts can check for link change immediately without resorting to approximate knowledge. When a host receives an RA with the same Link Identifier, it still remains at the same link. If it receives an RA with a different Link Identifier, a link change has occurred and the host is attached to a different link. Link identity detection is supposed to check for link change. If you present a way for link identity detection without link identifier, that would be nice but the only alternative (without standard change) I can think of is CPL. > >I don't think it's wise to include other helpful, but not relevant to DNA, features > >in DNA BCP draft. For example, I hardly see how Sec 8.6 is relevant to DNA. > >I think all it says w.r.t. DNA is "after a link change, MN should get CoA & send > >BU". > > > > > ;-) I agree, 8.6 could possibly go - it is more of a place holder right > now and we may cut it later. But, what about > all the other sub-sections in 8, and 7, 9,11 etc. 10 could possibly move > to an appendix. > During the last meeting, I got the sense that the working group wanted > to keep BCP as the place were lot of the > additional issues like MLD, ND cache etc. are discussed. If the group > feels otherwise, we could either cut them or > move them to the appendix. What concerns me the most is NOT the draft includes many uncruicial things BUT it doesn't include enough crucial things. Also I am afraid that too much focus on uncrucial things may prevent crucial things from getting enough attention. > >In my opinion, DNA BCP draft would better focus on DNA procedure. > >Wiht link identity detection, how to check for link change & > >Without link identity detection, how to ensure 1) default router (partial) > >reachability & 2) existing IP address (prefix) validity. > > > > > I don't know if DNA is possible without link identification conceptually > whether or not a unique (for > all nodes) 'identifier' is used. See my response below: A host may skip to check for link change and directly verify IP configuration one by one. > >Correct me if I am wrong, but Sec 4, 5 & 6 hardly tell about > >'how to verify the existing IP address'. I failed to find it and > >the content list is of little help. > > > >Also kindly bear in mind that I mean > > > >'to verify the validity of existing IP address' > > > >as > > > >'to verify that the prefix of existing IP address is supported on > >the currently attached link'. > > > >IP address can be called really valid only after DAD completion > >but it's not my intention to include DAD in DNA. > > > >Neither they tell enough of how to confirm (partial) reachability > >in the presence of link-local router address, where there are > >plenty about bi-directional reachability confirmation. > > > I don't think it is reasonable for me to argue that sections 4, 5 & 6 > are answering the question > 'how to verify the exiting IP address', if you (as a reader) don't agree > ;-) I will note this as part > of the issues and try to do a better job in -02. Thanks. > >Actually, the two seem the only confirmations that are relevant to > >DNA. Right now, I don't see any other configuration that need to > >be verified for DNA. > > > > > Again, other configurations like MLD, ND etc., are not directly relevant > to DNA - and the > question is back to whether the focus of BCP must be restricted by the > goals or not. I will > raise this question during the meeting to get some consensus from the group. I guess the issue is more of 'priority' rather than 'restriciton'. I think the BCP focus should be primarily on the DNA relevant stuffs. If those are adequately dealt with, we may work on other less-relevant stuffs. In organizational point of view, however, I would like secondary stuff be in another draft or appendix. > >Kindly, take notice (partial) Reachability, NOT bi-directional one. In goals > >draft-00, I wrote as below. > > > I understand. ok. > >IMO, w.r.t DNA, it's enough for a host to detect that it can hear from > >the existing default router. In DNA point of view, bi-directional reachability > >is 'nice to have' feature, NOT 'need to have' one. If necessary, after DNA > >completion, ND (RFC 2461) can kick in to establish bi-directional reachability. > > I agree. Don't you think, if bi-directional reachability can be > confirmed without additional cost as part of > DNA procedure, it makes sense to do so? I thought the goals draft allows > (with a may) 'the collection of some of the > necessary information for new IP configuration' as part of the DNA > procedure, to reduce handoff delay. > Same logic should apply here, if another 'nice to have' feature can be > achieved with little or no additional cost. I agree. It would be nice if a host can establish bi-directional reachability while performing DNA. > >Neither do I agree with 'any form of link-identification used for DNA is > >going to be derived from the default router'. > > > >What do you suggest a host would do if prefix information & router information > >conflicts each other, such as a host receives an RA that has the same link-local > >router address but includes only new Prefix Information Options? > > > > > My mistake - I didn't make myself clear - the way I look at it, in your > example the new prefix options are still > derived from the router and the link-identification depends on the > information from the router. ok. > >DNA wrapped with DAD inside bi-directional reachability is hard to see! > >:-( > > > > > This is not an accurate description of the draft. If you don't read the > additional information sections, you will not > come across DAD. I agree that as the second step in DNA process we have > presented bi-directional reachability. > We will have to take a closer look at it. ok. > But primarily, I think, your concerns with the draft are because of a > fundamental direction issue for the BCP. > Do we to a large extent restrict the scope of BCP based on the goals > draft or not? I think this question must be > answered in the next meeting. As I wrote above, this is about not so much as 'restriction' but 'priority'. issue. I understand that DNA BCP draft is about 'how to perform DNA without standard change'. What bothers me about the draft is not it includes many other stuffs but it doesn't include enough DNA stuff. IMO, the draft says much about secondary stuffs, such as DNA & DAD, but doesn't pay enough attention to DNA itself, especially link identity detection. It hardly say about how a host check for link change. For example, after a hint of a possible link change, assume a host receives a RA with a link-local router address that is identical to the currently stored default router address. How does the draft suggest host would determine the identity of the currently attached link? Can it assume that it still remains at the link based on link-local address? If so, what would be the risk? If not, what further activities the host would take to corroborate the decision? Also how much time it would take to perform all this activities and how to minimize the delay. I failed to find a guide for hosts in such situations. The main issue should be whether the draft deals with DNA adequately or not. If so, either way is ok for me about whether to include other stuffs or not. If not, the draft would better work on DNA proper, instead of payint too much attention on secondary stuffs. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 4 11:10:46 2004 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 LAA05194 for ; Thu, 4 Nov 2004 11:10:45 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGUZ7LWZVG8X79VL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 5 Nov 2004 03:06:40 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F04380002; Fri, 05 Nov 2004 03:06:30 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DE9373C00B; Fri, 05 Nov 2004 03:06:29 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA4G5lC07423 for dna-list; Fri, 05 Nov 2004 03:05:47 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA4G5j607419 for ; Fri, 05 Nov 2004 03:05:45 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGUZ6JS52C8X79VL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 05 Nov 2004 03:05:39 +1100 Received: by localhost (Postfix, from userid 510) id 38761AB554; Fri, 05 Nov 2004 03:05:39 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id A6C294FB03 for ; Fri, 05 Nov 2004 03:05:36 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA4F4t0i015319; Thu, 04 Nov 2004 10:04:55 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 2CEC73C80E6; Thu, 04 Nov 2004 10:02:59 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id D86AA3C80E4; Thu, 04 Nov 2004 10:02:46 -0500 (EST) Received: from [68.37.197.7] by pintlmail.MITL.Research.Panasonic.COM(mshttpd) ; Thu, 04 Nov 2004 10:04:38 -0500 Date: Thu, 04 Nov 2004 10:04:38 -0500 From: Sathya Narayanan Subject: Re: [DNA] DNA BCP Submission Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 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.0-rc3 (2004-09-03) X-Spam-Level: * Content-Transfer-Encoding: 7BIT Dear JinHyeock - > > "An RA with its current active prefix" can't represent a link > change > properly. Hence, it can't be a link identifier, unless a host > adopts CPL > technique. I am afraid we have a different notion about what link > identifier is. Arrival of an RA validating the current active prefix or a timeout without such an arrival can not be used for link change identification? Please correct me if I am wrong here. The timeout value may be 3 time MaxRtrAdvInterval, but this should still work. > We wrote, in "DNA solution framework" draft, > > ............................... Each link has its unique Link > Identifier and all > routers in the link advertise the same Link Identifier in RAs. I DISAGREE with the requirement of a 'unique link identifier' agreed among all the routers and the nodes in the link as the ONLY way to do this. The current active prefix in each node is also an acceptable identifier for the link even though it will not be the same in every node and every router. If a node can determine whether its current prefix is supported or not, it has determined link change - it may not be fast but it will still work. Again, I building this argument on my statement above - please correct me if I am wrong. > What concerns me the most is NOT the draft includes many > uncruicial > things BUT it doesn't include enough crucial things. Also I am afraid > that too much focus on uncrucial things may prevent crucial things > from getting enough attention. This is a valid concern. I agree - as I said earlier we will take your comments into consideration and improve sections 4,5 & 6 in -02. > > I don't know if DNA is possible without link identification > conceptually > > whether or not a unique (for > > all nodes) 'identifier' is used. See my response below: > > A host may skip to check for link change and directly verify > IP configuration one by one. I think this is coming back to our disagreement on the 'uniqueness' of an identifier versus link identification. Based on Pekka's and your clarification for an ealier email on 'DNA Goals Issues' from me, my understanding is that DNA goals is to achieve 'link identification' not necessarily only through the definition of a unique link identifier. By unique, I mean the same identifier in all the node & routers on the link. Under this understanding, any verification of IP configuration will inherently have a 'identification of the link' component in it. > > The main issue should be whether the draft deals with DNA > adequately > or not. If so, either way is ok for me about whether to include > other > stuffs or not. If not, the draft would better work on DNA proper, > instead > of payint too much attention on secondary stuffs. Again, this is a very valid comment. With your input we will try to improve sections 4, 5 & 6 in -02. thanks & regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 4 17:42:04 2004 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 RAA17079 for ; Thu, 4 Nov 2004 17:42:02 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGVCTP7Q788X30FO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 05 Nov 2004 09:36:36 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 51BEC80007; Fri, 05 Nov 2004 09:36:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id F37333C00D; Fri, 05 Nov 2004 09:36:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA4M6tj11247 for dna-list; Fri, 05 Nov 2004 09:06:55 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA4M4E611212 for ; Fri, 05 Nov 2004 09:04:14 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGVBL7RL2A90N1XM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 05 Nov 2004 09:01:04 +1100 Received: by localhost (Postfix, from userid 510) id 71AE4AB543; Fri, 05 Nov 2004 09:01:03 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id B42324FB17 for ; Fri, 05 Nov 2004 09:01:01 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA4LHUTZ025733; Thu, 04 Nov 2004 16:17:30 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 762E53C80E1; Thu, 04 Nov 2004 16:15:35 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 626433C80B4; Thu, 04 Nov 2004 16:15:35 -0500 (EST) Date: Thu, 04 Nov 2004 16:17:14 -0500 From: Sathya Narayanan Subject: Re: [DNA] DNA BCP Submission In-reply-to: <92e919fb04110412395d1460bb@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <418A9C5A.1070903@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 Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> <92e919fb04110412395d1460bb@mail.gmail.com> Content-Transfer-Encoding: 7BIT Dear JinHyeock - >I agree that 'RA with current active prefix' can be used for link >identity detection but kindly take notice an adverb 'PROPERLY'. >That's why I wrote that it can't be a link identifier, NOT it can't >do link identity detection. > > ok. And, my point is that as long as you can do link identity detection even though you don't define a link identifier it is still a good way to go. >If a host receives an RA with its current active prefix, it means it still >remains at the same link. However, if a host receives 'an RA with >a different prefix', it can't check for link change with it. > > A timeout without receiving a 'RA with current active prefix' can be used to indicate link change. Right? >In this framework, because current active prefix doesn't satisfy >2), it can't be a link identifier, though I agree that it can be used >to check for link change. > >In CPL or LinkID (by Brett), a link change can be detected instantly, >when a host get a different link identifier, such as the complete >prefix list in CPL or LinkID option in LinkID. > > ok. >We expect 'link identifier' to EXPLICITLY represent a link identity >and have the following two properties. >1) When the same link identifer arrives, it means the same link. >2) When a different link identifer arrives, it means a different link. > > I agree with these two properties with one 'little' caveat - these two properties need to hold only for a particular node in question. i.e. two nodes in the same link could be using different 'identifiers' to represent the link as long as within each of them the above two properties hold. You seem to be making his point below, but ... >To have the above properties, all the nodes adopting the same >link identifier method, whether it be CPL or LinkID, should agree >on the same, hence unique, link identifier. For example, if in a >link, a node use CPL and the other use LinkID, then they may >have different link identifers. However, among the nodes using CPL, >or any other link identifier, there can be only one link identifier >for a link. Otherwise 2) can't be satisfied. > > even within a same scheme , two nodes using the scheme could use different 'identifier', as long as the above two properties hold within the node (neither CPL nor LinkID is an example for this). I guess, you know where I am going with this. In my proposed solution draft, RRD: I am trying to use the current prefix and force the timeout within a short duration by defining new timer for the current router. Even though it doesn't define a 'unique' identifier for every node in the link, I think it is reasonable approach to achieve link identity detection, with its own advantages (and ofcourse, dis-advantages). best regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 4 17:52:02 2004 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 RAA18258 for ; Thu, 4 Nov 2004 17:52:00 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGVCUQ9QAO8X93VD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 5 Nov 2004 09:37:11 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04577AB548; Fri, 05 Nov 2004 09:36:59 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 74C274FB13; Fri, 05 Nov 2004 09:36:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA4MRDT11462 for dna-list; Fri, 05 Nov 2004 09:27:13 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA4MPx611447 for ; Fri, 05 Nov 2004 09:25:59 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGVCH13P4E8X929N@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 05 Nov 2004 09:25:56 +1100 Received: by localhost (Postfix, from userid 510) id 93B7DAB542; Fri, 05 Nov 2004 09:25:56 +1100 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by curly.its.monash.edu.au (Postfix) with ESMTP id 772FB4FB0E for ; Fri, 05 Nov 2004 09:25:54 +1100 (EST) Received: by wproxy.gmail.com with SMTP id 55so28168wri for ; Thu, 04 Nov 2004 14:25:53 -0800 (PST) Received: by 10.38.181.79 with SMTP id d79mr24487rnf; Thu, 04 Nov 2004 12:39:12 -0800 (PST) Received: by 10.38.125.23 with HTTP; Thu, 04 Nov 2004 12:39:12 -0800 (PST) Date: Fri, 05 Nov 2004 05:39:12 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA BCP Submission In-reply-to: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb04110412395d1460bb@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=UnmCT+Uh6uWNmjiY2zG05Fq4Yw76h44QM8iuQrblKVfxmvKncHe/ltXtuAS2mKj8PA4OxHs3l9kAq4cWpfw+6aUwnHf+/JAiFILOF+jTgWVJ5UPX+AsVG66Ht+1N8Tc0+XWN7xT9lRiFjg3nq2HC19bX0AJ6BLRB886MXxGyfzk= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > > "An RA with its current active prefix" can't represent a link > > change > > properly. Hence, it can't be a link identifier, unless a host > > adopts CPL > > technique. I am afraid we have a different notion about what link > > identifier is. > > Arrival of an RA validating the current active prefix or a timeout without such an arrival can not > be used for link change identification? Please correct me if I am wrong here. The timeout value may > be 3 time MaxRtrAdvInterval, but this should still > work. I agree that 'RA with current active prefix' can be used for link identity detection but kindly take notice an adverb 'PROPERLY'. That's why I wrote that it can't be a link identifier, NOT it can't do link identity detection. As I wrote before, we have a different notion about 'link identifier'. We expect 'link identifier' to EXPLICITLY represent a link identity and have the following two properties. 1) When the same link identifer arrives, it means the same link. 2) When a different link identifer arrives, it means a different link. If a host receives an RA with its current active prefix, it means it still remains at the same link. However, if a host receives 'an RA with a different prefix', it can't check for link change with it. In this framework, because current active prefix doesn't satisfy 2), it can't be a link identifier, though I agree that it can be used to check for link change. In CPL or LinkID (by Brett), a link change can be detected instantly, when a host get a different link identifier, such as the complete prefix list in CPL or LinkID option in LinkID. > > We wrote, in "DNA solution framework" draft, > > > > ............................... Each link has its unique Link > > Identifier and all > > routers in the link advertise the same Link Identifier in RAs. > > I DISAGREE with the requirement of a 'unique link identifier' agreed among all the routers and the nodes in the link as the ONLY way to do this. The current active prefix in each node is also an acceptable identifier for the link even though it will not be the same in every node and every router. If a node can determine whether its current prefix is supported or not, it has determined link change - it may not be fast but it will still work. Again, I building this argument on my statement above - please correct me if I am wrong. I guess this disagreement results from the disagreement on the link identifier definition. I wrote the above only to illuminate what I mean by the term 'link identifier', not to insist that is the only way for link identity detection. We expect 'link identifier' to EXPLICITLY represent a link identity and have the following two properties. 1) When the same link identifer arrives, it means the same link. 2) When a different link identifer arrives, it means a different link. To have the above properties, all the nodes adopting the same link identifier method, whether it be CPL or LinkID, should agree on the same, hence unique, link identifier. For example, if in a link, a node use CPL and the other use LinkID, then they may have different link identifers. However, among the nodes using CPL, or any other link identifier, there can be only one link identifier for a link. Otherwise 2) can't be satisfied. > > The main issue should be whether the draft deals with DNA > > adequately > > or not. If so, either way is ok for me about whether to include > > other > > stuffs or not. If not, the draft would better work on DNA proper, > > instead > > of payint too much attention on secondary stuffs. > > Again, this is a very valid comment. With your input we will try to improve sections 4, 5 & 6 in -02. ok. Thanks for your kind consideration. Best Regards From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 4 17:52:18 2004 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 RAA18345 for ; Thu, 4 Nov 2004 17:52:16 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGVD88YEAI90MUJX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 05 Nov 2004 09:48:56 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 12815AB55A; Fri, 05 Nov 2004 09:47:53 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 765C34FB07; Fri, 05 Nov 2004 09:47:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA4Mhqj11670 for dna-list; Fri, 05 Nov 2004 09:43:52 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA4Mhq611666 for ; Fri, 05 Nov 2004 09:43:52 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGVD36BD1C90N22I@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 05 Nov 2004 09:43:48 +1100 Received: by localhost (Postfix, from userid 510) id AB319AB555; Fri, 05 Nov 2004 09:43:47 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 50AB14FB0C for ; Fri, 05 Nov 2004 09:43:44 +1100 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6O00D0GF4T2V@mailout3.samsung.com> for dna@eng.monash.edu.au; Fri, 05 Nov 2004 07:43:41 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6O004Q7F4S0M@mailout3.samsung.com> for dna@eng.monash.edu.au; Fri, 05 Nov 2004 07:43:41 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6O00HJNF4SQZ@mmp1.samsung.com> for dna@eng.monash.edu.au; Fri, 05 Nov 2004 07:43:40 +0900 (KST) Date: Fri, 05 Nov 2004 07:43:41 +0900 From: JinHyeock Choi Subject: Re: [DNA] DNA BCP Submission Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan , JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <001401c4c2bf$bc085020$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> <92e919fb04110412395d1460bb@mail.gmail.com> <418A9C5A.1070903@Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Dear Sathya > >I agree that 'RA with current active prefix' can be used for link > >identity detection but kindly take notice an adverb 'PROPERLY'. > >That's why I wrote that it can't be a link identifier, NOT it can't > >do link identity detection. > > > > > ok. And, my point is that as long as you can do link identity detection > even though you don't define a link > identifier it is still a good way to go. Agree. If only link identity detection can be done quickly and precisely, we don't have to adhere to link identifier approach. . > >If a host receives an RA with its current active prefix, it means it still > >remains at the same link. However, if a host receives 'an RA with > >a different prefix', it can't check for link change with it. > > > > > A timeout without receiving a 'RA with current active prefix' can be > used to indicate link change. Right? What concerns me about timeout approach is 1) it's slow because a host needs to wait till timeout. 2) it's not precise. You need to rely on approximate knowledge, because other incidents, such as packet loss or prefix omission can occur timeout without receiving prefix. > >We expect 'link identifier' to EXPLICITLY represent a link identity > >and have the following two properties. > >1) When the same link identifer arrives, it means the same link. > >2) When a different link identifer arrives, it means a different link. > > > > > I agree with these two properties with one 'little' caveat - these two > properties need to hold only for a > particular node in question. i.e. two nodes in the same link could be > using different 'identifiers' to represent > the link as long as within each of them the above two properties hold. > You seem to be making > his point below, but ... Agree. But I am afraid that in a link, unless all the node that use the same technique agree on the same link identifier, these two properties are very difficult to hold even for a particular node. Assume node1 and node2 use the same link identifier technique, hence the same link identifier format. If node1 & node2 use different link identifiers, when node2 receives the link identifier used by node1, even though it receives a different link identifier, it doesn't mean a link change. This is an example w.r.t. RRD. In a link, assume node1 uses prefix A:: and node2 Prefix B::. When node1 receives an RA only with prefix B::., though it receives a different prefix, it doesn't change a link. > >To have the above properties, all the nodes adopting the same > >link identifier method, whether it be CPL or LinkID, should agree > >on the same, hence unique, link identifier. For example, if in a > >link, a node use CPL and the other use LinkID, then they may > >have different link identifers. However, among the nodes using CPL, > >or any other link identifier, there can be only one link identifier > >for a link. Otherwise 2) can't be satisfied. > > > > > even within a same scheme , two nodes using the scheme could use > different 'identifier', as long as the > above two properties hold within the node (neither CPL nor LinkID is an > example for this). ' I wrote my opinion about this on above. Also I think, without the unique link identifier in a link, to satisfy those two, each link identifier needs to carry information that indicates for which nodes this link identifier is intended. > I guess, > you know where I am going with this. In my proposed solution draft, RRD: > I am trying to use the current > prefix and force the timeout within a short duration by defining new > timer for the current router. Even though > it doesn't define a 'unique' identifier for every node in the link, I > think it is reasonable approach to achieve > link identity detection, with its own advantages (and ofcourse, > dis-advantages). I admit that my knowledge on RRD is not thorough. However, it's not clear to me 1) how to quicken timeout without side effects, such as false link change detection. 2) what's the advantage of using , instead of just a global prefix. If you use timeout to check for link change, any global prefix in a link can do the same, w.r.t DNA. A host remembers any prefix in a link, when it suspects it may be in a different link, it sends an RS. If it receives the same prefix, it's in the same link. If it doesn't receives it until timeout, a link change has happened. It doesn't have worry about 'current' things. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 4 21:41:36 2004 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 VAA08638 for ; Thu, 4 Nov 2004 21:41:35 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGVL9GG3QQ90N3JF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 05 Nov 2004 13:38:14 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3CFB8AB559; Fri, 05 Nov 2004 13:37:55 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E12404FB14; Fri, 05 Nov 2004 13:37:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA52bPV14439 for dna-list; Fri, 05 Nov 2004 13:37:25 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA52bN614435 for ; Fri, 05 Nov 2004 13:37:23 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGVL8ICHUI8X9A3B@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 05 Nov 2004 13:37:10 +1100 Received: by localhost (Postfix, from userid 510) id 16118AB544; Fri, 05 Nov 2004 13:37:09 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id E12204FB02 for ; Fri, 05 Nov 2004 13:37:06 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA52b5ZV000507; Thu, 04 Nov 2004 21:37:05 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 259753C80E1; Thu, 04 Nov 2004 21:35:10 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 14BB23C80B4; Thu, 04 Nov 2004 21:35:10 -0500 (EST) Date: Thu, 04 Nov 2004 21:36:49 -0500 From: Sathya Narayanan Subject: Re: [DNA] DNA BCP Submission In-reply-to: <001401c4c2bf$bc085020$eb5b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <418AE741.2020202@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M: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.0-rc3 (2004-09-03) References: <46bb84c3d0.4c3d046bb8@pintlmail.MITL.Research.Panasonic.COM> <"92 e919fb04110412395d1460bb"@mail.gmail.com> <001401c4c2bf$bc085020$eb5b024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear JinHyeock - >>A timeout without receiving a 'RA with current active prefix' can be >>used to indicate link change. Right? >> >> > >What concerns me about timeout approach is >1) it's slow because a host needs to wait till timeout. > > Agreed. >2) it's not precise. You need to rely on approximate knowledge, >because other incidents, such as packet loss or >prefix omission can occur timeout without receiving prefix. > > Doesn't the same set of problems apply to CPL also? May be to a varying degree? >This is an example w.r.t. RRD. In a link, assume node1 uses prefix A:: >and node2 Prefix B::. When node1 receives an RA only with prefix B::., >though it receives a different prefix, it doesn't change a link. > > Yes. If a 'unique' for all nodes 'link identifier' is not used, then the nodes can not make such assumptions of change. It should be a more specific algorithm to detect change. See below .. >I admit that my knowledge on RRD is not thorough. However, it's not >clear to me >1) how to quicken timeout without side effects, such as false link change detection. > > I am only suggesting to quicken the response to a RS - by defining a new smaller response time for current access router, which is identified primarily by means of the current prefix. >2) what's the advantage of using , > instead of just a global prefix. > > I could possibly name a few. But, primarily - the changes proposed in RRD is very minimal and I believe it to be very effective in solving the primary problem of link change detection. I will try to enumerate this and other possible advantages in my presentation (which I haven't prepared yet ;-) ). regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 06:27:44 2004 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 GAA01668 for ; Fri, 5 Nov 2004 06:27:42 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGW3PUACJK8ZF0SL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 5 Nov 2004 22:26:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C1ABBAB555; Fri, 05 Nov 2004 22:26:31 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7913E4FB0E; Fri, 05 Nov 2004 22:26:31 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5BPlV20427 for dna-list; Fri, 05 Nov 2004 22:25:47 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5BPk620423 for ; Fri, 05 Nov 2004 22:25:46 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGW3OOZDEU8X92AI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 05 Nov 2004 22:25:36 +1100 Received: by localhost (Postfix, from userid 510) id 6CD6FAB554; Fri, 05 Nov 2004 22:25:36 +1100 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by moe.its.monash.edu.au (Postfix) with ESMTP id AF68B4FB0B for ; Fri, 05 Nov 2004 22:25:32 +1100 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA5BPUR2019050 for ; Fri, 05 Nov 2004 12:25:30 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 05 Nov 2004 12:25:30 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 05 Nov 2004 12:25:30 +0100 Date: Fri, 05 Nov 2004 12:25:27 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-OriginalArrivalTime: 05 Nov 2004 11:25:30.0887 (UTC) FILETIME=[28820970:01C4C32A] X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of Bernard Aboba > Sent: 3. marraskuuta 2004 8:35 > To: NJEDJOU Eric RD-RESA-REN > Cc: Dna > Subject: Re: [DNA] DNA link hints document > > > Actually from an IP layer perspective on an MN, the GPRS link equals to > > a ppp connection. Therefore activation of a PDP context is seen by an IP > > node as the establishment of a ppp connection (because 3GPP specifies > > that an IP node interfaces to the GPRS mobile station via PPP). > > Actually, activation will express itself via completion of the PPP NCP > negotiation. Data may be sent after NCP negotiation is complete, so that > is when the link can be considered "up" for IPv4. For IPv6, I think that > isn't true; RS/RA also needs to be completed to enable address > assignment. Similarly, an LCP-terminate would bring the link "down" for > any network protocol. Actually, if I'm correct, the IPv6 address is acquired via the PDP context exchange. RAs are not sent to the terminal, for example, in the following scenario: LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN And the same is (obviously) true for UMTS as well... BR, Tero Kauppinen From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 11:15:57 2004 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 LAA24993 for ; Fri, 5 Nov 2004 11:15:56 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGWDSP4UHS90N87G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 06 Nov 2004 03:15:34 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DE4C1AB554; Sat, 06 Nov 2004 03:15:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 943124FB08; Sat, 06 Nov 2004 03:15:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5GEOR24064 for dna-list; Sat, 06 Nov 2004 03:14:24 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5GEN624060 for ; Sat, 06 Nov 2004 03:14:24 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGWDRIOKRM8X37JK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 06 Nov 2004 03:14:13 +1100 Received: by localhost (Postfix, from userid 510) id ED175AB554; Sat, 06 Nov 2004 03:14:12 +1100 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 774424FB02 for ; Sat, 06 Nov 2004 03:14:11 +1100 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CQ6iz-0003dL-E1; Fri, 05 Nov 2004 11:14:05 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA5GE3O02536; Fri, 05 Nov 2004 08:14:03 -0800 Date: Fri, 05 Nov 2004 08:14:03 -0800 (PST) From: Bernard Aboba Subject: RE: [DNA] DNA link hints document In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT > Actually, if I'm correct, the IPv6 address is acquired via the PDP context exchange. RAs are not sent to the terminal, for example, in the following scenario: > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > And the same is (obviously) true for UMTS as well... PPP IPv6CP can only assign an interface-ID, not a prefix, so without RA there is no way for the host to obtain a prefix. Or am I missing something? From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 12:50:06 2004 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 MAA02616 for ; Fri, 5 Nov 2004 12:50:05 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWH2FH9DE8ZF1Z2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 6 Nov 2004 04:48:34 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 34769AB555; Sat, 06 Nov 2004 04:48:31 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 53CD24FB08; Sat, 06 Nov 2004 04:48:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5Hlox25493 for dna-list; Sat, 06 Nov 2004 04:47:50 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5Hlf625489 for ; Sat, 06 Nov 2004 04:47:41 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGWH0YO5VE8X3538@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 06 Nov 2004 04:47:21 +1100 Received: by localhost (Postfix, from userid 510) id 3C44880003; Sat, 06 Nov 2004 04:47:20 +1100 (EST) Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by larry.its.monash.edu.au (Postfix) with ESMTP id B6EA53C005 for ; Sat, 06 Nov 2004 04:47:16 +1100 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA5HlCh5019625 for ; Fri, 05 Nov 2004 18:47:15 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 05 Nov 2004 18:47:12 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 05 Nov 2004 18:47:12 +0100 Date: Fri, 05 Nov 2004 18:47:07 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 05 Nov 2004 17:47:12.0051 (UTC) FILETIME=[7AAA5830:01C4C35F] Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: 5. marraskuuta 2004 18:14 > To: Tero Kauppinen (JO/LMF) > Cc: Dna > Subject: RE: [DNA] DNA link hints document > > > Actually, if I'm correct, the IPv6 address is acquired via the PDP context > exchange. RAs are not sent to the terminal, for example, in the following > scenario: > > > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > And the same is (obviously) true for UMTS as well... > > PPP IPv6CP can only assign an interface-ID, not a prefix, so without RA > there is no way for the host to obtain a prefix. Or am I missing > something? Well, that's what I thought also, but after running the setup on a Linux laptop I noticed that no RAs are actually received. Being a little bit surprise myself I confirmed my observation from a colleague of mine... It's of course a different situation if I setup an IPv6-over-IPvX tunnel over the connection in which case I indeed receive RAs. Then again, maybe there is just something wrong with my setup. Tero From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 13:22:38 2004 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 NAA04958 for ; Fri, 5 Nov 2004 13:22:37 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWI5R0D108ZF1SG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 6 Nov 2004 05:19:32 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EF21CAB554; Sat, 06 Nov 2004 05:19:25 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 73E924FB0D; Sat, 06 Nov 2004 05:19:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5IIqB25895 for dna-list; Sat, 06 Nov 2004 05:18:52 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5IIg625888 for ; Sat, 06 Nov 2004 05:18:43 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWI4GPQ4C8ZF1SG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 06 Nov 2004 05:18:24 +1100 Received: by localhost (Postfix, from userid 510) id 3B952AB542; Sat, 06 Nov 2004 05:18:24 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by curly.its.monash.edu.au (Postfix) with ESMTP id 964424FB0D for ; Sat, 06 Nov 2004 05:18:22 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 05 Nov 2004 13:18:01 -0500 Date: Fri, 05 Nov 2004 13:18:18 -0500 From: "Soliman, Hesham" Subject: RE: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: [DNA] DNA link hints document Thread-Index: AcTDKozTAZoHcyqSSxSdziT7AUbCsgAOOk0w Content-Class: urn:content-classes:message X-OriginalArrivalTime: 05 Nov 2004 18:18:01.0993 (UTC) FILETIME=[C9511790:01C4C363] X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Hi Tero, > Actually, if I'm correct, the IPv6 address is acquired via > the PDP context exchange. RAs are not sent to the terminal, > for example, in the following scenario: > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > And the same is (obviously) true for UMTS as well... => The RAs are sent (at least according to the specs) but what you might be seeing is that the RA is only sent to the phone and is not forwarded to the laptop. So the laptop only sees a PPP connection. The situation might be different if instead of the phone you see a PCMCIA card inside the laptop. Or if you snoop the traffic arriving at the phone itself. I.e. when the PPP part is removed. Hesham > > BR, > > Tero Kauppinen > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 13:35:22 2004 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 NAA05896 for ; Fri, 5 Nov 2004 13:35:21 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWINLFLVQ8ZF1LN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 6 Nov 2004 05:33:55 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 83B52AB554; Sat, 06 Nov 2004 05:33:49 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 17F3A4FB09; Sat, 06 Nov 2004 05:33:49 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5IXK926066 for dna-list; Sat, 06 Nov 2004 05:33:20 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5IXA626062 for ; Sat, 06 Nov 2004 05:33:11 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWIMRG5N68X9461@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 06 Nov 2004 05:33:09 +1100 Received: by localhost (Postfix, from userid 510) id 49A90AB554; Sat, 06 Nov 2004 05:33:09 +1100 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by moe.its.monash.edu.au (Postfix) with ESMTP id E5B9A4FB0A for ; Sat, 06 Nov 2004 05:33:05 +1100 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA5IX4R2004072 for ; Fri, 05 Nov 2004 19:33:04 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 05 Nov 2004 19:33:04 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 05 Nov 2004 19:33:03 +0100 Date: Fri, 05 Nov 2004 19:32:50 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Soliman, Hesham'" , Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-OriginalArrivalTime: 05 Nov 2004 18:33:04.0530 (UTC) FILETIME=[E3454F20:01C4C365] X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Hi Hesham, Thanks for clearing it up. BR, Tero > -----Original Message----- > From: Soliman, Hesham [mailto:H.Soliman@flarion.com] > Sent: 5. marraskuuta 2004 20:18 > To: Tero Kauppinen (JO/LMF); Dna > Subject: RE: [DNA] DNA link hints document > > Hi Tero, > > > Actually, if I'm correct, the IPv6 address is acquired via > > the PDP context exchange. RAs are not sent to the terminal, > > for example, in the following scenario: > > > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > And the same is (obviously) true for UMTS as well... > > => The RAs are sent (at least according to the specs) but what you > might be seeing is that the RA is only sent to the phone and is not > forwarded to the laptop. So the laptop only sees a PPP connection. > > The situation might be different if instead of the phone you see > a PCMCIA card inside the laptop. Or if you snoop the traffic arriving > at the phone itself. I.e. when the PPP part is removed. > > Hesham > > > > > BR, > > > > Tero Kauppinen > > > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Fri Nov 5 14:48:27 2004 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 OAA10565 for ; Fri, 5 Nov 2004 14:48:27 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGWL7P16688X3DQJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 06 Nov 2004 06:47:29 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D0B26AB555; Sat, 06 Nov 2004 06:47:17 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F5E24FB09; Sat, 06 Nov 2004 06:47:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA5JkHj26844 for dna-list; Sat, 06 Nov 2004 06:46:17 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA5Jk4626840 for ; Sat, 06 Nov 2004 06:46:05 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGWL5RTRXM8ZF11K@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 06 Nov 2004 06:45:45 +1100 Received: by localhost (Postfix, from userid 510) id E3E0180003; Sat, 06 Nov 2004 06:45:44 +1100 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 56C053C003 for ; Sat, 06 Nov 2004 06:45:43 +1100 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CQA1k-0000Kq-JJ; Fri, 05 Nov 2004 14:45:40 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iA5JjcQ15913; Fri, 05 Nov 2004 11:45:38 -0800 Date: Fri, 05 Nov 2004 11:45:38 -0800 (PST) From: Bernard Aboba Subject: RE: [DNA] DNA link hints document In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soliman, Hesham" Cc: "Tero Kauppinen (JO/LMF)" , Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > And the same is (obviously) true for UMTS as well... > > => The RAs are sent (at least according to the specs) but what you > might be seeing is that the RA is only sent to the phone and is not > forwarded to the laptop. So the laptop only sees a PPP connection. There is still the question of how the LAPTOP gets the IPv6 prefix without RA. Since PPP IPv6CP standards don't specify this, I'm at a loss to explain it. > The situation might be different if instead of the phone you see > a PCMCIA card inside the laptop. Or if you snoop the traffic arriving > at the phone itself. I.e. when the PPP part is removed. Well, there are driver models that emulate ethernet, and that translate this to PPP over the wire. But I think the question still stands... From dna-owner@webcamserver.eng.monash.edu.au Sat Nov 6 04:46:11 2004 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 EAA25744 for ; Sat, 6 Nov 2004 04:46:10 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGXEHNUY4090NB6K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 06 Nov 2004 20:45:41 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2714D80002; Sat, 06 Nov 2004 20:45:18 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D2FE63C005; Sat, 06 Nov 2004 20:45:17 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA69i8L03003 for dna-list; Sat, 06 Nov 2004 20:44:08 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA69i6602997 for ; Sat, 06 Nov 2004 20:44:06 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGXEFSO22U8ZEN3N@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 06 Nov 2004 20:43:48 +1100 Received: by localhost (Postfix, from userid 510) id EF66080002; Sat, 06 Nov 2004 20:43:47 +1100 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by larry.its.monash.edu.au (Postfix) with ESMTP id D3CE23C005 for ; Sat, 06 Nov 2004 20:43:45 +1100 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n2.nomadiclab.com (Postfix) with ESMTP id D8B2E212C33; Sat, 06 Nov 2004 11:43:41 +0200 (EET) Date: Sat, 06 Nov 2004 11:43:41 +0200 (EET) From: Tero Kauppinen Subject: RE: [DNA] DNA link hints document In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: "Soliman, Hesham" , "Tero Kauppinen (JO/LMF)" , Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT Hi, Actually I now do think that you must be correct and the RA must reach the node otherwise it doesn't make any sense why the setup would work. Thus the conclusion must be that there is something wrong with my experiment. Sorry about the inconvenience. Regz, Tero On Fri, 5 Nov 2004, Bernard Aboba wrote: > Date: Fri, 5 Nov 2004 11:45:38 -0800 (PST) > From: Bernard Aboba > To: "Soliman, Hesham" > Cc: "Tero Kauppinen (JO/LMF)" , > Dna > Subject: RE: [DNA] DNA link hints document > >> > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN >> > >> > And the same is (obviously) true for UMTS as well... >> >> => The RAs are sent (at least according to the specs) but what you >> might be seeing is that the RA is only sent to the phone and is not >> forwarded to the laptop. So the laptop only sees a PPP connection. > > There is still the question of how the LAPTOP gets the IPv6 prefix without > RA. Since PPP IPv6CP standards don't specify this, I'm at a loss to > explain it. > >> The situation might be different if instead of the phone you see >> a PCMCIA card inside the laptop. Or if you snoop the traffic arriving >> at the phone itself. I.e. when the PPP part is removed. > > Well, there are driver models that emulate ethernet, and that translate > this to PPP over the wire. But I think the question still stands... > From dna-owner@webcamserver.eng.monash.edu.au Sat Nov 6 14:17:09 2004 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 OAA28744 for ; Sat, 6 Nov 2004 14:17:08 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGXYG9ZN2G90NH2T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 07 Nov 2004 06:16:58 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CF4A080006; Sun, 07 Nov 2004 06:16:50 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id AF3583C006; Sun, 07 Nov 2004 06:16:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA6JFCu13216 for dna-list; Sun, 07 Nov 2004 06:15:12 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA6JEw613198 for ; Sun, 07 Nov 2004 06:14:59 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGXYDPTSM090NH2S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 07 Nov 2004 06:14:47 +1100 Received: by localhost (Postfix, from userid 510) id 20D1180002; Sun, 07 Nov 2004 06:14:47 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1817B3C008 for ; Sun, 07 Nov 2004 06:14:45 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 06 Nov 2004 14:14:41 -0500 Date: Sat, 06 Nov 2004 14:14:43 -0500 From: "Soliman, Hesham" Subject: RE: [DNA] DNA link hints document Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: "Tero Kauppinen (JO/LMF)" , Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: [DNA] DNA link hints document Thread-Index: AcTDcBC+KFvXTa/gQNGGrl41QFfQggAxHnTA Content-Class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 06 Nov 2004 19:14:41.0972 (UTC) FILETIME=[DE467740:01C4C434] Content-Transfer-Encoding: 7BIT > > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > > > And the same is (obviously) true for UMTS as well... > > > > => The RAs are sent (at least according to the specs) but what you > > might be seeing is that the RA is only sent to the phone and is not > > forwarded to the laptop. So the laptop only sees a PPP connection. > > There is still the question of how the LAPTOP gets the IPv6 > prefix without > RA. Since PPP IPv6CP standards don't specify this, I'm at a loss to > explain it. => It doesn't get the prefix in this model. It can only get the prefix if PPP is not there. If, for instance, a bluetooth PAN profile is used, then it can get the prefix through an RA. The phone would be acting like a router in this case. Hesham =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Sun Nov 7 15:59:31 2004 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 PAA24604 for ; Sun, 7 Nov 2004 15:59:29 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGZGBIZBAI8X9QAF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 8 Nov 2004 07:59:17 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5EB32AB544; Mon, 08 Nov 2004 07:59:12 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 182D74FB06; Mon, 08 Nov 2004 07:59:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA7KuNu29887 for dna-list; Mon, 08 Nov 2004 07:56:23 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA7KuK629881 for ; Mon, 08 Nov 2004 07:56:20 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGZG7P01ZG8ZF44Y@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 08 Nov 2004 07:56:07 +1100 Received: by localhost (Postfix, from userid 510) id 1886C80002; Mon, 08 Nov 2004 07:56:07 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7794B3C002 for ; Mon, 08 Nov 2004 07:56:05 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id A9417220005; Sun, 07 Nov 2004 22:56:02 +0200 (EET) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 0A3E98; Sun, 07 Nov 2004 22:55:59 +0200 (EET) Date: Sun, 07 Nov 2004 15:55:54 -0500 From: Pekka Nikander Subject: [DNA] On the BCP documents Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Dna , Sathya Narayanan Cc: JinHyeock Choi Message-id: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT JinHyecok and Sathya, Greg and I would like to make a few comments related to lengthy discussion with regard to the proposed BCP draft. Firstly, we'd like to see the two BCP related drafts, draft-narayanan-dna-bcp-01.txt draft-jinchoi-dna-cpl-01.txt to be merged and then adopted as a merged document a WG item. Ideally, it would be very nice if you could do that together. However, if that appears to be difficult, it is also possible to create a design team to produce such a merged document. Secondly, we don't think that the DNA goals document should _unnecessarily_ restrict the BCP work. Our understanding of our charter is that the purpose of the BCP work is to document what you can do without changing the current protocols. In some cases, such a "solution" may be incomplete or probabilistic, as long as it does not violate the existing standards. However, if the BCP document proposes such "incomplete solutions", it is still worth to explicitly document their limitations. --Pekka & Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Nov 7 20:29:33 2004 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 UAA19631 for ; Sun, 7 Nov 2004 20:29:32 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGZPQFNWDE8X3R36@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 08 Nov 2004 12:29:27 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6841BAB546; Mon, 08 Nov 2004 12:29:18 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0748E4FB10; Mon, 08 Nov 2004 12:29:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA81Sao00330 for dna-list; Mon, 08 Nov 2004 12:28:36 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA81SZ600326 for ; Mon, 08 Nov 2004 12:28:35 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGZPPAIA0G90NRB4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 08 Nov 2004 12:28:23 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 829A38000C for ; Mon, 08 Nov 2004 12:28:23 +1100 (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 6CDFF3C009 for ; Mon, 08 Nov 2004 12:28:23 +1100 (EST) Received: from [130.129.135.33] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 08 Nov 2004 12:28:23 +1100 Date: Mon, 08 Nov 2004 12:28:23 +1100 From: Greg Daley Subject: [DNA] Agenda for DNA @ IETF 61 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <62156f61ad76.61ad7662156f@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 Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Here's the proposed agenda which is published on the IETF 61 site in abbreviated form. Greg Detecting Network Attachment Agenda MONDAY, November 8, 2004 1530-1730 Afternoon Sessions II Agenda ====== 5 min Introduction & Agenda bashing 5 min Documents status draft-ietf-dna-goals-03.txt draft-ietf-dna-link-information-00.txt 10 min Link information draft draft-ietf-dna-link-information-00.txt 30 min Best Current Practises drafts 20 min draft-narayanan-dna-bcp-01.txt Status/Reviews/Intentions 10 min draft-jinchoi-dna-cpl-01.txt Status/Reviews/Intentions 50 min Solutions Work Updates 10 min draft-jinchoi-dna-soln-frame-00.txt Status/Reviews/Intentions 10 min draft-narayanan-dna-rrd-00.txt Summary and Discussion 10 min draft-daley-dna-det-fastra-01 Status/Impl Report/Intentions 10 min draft-pentland-mobileip-linkid-03 Status/Impl Report/Intentions 10 Min Actions and Summary Reading List: ============= Goals: ------ * Detecting Network Attachment in IPv6 Goals draft-ietf-dna-goals-03 Problem Statements: ------------------- * Considerations for DNA Schemes with Multiple Interfaces and Layer 2 Technologies draft-hong-dna-if-l2-00 Link Layer Events: ------------------ * Link-layer Event Notifications for Detecting Network Attachments draft-ietf-dna-link-information-00 BCPs: ----- * Detecting Network Attachment in IPv6 - Best Current Practices draft-narayanan-dna-bcp-01 * DNA with unmodified routers: Prefix list based approach draft-jinchoi-dna-cpl-01 Solution Framework: ------------------- * DNA solution framework draft-jinchoi-dna-soln-frame-00 Solutions: ---------- * Recommendations to achieve efficient Router Reachability Detection in IPv6 networks draft-narayanan-dna-rrd-00 * IPv6 Fast Router Advertisement draft-mkhalil-ipv6-fastra-05 * Deterministic Fast Router Advertisement Configuration draft-daley-dna-det-fastra-01 * Router Advertisement Link Identification for Mobile IPv6 Movement Detection draft-pentland-mobileip-linkid-03 * Fast Router Discovery with RA Caching draft-jinchoi-dna-frd-00 Other Related Drafts: --------------------- * Detection of Network Attachment (DNA) in IPv4 draft-ietf-dhc-dna-ipv4-09 * Optimistic Duplicate Address Detection for IPv6 draft-ietf-ipv6-optimistic-dad-02 * Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery draft-daley-ipv6-tsllao-00 * Neighbor Discovery for IP version 6 (IPv6) draft-ietf-ipv6-2461bis-01 * IPv6 Stateless Address Autoconfiguration draft-ietf-ipv6-rfc2462bis-06 From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 07:14:50 2004 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 HAA26647 for ; Mon, 8 Nov 2004 07:14:49 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0CACAOW890NV15@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 08 Nov 2004 23:14:37 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A766AB542; Mon, 08 Nov 2004 23:14:30 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 295BE4FB08; Mon, 08 Nov 2004 23:14:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8CDsT07857 for dna-list; Mon, 08 Nov 2004 23:13:54 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8CDp607853 for ; Mon, 08 Nov 2004 23:13:51 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0C9H6J7G90NV1U@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 08 Nov 2004 23:13:49 +1100 Received: by localhost (Postfix, from userid 510) id E1D4F80002; Mon, 08 Nov 2004 23:13:48 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by larry.its.monash.edu.au (Postfix) with ESMTP id C614D3C007 for ; Mon, 08 Nov 2004 23:13:46 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so302307rne for ; Mon, 08 Nov 2004 04:13:45 -0800 (PST) Received: by 10.38.161.4 with SMTP id j4mr311464rne; Mon, 08 Nov 2004 04:13:45 -0800 (PST) Received: by 10.38.125.23 with HTTP; Mon, 08 Nov 2004 04:13:45 -0800 (PST) Date: Mon, 08 Nov 2004 21:13:45 +0900 From: JinHyeock Choi Subject: [DNA] Re: On the BCP documents In-reply-to: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna , Sathya Narayanan , JinHyeock Choi Reply-to: JinHyeock Choi Message-id: <92e919fb04110804136868847b@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=BIuwWvlErxy04MstuexkVbVXHpwmNvGQWV3e0nh1MBShCMOky4I1XDYnuyqrNRZlikvpBYgvbLiXXYOU1p1VZmD9Ibhq4qfBg0tYgCIwhYgXl8+gxLD+3i2hc5eJwkeECp0NGMyn+9mXheBmzEtoOhwJMWOQmklXjsebTwxNkV0= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear Pekka & Gregg > Greg and I would like to make a few comments related to lengthy > discussion with regard to the proposed BCP draft. > > Firstly, we'd like to see the two BCP related drafts, > draft-narayanan-dna-bcp-01.txt > draft-jinchoi-dna-cpl-01.txt > to be merged and then adopted as a merged document a > WG item. Kindly tell me why. I looked through both drafts thoroughly and see few benefit to merge them. I point out the lengthy discusson is entirely about Sathya's draft & few word is mentioned on CPL draft. I wonder how you come to the merging recommendation from that. > Ideally, it would be very nice if you could > do that together. However, if that appears to be difficult, > it is also possible to create a design team to produce such > a merged document. I wish we discuss on whether we do this or not first, before deciding who will do this. > Secondly, we don't think that the DNA goals document > should _unnecessarily_ restrict the BCP work. I take notice of the word 'unnecessarily'. > Our understanding > of our charter is that the purpose of the BCP work is to document > what you can do without changing the current protocols. I agree. BCP work is to present a way (or ways) to perform DNA without standard change. I understand that BCP & Solution aim the same thing and 'whether standard change is allowed or not' is the main, or maybe only, difference between them. > In > some cases, such a "solution" may be incomplete or probabilistic, > as long as it does not violate the existing standards. However, if > the BCP document proposes such "incomplete solutions", it is still > worth to explicitly document their limitations. The reason I raised the issues about BCP draft is NOT that it present incomplete solutions BUT that it contains materials that are not part of BCP solutions For example, the draft talks about how a host performs DAD after DNA completion. Though I think it would be helpful, I don't think that's part of DNA and wish BCP draft focus more on how to perform DNA without standard change. Actually those materials, such as DNA & DAD or DNA or bi-directional reachability, concern both BCP & Solution works, so I think, for organizational point of view, it would be better to present them in a separate draft, not inside BCP. Do you still think it's wise for BCP draft to contain those materials, such as DNA & DAD? Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 09:14:25 2004 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 JAA10584 for ; Mon, 8 Nov 2004 09:14:23 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH0GG6EJ2E8ZF4MZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 9 Nov 2004 01:13:48 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C77CCAB555; Tue, 09 Nov 2004 01:13:44 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 850054FB04; Tue, 09 Nov 2004 01:13:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8EDLt09981 for dna-list; Tue, 09 Nov 2004 01:13:21 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8EDK609977 for ; Tue, 09 Nov 2004 01:13:20 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0GFI5NGA8X46AU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 09 Nov 2004 01:13:12 +1100 Received: by localhost (Postfix, from userid 510) id 66A4DAB545; Tue, 09 Nov 2004 01:13:12 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2A72E4FB10 for ; Tue, 09 Nov 2004 01:13:09 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 26D11220007; Mon, 08 Nov 2004 16:13:03 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2E05B8; Mon, 08 Nov 2004 16:13:02 +0200 (EET) Date: Mon, 08 Nov 2004 09:13:00 -0500 From: Pekka Nikander Subject: [DNA] Re: On the BCP documents In-reply-to: <92e919fb04110804136868847b@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , Dna , Sathya Narayanan Message-id: <4C341263-3190-11D9-A88A-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> <92e919fb04110804136868847b@mail.gmail.com> Content-Transfer-Encoding: 7BIT >> Firstly, we'd like to see the two BCP related drafts, >> draft-narayanan-dna-bcp-01.txt >> draft-jinchoi-dna-cpl-01.txt >> to be merged and then adopted as a merged document a >> WG item. > > Kindly tell me why. I looked through both drafts thoroughly > and see few benefit to merge them. Well, from a standardisation point of view, it would be nice if we had a single, nice BCP document. (Remember, IETF is mostly about standardisation.) If I understood correctly what Greg said, Greg and I think that both drafts represent nice pieces of work that seem to belong to the BCP space. Hence, merging them would be good. A counter point is that if there reasons for having several documents in the BCP space, e.g., because a single document would be excessively long, we *can* have several documents there. However, even combined, the two documents are still much less than 100 pages. Hence, from that point of view, I don't see a reason why they could not be combined. Ideally, at least I would like the BCP document to outline (or specify, or whatever) several procedures that can be considered BCP. The applicability of the procedures would probably depend on what kind of info you get from the link layer, and on other factors. For example, if you get reliable link up and down indications, you may get good enough results without CPL, using something more simple minded. Personally, from a deployment point of view, I don't expect much of the BCP work to be deployed soon. Some yes, but most probably any larger deployment will take place together with the "DNA solution", just to make hosts able to act nicely independent of whether they enter a network where the "DNA solution" has been deployed or not. Most people just don't update their stack that often. > I agree. BCP work is to present a way (or ways) to perform DNA > without standard change. I understand that BCP & Solution aim > the same thing and 'whether standard change is allowed or not' > is the main, or maybe only, difference between them. I mostly agree, but, personally, I wish that the BCP document would also explain more the background, and give more information in that sense. It does not need to be all normative text. > The reason I raised the issues about BCP draft is NOT that > it present incomplete solutions BUT that it contains materials > that are not part of BCP solutions Well, we can discuss today if the WG agrees with you. Personally, I don't see a reason why the BCP cannot explain background, and reasons why some things are suggested to be done in a certain way. In a way, what we are preparing may not be a typical BCP, but it does not seem to be a Standard either. It could be even just Informational, and maybe the IESG changes it to be so. On the other hand, the goal is to define the community consensus on how you could (or should) do DNA in existing networks that do not implement the forthcoming "DNA solution", and hence I still think that the BCP status looks like the best one. Due to the variety of networks, stacks, and implementations, the situation looks like that there is no single one-size- fits-all procedure, but you may want to do it differently depending on your conditions. Hence, to me, it makes sense to explain and ponder upon these conditions in the BCP, even if briefly. Thus, I don't agree with you that all that is not "part of BCP solutions" should be removed. But this is just my personal opinion; the WG decides, not me. > For example, the draft talks about how a host performs DAD > after DNA completion. Though I think it would be helpful, > I don't think that's part of DNA and wish BCP draft focus more > on how to perform DNA without standard change. As I explained already above, personally I don't seen any need for such strict focus. The documents are not multi-hundred-page ones, at least not yet. If they grow that large, then there may be a point to remove some of the stuff. > Actually those materials, such as DNA & DAD or DNA or > bi-directional reachability, concern both BCP & Solution works, > so I think, for organizational point of view, it would be better > to present them in a separate draft, not inside BCP. Again, personally, I don't see why. The document is not too long. > Do you still think it's wise for BCP draft to contain those > materials, such as DNA & DAD? Personally, yes. I guess it may be a good idea to discuss this at the f2f meeting today. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 13:14:19 2004 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 NAA08548 for ; Mon, 8 Nov 2004 13:14:18 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0OTAWBZ290NWTA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 09 Nov 2004 05:13:46 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A3AEE80003; Tue, 09 Nov 2004 05:13:23 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 225053C009; Tue, 09 Nov 2004 05:13:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8ICYf12695 for dna-list; Tue, 09 Nov 2004 05:12:34 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8ICQ612691 for ; Tue, 09 Nov 2004 05:12:27 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0ORVAXB28X434I@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 09 Nov 2004 05:12:14 +1100 Received: by localhost (Postfix, from userid 510) id 6E946AB542; Tue, 09 Nov 2004 05:12:14 +1100 (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 8EB1F4FB03 for ; Tue, 09 Nov 2004 05:12:12 +1100 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA8IC9s3026863; Mon, 08 Nov 2004 10:12:10 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA8IC5JQ021399; Mon, 08 Nov 2004 19:12:06 +0100 (MET) Date: Mon, 08 Nov 2004 10:12:56 -0800 From: Erik Nordmark Subject: Re: [DNA] Re: On the BCP documents In-reply-to: <4C341263-3190-11D9-A88A-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: JinHyeock Choi , JinHyeock Choi , Dna , Sathya Narayanan Message-id: <418FB728.2060408@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 Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> <92e919fb04110804136868847b@mail.gmail.com> <4C341263-3190-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Pekka Nikander wrote: > Well, from a standardisation point of view, it would be nice > if we had a single, nice BCP document. (Remember, IETF is > mostly about standardisation.) If I understood correctly > what Greg said, Greg and I think that both drafts represent > nice pieces of work that seem to belong to the BCP space. > Hence, merging them would be good. Perhaps the disagreement is due to different interpretations of "merging". While I'm all for producing one BCP document which has concrete advise for an implementor, "merging" too mean sounds like an editorial task of taking two drafts and editing them into one. I think both drafts have lots of text which isn't necessary for the purpose of providing concrete advise for an implementor. Thus I think we should take the concrete advise/ideas out of both and form a new draft which convers CPL, DAD, MLD, etc. > I mostly agree, but, personally, I wish that the BCP document > would also explain more the background, and give more information > in that sense. It does not need to be all normative text. Some background is useful so that the reader/implementor can understand why the recommendations are the way they are. But if there is too much to read less people will read the document as well. So this calls for some careful balancing. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 14:52:07 2004 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 OAA20957 for ; Mon, 8 Nov 2004 14:52:05 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0S8Y20LO8X3HP3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 09 Nov 2004 06:51:48 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CD77A80003; Tue, 09 Nov 2004 06:51:30 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 754AB3C003; Tue, 09 Nov 2004 06:51:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8Jotq13699 for dna-list; Tue, 09 Nov 2004 06:50:55 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8JoV613693 for ; Tue, 09 Nov 2004 06:50:33 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0S780VCW8X3HP3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 09 Nov 2004 06:50:07 +1100 Received: by localhost (Postfix, from userid 510) id A15D680002; Tue, 09 Nov 2004 06:50:07 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id 28C613C002 for ; Tue, 09 Nov 2004 06:50:05 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so354649rne for ; Mon, 08 Nov 2004 11:50:02 -0800 (PST) Received: by 10.38.86.18 with SMTP id j18mr219396rnb; Mon, 08 Nov 2004 11:50:02 -0800 (PST) Received: by 10.38.125.23 with HTTP; Mon, 08 Nov 2004 11:50:02 -0800 (PST) Date: Tue, 09 Nov 2004 04:50:02 +0900 From: JinHyeock Choi Subject: [DNA] Re: On the BCP documents In-reply-to: <4C341263-3190-11D9-A88A-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: JinHyeock Choi , Dna , Sathya Narayanan Reply-to: JinHyeock Choi Message-id: <92e919fb04110811502d79dbce@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=SjEh91eAdRJ6S9jsOnjS71oBmFX8m9Dt0K4DxU8GCQmu/DvKn864zjx3oJNpPUgkVdEeryMbX+673wcblcG/KWoH0Rf5pbcY2O4nGZKVKlRWcIFvDOQ5zExBT0IQpe2qtOmNRMyq9gzESvVriWQSU8UwDnF7eQS1JIe8LyIv8Yg= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <6A9C4D98-30FF-11D9-A88A-000D9331AFB0@nomadiclab.com> <92e919fb04110804136868847b@mail.gmail.com> <4C341263-3190-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT > >> Firstly, we'd like to see the two BCP related drafts, > >> draft-narayanan-dna-bcp-01.txt > >> draft-jinchoi-dna-cpl-01.txt > >> to be merged and then adopted as a merged document a > >> WG item. > > > > Kindly tell me why. I looked through both drafts thoroughly > > and see few benefit to merge them. > > Well, from a standardisation point of view, it would be nice > if we had a single, nice BCP document. (Remember, IETF is > mostly about standardisation.) If I understood correctly > what Greg said, Greg and I think that both drafts represent > nice pieces of work that seem to belong to the BCP space. > Hence, merging them would be good. > > A counter point is that if there reasons for having > several documents in the BCP space, e.g., because a single > document would be excessively long, we *can* have several > documents there. However, even combined, the two documents > are still much less than 100 pages. Hence, from that point > of view, I don't see a reason why they could not be combined. I wish that we make decision based on which way, whether single or multiple drafts, would be better to present BCP work to reader/ implementers. > Ideally, at least I would like the BCP document to outline > (or specify, or whatever) several procedures that can be > considered BCP. The applicability of the procedures would > probably depend on what kind of info you get from the link > layer, and on other factors. For example, if you get reliable > link up and down indications, you may get good enough > results without CPL, using something more simple minded. Also I would like to specify a few BCP procedures but wonder whether it's wise to put them all together in one draft. Aside CPL, I can think of, at least, 4 schemes. Our team implemented 4 DNA schemes 1) ECS (Eager Cell Switching), - whenever link-layer connection changes, a host assume a link change has happened. 2) NUD like, - after a hint, a host probes the current router three times with NS and assumes a link change if no NA returns. 3) 1 NS and timeout - similar to 2), but uses 1 NS instead of 3. 4) RA beaconing. - A host keeps monitoring current RA messages and if it misses a few RAs, it assumes a link change. Also we can think of schemes using RS/ RA exchange & timeout. So I am afraid there would be too many BCP schemes for one draft. We didn't submit a draft but the you can find our results at: http://www.thinkonweb.com/sait/MD.doc We also measured 1) MD delay and 2) Error rate of each scheme on a testbed. > Personally, from a deployment point of view, I don't expect > much of the BCP work to be deployed soon. Some yes, but most > probably any larger deployment will take place together with > the "DNA solution", just to make hosts able to act nicely > independent of whether they enter a network where the > "DNA solution" has been deployed or not. Most people just > don't update their stack that often. I see. > > > > I agree. BCP work is to present a way (or ways) to perform DNA > > without standard change. I understand that BCP & Solution aim > > the same thing and 'whether standard change is allowed or not' > > is the main, or maybe only, difference between them. > > I mostly agree, but, personally, I wish that the BCP document > would also explain more the background, and give more information > in that sense. It does not need to be all normative text. I guess we agree that BCP document can contain some background materials but may disagree w.r.t 'How much'. > > > > The reason I raised the issues about BCP draft is NOT that > > it present incomplete solutions BUT that it contains materials > > that are not part of BCP solutions > > Well, we can discuss today if the WG agrees with you. Personally, > I don't see a reason why the BCP cannot explain background, > and reasons why some things are suggested to be done in a certain > way. In a way, what we are preparing may not be a typical BCP, > but it does not seem to be a Standard either. It could be even > just Informational, and maybe the IESG changes it to be so. > On the other hand, the goal is to define the community consensus > on how you could (or should) do DNA in existing networks that > do not implement the forthcoming "DNA solution", and hence I still > think that the BCP status looks like the best one. > > Due to the variety of networks, stacks, and implementations, > the situation looks like that there is no single one-size- > fits-all procedure, but you may want to do it differently > depending on your conditions. Hence, to me, it makes sense > to explain and ponder upon these conditions in the BCP, > even if briefly. Thus, I don't agree with you that all > that is not "part of BCP solutions" should be removed. > But this is just my personal opinion; the WG decides, not me. We'd better check item by item. Also as long as DNA is properly treated, I don't mind including things that don't constitute DNA solution, while that's not my taste. > > For example, the draft talks about how a host performs DAD > > after DNA completion. Though I think it would be helpful, > > I don't think that's part of DNA and wish BCP draft focus more > > on how to perform DNA without standard change. > > As I explained already above, personally I don't seen any need > for such strict focus. The documents are not multi-hundred-page > ones, at least not yet. If they grow that large, then there > may be a point to remove some of the stuff. My point is that it would make a better point to put it in separate draft because it concerns both BCP & Solution. > > Actually those materials, such as DNA & DAD or DNA or > > bi-directional reachability, concern both BCP & Solution works, > > so I think, for organizational point of view, it would be better > > to present them in a separate draft, not inside BCP. > > Again, personally, I don't see why. The document is not too long. > > > Do you still think it's wise for BCP draft to contain those > > materials, such as DNA & DAD? > > Personally, yes. > > I guess it may be a good idea to discuss this at the f2f meeting > today. ok. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 16:12:48 2004 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 QAA02412 for ; Mon, 8 Nov 2004 16:12:47 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH0V0V4O8G8ZF3OL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 9 Nov 2004 08:11:26 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 03D93AB545; Tue, 09 Nov 2004 08:11:17 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 11A8E4FB06; Tue, 09 Nov 2004 08:11:15 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8LA6s14513 for dna-list; Tue, 09 Nov 2004 08:10:06 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8LA6614509 for ; Tue, 09 Nov 2004 08:10:06 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH0UZBMTXG8ZF3OL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 09 Nov 2004 08:10:03 +1100 Received: by localhost (Postfix, from userid 510) id B3789AB556; Tue, 09 Nov 2004 08:10:02 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1CE354FB02 for ; Tue, 09 Nov 2004 08:10:01 +1100 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6V00901PGLRI@mailout3.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 06:09:57 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6V00DWFPGLMN@mailout3.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 06:09:57 +0900 (KST) Received: from Alperyegin ([105.253.155.6]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6V002WTPGIBE@mmp1.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 06:09:57 +0900 (KST) Date: Mon, 08 Nov 2004 13:09:52 -0800 From: Alper Yegin Subject: [DNA] draft-ietf-dna-link-information-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" Cc: dna@eng.monash.edu.au Message-id: <001e01c4c5d7$4baa0290$7a868182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Hi Bernard, Have you read the latest version of the I-D draft-ietf-dna-link-information-00.txt? We had your long list of comments on the earlier version (thanks again) and already incorporated them. If you have any specific comments on the new version, we'd be happy to get the details and handle them. Thanks in advance. Alper From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 18:15:44 2004 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 SAA16440 for ; Mon, 8 Nov 2004 18:15:43 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH0ZB4JUKC8ZF4K0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 9 Nov 2004 10:14:09 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B148BAB554; Tue, 09 Nov 2004 10:14:05 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 601834FB0E; Tue, 09 Nov 2004 10:14:05 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA8NDUB16151 for dna-list; Tue, 09 Nov 2004 10:13:30 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA8NDT616147 for ; Tue, 09 Nov 2004 10:13:29 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH0ZA6IIUY8X3Z06@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 09 Nov 2004 10:13:20 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 07769AB544; Tue, 09 Nov 2004 10:13:20 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id C99CA4FB0E; Tue, 09 Nov 2004 10:13:19 +1100 (EST) Received: from [130.129.133.216] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 09 Nov 2004 10:13:19 +1100 Date: Tue, 09 Nov 2004 10:13:19 +1100 From: Greg Daley Subject: [DNA] RA Caching Apology and Retraction Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: margaret@thingmagic.com Message-id: <65953565aa6a.65aa6a659535@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-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en Content-Transfer-Encoding: 7BIT Dear WG, I apologize to all, and particularly to JinHyeock, regarding the way the RA Caching issue and document were presented today during the session. Unfortunately, I made a mistake in not giving JinHyeock the opportunity to present the document for himself, and in failing to adequately gain his permission to present the document. I am very sorry that this has caused consternation. I request that the WG re-consider the document: draft-jinchoi-dna-frd-00.txt, discuss its merits and interest to the working group, without reference to the discussion within the DNA session today. After a suitable discussion it would be appropriate to consider the document agan for WG adoption. This would be a great favour to myself, and I believe would be the most fair way to proceed given the circumstances. Please refer any questions regarding this to Pekka or to myself. Please refer any queries about the draft to JinHyeock. Yours faithfully (and apologetically) Greg Daley From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 20:24:56 2004 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 UAA27907 for ; Mon, 8 Nov 2004 20:24:54 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH13UDG66C90NZ7J@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 09 Nov 2004 12:24:21 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7EE81AB545; Tue, 09 Nov 2004 12:24:08 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2592F4FB14; Tue, 09 Nov 2004 12:24:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA91Ne517493 for dna-list; Tue, 09 Nov 2004 12:23:40 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA91Ne617489 for ; Tue, 09 Nov 2004 12:23:40 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH13SSU9M68ZF1I8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 09 Nov 2004 12:22:52 +1100 Received: by localhost (Postfix, from userid 510) id AFC73AB542; Tue, 09 Nov 2004 12:22:52 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9C1134FB07 for ; Tue, 09 Nov 2004 12:22:50 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 9BD61220006 for ; Tue, 09 Nov 2004 03:22:46 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 766428 for ; Tue, 09 Nov 2004 03:22:47 +0200 (EET) Date: Mon, 08 Nov 2004 20:22:45 -0500 From: Pekka Nikander Subject: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Folks, We made a number of decisions in today's WG meeting, which we need to confirm on the mailing list. I'm trying to summarise just the decisions here; the actual minutes will come later (hopefully tomorrow). If you don't agree with the following decisions, of if you have comments or questions, please don't hesitate to express your concerns. 1. Link-information draft The feeling in the room was that the draft is not quite ready. It requires more work both in explaining its applicability and with respect to some specific link layer technologies, including 3GPP and 3GPP2. With regard to 802.16, we were informed that the .16 mobility spec is not likely to be ready any soon, and therefore it may not warrant to include it. At San Diego people asked for an 802.3 section, but so far nobody has volunteered to write one. As a conclusion, more work is needed on the draft. 2. BCP The feeling of the room was that would be useful to have two BCP documents, one targeted to host implementors and the other one to people that configure networks and routers. More work is needed to determine how to proceed in this area. 3. Solutions framework We decided to adopt draft-jinchoi-dna-soln-frame-00.txt as a working group document, with the intent of publishing it as Information. The idea is that the document provides good information to the working group and to the community. However, this adoption does not mean that the eventual DNA solution must necessarily be based on this framework. Right now the framework seems to provide a good starting point, but our understanding may evolve. It was left as an open question how fast to proceed with the draft. The chairs suggested of quickly proceeding to a WG last call, but some other people thought that it might be better to wait for the design team to come up with at least some initial ideas before going forward. I would encourage people to express their opinions on this. 4. Solutions work The chairs proposed to set up a design team to work in the solutions base. The consensus in the room was favourable to this. The idea is that the design team would come up with an initial design before the next IETF meeting, if possible. I'll announce the design team membership once it is set up. In addition to those that we have currently in mind, it would not hurt to have one more person that intends to implement the design at the same time as the design team makes progress. --Pekka Nikander From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 8 21:02:45 2004 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 VAA02005 for ; Mon, 8 Nov 2004 21:02:44 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH155NXQOW8ZF3WJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 9 Nov 2004 13:01:57 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C524E8000F; Tue, 09 Nov 2004 13:01:28 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 775FB3C002; Tue, 09 Nov 2004 13:01:28 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA921AZ17891 for dna-list; Tue, 09 Nov 2004 13:01:10 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA9219617887 for ; Tue, 09 Nov 2004 13:01:09 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH1550HXBY8X3NTM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 09 Nov 2004 13:00:58 +1100 Received: by localhost (Postfix, from userid 510) id F0E1AAB542; Tue, 09 Nov 2004 13:00:57 +1100 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5826E4FB0A for ; Tue, 09 Nov 2004 13:00:56 +1100 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6W009R52XH1G@mailout1.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 11:00:53 +0900 (KST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6W009DT2S6N9@mailout1.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 10:57:42 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0I6W005D52S57W@ms3.samsung.com> for dna@eng.monash.edu.au; Tue, 09 Nov 2004 10:57:42 +0900 (KST) Date: Tue, 09 Nov 2004 01:57:50 +0000 (GMT) From: Daniel Park Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Pekka Nikander , HAKGOO LEE Cc: Dna Reply-to: soohong.park@samsung.com Message-id: <6371649.1099965452891.JavaMail.weblogic@ep_app42> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Precedence: bulk Msgkey: 20041109015732887@soohong.park X-MTR: 20041109015732887@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-Spam-Level: * Content-Transfer-Encoding: 7BIT Hi Pekka. >1. Link-information draft >The feeling in the room was that the draft is not quite >ready. It requires more work both in explaining its >applicability and with respect to some specific link >layer technologies, including 3GPP and 3GPP2. With >regard to 802.16, we were informed that the .16 mobility >spec is not likely to be ready any soon, and therefore it >may not warrant to include it. At San Diego people asked >for an 802.3 section, but so far nobody has volunteered >to write one. (I didn't appear my intent during this meeting, sorry !) Just indicating our related work on 802.3 section. Basically our lab had completed a commercial handover mechanism between 802.3 and 802.11 using Samsung's labtop and it was based on both Windows XP and Linux. It works well of course (very fast) , and it will appear in the market soon. My colleague (Hakgoo Lee) did entirely implement this mechanism, and he already has lots of good knowledge on this work. So, I'd respectfully recommend him as a volunteer to write this section if nobody appear until now... Hope this helps. Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 9 11:17:19 2004 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 LAA14769 for ; Tue, 9 Nov 2004 11:17:18 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH1Z0D8R9Q8ZF5NB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 10 Nov 2004 03:16:20 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C68E480003; Wed, 10 Nov 2004 03:16:12 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 758EA3C008; Wed, 10 Nov 2004 03:16:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA9GFZo27115 for dna-list; Wed, 10 Nov 2004 03:15:35 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA9GFX627109 for ; Wed, 10 Nov 2004 03:15:33 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH1YZCD1CY90O22D@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 10 Nov 2004 03:15:23 +1100 Received: by localhost (Postfix, from userid 510) id 5EB16AB554; Wed, 10 Nov 2004 03:15:23 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by moe.its.monash.edu.au (Postfix) with ESMTP id BC4FE4FB05; Wed, 10 Nov 2004 03:15:21 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 42AD422000B; Tue, 09 Nov 2004 18:15:18 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 878E58; Tue, 09 Nov 2004 18:15:12 +0200 (EET) Date: Tue, 09 Nov 2004 11:15:09 -0500 From: Pekka Nikander Subject: 802.3 section to link indications draft (was Re: [DNA] Confirming today's face-to-face meeting decisions) In-reply-to: <6371649.1099965452891.JavaMail.weblogic@ep_app42> Sender: owner-dna@ecselists.eng.monash.edu.au To: HAKGOO LEE Cc: Soohong Daniel Park , Dna , Greg Daley , Alper Yegin , NJEDJOU Eric RD-RESA-REN Message-id: <8726DB13-326A-11D9-A88A-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <6371649.1099965452891.JavaMail.weblogic@ep_app42> Content-Transfer-Encoding: 7BIT Hi Hakgoo, >> may not warrant to include it. At San Diego people asked >> for an 802.3 section, but so far nobody has volunteered >> to write one. > ... > > So, I'd respectfully recommend him as a volunteer to write > this section if nobody appear until now... Would you be willing to write a section about 802.3 link notifications to draft-ietf-dna-link-information? If so, would you please contact the draft authors (at least Alper and Eric) and co-ordinate the issue with them. It would be great if we had the text available and integrated still during this year, or at least before the next IETF meeting. --Pekka DNA co-chair From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 9 15:45:29 2004 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 PAA11078 for ; Tue, 9 Nov 2004 15:45:28 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH28EMKFEO8X9ZSY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 10 Nov 2004 07:45:07 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D95F2AB554; Wed, 10 Nov 2004 07:45:00 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8A44A4FB13; Wed, 10 Nov 2004 07:45:00 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA9KiS930024 for dna-list; Wed, 10 Nov 2004 07:44:28 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA9KiQ630020 for ; Wed, 10 Nov 2004 07:44:26 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH28DFRXJA90O5Z1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 10 Nov 2004 07:44:03 +1100 Received: by localhost (Postfix, from userid 510) id 9B90DAB554; Wed, 10 Nov 2004 07:44:03 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8E42F4FB03 for ; Wed, 10 Nov 2004 07:44:01 +1100 (EST) Received: by rproxy.gmail.com with SMTP id r35so107673rna for ; Tue, 09 Nov 2004 12:43:57 -0800 (PST) Received: by 10.38.161.52 with SMTP id j52mr608406rne; Tue, 09 Nov 2004 12:43:57 -0800 (PST) Received: by 10.38.125.23 with HTTP; Tue, 09 Nov 2004 12:43:57 -0800 (PST) Date: Wed, 10 Nov 2004 05:43:57 +0900 From: JinHyeock Choi Subject: Re: [DNA] RA Caching Apology and Retraction In-reply-to: <65953565aa6a.65aa6a659535@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au, margaret@thingmagic.com Reply-to: JinHyeock Choi Message-id: <92e919fb04110912437cbe0f43@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=U8PwtaLtpEC75TxnLkb3n/fwDLwEJgatM/BGxmiRz/qn7uNOFgpB/bqqU/RtgGprDLLqHCgyGB7Sq5I6cXeG2DE2NcTkWtMtefOIEi/ds5A9JpQK65QkT9WH6NHffTcfCNVYLLJzwnDw5pcwlEwSKkB9TJ7R0+2ozGAl98JD3ag= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <65953565aa6a.65aa6a659535@monash.edu.au> Content-Transfer-Encoding: 7BIT The proposed resolution seems reasonable and I'd like to add a few words about yesterday's incident. I point out that the presenter, Greg Daley, is not a co-author of the draft and that presentation was never discussed among Greg & I. In DNA agenda, there is no time slot for the draft and I never made a request to Greg to give a presentation, nor Greg to me. During lunch, when all presenters gathered together to prepare for a meeting, I was neither informed of the upcoming presentation, nor requested to review the presentation material. In fact I didn't have the slightest idea that Greg would present my draft and ask for a decision until the very last moment. Even though I belive all these are from unfortunate mistakes and his intention was only beneficial, I don't think this is a proper way to handle one's work and wish that would not happen again. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi On Tue, 09 Nov 2004 10:13:19 +1100, Greg Daley wrote: > Dear WG, > > I apologize to all, and particularly to JinHyeock, > regarding the way the RA Caching issue and document > were presented today during the session. > > Unfortunately, I made a mistake in not giving JinHyeock the > opportunity to present the document for himself, and in > failing to adequately gain his permission to present the > document. > > I am very sorry that this has caused consternation. > > I request that the WG re-consider the document: > draft-jinchoi-dna-frd-00.txt, discuss its merits > and interest to the working group, without reference to > the discussion within the DNA session today. > > After a suitable discussion it would be appropriate to > consider the document agan for WG adoption. > > This would be a great favour to myself, and I believe > would be the most fair way to proceed given the circumstances. > > Please refer any questions regarding this to Pekka or to myself. > > Please refer any queries about the draft to JinHyeock. > > Yours faithfully (and apologetically) > > Greg Daley > > From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 14:07:39 2004 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 OAA14176 for ; Wed, 10 Nov 2004 14:07:38 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3J9NNPNQ8X9ZEX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 06:07:11 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5577EAB543; Thu, 11 Nov 2004 06:07:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 96C774FB0B; Thu, 11 Nov 2004 06:07:04 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAJ5iU11981 for dna-list; Thu, 11 Nov 2004 06:05:44 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAJ5Y611975 for ; Thu, 11 Nov 2004 06:05:35 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3J7DORRA8X4UPJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 06:05:19 +1100 Received: by localhost (Postfix, from userid 510) id 53A2EAB554; Thu, 11 Nov 2004 06:05:19 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3654E4FB06 for ; Thu, 11 Nov 2004 06:05:17 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so339850rne for ; Wed, 10 Nov 2004 11:05:16 -0800 (PST) Received: by 10.38.71.43 with SMTP id t43mr679980rna; Wed, 10 Nov 2004 11:05:15 -0800 (PST) Received: by 10.38.125.23 with HTTP; Wed, 10 Nov 2004 11:05:15 -0800 (PST) Date: Thu, 11 Nov 2004 04:05:15 +0900 From: JinHyeock Choi Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna Reply-to: JinHyeock Choi Message-id: <92e919fb0411101105705cdd9@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=pQh+bZ1yY7ppJ3MRjQ6wq59qst/36tTJZJa/jtGzB9ih0dGwkFdJgaNEYlNNEMy9vaAaiMGPvuuEbcf1IudwpfKi1uDdJxYwSzQSQB88Cr0qZrwlRbBF1kPJ9wWfF9QmCEsneTGtgTnk3w9kEwD3d/iy3Fm6mbSJpRh1mlNTySA= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT Dear Pekka Thanks for a summary. I think it adequately sums up the decisions of the meeting and is of much help. [omitted] > 1. Link-information draft > > The feeling in the room was that the draft is not quite > ready. It requires more work both in explaining its > applicability and with respect to some specific link > layer technologies, including 3GPP and 3GPP2. With > regard to 802.16, we were informed that the .16 mobility > spec is not likely to be ready any soon, and therefore it > may not warrant to include it. At San Diego people asked > for an 802.3 section, but so far nobody has volunteered > to write one. > > As a conclusion, more work is needed on the draft. ok. > 2. BCP > > The feeling of the room was that would be useful to have > two BCP documents, one targeted to host implementors and > the other one to people that configure networks and routers. > > More work is needed to determine how to proceed in this area. ok. > 3. Solutions framework > > We decided to adopt draft-jinchoi-dna-soln-frame-00.txt as > a working group document, with the intent of publishing > it as Information. The idea is that the document provides > good information to the working group and to the community. > However, this adoption does not mean that the eventual > DNA solution must necessarily be based on this framework. > Right now the framework seems to provide a good starting > point, but our understanding may evolve. ok. > It was left as an open question how fast to proceed with > the draft. The chairs suggested of quickly proceeding to > a WG last call, but some other people thought that it > might be better to wait for the design team to come up > with at least some initial ideas before going forward. > I would encourage people to express their opinions on this. I am for a quick proceeding. > 4. Solutions work > > The chairs proposed to set up a design team to work in the > solutions base. The consensus in the room was favourable > to this. The idea is that the design team would come up > with an initial design before the next IETF meeting, if > possible. > > I'll announce the design team membership once it is set up. > In addition to those that we have currently in mind, it would > not hurt to have one more person that intends to implement > the design at the same time as the design team makes progress. ok Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 14:22:49 2004 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 OAA15909 for ; Wed, 10 Nov 2004 14:22:48 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3JSN5NBU90ODEJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 06:22:43 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CCA9980002; Thu, 11 Nov 2004 06:22:27 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6B6A13C009; Thu, 11 Nov 2004 06:22:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAJLxK12163 for dna-list; Thu, 11 Nov 2004 06:21:59 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAJLo612155 for ; Thu, 11 Nov 2004 06:21:51 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3JRJAYG890ODEJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 06:21:34 +1100 Received: by localhost (Postfix, from userid 510) id 68AF6AB542; Thu, 11 Nov 2004 06:21:34 +1100 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by curly.its.monash.edu.au (Postfix) with ESMTP id B353C4FB09 for ; Thu, 11 Nov 2004 06:21:31 +1100 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAAIrav15817; Wed, 10 Nov 2004 10:53:36 -0800 Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpdQ5cZnI; Wed, 10 Nov 2004 10:53:34 -0800 (PST) Date: Wed, 10 Nov 2004 11:21:08 -0800 From: Vijay Devarapalli Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna Message-id: <41926A24.2070209@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-mProtect: <200411101853> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT hi Pekka, Pekka Nikander wrote: > 3. Solutions framework > > We decided to adopt draft-jinchoi-dna-soln-frame-00.txt as > a working group document, with the intent of publishing > it as Information. The idea is that the document provides > good information to the working group and to the community. > However, this adoption does not mean that the eventual > DNA solution must necessarily be based on this framework. > Right now the framework seems to provide a good starting > point, but our understanding may evolve. > > It was left as an open question how fast to proceed with > the draft. The chairs suggested of quickly proceeding to > a WG last call, but some other people thought that it > might be better to wait for the design team to come up > with at least some initial ideas before going forward. > I would encourage people to express their opinions on this. I have a hard time understanding proceedingly quickly with a solution framework document, when we dont have stable solutions (atleast agreed to by the WG) in the WG. the solution framework is bound to be different based on which links are being used (cdma2000 make-before-break). some links might only require fastRA and optDAD and dont need link identifiers. some make-before-break links might just require link identifiers. Vijay From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 15:40:24 2004 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 PAA26456 for ; Wed, 10 Nov 2004 15:40:23 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3MIXB9MK8X4FLM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 07:40:16 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4DA7DAB544; Thu, 11 Nov 2004 07:40:08 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 06E434FB05; Thu, 11 Nov 2004 07:40:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAKdXE12938 for dna-list; Thu, 11 Nov 2004 07:39:33 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAKdX612934 for ; Thu, 11 Nov 2004 07:39:33 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3MHYO5UI8X4RGB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 07:39:22 +1100 Received: by localhost (Postfix, from userid 510) id D3279AB554; Thu, 11 Nov 2004 07:39:21 +1100 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4A25A4FB07 for ; Thu, 11 Nov 2004 07:39:20 +1100 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 6EF8670A7AA; Thu, 11 Nov 2004 07:39:18 +1100 (EST) X-URL: http://zoic.org/sharkey/ Date: Thu, 11 Nov 2004 07:39:17 +1100 From: "Nick 'Sharkey' Moore" Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <41926A24.2070209@iprg.nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: Vijay Devarapalli Message-id: <20041110203917.GB13725@zoic.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Precedence: bulk User-Agent: Mutt/1.3.28i X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <41926A24.2070209@iprg.nokia.com> Content-Transfer-Encoding: 7BIT On 2004-11-10, Vijay Devarapalli wrote: > > I have a hard time understanding proceedingly quickly with > a solution framework document, when we dont have stable > solutions (atleast agreed to by the WG) in the WG. Hi Vijay, my point of view is that the solution framework should. discuss the techniques available and the situations in which they are suitable. Actual link types would be used as examples rather than trying to combine a canonical list of link types. That way, when someone decides to implement fast network attachment on PhlogistonNet or whatever, they can go to the informational and say yes: it needs this, no: it doesn't need that, etc. Mind you, I haven't read the document in question lately, and I'm not there in DC, so this comment may be rather irrelevant! -----Nick in Melbourne From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 15:48:47 2004 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 PAA28903 for ; Wed, 10 Nov 2004 15:48:46 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3MRTLTRS8X4L57@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 07:47:49 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 62151AB543; Thu, 11 Nov 2004 07:47:18 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1DACE4FB04; Thu, 11 Nov 2004 07:47:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAKl0e13032 for dna-list; Thu, 11 Nov 2004 07:47:00 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAKl0613028 for ; Thu, 11 Nov 2004 07:47:00 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3MRETRS88XA6XP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 07:46:59 +1100 Received: by localhost (Postfix, from userid 510) id D194FAB554; Thu, 11 Nov 2004 07:46:58 +1100 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by moe.its.monash.edu.au (Postfix) with ESMTP id BFCD44FB07 for ; Thu, 11 Nov 2004 07:46:56 +1100 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAAKJ3A20082; Wed, 10 Nov 2004 12:19:03 -0800 Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpdqyiIuJ; Wed, 10 Nov 2004 12:19:01 -0800 (PST) Date: Wed, 10 Nov 2004 12:46:36 -0800 From: Vijay Devarapalli Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <20041110203917.GB13725@zoic.org> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Nick 'Sharkey' Moore" Cc: Dna Message-id: <41927E2C.2090908@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-mProtect: <200411102019> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <41926A24.2070209@iprg.nokia.com> <20041110203917.GB13725@zoic.org> Content-Transfer-Encoding: 7BIT Nick 'Sharkey' Moore wrote: > On 2004-11-10, Vijay Devarapalli wrote: > >>I have a hard time understanding proceedingly quickly with >>a solution framework document, when we dont have stable >>solutions (atleast agreed to by the WG) in the WG. > > > Hi Vijay, > > my point of view is that the solution framework should. > discuss the techniques available my point is have we agreed that we have some techniques available? Vijay > and the situations in which > they are suitable. Actual link types would be used as examples > rather than trying to combine a canonical list of link types. > > That way, when someone decides to implement fast > network attachment on PhlogistonNet or whatever, they > can go to the informational and say yes: it needs this, > no: it doesn't need that, etc. > > Mind you, I haven't read the document in question > lately, and I'm not there in DC, so this comment may be > rather irrelevant! > > -----Nick in Melbourne From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 16:04:00 2004 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 QAA02329 for ; Wed, 10 Nov 2004 16:03:59 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3NC4D8J290OE2K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 08:03:49 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8D17DAB544; Thu, 11 Nov 2004 08:03:40 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 42E6D4FB03; Thu, 11 Nov 2004 08:03:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAL3VH13222 for dna-list; Thu, 11 Nov 2004 08:03:31 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAL3U613218 for ; Thu, 11 Nov 2004 08:03:30 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3NBKS1JC8X9ZUF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 08:03:14 +1100 Received: by localhost (Postfix, from userid 510) id 592B6AB542; Thu, 11 Nov 2004 08:03:14 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id BD82A4FB02 for ; Thu, 11 Nov 2004 08:03:13 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 109B2220003; Wed, 10 Nov 2004 23:03:11 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 4BB648; Wed, 10 Nov 2004 23:03:10 +0200 (EET) Date: Wed, 10 Nov 2004 16:03:09 -0500 From: Pekka Nikander Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <41926A24.2070209@iprg.nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Vijay Devarapalli Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <41926A24.2070209@iprg.nokia.com> Content-Transfer-Encoding: 7BIT >> It was left as an open question how fast to proceed with >> the draft. The chairs suggested of quickly proceeding to >> a WG last call, but some other people thought that it >> might be better to wait for the design team to come up >> with at least some initial ideas before going forward. >> I would encourage people to express their opinions on this. > > I have a hard time understanding proceedingly quickly with > a solution framework document, when we dont have stable > solutions (atleast agreed to by the WG) in the WG. Maybe it is better to wait; I am open to both options. Opinions, please! I'm just trying to keep us making progress and not lag too far behind our milestones; OTOH, it there is a reason it is not that hard to update the milestones. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 16:32:57 2004 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 QAA06962 for ; Wed, 10 Nov 2004 16:32:55 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3O9CCUWU8ZF6C7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 08:29:51 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A53FCAB558; Thu, 11 Nov 2004 08:29:40 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 523C44FB09; Thu, 11 Nov 2004 08:29:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAALTPE13527 for dna-list; Thu, 11 Nov 2004 08:29:25 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAALTO613521 for ; Thu, 11 Nov 2004 08:29:24 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3O8ZM1VK8ZF6QD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 08:29:24 +1100 Received: by localhost (Postfix, from userid 510) id 97CD780006; Thu, 11 Nov 2004 08:29:23 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4B6A13C00B for ; Thu, 11 Nov 2004 08:29:21 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iAALTJh3026075; Wed, 10 Nov 2004 16:29:19 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 2CEFD3C8156; Wed, 10 Nov 2004 16:27:23 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 2135B3C8155; Wed, 10 Nov 2004 16:27:23 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Wed, 10 Nov 2004 16:29:19 -0500 Date: Wed, 10 Nov 2004 16:29:19 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Vijay Devarapalli , Dna Message-id: <51a8654d22.54d2251a86@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 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.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT > >> It was left as an open question how fast to proceed with > >> the draft. The chairs suggested of quickly proceeding to > >> a WG last call, but some other people thought that it > >> might be better to wait for the design team to come up > >> with at least some initial ideas before going forward. > >> I would encourage people to express their opinions on this. > > > > I have a hard time understanding proceedingly quickly with > > a solution framework document, when we dont have stable > > solutions (atleast agreed to by the WG) in the WG. > > Maybe it is better to wait; I am open to both options. > Opinions, please! I too think its better to wait. We don't have to wait till the solutions work is completed, but we need to atleast go through one(or few)-cycle(s) of the solutions discussion before we move the framework document. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 16:46:13 2004 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 QAA08252 for ; Wed, 10 Nov 2004 16:46:12 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3OT4V6N28ZF7C3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 08:45:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2255D80006; Thu, 11 Nov 2004 08:45:38 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C75983C002; Thu, 11 Nov 2004 08:45:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAALjMi13705 for dna-list; Thu, 11 Nov 2004 08:45:22 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAALjL613701 for ; Thu, 11 Nov 2004 08:45:21 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3OSNR81M90OBUQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 08:45:15 +1100 Received: by localhost (Postfix, from userid 510) id 2445080007; Thu, 11 Nov 2004 08:45:14 +1100 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id EAF7F3C007 for ; Thu, 11 Nov 2004 08:45:12 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAALjBs3007393; Wed, 10 Nov 2004 13:45:11 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAALjANm256493; Wed, 10 Nov 2004 13:45:10 -0800 (PST) Date: Wed, 10 Nov 2004 13:46:01 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Vijay Devarapalli , Dna Message-id: <41928C19.6020600@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <41926A24.2070209@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Pekka Nikander wrote: better to wait; I am open to both options. > Opinions, please! > > I'm just trying to keep us making progress and not lag > too far behind our milestones; OTOH, it there is a reason > it is not that hard to update the milestones. Seems like folks are confusing "framework" and "summary" or "overview". A framework is the thing you build before you place things into it. For instance, you build the supporting structure of a building before you place the wallboards. I agree that we can't write a summary or overview document until we know what we end up with, but we should be able to write a framework document which provides the frame into which the puzzle pieces will fit. If we can't do that, then we must be fumbling around in the dark. So I'm confused why folks think we must wait. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 17:00:28 2004 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 RAA09544 for ; Wed, 10 Nov 2004 17:00:27 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3PAT9E5G8X4LRJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 09:00:21 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 071BC8000B; Thu, 11 Nov 2004 08:59:53 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id B324B3C002; Thu, 11 Nov 2004 08:59:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAALxfw13855 for dna-list; Thu, 11 Nov 2004 08:59:41 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAALxe613851 for ; Thu, 11 Nov 2004 08:59:40 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3PA8RQN48X9TFQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 08:59:26 +1100 Received: by localhost (Postfix, from userid 510) id BC7A1AB543; Thu, 11 Nov 2004 08:59:25 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3C0354FB09 for ; Thu, 11 Nov 2004 08:59:23 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iAALxMH8026922; Wed, 10 Nov 2004 16:59:22 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 7129F3C8158; Wed, 10 Nov 2004 16:57:25 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 308CE3C8155; Wed, 10 Nov 2004 16:57:25 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Wed, 10 Nov 2004 16:59:21 -0500 Date: Wed, 10 Nov 2004 16:59:21 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Pekka Nikander , Vijay Devarapalli , Dna Message-id: <5326a554ef.554ef5326a@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:15 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > Pekka Nikander wrote: > better to wait; I am open to both options. > > Opinions, please! > > > > I'm just trying to keep us making progress and not lag > > too far behind our milestones; OTOH, it there is a reason > > it is not that hard to update the milestones. > > Seems like folks are confusing "framework" and "summary" or > "overview".A framework is the thing you build before you place > things into it. > For instance, you build the supporting structure of a building > before > you place the wallboards. > > I agree that we can't write a summary or overview document until > we know > what we end up with, but we should be able to write a framework > document > which provides the frame into which the puzzle pieces will fit. > If we can't do that, then we must be fumbling around in the dark. I think the framework document is very useful and provides us with a nice, well, framework to begin work - but my only suggestion is, it makes sense to go through an iteration of the solution work, come back and may be make some changes to the framework document and then move it forward through WGLC etc. , instead of moving it forward now and making it absolete if the solutions fall outside the proposed framework. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 17:08:42 2004 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 RAA10501 for ; Wed, 10 Nov 2004 17:08:41 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3PK1RETY8ZF65R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 09:07:22 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0C74FAB554; Thu, 11 Nov 2004 09:07:20 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B71324FB0C; Thu, 11 Nov 2004 09:07:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAM74c13985 for dna-list; Thu, 11 Nov 2004 09:07:04 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAM74613979 for ; Thu, 11 Nov 2004 09:07:04 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3PJCUNU490OEN8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 09:06:46 +1100 Received: by localhost (Postfix, from userid 510) id A6EC880003; Thu, 11 Nov 2004 09:06:46 +1100 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6EBEE3C005 for ; Thu, 11 Nov 2004 09:06:44 +1100 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAALcif18021; Wed, 10 Nov 2004 13:38:44 -0800 Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpd2ECJrY; Wed, 10 Nov 2004 13:38:42 -0800 (PST) Date: Wed, 10 Nov 2004 14:06:17 -0800 From: Vijay Devarapalli Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <41928C19.6020600@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Pekka Nikander , Dna Message-id: <419290D9.6030709@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en X-mProtect: <200411102138> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <41926A24.2070209@iprg.nokia.com> <41928C19.6020600@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Pekka Nikander wrote: > better to wait; I am open to both options. > >> Opinions, please! >> >> I'm just trying to keep us making progress and not lag >> too far behind our milestones; OTOH, it there is a reason >> it is not that hard to update the milestones. > > > Seems like folks are confusing "framework" and "summary" or "overview". > A framework is the thing you build before you place things into it. > For instance, you build the supporting structure of a building before > you place the wallboards. > > I agree that we can't write a summary or overview document until we know > what we end up with, but we should be able to write a framework document > which provides the frame into which the puzzle pieces will fit. > If we can't do that, then we must be fumbling around in the dark. > > So I'm confused why folks think we must wait. the framework seems to recommend that we need a Link identifier solution, fast RA, fast RS, optDAD and TSLLAO. it says with this we have a good DNA solution. that doesnt seem like a "supporting structure" to me. maybe I dont understand whats in the framework document. Vijay From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 17:23:11 2004 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 RAA11745 for ; Wed, 10 Nov 2004 17:23:10 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3Q4CDQHK8XA7PJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 09:22:58 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CA941AB545; Thu, 11 Nov 2004 09:22:54 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6888A4FB02; Thu, 11 Nov 2004 09:22:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAAMMbD14170 for dna-list; Thu, 11 Nov 2004 09:22:37 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAAMMb614166 for ; Thu, 11 Nov 2004 09:22:37 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3Q3W0WKQ8X4W4V@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 09:22:33 +1100 Received: by localhost (Postfix, from userid 510) id EBE3CAB542; Thu, 11 Nov 2004 09:22:32 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by curly.its.monash.edu.au (Postfix) with ESMTP id E97674FB05 for ; Thu, 11 Nov 2004 09:22:30 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so368340rne for ; Wed, 10 Nov 2004 14:22:30 -0800 (PST) Received: by 10.38.181.26 with SMTP id d26mr726834rnf; Wed, 10 Nov 2004 14:22:29 -0800 (PST) Received: by 10.38.125.23 with HTTP; Wed, 10 Nov 2004 14:22:29 -0800 (PST) Date: Thu, 11 Nov 2004 07:22:29 +0900 From: JinHyeock Choi Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <419290D9.6030709@iprg.nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Vijay Devarapalli Cc: Erik Nordmark , Pekka Nikander , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb041110142256b44d98@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=EWLF3Q4/exY+Ta2DgZon66wzJTRqcUngUx6EkfWIOftIOXz4if6uvqaW+4VRMOTlxCuTToBeilnYNO7XsB7AGTOtWXsKU6DMZX2RIWV8IgOgzjVIVHuxhh6le6q6bNG3BQkgx6r0dDFX3xOkBa6+4bPX+SqirZgwRYGjouFg3r0= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <41926A24.2070209@iprg.nokia.com> <41928C19.6020600@sun.com> <419290D9.6030709@iprg.nokia.com> Content-Transfer-Encoding: 7BIT > the framework seems to recommend that we need a Link identifier > solution, fast RA, fast RS, optDAD and TSLLAO. it says with this > we have a good DNA solution. > > that doesnt seem like a "supporting structure" to me. Framework presents a few ideas on which we base DNA solutions, such as Link Identifier, RA optimized for DNA & Quick RA delivery. However, they are rather conceptual and even though the draft mentions a few current schemes as possible candidates, it was not out intention to recommend a specific scheme, such as FastRA, as a solution. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 20:16:14 2004 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 UAA26986 for ; Wed, 10 Nov 2004 20:16:13 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3W4M6G4U8X4PA4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 12:15:09 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D7E25AB554; Thu, 11 Nov 2004 12:14:55 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 956F24FB05; Thu, 11 Nov 2004 12:14:55 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAB1EM515942 for dna-list; Thu, 11 Nov 2004 12:14:22 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAB1EL615930 for ; Thu, 11 Nov 2004 12:14:21 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3W3KFC2E8X7EK7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 12:14:05 +1100 Received: by localhost (Postfix, from userid 510) id 44494AB544; Thu, 11 Nov 2004 12:14:05 +1100 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9265F4FB05; Thu, 11 Nov 2004 12:14:03 +1100 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6Z00MJ2Q34UF@mailout2.samsung.com>; Thu, 11 Nov 2004 10:13:52 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6Z0091WPZNJH@mailout2.samsung.com>; Thu, 11 Nov 2004 10:11:47 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0I6Z00I75PZMS2@ms3.samsung.com>; Thu, 11 Nov 2004 10:11:47 +0900 (KST) Date: Thu, 11 Nov 2004 01:11:46 +0000 (GMT) From: HAKGOO LEE Subject: Re: 802.3 section to link indications draft (was Re: [DNA] Confirming today's face-to-face meeting decisions) Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbGUgUGw=?= =?windows-1252?B?YXRmb3JtIExhYj9Bc3Npc3RhbnQ/RW5nZW5lZXI=?= To: Pekka Nikander Cc: =?windows-1252?Q?=3F=3F=3F_?= , Dna , Greg Daley , Alper Yegin , NJEDJOU Eric RD-RESA-REN Reply-to: goodguy.lee@samsung.com Message-id: <3316268.1100135505053.JavaMail.weblogic@ep_app31> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Precedence: bulk Msgkey: 20041111011145049@goodguy.lee X-MTR: 20041111011145049@goodguy.lee X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-Spam-Level: * Content-Transfer-Encoding: 7BIT Hi All My name is HakGoo LEE. I'm Working at Samsung Electronics. First of all, I have a pleasure to get an opportunity of join in DNA Working Group. Of course, I want to participate in your job. I have working for IPv6, Mobile IPv6, Seamless Handoff. So, I want to Contribute My Network Development Experience to DNA Working Group. Best Regard ------- Original Message ------- Sender : Pekka Nikander Date : 2004-11-10 01:15 Title : 802.3 section to link indications draft (was Re: [DNA] Confirming today's face-to-face meeting decisions) Hi Hakgoo, >> may not warrant to include it. At San Diego people asked >> for an 802.3 section, but so far nobody has volunteered >> to write one. > ... > > So, I'd respectfully recommend him as a volunteer to write > this section if nobody appear until now... Would you be willing to write a section about 802.3 link notifications to draft-ietf-dna-link-information? If so, would you please contact the draft authors (at least Alper and Eric) and co-ordinate the issue with them. It would be great if we had the text available and integrated still during this year, or at least before the next IETF meeting. --Pekka DNA co-chair From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 21:09:29 2004 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 VAA01422 for ; Wed, 10 Nov 2004 21:09:28 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3XYF4T7290OBUK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 13:08:33 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 06645AB555; Thu, 11 Nov 2004 13:07:59 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9937B4FB03; Thu, 11 Nov 2004 13:07:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAB27l416565 for dna-list; Thu, 11 Nov 2004 13:07:47 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAB27k616561 for ; Thu, 11 Nov 2004 13:07:46 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3XY2N8YK8ZF7J7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 11 Nov 2004 13:07:42 +1100 Received: by localhost (Postfix, from userid 510) id 69F20AB558; Thu, 11 Nov 2004 13:07:42 +1100 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3BBDE4FB07 for ; Thu, 11 Nov 2004 13:07:40 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAB27cNH021487; Wed, 10 Nov 2004 19:07:39 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAB27W20432125; Wed, 10 Nov 2004 18:07:33 -0800 (PST) Date: Wed, 10 Nov 2004 18:08:20 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <419290D9.6030709@iprg.nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Vijay Devarapalli Cc: Pekka Nikander , Dna Message-id: <4192C994.3000307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <41926A24.2070209@iprg.nokia.com> <41928C19.6020600@sun.com> <419290D9.6030709@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Vijay Devarapalli wrote: > the framework seems to recommend that we need a Link identifier > solution, fast RA, fast RS, optDAD and TSLLAO. it says with this > we have a good DNA solution. > > that doesnt seem like a "supporting structure" to me. > > maybe I dont understand whats in the framework document. This discussion, about the content of the document, is what I'd like to see. Thanks. The current content of the document captures (captured) the authors ideas when it was written. It probably makes sense to rephrase things as the desirable properties. For instance, I think we know we want a solution which uses router advertisements so that one can find the configuration of the new link at the same time as detecting whether or not one has moved to a new link. And given that we have two different styles to detect the link (an explicit link identifier, compared to what I would characterize as a cookie or a landmark, where the host asks "does this landmark still exist" without an explicit linkid) we should express the need based on the property that a host should be able to determine whether it is on the same link or not from receiving a single message. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 21:51:32 2004 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 VAA04510 for ; Wed, 10 Nov 2004 21:51:31 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH3ZF7TKLK8XA3CL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 13:49:56 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2376E80009; Thu, 11 Nov 2004 13:49:46 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id AF1AE3C009; Thu, 11 Nov 2004 13:49:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAB2nSd16974 for dna-list; Thu, 11 Nov 2004 13:49:28 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAB2nR616970 for ; Thu, 11 Nov 2004 13:49:27 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH3ZEGOUM890O8DT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 13:49:10 +1100 Received: by localhost (Postfix, from userid 510) id 85EF6AB554; Thu, 11 Nov 2004 13:49:09 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 35C684FB08 for ; Thu, 11 Nov 2004 13:49:07 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iAB2n6Pw000730; Wed, 10 Nov 2004 21:49:06 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 2CEBC3C8159; Wed, 10 Nov 2004 21:47:09 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 21DFF3C8158; Wed, 10 Nov 2004 21:47:09 -0500 (EST) Received: from [130.129.97.39] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Wed, 10 Nov 2004 21:49:05 -0500 Date: Wed, 10 Nov 2004 21:49:05 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Vijay Devarapalli , Pekka Nikander , Dna Message-id: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:72.93833 C:21 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > And given that we have two different styles to detect the link (an > explicit link identifier, compared to what I would characterize as > a > cookie or a landmark, where the host asks "does this landmark > still > exist" without an explicit linkid) we should express the need > based on > the property that a host should be able to determine whether it is > on > the same link or not from receiving a single message. Yes. The advantage in using a 'Link Identifier' with a scope applicable to all the nodes in the network is that the host will be able to determine whether it is on the same link or not from receiving a single (RA) message. On the other hand, when such identifier is not available, the host can ask the question 'does this landmark still exist' everytime it has (good) reason to believe it may have changed link. Can we refer to the first scheme as 'link scoped identifier' and second as 'host scoped identifier' scheme? ;-) The question to ask is, whether the cost of establishing the unique link identifier among all the nodes (routers) in the link is worth to avoid an extra 'does this landmark still exists' question and answer? Link scoped identifier scheme requires completely securing the link so that nobody can spoof a RA message or confuse the link identifier, while we (I am not sure about this) may not need complete security as long as a secure association between the host and the current AR is good in the host scoped identifier approach. -Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 22:08:08 2004 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 WAA05914 for ; Wed, 10 Nov 2004 22:08:07 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH401JCMMC8XA1SP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 14:07:03 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9B16AB542; Thu, 11 Nov 2004 14:06:58 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9F94A4FB07; Thu, 11 Nov 2004 14:06:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAB36lK17201 for dna-list; Thu, 11 Nov 2004 14:06:47 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAB36k617197 for ; Thu, 11 Nov 2004 14:06:46 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH400XVJBG90O97M@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 14:06:30 +1100 Received: by localhost (Postfix, from userid 510) id 42D8780002; Thu, 11 Nov 2004 14:06:30 +1100 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by larry.its.monash.edu.au (Postfix) with ESMTP id 053C23C009 for ; Thu, 11 Nov 2004 14:06:28 +1100 (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 iAB36Qs3023724; Wed, 10 Nov 2004 19:06:27 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAB36M5a471931; Wed, 10 Nov 2004 19:06:26 -0800 (PST) Date: Wed, 10 Nov 2004 19:07:13 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Vijay Devarapalli , Pekka Nikander , Dna Message-id: <4192D761.1020806@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Yes. The advantage in using a 'Link Identifier' with a scope > applicable to all the nodes in the network is that the host will be > able to determine whether it is on the same link or not from > receiving a single (RA) message. On the other hand, when such > identifier is not available, the host can ask the question 'does this > landmark still exist' everytime it has (good) reason to believe it > may have changed link. > > Can we refer to the first scheme as 'link scoped identifier' and > second as 'host scoped identifier' scheme? ;-) > > The question to ask is, whether the cost of establishing the unique > link identifier among all the nodes (routers) in the link is worth to > avoid an extra 'does this landmark still exists' question and answer? Indeed. But I think that we shouldn't constrain our thinking about the latter to the case when only one router can answer the question about the landmark; one could have the routers share this so that any of them can answer the question. > Link scoped identifier scheme requires completely securing the link > so that nobody can spoof a RA message or confuse the link identifier, > while we (I am not sure about this) may not need complete security as > long as a secure association between the host and the current AR is > good in the host scoped identifier approach. Why would the RAs that carry linkids need to be secured any more than RAs that carry prefixes and default router information? I don't understand. It might be that the Rtr-to-Rtr messages have different concerns than the RAs and other ND messages, but I haven't seen any semblance of a threat analysis that makes even this case. But that's separate from the RAs adverting linkids to hosts. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 10 22:33:55 2004 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 WAA08387 for ; Wed, 10 Nov 2004 22:33:54 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH40Y0IEYK8X4XP8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 11 Nov 2004 14:33:22 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E730CAB542; Thu, 11 Nov 2004 14:33:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8F41F4FB03; Thu, 11 Nov 2004 14:33:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAB3Wl017461 for dna-list; Thu, 11 Nov 2004 14:32:47 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAB3Wl617457 for ; Thu, 11 Nov 2004 14:32:47 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH40XGGJX48X4RDP@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 11 Nov 2004 14:32:43 +1100 Received: by localhost (Postfix, from userid 510) id 250D380007; Thu, 11 Nov 2004 14:32:43 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0EA723C00E for ; Thu, 11 Nov 2004 14:32:41 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so396010rne for ; Wed, 10 Nov 2004 19:32:40 -0800 (PST) Received: by 10.38.162.70 with SMTP id k70mr6380rne; Wed, 10 Nov 2004 19:32:40 -0800 (PST) Received: by 10.38.125.23 with HTTP; Wed, 10 Nov 2004 19:32:40 -0800 (PST) Date: Thu, 11 Nov 2004 12:32:40 +0900 From: JinHyeock Choi Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb041110193237362eeb@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=XJRdzyYQC/WROmWzfJKlCTUWmPZdz0vvDiWFFqeoEbq/kHR9qmiLa4UC/g1Ulvl+v8Kd6+w7qe5kdmhi7bxPyxALPpl8Z6CygYDjfNm9o6YGSd9NyxLt32596kvj3EYH2deO5ClDBmEEOOrmQBRKwflnliu+F4F8eSWgWOBskDQ= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya > Yes. The advantage in using a 'Link Identifier' with a scope applicable to all the nodes in the network is that the host will be able to determine whether it is on the same link or not from receiving a single (RA) message. On the other hand, when such identifier is not available, the host can ask the question 'does this landmark still exist' everytime it has (good) reason to believe it may have changed link. > > Can we refer to the first scheme as 'link scoped identifier' and second as 'host scoped identifier' scheme? ;-) Landmark approach don't have to be host scoped. Many hosts can share the same landmark. > The question to ask is, whether the cost of establishing the unique link identifier among all the nodes (routers) in the link is worth to avoid an extra 'does this landmark still exists' question and answer? > > Link scoped identifier scheme requires completely securing the link so that nobody can spoof a RA message or confuse the link identifier, while we (I am not sure about this) may not need complete security as long as a secure association between the host and the current AR is good in the host scoped identifier approach. Even with host scoped (?) approach, if there is only the secure association between a host and the current AR, the host can't securely detect that a link change has happened. The host can't receive a secure message confirming a link change when it actually happens. JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 09:13:19 2004 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 JAA12862 for ; Thu, 11 Nov 2004 09:13:18 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4N9KR56U8XA0N6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 01:12:27 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E23F2AB543; Fri, 12 Nov 2004 01:12:24 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9DA324FB05; Fri, 12 Nov 2004 01:12:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABEBo523758 for dna-list; Fri, 12 Nov 2004 01:11:50 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABEBm623754 for ; Fri, 12 Nov 2004 01:11:48 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4N8HQZ0U8X4MUA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 01:11:32 +1100 Received: by localhost (Postfix, from userid 510) id B249280002; Fri, 12 Nov 2004 01:11:32 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 74A4C3C007 for ; Fri, 12 Nov 2004 01:11:30 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABEBSQK011523; Thu, 11 Nov 2004 09:11:28 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 73BC23C8158; Thu, 11 Nov 2004 09:09:31 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 6900F3C8155; Thu, 11 Nov 2004 09:09:31 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 09:11:28 -0500 Date: Thu, 11 Nov 2004 09:11:28 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <51fcf5715d.5715d51fcf@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:19 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.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT JinHyeock - > Landmark approach don't have to be host scoped. Many hosts can share the same landmark. It is the minimum requirement - similarly the same linkID can conceivably be used in more than one link (as long as they are further apart), I don't remember global uniqueness of LinkID being agreed upon. But, the linkID MUST ATLEAST BE the same within the link in one case (link scoped) and its enough if the host picks its own in the other (host scoped). > > > The question to ask is, whether the cost of establishing the > unique link identifier among all the nodes (routers) in the link > is worth to avoid an extra 'does this landmark still exists' > question and answer? > > > > Link scoped identifier scheme requires completely securing the > link so that nobody can spoof a RA message or confuse the link > identifier, while we (I am not sure about this) may not need > complete security as long as a secure association between the host > and the current AR is good in the host scoped identifier approach. > > Even with host scoped (?) approach, if there is only the secure > association between a host and the current AR, the host can't securely > detect that a link change has happened. The host can't receive a > secure > message confirming a link change when it actually happens. In the host scoped approach, link change is inferred when the current landmark is not confirmed by the network (timeout) - I know, packet loss will have the same effect as link change and this becomes a additional cost for host scoped approach. My only request is that we do a cost comparison (atleast a preliminary one) before deciding to go with either approach. with regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 09:34:40 2004 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 JAA15226 for ; Thu, 11 Nov 2004 09:34:39 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4O1GNLHU8X9VJC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 01:34:10 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 155C3AB542; Fri, 12 Nov 2004 01:34:07 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B79264FB08; Fri, 12 Nov 2004 01:34:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABEXvr24027 for dna-list; Fri, 12 Nov 2004 01:33:57 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABEXu624021 for ; Fri, 12 Nov 2004 01:33:57 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4O16WGOA8ZF7FB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 01:33:54 +1100 Received: by localhost (Postfix, from userid 510) id 141CE80002; Fri, 12 Nov 2004 01:33:54 +1100 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by larry.its.monash.edu.au (Postfix) with ESMTP id 01FE93C007 for ; Fri, 12 Nov 2004 01:33:52 +1100 (EST) Received: by rproxy.gmail.com with SMTP id c16so439894rne for ; Thu, 11 Nov 2004 06:33:50 -0800 (PST) Received: by 10.38.90.60 with SMTP id n60mr63519rnb; Thu, 11 Nov 2004 06:33:50 -0800 (PST) Received: by 10.38.125.23 with HTTP; Thu, 11 Nov 2004 06:33:50 -0800 (PST) Date: Thu, 11 Nov 2004 23:33:50 +0900 From: JinHyeock Choi Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <51fcf5715d.5715d51fcf@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Reply-to: JinHyeock Choi Message-id: <92e919fb04111106335404e6aa@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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=QAhjjCeis8+vVrSyDeWtePdKs7kc9W0O9slnAVxH/dOXRo2GMnOle7dpbmT72QK2tvvygMO8o9t8Id/q6Nw9N3k9EwF47rUtNY1ibAkqijXUgHPoI1QVK3FAMVko2BQM4SQqUPV2E0ANrzFqIfmO3x3Jzqlc6yhZtBvQGeBDGek= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <51fcf5715d.5715d51fcf@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya [omitted] > It is the minimum requirement - similarly the same linkID can conceivably be used in more than one link (as long as they are further apart), I don't remember global uniqueness of LinkID being agreed upon. But, the linkID MUST ATLEAST BE the same within the link in one case (link scoped) and its enough if the host picks its own in the other (host scoped). ok. Can I assume that now we have agreed that a link identifier must be the same within the link? > > Even with host scoped (?) approach, if there is only the secure > > association between a host and the current AR, the host can't securely > > detect that a link change has happened. The host can't receive a > > secure > > message confirming a link change when it actually happens. > > In the host scoped approach, link change is inferred when the current landmark is not confirmed by the network (timeout) - I know, packet loss will have the same effect as link change and this becomes a additional cost for host scoped approach. ok. I clarify my statement. Even with host scoped approach, if there is only the secure association between a host and the current AR, the host can't quickly detect that a link change has happened in secure manner. > My only request is that we do a cost comparison (atleast a preliminary one) before deciding to go with either approach. ok. I am afraid that timeout approach takes too much time that would result in service disruption. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 09:43:18 2004 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 JAA16255 for ; Thu, 11 Nov 2004 09:43:17 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4OC8G5EG90OKA8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 01:42:58 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 29083AB556; Fri, 12 Nov 2004 01:42:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id DC7CC4FB15; Fri, 12 Nov 2004 01:42:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABEgar24130 for dna-list; Fri, 12 Nov 2004 01:42:36 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABEga624126 for ; Fri, 12 Nov 2004 01:42:36 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4OBUL3MU90OK9R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 01:42:31 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 895ACAB542; Fri, 12 Nov 2004 01:42:29 +1100 (EST) Received: from [130.194.18.10] (vpn-student-18-10.its.monash.edu.au [130.194.18.10]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 5DD984FB16; Fri, 12 Nov 2004 01:42:27 +1100 (EST) Date: Fri, 12 Nov 2004 01:42:24 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41937A50.7080502@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Yes. The advantage in using a 'Link Identifier' with a scope > applicable to all the nodes in the network is that the host will be > able to determine whether it is on the same link or not from > receiving a single (RA) message. On the other hand, when such > identifier is not available, the host can ask the question 'does this > landmark still exist' everytime it has (good) reason to believe it > may have changed link. > > Can we refer to the first scheme as 'link scoped identifier' and > second as 'host scoped identifier' scheme? ;-) > > The question to ask is, whether the cost of establishing the unique > link identifier among all the nodes (routers) in the link is worth to > avoid an extra 'does this landmark still exists' question and answer? There may be extra cost in making all the routers on a link agree on a "link scoped identifier", but that is an out of band management cost. Using "does this landmark still exist" has a cost during movement in that there is no negative acknowledgement and we have to wait for a timer to expire if the link is new and the landmark does not still exist. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 09:47:20 2004 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 JAA16568 for ; Thu, 11 Nov 2004 09:47:19 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4OHEDNC48XA2O3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 01:47:00 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E1203AB557; Fri, 12 Nov 2004 01:46:57 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9EA814FB0A; Fri, 12 Nov 2004 01:46:57 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABEkn224196 for dna-list; Fri, 12 Nov 2004 01:46:49 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABEkm624192 for ; Fri, 12 Nov 2004 01:46:48 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4OGVXQ7K8XA2O3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 01:46:33 +1100 Received: by localhost (Postfix, from userid 510) id 37472AB542; Fri, 12 Nov 2004 01:46:33 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 041EA4FB11 for ; Fri, 12 Nov 2004 01:46:30 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABEkUIA012395; Thu, 11 Nov 2004 09:46:30 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 121073C8159; Thu, 11 Nov 2004 09:44:33 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 07E423C8158; Thu, 11 Nov 2004 09:44:33 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 09:46:29 -0500 Date: Thu, 11 Nov 2004 09:46:29 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Vijay Devarapalli , Pekka Nikander , Dna Message-id: <5739a542f4.542f45739a@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:97.10110 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.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Erik - > Indeed. > > But I think that we shouldn't constrain our thinking about the > latter to > the case when only one router can answer the question about the > landmark; one could have the routers share this so that any of > them can > answer the question. Agreed. I thought about this - it has some advantages. My concern with this is, by allowing any router to respond, we are brnging back the problem of requiring random-delay before RA response. With the current AR being the 'chosen' one to respond first, we could have the other routers go through the normal (or preferably a new) random process and this will help with mitigating the packet loss problem as well. > Why would the RAs that carry linkids need to be secured any more > than > RAs that carry prefixes and default router information? I don't > understand. > It might be that the Rtr-to-Rtr messages have different concerns > than > the RAs and other ND messages, but I haven't seen any semblance of > a > threat analysis that makes even this case. But that's separate > from the > RAs adverting linkids to hosts. Yeah - I was primarily referring to the Rtr-to-Rtr messages having different and possibly new set of concerns. I don't have any threat analysis on this either (thats why I was careful to qualify my earlier comment), but my gut feeling is that it adds new security requirements. I think we should look into this possible security overhead as part of the cost of doing link-scoped identifier. Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 09:48:45 2004 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 JAA16769 for ; Thu, 11 Nov 2004 09:48:44 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4OIG881W8ZF7MS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 01:47:53 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D177080002; Fri, 12 Nov 2004 01:47:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8C4EC3C010; Fri, 12 Nov 2004 01:47:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABEllu24233 for dna-list; Fri, 12 Nov 2004 01:47:47 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABElk624224 for ; Fri, 12 Nov 2004 01:47:46 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4OI75O2I8XA8M3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 01:47:37 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A2F4D80003; Fri, 12 Nov 2004 01:47:36 +1100 (EST) Received: from [130.194.18.10] (vpn-student-18-10.its.monash.edu.au [130.194.18.10]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 7C4323C00E; Fri, 12 Nov 2004 01:47:34 +1100 (EST) Date: Fri, 12 Nov 2004 01:47:31 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <4192D761.1020806@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Sathya Narayanan , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41937B83.8020605@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> <4192D761.1020806@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Sathya Narayanan wrote: > >> Yes. The advantage in using a 'Link Identifier' with a scope >> applicable to all the nodes in the network is that the host will be >> able to determine whether it is on the same link or not from >> receiving a single (RA) message. On the other hand, when such >> identifier is not available, the host can ask the question 'does this >> landmark still exist' everytime it has (good) reason to believe it >> may have changed link. >> >> Can we refer to the first scheme as 'link scoped identifier' and >> second as 'host scoped identifier' scheme? ;-) >> >> The question to ask is, whether the cost of establishing the unique >> link identifier among all the nodes (routers) in the link is worth to >> avoid an extra 'does this landmark still exists' question and answer? > > > Indeed. > > But I think that we shouldn't constrain our thinking about the latter to > the case when only one router can answer the question about the > landmark; one could have the routers share this so that any of them can > answer the question. > I agree that the routers on a link should share information. If they do, then isn't this similar to the cost of negotiating an explicit link identifier, but with the additional cost of maintaining the "landmark" information for the link as prefixes come and go? Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:06:22 2004 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 KAA19372 for ; Thu, 11 Nov 2004 10:06:21 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4P4NHBKK8X537P@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:06:07 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F1AE80002; Fri, 12 Nov 2004 02:05:42 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 533F13C005; Fri, 12 Nov 2004 02:05:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABF5dN24507 for dna-list; Fri, 12 Nov 2004 02:05:39 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABF5c624503 for ; Fri, 12 Nov 2004 02:05:38 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4P48208890OKC8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:05:22 +1100 Received: by localhost (Postfix, from userid 510) id 1B4DEAB556; Fri, 12 Nov 2004 02:05:22 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id D80A14FB06; Fri, 12 Nov 2004 02:05:20 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABF5KQj012915; Thu, 11 Nov 2004 10:05:20 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id F2ADB3C8158; Thu, 11 Nov 2004 10:03:22 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id E83A33C8155; Thu, 11 Nov 2004 10:03:22 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 10:05:19 -0500 Date: Thu, 11 Nov 2004 10:05:19 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <56bdb5924c.5924c56bdb@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:56.71853 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.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > There may be extra cost in making all the routers on a link agree on > a "link scoped identifier", but that is an out of band management > cost.Using "does this landmark still exist" has a cost during > movement in > that there is no negative acknowledgement and we have to wait for a > timer to expire if the link is new and the landmark does not still > exist. Yes. I agree. Few points: 1) For aguments sake, if we find out that the out-band cost is so high it is not going to be deployed in most scenarios, it still a bad idea to work on it. Again, my only request is that we do this cost analysis using some objective way to measure this cost. 2) Whether immediate change is detected in link-scoped identifier is actually not clear - this is primarily because of the non-dependency of the method on L2 trigger (and that is arguably a good thing), so the average gain in the detection time for link-scoped identifier approach MAY not be very high. Again, we need some analysis. 3) I am not recommending timeout as the only change detection - if you think about the mechanism proposed in RRD, when the 'landmark still exists?' question is asked, if you receive a 'this NEW landmark exists' answer thats an indication of link change. Ofcourse, you need to authenticate this response - but in most cases the router that responded is likely to be the router you are going to use as default router and you need to authenticate it anyway. with regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:06:41 2004 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 KAA19434 for ; Thu, 11 Nov 2004 10:06:40 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4P39U6U08X3PRG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:04:44 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 08128AB555; Fri, 12 Nov 2004 02:04:36 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A843A4FB09; Fri, 12 Nov 2004 02:04:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABF4Qk24470 for dna-list; Fri, 12 Nov 2004 02:04:26 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABF4P624466 for ; Fri, 12 Nov 2004 02:04:25 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4P2PR32W90OKC5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:04:10 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22EDAAB542; Fri, 12 Nov 2004 02:04:09 +1100 (EST) Received: from [130.194.18.10] (vpn-student-18-10.its.monash.edu.au [130.194.18.10]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id AEF134FB14; Fri, 12 Nov 2004 02:04:06 +1100 (EST) Date: Fri, 12 Nov 2004 02:04:03 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <51fcf5715d.5715d51fcf@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41937F63.6090106@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en References: <51fcf5715d.5715d51fcf@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > It is the minimum requirement - similarly the same linkID can > conceivably be used in more than one link (as long as they are > further apart), I don't remember global uniqueness of LinkID being > agreed upon. But, the linkID MUST ATLEAST BE the same within the link > in one case (link scoped) and its enough if the host picks its own in > the other (host scoped). How unique a LinkID has to be is a matter for debate, but I think the requirements are greater than link scope. Having the same LinkID on all routers on link provides the positive acknowledgement that "yes, this is the same link that I last received an RA from". This is not really any better than sending out an RS and getting an RA with a prefix that we have already seen. A LinkID needs to be unique within the set of links that a host might potentially move to (possibly within some limited timeframe) so that a change in the LinkID received from a previous one gives us the negative acknowledgement that "no, this is definitely not the same link as one we last received an RA from" (rather than having to wait for a timer to expire). Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:13:51 2004 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 KAA20459 for ; Thu, 11 Nov 2004 10:13:50 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PDNW7X090OKD7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:13:31 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 81E0DAB555; Fri, 12 Nov 2004 02:12:58 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 328C54FB0F; Fri, 12 Nov 2004 02:12:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFCju24621 for dna-list; Fri, 12 Nov 2004 02:12:45 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFCh624617 for ; Fri, 12 Nov 2004 02:12:44 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PD1965I8X57Z5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:12:29 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F282AB543; Fri, 12 Nov 2004 02:12:28 +1100 (EST) Received: from [130.194.18.10] (vpn-student-18-10.its.monash.edu.au [130.194.18.10]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id EA4B54FB0E; Fri, 12 Nov 2004 02:12:25 +1100 (EST) Date: Fri, 12 Nov 2004 02:12:22 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <56bdb5924c.5924c56bdb@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41938156.2040503@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) References: <56bdb5924c.5924c56bdb@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: >>There may be extra cost in making all the routers on a link agree on >>a "link scoped identifier", but that is an out of band management >>cost.Using "does this landmark still exist" has a cost during >>movement in >>that there is no negative acknowledgement and we have to wait for a >>timer to expire if the link is new and the landmark does not still >>exist. > > Yes. I agree. > > Few points: > 1) For aguments sake, if we find out that the out-band cost is so high it is not going to be deployed in most scenarios, it still a bad idea to work on it. Again, my only request is that we do this cost analysis using some objective way to measure this cost. Agreed. > 2) Whether immediate change is detected in link-scoped identifier is actually not clear - this is primarily because of the non-dependency of the method on L2 trigger (and that is arguably a good thing), so the average gain in the detection time for link-scoped identifier approach MAY not be very high. Again, we need some analysis. I think this is a separate problem. The point is in being able to make a correct decision based on the reception of a single RA. How you get that RA is a separate problem. > 3) I am not recommending timeout as the only change detection - if you think about the mechanism proposed in RRD, when the 'landmark still exists?' question is asked, if you receive a 'this NEW landmark exists' answer thats an indication of link change. Ofcourse, you need to authenticate this response - but in most cases the router that responded is likely to be the router you are going to use as default router and you need to authenticate it anyway. I can't remember the details of RRD - are you saying that there is a way for an RA with a prefix that you haven't seen before indicates a link change as oposed to a new router on the same link? Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:13:53 2004 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 KAA20478 for ; Thu, 11 Nov 2004 10:13:51 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PDUB89C90OKD7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:13:32 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1EE9AAB546; Fri, 12 Nov 2004 02:13:07 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AB9FB4FB0E; Fri, 12 Nov 2004 02:13:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFCsd24628 for dna-list; Fri, 12 Nov 2004 02:12:54 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFCs624624 for ; Fri, 12 Nov 2004 02:12:54 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4PDCN3HE8ZF7N9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:12:44 +1100 Received: by localhost (Postfix, from userid 510) id AB0FCAB542; Fri, 12 Nov 2004 02:12:43 +1100 (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 9E3A54FB0A; Fri, 12 Nov 2004 02:12:41 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iABFCes3004651; Thu, 11 Nov 2004 07:12:40 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABFCdtL901921; Thu, 11 Nov 2004 07:12:39 -0800 (PST) Date: Thu, 11 Nov 2004 07:13:30 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <41937A50.7080502@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Sathya Narayanan , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <4193819A.7060909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> <41937A50.7080502@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett Pentland wrote: > There may be extra cost in making all the routers on a link agree on > a "link scoped identifier", but that is an out of band management cost. > Using "does this landmark still exist" has a cost during movement in > that there is no negative acknowledgement and we have to wait for a > timer to expire if the link is new and the landmark does not still > exist. While the timeout is the case in the current rrd draft, it isn't a fundamental property of landmark-based schemes. For instance, in a landmark scheme the routers on the link can share the landmarks they have so that any router can respond. If you do this, a RS containing a landmark can be responded by any router, whether on the same link or not. If on the same link the router would respond "yes, this landmark is on this link" and if its it a different link the router would respond "no". Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:16:02 2004 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 KAA20857 for ; Thu, 11 Nov 2004 10:16:01 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4PGWMK4W8XAHJB@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:15:40 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 85931AB547; Fri, 12 Nov 2004 02:15:35 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2E0624FB02; Fri, 12 Nov 2004 02:15:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFFTE24723 for dna-list; Fri, 12 Nov 2004 02:15:29 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFFT624719 for ; Fri, 12 Nov 2004 02:15:29 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PGGHO968X57Z5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:15:14 +1100 Received: by localhost (Postfix, from userid 510) id F1EBAAB554; Fri, 12 Nov 2004 02:15:13 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id F18C44FB0F; Fri, 12 Nov 2004 02:15:11 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABFFAWr013187; Thu, 11 Nov 2004 10:15:10 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 64FC63C8158; Thu, 11 Nov 2004 10:13:13 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 593333C8155; Thu, 11 Nov 2004 10:13:13 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 10:15:10 -0500 Date: Thu, 11 Nov 2004 10:15:10 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: JinHyeock Choi , Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <53dda5303b.5303b53dda@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:26.72286 C:21 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > A LinkID needs to be unique within the set of links that a host might > potentially move to (possibly within some limited timeframe) so > that a > change in the LinkID received from a previous one gives us the > negativeacknowledgement that "no, this is definitely not the same > link as one > we last received an RA from" (rather than having to wait for a > timer to > expire). I just want to re-state this - time window involved here can be very small and the moment you receive a response wiht NEW landmark before your current landmark is confirmed by your current router you can infer link-change. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:25:40 2004 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 KAA22235 for ; Thu, 11 Nov 2004 10:25:39 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PSWIR3U90OKEK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:25:31 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE95BAB557; Fri, 12 Nov 2004 02:25:15 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6417A4FB0A; Fri, 12 Nov 2004 02:25:15 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFPD124869 for dna-list; Fri, 12 Nov 2004 02:25:13 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFPD624865 for ; Fri, 12 Nov 2004 02:25:13 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PSI1C5Y90OKEK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:24:56 +1100 Received: by localhost (Postfix, from userid 510) id 7662180006; Fri, 12 Nov 2004 02:24:56 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2D8153C011; Fri, 12 Nov 2004 02:24:55 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABFOscW013469; Thu, 11 Nov 2004 10:24:54 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 4539D3C8158; Thu, 11 Nov 2004 10:22:57 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 3AA393C8155; Thu, 11 Nov 2004 10:22:57 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 10:24:54 -0500 Date: Thu, 11 Nov 2004 10:24:54 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <55b2157b0c.57b0c55b21@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT > > 2) Whether immediate change is detected in link-scoped > identifier is actually not clear - this is primarily because of > the non-dependency of the method on L2 trigger (and that is > arguably a good thing), so the average gain in the detection time > for link-scoped identifier approach MAY not be very high. Again, > we need some analysis. > > I think this is a separate problem. The point is in being able to > makea correct decision based on the reception of a single RA. How > you get that RA is a separate problem. Yes. It is a separate problem, but when we are talking (comparing) the quickness of link-change-detection we need to look at the complete picture. If the link-scoped approach has the property of link-change-detection when a unsolicited RA is received (which is a good thing about it), but how useful is it if you need the RS message to initiate it for rapid-detection is a valid point to consider in terms of the cost. If the link-scoped approach depends on a RS message, than host-scoped approach is (arguably) as good as the link-scoped approach with less out-of-band cost. > > 3) I am not recommending timeout as the only change detection - > if you think about the mechanism proposed in RRD, when the > 'landmark still exists?' question is asked, if you receive a 'this > NEW landmark exists' answer thats an indication of link change. > Ofcourse, you need to authenticate this response - but in most > cases the router that responded is likely to be the router you are > going to use as default router and you need to authenticate it anyway. > > I can't remember the details of RRD - are you saying that there is > a way > for an RA with a prefix that you haven't seen before indicates a link > change as oposed to a new router on the same link? Yes - if we can design a mechnism that with a high probability can ensure that the confirmation of current landmark (from current AR) is likely to happen before any other router responds. Thats what I am trying to achieve with my MaxDelayForCurrRouter and MinDelayForOtherRouters variables. If these two variables are equal to zero, the probability is 1 - packet loss probability and the time window involved can be few milli-seconds (this needs to be confirmed using simulations, ofcourse). Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:28:52 2004 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 KAA22503 for ; Thu, 11 Nov 2004 10:28:51 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4PRVY2RC8ZF5H9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:24:29 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8DC9AB556; Fri, 12 Nov 2004 02:24:26 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 27F134FB0C; Fri, 12 Nov 2004 02:24:25 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFOHX24842 for dna-list; Fri, 12 Nov 2004 02:24:17 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFOH624838 for ; Fri, 12 Nov 2004 02:24:17 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4PRJP0D88ZF7N9@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:24:10 +1100 Received: by localhost (Postfix, from userid 510) id 5FDFEAB542; Fri, 12 Nov 2004 02:24:10 +1100 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2BB0E4FB10 for ; Fri, 12 Nov 2004 02:24:08 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.81.144]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iABFO7ui004620; Thu, 11 Nov 2004 08:24:07 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABFO6Zg906368; Thu, 11 Nov 2004 07:24:06 -0800 (PST) Date: Thu, 11 Nov 2004 07:24:57 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <5739a542f4.542f45739a@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41938449.9070504@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <5739a542f4.542f45739a@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Agreed. I thought about this - it has some advantages. My concern > with this is, by allowing any router to respond, we are brnging back > the problem of requiring random-delay before RA response. With the > current AR being the 'chosen' one to respond first, we could have the > other routers go through the normal (or preferably a new) random > process and this will help with mitigating the packet loss problem as > well. Yes, but don't we want an immediate RA whether on the same link or on a different link? (Making sure we agree on the goal.) If we do, we can't restrict things so that only an old router can respond, since on a new link the old router would not be present. Thus we need to allow any router to respond and use some other technique to avoid the random delay. We have at least an existence proof that such techniques are possible in DET. > Yeah - I was primarily referring to the Rtr-to-Rtr messages having > different and possibly new set of concerns. I don't have any threat > analysis on this either (thats why I was careful to qualify my > earlier comment), but my gut feeling is that it adds new security > requirements. I think we should look into this possible security > overhead as part of the cost of doing link-scoped identifier. You can't think about the security overhead without knowing what to secure which requires some idea of the threats. I don't think this is particularly complicated - just requires sitting down seeing what an attacker can accomplish by spoofing the linkid to the routers. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:29:27 2004 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 KAA22571 for ; Thu, 11 Nov 2004 10:29:26 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4PXJ5CSS8ZF69Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:29:02 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C5B90AB544; Fri, 12 Nov 2004 02:28:59 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 771834FB02; Fri, 12 Nov 2004 02:28:59 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFSu124935 for dna-list; Fri, 12 Nov 2004 02:28:56 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFSt624930 for ; Fri, 12 Nov 2004 02:28:55 +1100 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4PX9202I8X152I@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:28:46 +1100 Received: by localhost (Postfix, from userid 510) id 52E70AB554; Fri, 12 Nov 2004 02:28:46 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3F1104FB0A; Fri, 12 Nov 2004 02:28:45 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABFSiro013560; Thu, 11 Nov 2004 10:28:44 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 58C3E3C8159; Thu, 11 Nov 2004 10:26:47 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 4E06E3C8158; Thu, 11 Nov 2004 10:26:47 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 10:28:44 -0500 Date: Thu, 11 Nov 2004 10:28:44 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <59354558b1.558b159354@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:53.62939 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.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Erik - > While the timeout is the case in the current rrd draft, it isn't a > fundamental property of landmark-based schemes. Just to set the record straight, timeout is not the case in current RRD draft. I agree with you that it is not a fundamental property of 'host-scoped' ;-)scheme. I mentioned timeout in response to a specific question. > For instance, in a landmark scheme the routers on the link can > share the > landmarks they have so that any router can respond. If you do > this, a RS > containing a landmark can be responded by any router, whether on > the > same link or not. If on the same link the router would respond > "yes, > this landmark is on this link" and if its it a different link the > router > would respond "no". I am not sure I like where you are going with this. You are slowly moving the landmark towards becoming 'link-scoped' identifier. - Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 10:42:40 2004 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 KAA24027 for ; Thu, 11 Nov 2004 10:42:39 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4QELHYHQ8X4BOC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 02:42:23 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4908DAB544; Fri, 12 Nov 2004 02:41:58 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EE7BF4FB02; Fri, 12 Nov 2004 02:41:57 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABFfkx25137 for dna-list; Fri, 12 Nov 2004 02:41:46 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABFfj625133 for ; Fri, 12 Nov 2004 02:41:46 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4QDZW4YA8XA107@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 02:41:29 +1100 Received: by localhost (Postfix, from userid 510) id 772A780003; Fri, 12 Nov 2004 02:41:29 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 44E8C3C010 for ; Fri, 12 Nov 2004 02:41:27 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABFfQvl014205 for ; Thu, 11 Nov 2004 10:41:26 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id B35B13C8163 for ; Thu, 11 Nov 2004 10:39:23 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id DF51C3C816Bfor ; Thu, 11 Nov 2004 10:38:25 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 10:40:21 -0500 Date: Thu, 11 Nov 2004 10:40:21 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <53d28571e7.571e753d28@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:80.97670 C:21 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT Erik - > Yes, but don't we want an immediate RA whether on the same link or > on a > different link? (Making sure we agree on the goal.) I am going to take the risk and suggest that how immediate the response is generated should also be part of the cost analysis. i.e. if we can guarantee a response within say 10 ms, but save a lot of overhead based on this compromise rather than requiring the response to be immediate, I think we should consider it. > You can't think about the security overhead without knowing what > to > secure which requires some idea of the threats. I don't think this > is > particularly complicated - just requires sitting down seeing what > an > attacker can accomplish by spoofing the linkid to the routers. Agreed. We should do this ( I will try to work on this). thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 11:20:14 2004 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 LAA27400 for ; Thu, 11 Nov 2004 11:20:12 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4RP3GDHO8ZF6AK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 03:19:31 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9384BAB554; Fri, 12 Nov 2004 03:19:27 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4935B4FB0F; Fri, 12 Nov 2004 03:19:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABGJ5625553 for dna-list; Fri, 12 Nov 2004 03:19:05 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABGJ3625549 for ; Fri, 12 Nov 2004 03:19:03 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4ROHGSFY8ZF6AK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 03:18:58 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22E31AB554; Fri, 12 Nov 2004 03:18:58 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 01F9F4FB0B; Fri, 12 Nov 2004 03:18:58 +1100 (EST) Received: from [130.129.133.216] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 12 Nov 2004 03:18:57 +1100 Date: Fri, 12 Nov 2004 03:18:57 +1100 From: Greg Daley Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Brett Pentland , Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <73172972c7f3.72c7f3731729@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-disposition: inline Content-transfer-encoding: 7BIT Precedence: bulk X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Sathya, ----- Original Message ----- From: Sathya Narayanan Date: Friday, November 12, 2004 2:24 am Subject: Re: [DNA] Confirming today's face-to-face meeting decisions > > > > 2) Whether immediate change is detected in link-scoped > > identifier is actually not clear - this is primarily because of > > the non-dependency of the method on L2 trigger (and that is > > arguably a good thing), so the average gain in the detection time > > for link-scoped identifier approach MAY not be very high. Again, > > we need some analysis. > > > > I think this is a separate problem. The point is in being able > to > > makea correct decision based on the reception of a single RA. > How > > you get that RA is a separate problem. > Yes. It is a separate problem, but when we are talking (comparing) > the quickness of link-change-detection we need to look at the > complete picture. If the link-scoped approach has the property of > link-change-detection when a unsolicited RA is received (which is a > good thing about it), but how useful is it if you need the RS > message to initiate it for rapid-detection is a valid point to > consider in terms of the cost. If the link-scoped approach depends > on a RS message, than host-scoped approach is (arguably) as good as > the link-scoped approach with less out-of-band cost. > L2 Trigger isn't needed, if in MIPv6 the RA rate is 20/second. In this case, the only issue is establishment of trust with the router, which is a problem in both cases. > > > 3) I am not recommending timeout as the only change detection - > > if you think about the mechanism proposed in RRD, when the > > 'landmark still exists?' question is asked, if you receive a > 'this > > NEW landmark exists' answer thats an indication of link change. > > Ofcourse, you need to authenticate this response - but in most > > cases the router that responded is likely to be the router you > are > > going to use as default router and you need to authenticate it > anyway.> > > I can't remember the details of RRD - are you saying that there > is > > a way > > for an RA with a prefix that you haven't seen before indicates a > link> change as oposed to a new router on the same link? > Yes - if we can design a mechnism that with a high probability can > ensure that the confirmation of current landmark (from current AR) > is likely to happen before any other router responds. Thats what I > am trying to achieve with my MaxDelayForCurrRouter and > MinDelayForOtherRouters variables. If these two variables are equal > to zero, the probability is 1 - packet loss probability and the > time window involved can be few milli-seconds (this needs to be > confirmed using simulations, ofcourse). There's a reliance on Positive Ack here in the case where there's no negotiation amongst peers. Packet loss is obviously a considerable factor, but it's not clear without simulation whether the false positive movement in this case causes more work or harm than the cost of explicitly changed LinkIDs. Where there is any trust or knowledge of the prefixes or router id's on a link, this has exactly the same issue as Link Identification in establishing trust between routers as Link ID. These approaches Explicit LinkID and Landmarks are still likely to be required in backwards compatability for non LinkID routers on the same or different link. For hosts which need landmarks it's possibly worthwhile working along the lines of confidence intervals somewhat like CPL. If we're confident that the landmarks are representative of the link (Link ID stored for a while across RS/RA, routerids stored), then any response which doesn't match the stored landmarks may be acted upon immediately. If we're not sure, but have an indication throgh reception of a non matching landmark, then we should check the reachability of the landmark explicitly (possibly with hysteresis). This may require a further test or waiting for a timeout... Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 11:24:47 2004 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 LAA27740 for ; Thu, 11 Nov 2004 11:24:46 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4RVF90O08ZF7VS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 03:24:36 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B152EAB543; Fri, 12 Nov 2004 03:24:33 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 65A374FB05; Fri, 12 Nov 2004 03:24:33 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABGON725641 for dna-list; Fri, 12 Nov 2004 03:24:23 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABGON625636 for ; Fri, 12 Nov 2004 03:24:23 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4RUUSWRM8X4NMQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 03:24:06 +1100 Received: by localhost (Postfix, from userid 510) id 6619C80002; Fri, 12 Nov 2004 03:24:06 +1100 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by larry.its.monash.edu.au (Postfix) with ESMTP id 452113C007; Fri, 12 Nov 2004 03:24:04 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.87.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iABGO3NH022215; Thu, 11 Nov 2004 09:24:03 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABGO17r936738; Thu, 11 Nov 2004 08:24:02 -0800 (PST) Date: Thu, 11 Nov 2004 08:24:53 -0800 From: Erik Nordmark Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <59354558b1.558b159354@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Brett Pentland , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41939255.1070901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <59354558b1.558b159354@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > Just to set the record straight, timeout is not the case in current > RRD draft. I agree with you that it is not a fundamental property of > 'host-scoped' ;-)scheme. I mentioned timeout in response to a > specific question. Sorry for jumping to conclusions about rrd based on what we were discussing. > I am not sure I like where you are going with this. You are slowly > moving the landmark towards becoming 'link-scoped' identifier. And what's the problem? Physical landmarks might be visible from a long distance, or might be the mailbox next to starbucks down the road (at least if you stretch the definition). And since I started using the "landmark" term I get first dibs on its definition :-) More seriously, if we are concerned about the issues around routers agreeing on a single number, then allowing there to be multiple numbers removes that problem. I the interest of making progress it is useful to try to understand what we see as desirable properties of a solution, and I don't see how your comment above helps with this. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 11:30:22 2004 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 LAA28194 for ; Thu, 11 Nov 2004 11:30:20 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4S2O8W208X4NMQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 03:29:58 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8E0FF80002; Fri, 12 Nov 2004 03:29:37 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4370F3C006; Fri, 12 Nov 2004 03:29:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABGTVk25718 for dna-list; Fri, 12 Nov 2004 03:29:31 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABGTV625714 for ; Fri, 12 Nov 2004 03:29:31 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4S2EJQ2O8X4NMQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 03:29:24 +1100 Received: by localhost (Postfix, from userid 510) id 9E0A280002; Fri, 12 Nov 2004 03:29:24 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6578B3C00E; Fri, 12 Nov 2004 03:29:22 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iABGTLKs015518; Thu, 11 Nov 2004 11:29:21 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 7FFDA3C8159; Thu, 11 Nov 2004 11:27:24 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id 74D0E3C8158; Thu, 11 Nov 2004 11:27:24 -0500 (EST) Received: from [130.129.134.38] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Thu, 11 Nov 2004 11:29:21 -0500 Date: Thu, 11 Nov 2004 11:29:21 -0500 From: Sathya Narayanan Subject: Re: [DNA] Confirming today's face-to-face meeting decisions Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <5a1fe555e6.555e65a1fe@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:63.58122 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.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT Erik - > And what's the problem? No problem at all. It was just a comment ;-) > I the interest of making progress it is useful to try to > understand what > we see as desirable properties of a solution, and I don't see how > your comment above helps with this. Only in the sense that, we need to be careful not to become dependent on all the routers agreeing on the same landmark - thats why I said 'towards'. thanks, Sathya From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 12:05:19 2004 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 MAA02294 for ; Thu, 11 Nov 2004 12:05:18 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4TAB8HQS8ZF4QV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 04:04:59 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7C785AB545; Fri, 12 Nov 2004 04:04:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id B508E4FB15; Fri, 12 Nov 2004 04:04:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABH4fw26295 for dna-list; Fri, 12 Nov 2004 04:04:41 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABH4d626291 for ; Fri, 12 Nov 2004 04:04:39 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4T9RNGNK90OK9Y@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 12 Nov 2004 04:04:28 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B62C2AB558; Fri, 12 Nov 2004 04:04:20 +1100 (EST) Received: from [130.194.18.1] (vpn-student-18-1.its.monash.edu.au [130.194.18.1]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 5C9FA4FB1B; Fri, 12 Nov 2004 04:04:18 +1100 (EST) Date: Fri, 12 Nov 2004 04:04:13 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <53dda5303b.5303b53dda@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: JinHyeock Choi , Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41939B8D.3000905@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en References: <53dda5303b.5303b53dda@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: >>A LinkID needs to be unique within the set of links that a host might >>potentially move to (possibly within some limited timeframe) so >>that a >>change in the LinkID received from a previous one gives us the >>negativeacknowledgement that "no, this is definitely not the same >>link as one >>we last received an RA from" (rather than having to wait for a >>timer to >>expire). > > I just want to re-state this - time window involved here can be very small and the moment you receive a response wiht NEW landmark before your current landmark is confirmed by your current router you can infer link-change. > > - Sathya > By "landmark" are we talking about prefixes? If so, the reception of a new one may be an indication that a link change has occured, but is certainly not confirmation of that. It might just be a new prefix. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 12:06:27 2004 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 MAA02460 for ; Thu, 11 Nov 2004 12:06:26 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4T7RHH7M8X5352@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 04:04:50 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BFC1AAB557; Fri, 12 Nov 2004 04:02:44 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 52DCD4FB0A; Fri, 12 Nov 2004 04:02:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABH2Re26254 for dna-list; Fri, 12 Nov 2004 04:02:27 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABH2N626247 for ; Fri, 12 Nov 2004 04:02:24 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4T6CFUOE8ZF6IK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 04:01:37 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 92D98AB543; Fri, 12 Nov 2004 04:01:36 +1100 (EST) Received: from [130.194.18.1] (vpn-student-18-1.its.monash.edu.au [130.194.18.1]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 633EA4FB0E; Fri, 12 Nov 2004 04:01:34 +1100 (EST) Date: Fri, 12 Nov 2004 04:01:30 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <4193819A.7060909@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Sathya Narayanan , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41939AEA.7080003@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) References: <529205157e.5157e52920@pintlmail.MITL.Research.Panasonic.COM> <41937A50.7080502@eng.monash.edu.au> <4193819A.7060909@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Brett Pentland wrote: > >> There may be extra cost in making all the routers on a link agree on >> a "link scoped identifier", but that is an out of band management cost. >> Using "does this landmark still exist" has a cost during movement in >> that there is no negative acknowledgement and we have to wait for a >> timer to expire if the link is new and the landmark does not still >> exist. > > > While the timeout is the case in the current rrd draft, it isn't a > fundamental property of landmark-based schemes. > > For instance, in a landmark scheme the routers on the link can share the > landmarks they have so that any router can respond. If you do this, a RS > containing a landmark can be responded by any router, whether on the > same link or not. If on the same link the router would respond "yes, > this landmark is on this link" and if its it a different link the router > would respond "no". > > Erik Ok, fair enough. It does require a little work from the routers to make sure that they know that landmarks they have seen on the link are still current, but that's certainly doable. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 11 12:23:30 2004 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 MAA04624 for ; Thu, 11 Nov 2004 12:23:29 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LH4TWNIBIW8X4PQZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 12 Nov 2004 04:23:00 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B06180006; Fri, 12 Nov 2004 04:22:49 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id C9C123C009; Fri, 12 Nov 2004 04:22:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iABHMDS26646 for dna-list; Fri, 12 Nov 2004 04:22:13 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iABHM8626642 for ; Fri, 12 Nov 2004 04:22:08 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LH4TVQ1GUQ8XA7OS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 12 Nov 2004 04:22:04 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 44423AB542; Fri, 12 Nov 2004 04:22:04 +1100 (EST) Received: from [130.194.18.1] (vpn-student-18-1.its.monash.edu.au [130.194.18.1]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 29F3E4FB0D; Fri, 12 Nov 2004 04:22:02 +1100 (EST) Date: Fri, 12 Nov 2004 04:21:59 +1100 From: Brett Pentland Subject: Re: [DNA] Confirming today's face-to-face meeting decisions In-reply-to: <55b2157b0c.57b0c55b21@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Erik Nordmark , Vijay Devarapalli , Pekka Nikander , Dna Message-id: <41939FB7.9070008@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) References: <55b2157b0c.57b0c55b21@pintlmail.MITL.Research.Panasonic.COM> Content-Transfer-Encoding: 7BIT Sathya Narayanan wrote: > > >>> 2) Whether immediate change is detected in link-scoped >> >> identifier is actually not clear - this is primarily because of the >> non-dependency of the method on L2 trigger (and that is arguably a >> good thing), so the average gain in the detection time for >> link-scoped identifier approach MAY not be very high. Again, we >> need some analysis. >> >> I think this is a separate problem. The point is in being able to >> makea correct decision based on the reception of a single RA. How >> you get that RA is a separate problem. > > Yes. It is a separate problem, but when we are talking (comparing) > the quickness of link-change-detection we need to look at the > complete picture. If the link-scoped approach has the property of > link-change-detection when a unsolicited RA is received (which is a > good thing about it), but how useful is it if you need the RS message > to initiate it for rapid-detection is a valid point to consider in > terms of the cost. If the link-scoped approach depends on a RS > message, than host-scoped approach is (arguably) as good as the > link-scoped approach with less out-of-band cost. > I'm not sure I understand your point. Yes, I agree that the whole picture needs to be considered, but aren't we comparing two things that depend on receiving RAs. If so, then isn't the time taken to get them the same in each case? Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 05:05:10 2004 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 FAA07269 for ; Wed, 17 Nov 2004 05:05:09 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHCSB4CHLM91WPYV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 17 Nov 2004 21:02:55 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DEA4AB555; Wed, 17 Nov 2004 21:02:46 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 11B264FB0B; Wed, 17 Nov 2004 21:02:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHA1RH12222 for dna-list; Wed, 17 Nov 2004 21:01:27 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHA1P612218 for ; Wed, 17 Nov 2004 21:01:25 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHCS9FWPE88ZFD8F@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 17 Nov 2004 21:01:25 +1100 Received: by localhost (Postfix, from userid 510) id 56713AB554; Wed, 17 Nov 2004 21:01:25 +1100 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by moe.its.monash.edu.au (Postfix) with ESMTP id 01F794FB04 for ; Wed, 17 Nov 2004 21:01:20 +1100 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAHA1HvD022616 for ; Wed, 17 Nov 2004 11:01:17 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 11:01:16 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 11:01:16 +0100 Date: Wed, 17 Nov 2004 10:46:26 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: [DNA] IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Soliman, Hesham'" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 17 Nov 2004 10:01:16.0340 (UTC) FILETIME=[60B85F40:01C4CC8C] Content-Transfer-Encoding: 7BIT > > > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > > > > > And the same is (obviously) true for UMTS as well... > > > > > > => The RAs are sent (at least according to the specs) but what you > > > might be seeing is that the RA is only sent to the phone and is not > > > forwarded to the laptop. So the laptop only sees a PPP connection. > > > > There is still the question of how the LAPTOP gets the IPv6 > > prefix without > > RA. Since PPP IPv6CP standards don't specify this, I'm at a loss to > > explain it. > > => It doesn't get the prefix in this model. > It can only get the prefix if PPP is not there. If, for instance, > a bluetooth PAN profile is used, then it can get the prefix through > an RA. The phone would be acting like a router in this case. > > Hesham I thought that there was something wrong with my setup and I came to the conclusion that RAs are indeed sent but I just couldn't see them. However, this was not a correct conclusion either. From the network administrators I learn that RAs never reach the phone because a firewall on their GPRS network side blocks them. I was indeed confused: no RAs and no option in PPP to negotiate a prefix and still the laptop had a global address. Took awhile to realize that there is a component missing from the picture and that is RADIUS (RADIUS and IPv6 -- rfc3162). Now the setup starts to make sense: the phone gets an address via a PDP context and it's delivered to the phone by using RADIUS. Does this sound reasonable or am I still in error? BR, Tero From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 09:41:20 2004 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 JAA03622 for ; Wed, 17 Nov 2004 09:41:19 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD1YH7QTA8X6JMY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 01:39:49 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6909FAB559; Thu, 18 Nov 2004 01:39:41 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id EFC0A4FB02; Thu, 18 Nov 2004 01:39:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHEc5w15546 for dna-list; Thu, 18 Nov 2004 01:38:05 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHEc4615542 for ; Thu, 18 Nov 2004 01:38:04 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD1W5SAZK8X6RJA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 01:37:49 +1100 Received: by localhost (Postfix, from userid 510) id A0ADDAB542; Thu, 18 Nov 2004 01:37:49 +1100 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id B79104FB03 for ; Thu, 18 Nov 2004 01:37:47 +1100 (EST) Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CUQwK-0007eW-FQ; Wed, 17 Nov 2004 09:37:44 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id iAHEbgQ31911; Wed, 17 Nov 2004 06:37:42 -0800 Date: Wed, 17 Nov 2004 06:37:42 -0800 (PST) From: Bernard Aboba Subject: Re: [DNA] IPv6 over PPP over GPRS -- once again In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: "'Soliman, Hesham'" , Dna Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT > Took awhile to realize that there is a component missing from the picture and that > is RADIUS (RADIUS and IPv6 -- rfc3162). Now the setup starts to make > sense: the phone gets an address via a PDP context and it's delivered to > the phone by using RADIUS. Does this sound reasonable or am I still in > error? This would surprise me, since if it were true, then every phone would need to be provisioned with a RADIUS shared secret, which I doubt. The NAS-IPv6-Address attribute is meant to be sent from server to client, not the other way around, so IPv6 addresses can't be assigned that way. There are Framed-Interface-Id and Framed-IPv6-Prefix attributes, but those are meant to be consumed by a NAS in order to inform its PPP Link-Identifier negotation and RA, respectively. Sounds like we are witnessing the "immaculate configuration"! From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 11:13:13 2004 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 LAA13616 for ; Wed, 17 Nov 2004 11:13:12 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD55F241W8X67ML@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 03:11:07 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CE30AB555; Thu, 18 Nov 2004 03:10:47 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2A4614FB09; Thu, 18 Nov 2004 03:10:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHG8t416502 for dna-list; Thu, 18 Nov 2004 03:08:55 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHG8t616498 for ; Thu, 18 Nov 2004 03:08:55 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD52XSENG8ZFDGC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 18 Nov 2004 03:08:48 +1100 Received: by localhost (Postfix, from userid 510) id 0B63280002; Thu, 18 Nov 2004 03:08:48 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by larry.its.monash.edu.au (Postfix) with ESMTP id CE4D93C003 for ; Thu, 18 Nov 2004 03:08:45 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 11:08:33 -0500 Date: Wed, 17 Nov 2004 11:08:33 -0500 From: "Soliman, Hesham" Subject: [DNA] RE: IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: IPv6 over PPP over GPRS -- once again Thread-Index: AcTMjGGXzJri9Jx3Qfy846k+sOBXfQAMyj7Q Content-Class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 17 Nov 2004 16:08:33.0572 (UTC) FILETIME=[AFEF1E40:01C4CCBF] Content-Transfer-Encoding: 7BIT Tero, I think RADIUS only comes into the picture if you're running PPP over the air. Are you? I thought it was only between the phone and laptop. But if you're running it over the air then it's a completely different story. Hesham > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: Wednesday, November 17, 2004 4:46 AM > To: Soliman, Hesham; Bernard Aboba > Cc: Dna > Subject: IPv6 over PPP over GPRS -- once again > > > > > > > LAPTOP <-- PPP --> PHONE <---- GPRS ----> GGSN > > > > > > > > > > And the same is (obviously) true for UMTS as well... > > > > > > > > => The RAs are sent (at least according to the specs) > but what you > > > > might be seeing is that the RA is only sent to the > phone and is not > > > > forwarded to the laptop. So the laptop only sees a > PPP connection. > > > > > > There is still the question of how the LAPTOP gets the IPv6 > > > prefix without > > > RA. Since PPP IPv6CP standards don't specify this, I'm > at a loss to > > > explain it. > > > > => It doesn't get the prefix in this model. > > It can only get the prefix if PPP is not there. If, for instance, > > a bluetooth PAN profile is used, then it can get the prefix through > > an RA. The phone would be acting like a router in this case. > > > > Hesham > > I thought that there was something wrong with my setup and I > came to the conclusion that RAs are indeed sent but I just > couldn't see them. However, this was not a correct > conclusion either. From the network administrators I learn > that RAs never reach the phone because a firewall on their > GPRS network side blocks them. I was indeed confused: no RAs > and no option in PPP to negotiate a prefix and still the > laptop had a global address. > > Took awhile to realize that there is a component missing > from the picture and that is RADIUS (RADIUS and IPv6 -- > rfc3162). Now the setup starts to make sense: the phone gets > an address via a PDP context and it's delivered to the phone > by using RADIUS. Does this sound reasonable or am I still in error? > > BR, > > Tero > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 11:21:05 2004 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 LAA14857 for ; Wed, 17 Nov 2004 11:21:04 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD5B8610A8XBEGF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 03:15:33 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B880C80006; Thu, 18 Nov 2004 03:15:28 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 706703C002; Thu, 18 Nov 2004 03:15:28 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHGFMM16606 for dna-list; Thu, 18 Nov 2004 03:15:22 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHGFM616602 for ; Thu, 18 Nov 2004 03:15:22 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD5AS11AK8ZF8IQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 18 Nov 2004 03:15:07 +1100 Received: by localhost (Postfix, from userid 510) id 44F24AB554; Thu, 18 Nov 2004 03:15:07 +1100 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by moe.its.monash.edu.au (Postfix) with ESMTP id EE4844FB0B for ; Thu, 18 Nov 2004 03:15:03 +1100 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAHGExvD003991 for ; Wed, 17 Nov 2004 17:14:59 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 17:14:57 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 17:14:58 +0100 Date: Wed, 17 Nov 2004 17:14:56 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: [DNA] RE: IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Soliman, Hesham'" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-OriginalArrivalTime: 17 Nov 2004 16:14:57.0991 (UTC) FILETIME=[9510CD70:01C4CCC0] X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > Tero, Hi Hesham, > > I think RADIUS only comes into the picture if you're running > PPP over the air. Are you? I thought it was only between the > phone and laptop. But if you're running it over the air > then it's a completely different story. No, I am not. It's between the phone and laptop. Well, this is getting really strange... Tero From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 11:21:06 2004 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 LAA14867 for ; Wed, 17 Nov 2004 11:21:05 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD5CZU5348XB66G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 03:17:00 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 673D580003; Thu, 18 Nov 2004 03:16:54 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1A4D23C002; Thu, 18 Nov 2004 03:16:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHGGpa16643 for dna-list; Thu, 18 Nov 2004 03:16:51 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHGGo616639 for ; Thu, 18 Nov 2004 03:16:50 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD5CR6RUW91WU73@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 03:16:43 +1100 Received: by localhost (Postfix, from userid 510) id C16A3AB542; Thu, 18 Nov 2004 03:16:42 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by curly.its.monash.edu.au (Postfix) with ESMTP id B93494FB0B for ; Thu, 18 Nov 2004 03:16:41 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 11:16:40 -0500 Date: Wed, 17 Nov 2004 11:16:40 -0500 From: "Soliman, Hesham" Subject: [DNA] RE: IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: IPv6 over PPP over GPRS -- once again Thread-Index: AcTMwJbKQlwoLO8GSVeZbsNLaClahQAAC1UA Content-Class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 17 Nov 2004 16:16:40.0500 (UTC) FILETIME=[D22A6F40:01C4CCC0] Content-Transfer-Encoding: 7BIT Check if the laptop is manually configured :) or if you're using ISATAP ! Hesham > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: Wednesday, November 17, 2004 11:15 AM > To: Soliman, Hesham; Bernard Aboba > Cc: Dna > Subject: RE: IPv6 over PPP over GPRS -- once again > > > > Tero, > > Hi Hesham, > > > > > I think RADIUS only comes into the picture if you're running > > PPP over the air. Are you? I thought it was only between the > > phone and laptop. But if you're running it over the air > > then it's a completely different story. > > No, I am not. It's between the phone and laptop. > > Well, this is getting really strange... > > Tero > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 11:26:00 2004 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 LAA15410 for ; Wed, 17 Nov 2004 11:25:59 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD5K4YN5U8X5U8T@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 03:22:56 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D273AAB556; Thu, 18 Nov 2004 03:22:39 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 88A574FB08; Thu, 18 Nov 2004 03:22:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHGMZC16736 for dna-list; Thu, 18 Nov 2004 03:22:35 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHGMY616732 for ; Thu, 18 Nov 2004 03:22:34 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD5JP9B9691WU73@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 03:22:19 +1100 Received: by localhost (Postfix, from userid 510) id C32DBAB542; Thu, 18 Nov 2004 03:22:18 +1100 (EST) Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by curly.its.monash.edu.au (Postfix) with ESMTP id 700844FB04 for ; Thu, 18 Nov 2004 03:22:15 +1100 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAHGMDh5024673 for ; Wed, 17 Nov 2004 17:22:14 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 17:22:13 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 17:22:13 +0100 Date: Wed, 17 Nov 2004 17:22:06 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: [DNA] RE: IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Soliman, Hesham'" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 17 Nov 2004 16:22:13.0496 (UTC) FILETIME=[98A59780:01C4CCC1] Content-Transfer-Encoding: 7BIT > Check if the laptop is manually configured :) Nope. It's not... ;) >or if you're using ISATAP ! No ISATAP either... Tero From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 12:35:57 2004 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 MAA22984 for ; Wed, 17 Nov 2004 12:35:56 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD80ZG9NQ8XB5Q6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 04:32:47 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D4A9BAB545; Thu, 18 Nov 2004 04:32:43 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D3FBC4FB0D; Thu, 18 Nov 2004 04:32:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHHW8L17634 for dna-list; Thu, 18 Nov 2004 04:32:08 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHHW1617630 for ; Thu, 18 Nov 2004 04:32:02 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHD802R4KO8XB5Q6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 18 Nov 2004 04:32:00 +1100 Received: by localhost (Postfix, from userid 510) id 1D3C8AB542; Thu, 18 Nov 2004 04:32:00 +1100 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by curly.its.monash.edu.au (Postfix) with ESMTP id 786564FB0C for ; Thu, 18 Nov 2004 04:31:57 +1100 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 63D5789892; Wed, 17 Nov 2004 19:31:53 +0200 (EET) Date: Wed, 17 Nov 2004 19:30:01 +0200 From: Jari Arkko Subject: Re: [DNA] IPv6 over PPP over GPRS -- once again In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , "Tero Kauppinen (JO/LMF)" , "'Soliman, Hesham'" Cc: Dna Message-id: <419B8A99.6020704@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT Hi guys, I can confirm that RADIUS does not belong to this discussion. (If there's RADIUS involvement, its always on the network side, GGSN and onwards.) I can also confirm that RAs are indeed sent by the GGSN. My understanding is that if PPP is used between a phone a laptop, the PDP context is reserved for the laptop and the RA goes straight to the laptop too. Note that in GSM, there is nothing corresponding to a MAC address; one of the link layer messages from the GGSN gives the phone an IID that it can use. In the laptop case the laptop obviously doesn't see the link layer messages, but bases its IID either on its own MAC address or the IPv6CP negotiated IID. For more information, see Section 9.2.1.1 in http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/23060-660.zip --Jari From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 17:16:14 2004 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 RAA25030 for ; Wed, 17 Nov 2004 17:16:12 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHDHTFA1VG8XB7AZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 09:13:48 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EA46480006; Thu, 18 Nov 2004 09:13:44 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8BB133C006; Thu, 18 Nov 2004 09:13:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHMBKO20283 for dna-list; Thu, 18 Nov 2004 09:11:20 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHMBJ620279 for ; Thu, 18 Nov 2004 09:11:19 +1100 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHDHQAT00M8XBLIA@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 18 Nov 2004 09:11:14 +1100 Received: by localhost (Postfix, from userid 510) id DD510AB543; Thu, 18 Nov 2004 09:11:13 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by curly.its.monash.edu.au (Postfix) with ESMTP id E37914FB09 for ; Thu, 18 Nov 2004 09:11:10 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 17:10:56 -0500 Date: Wed, 17 Nov 2004 17:10:56 -0500 From: "Soliman, Hesham" Subject: RE: [DNA] IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: Jari Arkko , Bernard Aboba , "Tero Kauppinen (JO/LMF)" Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: [DNA] IPv6 over PPP over GPRS -- once again Thread-Index: AcTMy16TpQ8Q920nSm+X1eo1jk82YQAJpRgQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 17 Nov 2004 22:10:56.0796 (UTC) FILETIME=[4FE7CDC0:01C4CCF2] X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT > I can confirm that RADIUS does not belong to this > discussion. (If there's RADIUS involvement, its always > on the network side, GGSN and onwards.) => Agreed. > > I can also confirm that RAs are indeed sent by the GGSN. > My understanding is that if PPP is used between a phone a > laptop, the PDP context is reserved for the laptop and the > RA goes straight to the laptop too. => I don't think the GGSN knows if it's for the phone or laptop. But yes the RA should be sent to the phone. And the phone should sent it to the laptop, but it's an implementatio issue. I don't recall anything in the spec that says the MT has to do that. Obviously it should do it though. Hesham =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Wed Nov 17 23:58:43 2004 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 XAA28308 for ; Wed, 17 Nov 2004 23:58:42 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHDVUF449M8ZFDZR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 15:55:27 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B6927AB557; Thu, 18 Nov 2004 15:55:24 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4FE724FB07; Thu, 18 Nov 2004 15:55:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAI4so224405 for dna-list; Thu, 18 Nov 2004 15:54:50 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAI4sn624401 for ; Thu, 18 Nov 2004 15:54:49 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHDVTIB36C91WQTD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 15:54:41 +1100 Received: by localhost (Postfix, from userid 510) id EC9E880003; Thu, 18 Nov 2004 15:54:40 +1100 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by larry.its.monash.edu.au (Postfix) with ESMTP id 53C143C002 for ; Thu, 18 Nov 2004 15:54:39 +1100 (EST) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4280F8983B; Thu, 18 Nov 2004 06:54:36 +0200 (EET) Date: Thu, 18 Nov 2004 06:52:43 +0200 From: Jari Arkko Subject: Re: [DNA] IPv6 over PPP over GPRS -- once again In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Soliman, Hesham" Cc: Bernard Aboba , "Tero Kauppinen (JO/LMF)" , Dna Message-id: <419C2A9B.6070802@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT Soliman, Hesham wrote: > => I don't think the GGSN knows if it's for the phone > or laptop. But yes the RA should be sent to the phone. The GGSN does not need to know, really. It always sends an RA, and if the PDP context happens to be for the phone, the phone is the ultimate user of that RA. If its the laptop for which the PDP context has been requested, then the RA ends up in the laptop. > And the phone should sent it to the laptop, but it's > an implementatio issue. I don't recall anything in the > spec that says the MT has to do that. Obviously it should > do it though. Yes. I did not find anything specific about this either, but my understanding is that if a laptop establishes a connection through the phone, the laptop gets its own PDP context and gets everything sent to it -- including the RAs. --Jari From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 18 00:08:51 2004 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 AAA29069 for ; Thu, 18 Nov 2004 00:08:50 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD6DYA1KG91WUNA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 03:46:16 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A9EBAB55A; Thu, 18 Nov 2004 03:45:55 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A17384FB0E; Thu, 18 Nov 2004 03:45:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAHGjfk16988 for dna-list; Thu, 18 Nov 2004 03:45:41 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAHGje616984 for ; Thu, 18 Nov 2004 03:45:40 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHD6DDR38691WUNA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 03:45:27 +1100 Received: by localhost (Postfix, from userid 510) id 972B480002; Thu, 18 Nov 2004 03:45:25 +1100 (EST) Received: from ftmailgfi.flariontech.com (mail.flarion.com [63.103.94.23]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0204C3C019 for ; Thu, 18 Nov 2004 03:45:19 +1100 (EST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 11:45:18 -0500 Date: Wed, 17 Nov 2004 11:45:18 -0500 From: "Soliman, Hesham" Subject: [DNA] RE: IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , Bernard Aboba Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: IPv6 over PPP over GPRS -- once again Thread-Index: AcTMwZp4TvCILpfFSMCMqwlAKcIl6QAAxeeQ Content-Class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 17 Nov 2004 16:45:18.0522 (UTC) FILETIME=[D22FC9A0:01C4CCC4] Content-Transfer-Encoding: 7BIT My final attempt ;) check if it's a 6-to-4 address. Windows does that I think if it gets a v4 address. > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: Wednesday, November 17, 2004 11:22 AM > To: Soliman, Hesham; Bernard Aboba > Cc: Dna > Subject: RE: IPv6 over PPP over GPRS -- once again > > > > > Check if the laptop is manually configured :) > > Nope. It's not... ;) > > >or if you're using ISATAP ! > > No ISATAP either... > > Tero > > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 18 02:18:55 2004 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 CAA22841 for ; Thu, 18 Nov 2004 02:18:54 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHE0S6L5QQ91WWD1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 18:17:09 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 241CEAB554; Thu, 18 Nov 2004 18:16:23 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D27E04FB06; Thu, 18 Nov 2004 18:16:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAI7G2E25745 for dna-list; Thu, 18 Nov 2004 18:16:02 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAI7G1625741 for ; Thu, 18 Nov 2004 18:16:01 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHE0RPYOFO8X71OI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 18:16:01 +1100 Received: by localhost (Postfix, from userid 510) id EA5A280007; Thu, 18 Nov 2004 18:16:00 +1100 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by larry.its.monash.edu.au (Postfix) with ESMTP id 717403C006 for ; Thu, 18 Nov 2004 18:15:57 +1100 (EST) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAI7FtR2023027 for ; Thu, 18 Nov 2004 08:15:55 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 08:15:55 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Nov 2004 08:15:55 +0100 Date: Thu, 18 Nov 2004 08:15:54 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] IPv6 over PPP over GPRS -- once again Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Jari Arkko'" , "Soliman, Hesham" Cc: Bernard Aboba , Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 18 Nov 2004 07:15:55.0396 (UTC) FILETIME=[71CA3440:01C4CD3E] Content-Transfer-Encoding: 7BIT Hi all, It feels like this might start to disturb people and it is better that I try to find an answer to this before further posting on the mailing list. Q'apla, Tero > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 18. marraskuuta 2004 6:53 > To: Soliman, Hesham > Cc: Bernard Aboba; Tero Kauppinen (JO/LMF); Dna > Subject: Re: [DNA] IPv6 over PPP over GPRS -- once again > > Soliman, Hesham wrote: > > > => I don't think the GGSN knows if it's for the phone > > or laptop. But yes the RA should be sent to the phone. > > The GGSN does not need to know, really. It always sends > an RA, and if the PDP context happens to be for the phone, > the phone is the ultimate user of that RA. If its the laptop > for which the PDP context has been requested, then the RA > ends up in the laptop. > > > And the phone should sent it to the laptop, but it's > > an implementatio issue. I don't recall anything in the > > spec that says the MT has to do that. Obviously it should > > do it though. > > Yes. I did not find anything specific about this either, > but my understanding is that if a laptop establishes a > connection through the phone, the laptop gets its own > PDP context and gets everything sent to it -- including > the RAs. > > --Jari From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 18 05:23:23 2004 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 FAA09618 for ; Thu, 18 Nov 2004 05:23:22 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHE79L1TCU8WVYYO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Nov 2004 21:22:18 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FE7580003; Thu, 18 Nov 2004 21:22:12 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1C6823C00D; Thu, 18 Nov 2004 21:22:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAIAJiT28084 for dna-list; Thu, 18 Nov 2004 21:19:44 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAIAJg628080 for ; Thu, 18 Nov 2004 21:19:43 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHE764FA7691WVP3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Nov 2004 21:19:25 +1100 Received: by localhost (Postfix, from userid 510) id 6297780008; Thu, 18 Nov 2004 21:19:25 +1100 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by larry.its.monash.edu.au (Postfix) with ESMTP id 137283C004 for ; Thu, 18 Nov 2004 21:19:20 +1100 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAIAJIvD029811 for ; Thu, 18 Nov 2004 11:19:18 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 11:19:16 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Nov 2004 11:19:16 +0100 Date: Thu, 18 Nov 2004 11:19:10 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] IPv6 over PPP over GPRS -- final statement Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" , "'Jari Arkko'" , "Soliman, Hesham" Cc: Bernard Aboba , Dna Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-OriginalArrivalTime: 18 Nov 2004 10:19:16.0583 (UTC) FILETIME=[0F021F70:01C4CD58] Content-Transfer-Encoding: 7BIT Hi all, Once again learnt the hard way, one shouldn't believe what someone other hears. RAs indeed reach the laptop (just something wrong with the package capturing) and everyone is happy now. I beg for your humble forgiveness regarding this matter. You can understandably ignore my postings for the next century or so ;) -- Q'apla - Tero From dna-owner@webcamserver.eng.monash.edu.au Thu Nov 18 08:22:34 2004 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 IAA23143 for ; Thu, 18 Nov 2004 08:22:33 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHEDFOWA6K8WVZGJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Nov 2004 00:19:04 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C6A780006; Fri, 19 Nov 2004 00:18:56 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D5B7B3C00A; Fri, 19 Nov 2004 00:18:55 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAIDHAb29872 for dna-list; Fri, 19 Nov 2004 00:17:10 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAIDH9629868 for ; Fri, 19 Nov 2004 00:17:09 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHEDDCROYE91WTEV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Nov 2004 00:17:03 +1100 Received: by localhost (Postfix, from userid 510) id 2B1FF80003; Fri, 19 Nov 2004 00:17:03 +1100 (EST) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by larry.its.monash.edu.au (Postfix) with ESMTP id 322D73C017 for ; Fri, 19 Nov 2004 00:17:01 +1100 (EST) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIDIV3B017460; Thu, 18 Nov 2004 06:18:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iAIDFgSO009389; Thu, 18 Nov 2004 07:15:42 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 83F6285C461; Thu, 18 Nov 2004 14:16:56 +0100 (CET) Date: Thu, 18 Nov 2004 14:16:56 +0100 From: Alexandru Petrescu Subject: Re: [DNA] IPv6 over PPP over GPRS -- final statement In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: "'Jari Arkko'" , "Soliman, Hesham" , Bernard Aboba , Dna Message-id: <419CA0C8.3020107@motorola.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT Tero Kauppinen (JO/LMF) wrote: > Hi all, > > Once again learnt the hard way, one shouldn't believe what someone > other hears. RAs indeed reach the laptop (just something wrong with > the package capturing) and everyone is happy now. Tero, this messaging is not at all disturbing for me. All I want to find out is whether that particular operator offers IPv6 access on a somehow public basis, and non-encapsulated. Facts about this stuff are important for this particular group and for others as well, IMHO. If it's not public information, then sorry for asking. > I beg for your humble forgiveness regarding this matter. You can > understandably ignore my postings for the next century or so ;) People who will: please ignore mine too :-) Alex From dna-owner@webcamserver.eng.monash.edu.au Mon Nov 22 22:20:53 2004 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 WAA02637 for ; Mon, 22 Nov 2004 22:20:51 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHKRYKAQEE8X7VNW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 23 Nov 2004 14:19:56 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BBF7AB559; Tue, 23 Nov 2004 14:19:46 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id BB65A4FB08; Tue, 23 Nov 2004 14:19:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iAN3INY00709 for dna-list; Tue, 23 Nov 2004 14:18:23 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iAN3IM600705 for ; Tue, 23 Nov 2004 14:18:22 +1100 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHKRWM00HW8Y50G7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 23 Nov 2004 14:18:12 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE0F480006 for ; Tue, 23 Nov 2004 14:18:11 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 79DAF3C005 for ; Tue, 23 Nov 2004 14:18:11 +1100 (EST) Date: Tue, 23 Nov 2004 14:18:11 +1100 From: Greg Daley Subject: [DNA] FYI: [Fwd: ID Tracker State Update Notice: draft-ietf-dna-goals] Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <41A2ABF3.8030804@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT As an update, the DNA Goals draft has been put on the agenda for the IESG telechat on 2 December. Please be prepared to help JinHyeock to resolve any issues raised by the IESG which they want to discuss with the working group. Description of AD Discusses: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_evaluation_desc Greg. -------- Original Message -------- Date: Mon, 22 Nov 2004 06:50:09 -0500 From: The IESG Subject: ID Tracker State Update Notice: draft-ietf-dna-goals Sender: Apache To: Pekka.Nikander@nomadiclab.com, greg.daley@eng.monash.edu.au 'State Changes to IESG Evaluation from AD Evaluation by Margaret Wasserman' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11887&rfc_flag=0 From dna-owner@webcamserver.eng.monash.edu.au Tue Nov 23 05:37:30 2004 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 FAA25246 for ; Tue, 23 Nov 2004 05:37:28 -0500 (EST) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHL76QMO8O91Y5GS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 23 Nov 2004 21:35:36 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 062BDAB543; Tue, 23 Nov 2004 21:35:28 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A79504FB0F; Tue, 23 Nov 2004 21:35:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iANAYtO05327 for dna-list; Tue, 23 Nov 2004 21:34:55 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iANAYs605323 for ; Tue, 23 Nov 2004 21:34:54 +1100 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHL75PV2DO8WWHVU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 23 Nov 2004 21:34:38 +1100 Received: by localhost (Postfix, from userid 510) id A48F0AB555; Tue, 23 Nov 2004 21:34:38 +1100 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by moe.its.monash.edu.au (Postfix) with ESMTP id 3D0C74FB07 for ; Tue, 23 Nov 2004 21:34:35 +1100 (EST) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iANAYXR2030033 for ; Tue, 23 Nov 2004 11:34:33 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 11:34:33 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 11:34:32 +0100 Date: Tue, 23 Nov 2004 11:34:24 +0100 From: "Tero Kauppinen (JO/LMF)" Subject: [DNA] Any need for Bluetooth in draft-ietf-dna-link-information? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 23 Nov 2004 10:34:33.0220 (UTC) FILETIME=[056E9440:01C4D148] Content-Transfer-Encoding: 7BIT Hi all, Do people feel that there is a need to mention Bluetooth as one of the network access technologies in draft-ietf-dna-link-information? The SIG has plans to triple Blutooth's bandwidth (http://slashdot.org/article.pl?sid=04/11/09/156205&tid=193&tid=1) which might draw more attention to solutions like BNEP (Bluetooth Network Encapsulation Protocol). Regz, Tero Kauppinen