From architecture-discuss-bounces@ietf.org Mon Feb 05 15:52:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAmh-000614-RF; Mon, 05 Feb 2007 15:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAmh-00060z-96 for architecture-discuss@ietf.org; Mon, 05 Feb 2007 15:49:55 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEAmf-0006Jk-0G for architecture-discuss@ietf.org; Mon, 05 Feb 2007 15:49:55 -0500 Received: from [10.0.0.189] (tm-beth-server.cictr.com?[204.9.221.19]) by comcast.net (sccrmhc11) with SMTP id <2007020520493201100e9l6ie>; Mon, 5 Feb 2007 20:49:42 +0000 In-Reply-To: <455C81C5.9060708@zurich.ibm.com> References: <455C81C5.9060708@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40758327-A51D-46DE-90BA-778DE3632D92@lilacglade.org> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Mon, 5 Feb 2007 15:49:28 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [I have not seen this come out on the list yet. Apologies for any duplicates.] Hi All, On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: > You clearly need to be able to invalidate a network layer handle > if the upper layer entity migrates; and then you have to pay the > lookup overhead. I agree. One thing I've been struggling with, though, is whether this lookup should happen in the end-node or in the network... My thoughts on this topic have favored a two-tiered routing approach, which would allow us to highly optimize and evolve the global routing infrastructure without affecting end-nodes and local networks. I have been trying to work out the details of an architecture where the two end-points of a connection use local end-point addresses to refer to each other, while the network uses global locators for routing. The same, globally unique, centrally allocated (?) IPv6 addresses are used by the end-nodes on both ends, but they will only be routable within their own local network. Those identifiers are translated into globally-routable locators within the network by routers at the local/global boundary, and the original end-point identifiers are stored in an extension header. The global locators are _not_ unique, per end-node identifiers. They identify (and provide the information needed to route to) another border router that is taking responsibility for delivering traffic for a particular set of end-node addresses. There would a one-to- many mapping from a global locator to end-point-addresses, and a one- to-one mapping of an end-point address to a global locator. This is intended to be a tiered routing approach, not an id/loc split technology. Both the end-point addresses and the global locators have the property of both identifying an entity and providing topological information about how to route to it (locally in the case of end-point addresses, globally in the case of global locators). This approach is essentially identical to IP-in-IP tunneling, with optimized headers. This approach has some similarities to NAT, but with several differences that would eliminate the problems caused by NAT: (1) The local address space is unique (not overlapping) and centrally allocated (you can tell who owns it). (2) State for mapping the local addresses (end-point identifiers) to global locators is held in a global system, like global routing tables, not held only on local translators. (3) The original end-point addresses in the packet remain in the packet and are restored to their original location at the other end. (3) Nothing inside the outer IP header needs to be translated. I think that it has several benefits that make it interesting to think about: (1) It requires no changes to end-nodes. Applications use DNS to get end-point identifiers, as they do today. (2) Most routers would not have to change, even within the global routing domain. They'd just route on the packet as it was presented to them. Only boundary routers would need to know about this mechanism, and they would only perform the transformation for packets addressed directly to them. (3) Local traffic would "just work" as it does today -- no extra look- ups or translations. There are still a lot of things that I have to work out before I'll be confident that this approach could be used in a scalable and useful way, but I think it is something to think about... A few areas for discussion are: (1) How are the endpoint addresses mapped to global locators at the local/global boundary? How is this mapping information propagated and updated when the mapping changes? (This problem is similar to the problems faced be routing protocols today.) (2) What are the security implications of this approach, and what is needed to prevent this from becoming a great way to inject apparently local packets and/or do other types of spoofing? Margaret _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 06 10:18:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES3H-0002nS-4B; Tue, 06 Feb 2007 10:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Ex-00024j-Bj for architecture-discuss@ietf.org; Mon, 05 Feb 2007 13:06:55 -0500 Received: from [64.25.87.235] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8Ew-0004cE-1A for architecture-discuss@ietf.org; Mon, 05 Feb 2007 13:06:55 -0500 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1827886; Mon, 05 Feb 2007 13:06:50 -0500 In-Reply-To: <455C81C5.9060708@zurich.ibm.com> References: <455C81C5.9060708@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3098FD00-786A-4A47-935C-32DCFD15B7F8@thingmagic.com> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Mon, 5 Feb 2007 13:06:49 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Tue, 06 Feb 2007 10:16:09 -0500 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi All, On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: > You clearly need to be able to invalidate a network layer handle > if the upper layer entity migrates; and then you have to pay the > lookup overhead. I agree. One thing I've been struggling with, though, is whether this lookup should happen in the end-node or in the network... My thoughts on this topic have favored a two-tiered routing approach, which would allow us to highly optimize and evolve the global routing infrastructure without affecting end-nodes and local networks. I have been trying to work out the details of an architecture where the two end-points of a connection use local end-point addresses to refer to each other, while the network uses global locators for routing. The same, globally unique, centrally allocated (?) IPv6 addresses are used by the end-nodes on both ends, but they will only be routable within their own local network. Those identifiers are translated into globally-routable locators within the network by routers at the local/global boundary, and the original end-point identifiers are stored in an extension header. The global locators are _not_ unique, per end-node identifiers. They identify (and provide the information needed to route to) another border router that is taking responsibility for delivering traffic for a particular set of end-node addresses. There would a one-to- many mapping from a global locator to end-point-addresses, and a one- to-one mapping of an end-point address to a global locator. This is intended to be a tiered routing approach, not an id/loc split technology. Both the end-point addresses and the global locators have the property of both identifying an entity and providing topological information about how to route to it (locally in the case of end-point addresses, globally in the case of global locators). This approach is essentially identical to IP-in-IP tunneling, with optimized headers. This approach has some similarities to NAT, but with several differences that would eliminate the problems caused by NAT: (1) The local address space is unique (not overlapping) and centrally allocated (you can tell who owns it). (2) State for mapping the local addresses (end-point identifiers) to global locators is held in a global system, like global routing tables, not held only on local translators. (3) The original end-point addresses in the packet remain in the packet and are restored to their original location at the other end. (3) Nothing inside the outer IP header needs to be translated. I think that it has several benefits that make it interesting to think about: (1) It requires no changes to end-nodes. Applications use DNS to get end-point identifiers, as they do today. (2) Most routers would not have to change, even within the global routing domain. They'd just route on the packet as it was presented to them. Only boundary routers would need to know about this mechanism, and they would only perform the transformation for packets addressed directly to them. (3) Local traffic would "just work" as it does today -- no extra look- ups or translations. There are still a lot of things that I have to work out before I'll be confident that this approach could be used in a scalable and useful way, but I think it is something to think about... A few areas for discussion are: (1) How are the endpoint addresses mapped to global locators at the local/global boundary? How is this mapping information propagated and updated when the mapping changes? (This problem is similar to the problems faced be routing protocols today.) (2) What are the security implications of this approach, and what is needed to prevent this from becoming a great way to inject apparently local packets and/or do other types of spoofing? Margaret _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 06 11:11:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESuD-0005Ek-Nv; Tue, 06 Feb 2007 11:10:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESuB-0005EZ-Rg for architecture-discuss@ietf.org; Tue, 06 Feb 2007 11:10:51 -0500 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HESu9-0000ON-Cl for architecture-discuss@ietf.org; Tue, 06 Feb 2007 11:10:51 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l16GAkNS216874 for ; Tue, 6 Feb 2007 16:10:46 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l16GAkQm1937536 for ; Tue, 6 Feb 2007 17:10:46 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l16GAjGL004125 for ; Tue, 6 Feb 2007 17:10:46 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l16GAjdR004101; Tue, 6 Feb 2007 17:10:45 +0100 Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA233294; Tue, 6 Feb 2007 17:10:44 +0100 Message-ID: <45C8A883.6090500@zurich.ibm.com> Date: Tue, 06 Feb 2007 17:10:43 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Margaret Wasserman Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) References: <455C81C5.9060708@zurich.ibm.com> <3098FD00-786A-4A47-935C-32DCFD15B7F8@thingmagic.com> In-Reply-To: <3098FD00-786A-4A47-935C-32DCFD15B7F8@thingmagic.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Margaret, You'll definitely want to read draft-farinacci-lisp, although it may give you some terminology concerns. (It's likely to be discussed on the RAM list.) Brian On 2007-02-05 19:06, Margaret Wasserman wrote: > > Hi All, > > On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: >> You clearly need to be able to invalidate a network layer handle >> if the upper layer entity migrates; and then you have to pay the >> lookup overhead. > > I agree. One thing I've been struggling with, though, is whether this > lookup should happen in the end-node or in the network... > > My thoughts on this topic have favored a two-tiered routing approach, > which would allow us to highly optimize and evolve the global routing > infrastructure without affecting end-nodes and local networks. > > I have been trying to work out the details of an architecture where the > two end-points of a connection use local end-point addresses to refer to > each other, while the network uses global locators for routing. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 07 10:05:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEoKI-00020E-K2; Wed, 07 Feb 2007 10:03:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElRj-0000uU-6q for architecture-discuss@ietf.org; Wed, 07 Feb 2007 06:58:43 -0500 Received: from [64.25.87.235] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElRh-0006Hq-Vl for architecture-discuss@ietf.org; Wed, 07 Feb 2007 06:58:43 -0500 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1834386; Wed, 07 Feb 2007 06:58:36 -0500 In-Reply-To: <45C8A883.6090500@zurich.ibm.com> References: <455C81C5.9060708@zurich.ibm.com> <3098FD00-786A-4A47-935C-32DCFD15B7F8@thingmagic.com> <45C8A883.6090500@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <853F568F-D23B-4BCD-973A-2D3C09E000A2@thingmagic.com> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Wed, 7 Feb 2007 06:58:34 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Wed, 07 Feb 2007 10:03:14 -0500 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > You'll definitely want to read draft-farinacci-lisp, > although it may give you some terminology concerns. > (It's likely to be discussed on the RAM list.) Thanks for the pointers, to the draft and to the list (which I had somehow failed to join). I saw your discussion of this document on the other list, and I'll hop over there. I just wanted to make one point here, though... The two proposals are similar in many ways. The biggest difference between lisp and my approach (other than the fact that Dino has written a nice document, and I've written a cryptic e-mail) is that, in my approach, the packet remains an IP packet. The only routers that have to change are the ones at the local/global boundary, not all of the global domain routers. Also, in my approach, it might be possible to make this work (perhaps only for IPv6, because it has the header extension mechanism? and perhaps only as well as NAT?) when only one end implements the transformation, by having the global locators and the end-point addresses have the same value for hosts on networks that don't implement the new mechanism. I'm still working out the details of that part... Margaret _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 26 08:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg1Q-0001Oi-EH; Mon, 26 Feb 2007 08:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg1P-0001Od-4b for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:36:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLg1M-0001gJ-IO for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:36:07 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 05:36:03 -0800 X-IronPort-AV: i="4.14,220,1170662400"; d="scan'208,217"; a="42544852:sNHT96102846" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QDa2xN019599; Mon, 26 Feb 2007 14:36:02 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QDZnCc023648; Mon, 26 Feb 2007 14:36:02 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:36:00 +0100 Received: from [10.71.10.163] ([10.68.20.107]) by xmb-ams-33b.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:35:53 +0100 In-Reply-To: <45B60D71.1030206@zurich.ibm.com> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <45B60D71.1030206@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1050D894-6A15-4B66-A90D-0378228BE197@cisco.com> From: Peter Tomsu Subject: Re: [arch-d] 2. thinking about an implementation Date: Mon, 26 Feb 2007 14:34:46 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 13:35:56.0463 (UTC) FILETIME=[0B256BF0:01C759AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6446; t=1172496962; x=1173360962; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20[arch-d]=202.=20thinking=20about=20an=20implementatio n |Sender:=20; bh=RiHJgIHM+fVetkj7zeVqCtRlXbW+abKQRZX7P9nQL2A=; b=cP+uaoveXLNJMHEcRGqh9wfobR6eEHZsl5CI4id/+Emq5xhUubcjbzcGvpts/pFB3ltSTluK s0SHG9uBPBq9mDeMGwlzTwn4Zf1ukiEJ1JT69eo+9mYjS3uyIpT9vxKO; Authentication-Results: ams-dkim-1; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120912938==" Errors-To: architecture-discuss-bounces@ietf.org --===============2120912938== Content-Type: multipart/alternative; boundary=Apple-Mail-3-916158116 --Apple-Mail-3-916158116 Content-Transfer-Encoding:From architecture-discuss-bounces@ietf.org Mon Feb 26 08:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg1Q-0001Oi-EH; Mon, 26 Feb 2007 08:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg1P-0001Od-4b for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:36:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLg1M-0001gJ-IO for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:36:07 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 05:36:03 -0800 X-IronPort-AV: i="4.14,220,1170662400"; d="scan'208,217"; a="42544852:sNHT96102846" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QDa2xN019599; Mon, 26 Feb 2007 14:36:02 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QDZnCc023648; Mon, 26 Feb 2007 14:36:02 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:36:00 +0100 Received: from [10.71.10.163] ([10.68.20.107]) by xmb-ams-33b.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:35:53 +0100 In-Reply-To: <45B60D71.1030206@zurich.ibm.com> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <45B60D71.1030206@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1050D894-6A15-4B66-A90D-0378228BE197@cisco.com> From: Peter Tomsu Subject: Re: [arch-d] 2. thinking about an implementation Date: Mon, 26 Feb 2007 14:34:46 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 13:35:56.0463 (UTC) FILETIME=[0B256BF0:01C759AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6446; t=1172496962; x=1173360962; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20[arch-d]=202.=20thinking=20about=20an=20implementatio n |Sender:=20; bh=RiHJgIHM+fVetkj7zeVqCtRlXbW+abKQRZX7P9nQL2A=; b=cP+uaoveXLNJMHEcRGqh9wfobR6eEHZsl5CI4id/+Emq5xhUubcjbzcGvpts/pFB3ltSTluK s0SHG9uBPBq9mDeMGwlzTwn4Zf1ukiEJ1JT69eo+9mYjS3uyIpT9vxKO; Authentication-Results: ams-dkim-1; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120912938==" Errors-To: architecture-discuss-bounces@ietf.org --===============2120912938== Content-Type: multipart/alternative; boundary=Apple-Mail-3-916158116 --Apple-Mail-3-916158116 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed So you actually think this is the better solution? Just distributing the task? Not sure Peter On 23.01.2007, at 14:28, Brian E Carpenter wrote: > On 2007-01-22 18:50, Simon Leinen wrote: >> Brian E Carpenter writes: >>> Please note, though, that one of the more interesting criticisms of >>> shim6 is that it asks end systems (e.g. server farms) to hold extra >>> state per session. Moving state around does move heat dissipation >>> around. >> What amount of additional state are we talking about? > > I like Jari's answer, but I would suggest another way to look > at it: instead of the site NAT (or PAT) having to hold state > per active flow, each host will have to hold state per active > flow. So the border box will get noticeably less hot and (in a > server farm) the offload NICs will each get a little hotter. > > Brian > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-3-916158116 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
So you = actually think this is the better solution? Just distributing the = task?

Not sure

Peter

On = 23.01.2007, at 14:28, Brian E Carpenter wrote:

On 2007-01-22 18:50, Simon = Leinen wrote:
Brian E = Carpenter writes:
Please note, though, that one of the more = interesting criticisms of
shim6 is that = it asks end systems (e.g. server farms) to hold extra
state per session. Moving state around does move = heat dissipation
around.
What amount of additional state are we talking = about?
I like Jari's answer, but I = would suggest another way to look
at it: = instead of the site NAT (or PAT) having to hold state
per active flow, each host will have to hold state = per active 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed So you actually think this is the better solution? Just distributing the task? Not sure Peter On 23.01.2007, at 14:28, Brian E Carpenter wrote: > On 2007-01-22 18:50, Simon Leinen wrote: >> Brian E Carpenter writes: >>> Please note, though, that one of the more interesting criticisms of >>> shim6 is that it asks end systems (e.g. server farms) to hold extra >>> state per session. Moving state around does move heat dissipation >>> around. >> What amount of additional state are we talking about? > > I like Jari's answer, but I would suggest another way to look > at it: instead of the site NAT (or PAT) having to hold state > per active flow, each host will have to hold state per active > flow. So the border box will get noticeably less hot and (in a > server farm) the offload NICs will each get a little hotter. > > Brian > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-3-916158116 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
So you = actually think this is the better solution? Just distributing the = task?

Not sure

Peter

On = 23.01.2007, at 14:28, Brian E Carpenter wrote:

On 2007-01-22 18:50, Simon = Leinen wrote:
Brian E = Carpenter writes:
Please note, though, that one of the more = interesting criticisms of
shim6 is that = it asks end systems (e.g. server farms) to hold extra
state per session. Moving state around does move = heat dissipation
around.
What amount of additional state are we talking = about?
I like Jari's answer, but I = would suggest another way to look
at it: = instead of the site NAT (or PAT) having to hold state
per active flow, each host will have to hold state = per active
flow. So the border box will get = noticeably less hot and (in a
server farm) = the offload NICs will each get a little hotter.

=A0=A0 Brian

Architecture-discuss mailing list
=



= --Apple-Mail-3-916158116-- --===============2120912938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2120912938==-- From architecture-discuss-bounces@ietf.org Mon Feb 26 08:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg3A-0002Jd-E8; Mon, 26 Feb 2007 08:37:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg39-0002JW-7t for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:37:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLg37-0001t2-Ci for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:37:55 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 05:37:51 -0800 X-IronPort-AV: i="4.14,220,1170662400"; d="scan'208,217"; a="42545571:sNHT107920089" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QDbpZF020479; Mon, 26 Feb 2007 14:37:51 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QDbICc024415; Mon, 26 Feb 2007 14:37:48 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:37:39 +0100 Received: from [10.71.10.163] ([10.68.20.107]) by xmb-ams-33b.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:36:53 +0100 In-Reply-To: <40758327-A51D-46DE-90BA-7
flow. So the border box will get = noticeably less hot and (in a
server farm) = the offload NICs will each get a little hotter.

=A0=A0 Brian

Architecture-discuss mailing list
=



= --Apple-Mail-3-916158116-- --===============2120912938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2120912938==-- From architecture-discuss-bounces@ietf.org Mon Feb 26 08:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg3A-0002Jd-E8; Mon, 26 Feb 2007 08:37:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLg39-0002JW-7t for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:37:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLg37-0001t2-Ci for architecture-discuss@ietf.org; Mon, 26 Feb 2007 08:37:55 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 05:37:51 -0800 X-IronPort-AV: i="4.14,220,1170662400"; d="scan'208,217"; a="42545571:sNHT107920089" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QDbpZF020479; Mon, 26 Feb 2007 14:37:51 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QDbICc024415; Mon, 26 Feb 2007 14:37:48 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:37:39 +0100 Received: from [10.71.10.163] ([10.68.20.107]) by xmb-ams-33b.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:36:53 +0100 In-Reply-To: <40758327-A51D-46DE-90BA-778DE3632D92@lilacglade.org> References: <455C81C5.9060708@zurich.ibm.com> <40758327-A51D-46DE-90BA-778DE3632D92@lilacglade.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <836747A7-6DA1-4648-9FEA-4D6D2D295E73@cisco.com> From: Peter Tomsu Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Mon, 26 Feb 2007 14:35:57 +0100 To: Margaret Wasserman X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 13:36:57.0634 (UTC) FILETIME=[2F9B6020:01C759AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16406; t=1172497071; x=1173361071; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20Ok, =20so=20what=20should=20we=20do=20then?=20(Was=3A= 20Re=3A=20[arch-d]=20[Off-topic]Furtherthoughts=3A=20about=20systems=20the ory=20and=20the=20theory=20U) |Sender:=20; bh=lEenaxYken+JODVJgq9G4/9VVHwPhaFMsuNDRrBYT2Y=; b=CJ+Ng+I9eDPfE8948llddoG5d4A/bs4a/H3DiX5av1cmmon9QaTBobNOtW7nrFxsJT53nb4+ 5tliNKOLFtGsPJaYul85KW8Gyu7bdFhBm6uUR6Xu424NPcSATtk5vwts; Authentication-Results: ams-dkim-1; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585100327==" Errors-To: architecture-discuss-bounces@ietf.org --===============0585100327== Content-Type: multipart/alternative; boundary=Apple-Mail-4-916229499 --Apple-Mail-4-916229499 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Margaret, I could not agree more ! Peter On 05.02.2007, at 21:49, Margaret Wasserman wrote: > > [I have not seen this come out on the list yet. Apologies for any > duplicates.] > > Hi All, > > On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: >> You clearly need to be able to invalidate a network layer handle >> if the upper layer entity migrates; and then you have to pay the >> lookup overhead. > > I agree. One thing I've been struggling with, though, is whether > this lookup should happen in the end-node or in the network... > > My thoughts on this topic have favored a two-tiered routing > approach, which would allow us to highly optimize and evolve the > global routing infrastructure without affecting end-nodes and local > networks. > > I have been trying to work out the details of an architecture where > the two end-points of a connection use local end-point addresses to > refer to each other, while the network uses global locators for > routing. > > The same, globally unique, centrally allocated (?) IPv6 addresses > are used by the end-nodes on both ends, but they will only be > routable within their own local network. Those identifiers are > translated into globally-routable locators within the network by > routers at the local/global boundary, and the original end-point > identifiers are stored in an extension header. > > The global locators are _not_ unique, per end-node identifiers. > They identify (and provide the78DE3632D92@lilacglade.org> References: <455C81C5.9060708@zurich.ibm.com> <40758327-A51D-46DE-90BA-778DE3632D92@lilacglade.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <836747A7-6DA1-4648-9FEA-4D6D2D295E73@cisco.com> From: Peter Tomsu Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Mon, 26 Feb 2007 14:35:57 +0100 To: Margaret Wasserman X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 13:36:57.0634 (UTC) FILETIME=[2F9B6020:01C759AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16406; t=1172497071; x=1173361071; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20Ok, =20so=20what=20should=20we=20do=20then?=20(Was=3A= 20Re=3A=20[arch-d]=20[Off-topic]Furtherthoughts=3A=20about=20systems=20the ory=20and=20the=20theory=20U) |Sender:=20; bh=lEenaxYken+JODVJgq9G4/9VVHwPhaFMsuNDRrBYT2Y=; b=CJ+Ng+I9eDPfE8948llddoG5d4A/bs4a/H3DiX5av1cmmon9QaTBobNOtW7nrFxsJT53nb4+ 5tliNKOLFtGsPJaYul85KW8Gyu7bdFhBm6uUR6Xu424NPcSATtk5vwts; Authentication-Results: ams-dkim-1; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585100327==" Errors-To: architecture-discuss-bounces@ietf.org --===============0585100327== Content-Type: multipart/alternative; boundary=Apple-Mail-4-916229499 --Apple-Mail-4-916229499 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Margaret, I could not agree more ! Peter On 05.02.2007, at 21:49, Margaret Wasserman wrote: > > [I have not seen this come out on the list yet. Apologies for any > duplicates.] > > Hi All, > > On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: >> You clearly need to be able to invalidate a network layer handle >> if the upper layer entity migrates; and then you have to pay the >> lookup overhead. > > I agree. One thing I've been struggling with, though, is whether > this lookup should happen in the end-node or in the network... > > My thoughts on this topic have favored a two-tiered routing > approach, which would allow us to highly optimize and evolve the > global routing infrastructure without affecting end-nodes and local > networks. > > I have been trying to work out the details of an architecture where > the two end-points of a connection use local end-point addresses to > refer to each other, while the network uses global locators for > routing. > > The same, globally unique, centrally allocated (?) IPv6 addresses > are used by the end-nodes on both ends, but they will only be > routable within their own local network. Those identifiers are > translated into globally-routable locators within the network by > routers at the local/global boundary, and the original end-point > identifiers are stored in an extension header. > > The global locators are _not_ unique, per end-node identifiers. > They identify (and provide the information needed to route to) > another border router that is taking responsibility for delivering > traffic for a particular set of end-node addresses. There would a > one-to-many mapping from a global locator to end-point-addresses, > and a one-to-one mapping of an end-point address to a global locator. > > This is intended to be a tiered routing approach, not an id/loc > split technology. Both the end-point addresses and the global > locators have the property of both identifying an entity and > providing topological information about how to route to it (locally > in the case of end-point addresses, globally in the case of global > locators). > > This approach is essentially identical to IP-in-IP tunneling, with > optimized headers. > > This approach has some similarities to NAT, but with several > differences that would eliminate the problems caused by NAT: > > (1) The local address space is unique (not overlapping) and > centrally allocated (you can tell who owns it). > (2) State for mapping the local addresses (end-point identifiers) > to global locators is held in a global system, like global routing > tables, not held only on local translators. > (3) The original end-point addresses in the packet remain in the > packet and are restored to their original location at the other end. > (3) Nothing inside the outer IP header needs to be translated. > > I think that it has several benefits that make it interesting to > think about: > > (1) It requires no changes to end-nodes. Applications use DNS to > get end-point identifiers, as they do today. > (2) Most routers would not have to change, even within the global > routing domain. They'd just route on the packet as it was > presented to them. Only boundary routers would need to know about > this mechanism, and they would only perform the transformation for > packets addressed directly to them. > (3) Local traffic would "just work" as it does today -- no extra > look-ups or translations. > > There are still a lot of things that I have to work out before I'll > be confident that this approach could be used in a scalable and > useful way, but I think it is something to think about... > > A few areas for discussion are: > > (1) How are the endpoint addresses mapped to global locators at the > local/global boundary? How is this mapping information propagated > and updated when the mapping changes? (This problem is similar to > the problems faced be routing protocols today.) > (2) What are the security implications of this approach, and what > is needed to prevent this from becoming a great way to inject > apparently local packets and/or do other types of spoofing? > > Margaret > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-4-916229499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I could not agree more = !

Peter


On = 05.02.2007, at 21:49, Margaret Wasserman wrote:

another border router that is taking responsibility for delivering > traffic for a particular set of end-node addresses. There would a > one-to-many mapping from a global locator to end-point-addresses, > and a one-to-one mapping of an end-point address to a global locator. > > This is intended to be a tiered routing approach, not an id/loc > split technology. Both the end-point addresses and the global > locators have the property of both identifying an entity and > providing topological information about how to route to it (locally > in the case of end-point addresses, globally in the case of global > locators). > > This approach is essentially identical to IP-in-IP tunneling, with > optimized headers. > > This approach has some similarities to NAT, but with several > differences that would eliminate the problems caused by NAT: > > (1) The local address space is unique (not overlapping) and > centrally allocated (you can tell who owns it). > (2) State for mapping the local addresses (end-point identifiers) > to global locators is held in a global system, like global routing > tables, not held only on local translators. > (3) The original end-point addresses in the packet remain in the > packet and are restored to their original location at the other end. > (3) Nothing inside the outer IP header needs to be translated. > > I think that it has several benefits that make it interesting to > think about: > > (1) It requires no changes to end-nodes. Applications use DNS to > get end-point identifiers, as they do today. > (2) Most routers would not have to change, even within the global > routing domain. They'd just route on the packet as it was > presented to them. Only boundary routers would need to know about > this mechanism, and they would only perform the transformation for > packets addressed directly to them. > (3) Local traffic would "just work" as it does today -- no extra > look-ups or translations. > > There are still a lot of things that I have to work out before I'll > be confident that this approach could be used in a scalable and > useful way, but I think it is something to think about... > > A few areas for discussion are: > > (1) How are the endpoint addresses mapped to global locators at the > local/global boundary? How is this mapping information propagated > and updated when the mapping changes? (This problem is similar to > the problems faced be routing protocols today.) > (2) What are the security implications of this approach, and what > is needed to prevent this from becoming a great way to inject > apparently local packets and/or do other types of spoofing? > > Margaret > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-4-916229499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I could not agree more = !

Peter


On = 05.02.2007, at 21:49, Margaret Wasserman wrote:


[I have = not seen this come out on the list yet.=A0 Apologies for any = duplicates.]

Hi All,

On Nov 16, 2006, at 10:20 AM, = Brian E Carpenter wrote:
You clearly need to be able to invalidate a network = layer handle
if the upper layer entity = migrates; and then you have to pay the
lookup = overhead.

I agree.=A0 One thing I've been = struggling with, though, is whether this lookup should happen in the = end-node or in the network...

My thoughts on this topic have = favored a two-tiered routing approach, which would allow us to highly = optimize and evolve the global routing infrastructure without affecting = end-nodes and local networks.

I have been trying to work out = the details of an architecture where the two end-points of a connection = use local end-point addresses to refer to each other, while the network = uses global locators for routing.

The same, globally unique, = centrally allocated (?) IPv6 addresses are used by the end-nodes on both = ends, but they will only be routable within their own local = network.=A0 Those = identifiers are translated into globally-routable locators within the = network by routers at the local/global boundary, and the original = end-point identifiers are stored in an extension header.

The = global locators are _not_ unique, per end-node identifiers.=A0 They identify (and provide = the information needed to route to) another border router that is taking = responsibility for delivering traffic for a particular set of end-node = addresses.=A0 There would a = one-to-many mapping from a global locator to end-point-addresses, and a = one-to-one mapping of an end-point address to a global = locator.


[I have = not seen this come out on the list yet.=A0 Apologies for any = duplicates.]

Hi All,

On Nov 16, 2006, at 10:20 AM, = Brian E Carpenter wrote:
You clearly need to be able to invalidate a network = layer handle
if the upper layer entity = migrates; and then you have to pay the
lookup = overhead.

I agree.=A0 One thing I've been = struggling with, though, is whether this lookup should happen in the = end-node or in the network...

My thoughts on this topic have = favored a two-tiered routing approach, which would allow us to highly = optimize and evolve the global routing infrastructure without affecting = end-nodes and local networks.

I have been trying to work out = the details of an architecture where the two end-points of a connection = use local end-point addresses to refer to each other, while the network = uses global locators for routing.

The same, globally unique, = centrally allocated (?) IPv6 addresses are used by the end-nodes on both = ends, but they will only be routable within their own local = network.=A0 Those = identifiers are translated into globally-routable locators within the = network by routers at the local/global boundary, and the original = end-point identifiers are stored in an extension header.

The = global locators are _not_ unique, per end-node identifiers.=A0 They identify (and provide = the information needed to route to) another border router that is taking = responsibility for delivering traffic for a particular set of end-node = addresses.=A0 There would a = one-to-many mapping from a global locator to end-point-addresses, and a = one-to-one mapping of an end-point address to a global = locator.

This is intended to be a tiered routing approach, = not an id/loc split technology.=A0 = Both the end-point addresses and the global locators have the = property of both identifying an entity and providing topological = information about how to route to it (locally in the case of end-point = addresses, globally in the case of global locators).

This = approach is essentially identical to IP-in-IP tunneling, with optimized = headers.

This approach has some similarities to NAT, but with = several differences that would eliminate the problems caused by = NAT:

(1) The local address space is unique (not = overlapping) and centrally allocated (you can tell who owns = it).
(2) State for mapping the local = addresses (end-point identifiers) to global locators is held in a global = system, like global routing tables, not held only on local = translators.
(3) The original end-point = addresses in the packet remain in the packet and are restored to their = original location at the other end.
(3) Nothing = inside the outer IP header needs to be translated.

I think = that it has several benefits that make it interesting to think = about:

(1) It requires no changes to end-nodes.=A0 Applications use DNS to get = end-point identifiers, as they do today.
(2) Most = routers would not have to change, even within the global routing = domain.=A0 They'd just = route on the packet as it was presented to them.=A0 Only boundary routers would = need to know about this mechanism, and they would only perform the = transformation for packets addressed directly to them.
(3) Local traffic would "just work" as it does today = -- no extra look-ups or translations.

There are = still a lot of things that I have to work out before I'll be confident = that this approach could be used in a scalable and useful way, but I = think it is something to think about...

A few areas = for discussion arex; ">This is intended to be a tiered routing approach, = not an id/loc split technology.=A0 = Both the end-point addresses and the global locators have the = property of both identifying an entity and providing topological = information about how to route to it (locally in the case of end-point = addresses, globally in the case of global locators).

This = approach is essentially identical to IP-in-IP tunneling, with optimized = headers.

This approach has some similarities to NAT, but with = several differences that would eliminate the problems caused by = NAT:

(1) The local address space is unique (not = overlapping) and centrally allocated (you can tell who owns = it).
(2) State for mapping the local = addresses (end-point identifiers) to global locators is held in a global = system, like global routing tables, not held only on local = translators.
(3) The original end-point = addresses in the packet remain in the packet and are restored to their = original location at the other end.
(3) Nothing = inside the outer IP header needs to be translated.

I think = that it has several benefits that make it interesting to think = about:

(1) It requires no changes to end-nodes.=A0 Applications use DNS to get = end-point identifiers, as they do today.
(2) Most = routers would not have to change, even within the global routing = domain.=A0 They'd just = route on the packet as it was presented to them.=A0 Only boundary routers would = need to know about this mechanism, and they would only perform the = transformation for packets addressed directly to them.
(3) Local traffic would "just work" as it does today = -- no extra look-ups or translations.

There are = still a lot of things that I have to work out before I'll be confident = that this approach could be used in a scalable and useful way, but I = think it is something to think about...

A few areas = for discussion are:
(1) How are the endpoint = addresses mapped to global locators at the local/global boundary?=A0 How is this mapping = information propagated and updated when the mapping changes?=A0 (This problem is similar to = the problems faced be routing protocols today.)
(2) What are the security implications of this = approach, and what is needed to prevent this from becoming a great way = to inject apparently local packets and/or do other types of = spoofing?

Margaret



Architecture-discuss mailing list
=

= --Apple-Mail-4-916229499-- --===============0585100327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0585100327==-- :
(1) How are the endpoint = addresses mapped to global locators at the local/global boundary?=A0 How is this mapping = information propagated and updated when the mapping changes?=A0 (This problem is similar to = the problems faced be routing protocols today.)
(2) What are the security implications of this = approach, and what is needed to prevent this from becoming a great way = to inject apparently local packets and/or do other types of = spoofing?

Margaret



Architecture-discuss mailing list
=
= --Apple-Mail-4-916229499-- --===============0585100327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0585100327==-- From architecture-discuss-bounces@ietf.org Mon Feb 26 12:45:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtS-0008DF-TE; Mon, 26 Feb 2007 12:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtS-0008DA-91 for architecture-discuss@ietf.org; Mon, 26 Feb 2007 12:44:10 -0500 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjtQ-0000kp-FA for architecture-discuss@ietf.org; Mon, 26 Feb 2007 12:44:10 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1QHhv4A123402 for ; Mon, 26 Feb 2007 17:43:57 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QHhvmP1208556 for ; Mon, 26 Feb 2007 17:43:57 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QHhvBh011517 for ; Mon, 26 Feb 2007 17:43:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QHhvat011508; Mon, 26 Feb 2007 17:43:57 GMT Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA61348; Mon, 26 Feb 2007 18:43:54 +0100 Message-ID: <45E308A0.2020403@zurich.ibm.com> Date: Mon, 26 Feb 2007 17:19:44 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Peter Tomsu Subject: Re: [arch-d] 2. thinking about an implementation References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <45B60D71.1030206@zurich.ibm.com> <1050D894-6A15-4B66-A90D-0378228BE197@cisco.com> In-Reply-To: <1050D894-6A15-4B66-A90D-0378228BE197@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, If people are worried about bottleneck effects and (literally) hot spots, distribution is surely something to consider. That's an engineering question. From an architectural viewpoint, it seems quite important to think carefully about what the end to end principle actually says: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)" [End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.] If we continue to build things such that upper layers in end systems need to know what address the upper layer at the other end sees, this quote applies precisely to dynamic address changes. Brian On 2007-02-26 14:34, Peter Tomsu wrote: > So you actually think this is the better solution? Just distributing the > task? > > Not sure > > Peter > > On 23.01.2007, at 14:28, Brian E Carpenter wrote: > >> On 2007-01-22 18:50, Simon Leinen wrote: >>> Brian E Carpenter writes: >>>> Please note, though, that one of the more interesting criticisms of >>>> shim6 is that it asks end systems (e.g. server farms) to hold extra >>>> state per session. Moving state around does move heat dissipation >>>> around. >>> What amount of additional state are we talking about? >> >> I like Jari's answer, but I would suggest another way to look >> at it: instead of the site NAT (or PAT) having to hold state >> per active flow, each host will have to hold state per active >> flow. So the border box will get noticeably less hot and (in a >> server farm) the offload NICs will each get a little hotter. >> >> Brian >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 26 17:46:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLobD-0001AJ-4t; Mon, 26 Feb 2007 17:45:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnqY-0008JN-NW for architecture-discuss@ietf.org; Mon, 26 Feb 2007 16:57:26 -0500 Received: from relay-em.club-internet.fr ([194.158.104.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnK6-0001vm-2r for architecture-discuss@ietf.org; Mon, 26 Feb 2007 16:24:03 -0500 Received: from asus.club-internet.fr (i03m-212-195-38-17.d4.club-internet.fr [212.195.38.17]) by relay-em.club-internet.fr (Postfix) with ESMTP id 698F22560F; Mon, 26 Feb 2007 22:23:36 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Feb 2007 21:57:30 +0100 To: Peter Tomsu , Margaret Wasserman From: JFC Morfin Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) In-Reply-To: <836747A7-6DA1-4648-9FEA-4D6D2D295E73@cisco.com> References: <455C81C5.9060708@zurich.ibm.com> <40758327-A51D-46DE-90BA-778DE3632D92@lilacglade.org> <836747A7-6DA1-4648-9FEA-4D6D2D295E73@cisco.com> Mime-Version: 1.0 Message-Id: <20070226212336.698F22560F@relay-em.club-internet.fr> X-Spam-Score: 0.3 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1456867131==" Errors-To: architecture-discuss-bounces@ietf.org --===============1456867131== Content-Type: multipart/alternative; boundary="=====================_5661015==.ALT" --=====================_5661015==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Peter, I think that OPES could be an elegant solution offering the best of both (no change on the host, etc.). An additional advantage is that the DDDS service to resolve the routing information (whatever the system) could be performed by what I call a ONES (open network extended service). This means that it would be managed by OPES call-out hosts operating as one or several overlaying networks. Let take Lisp for example, it could be used only if the destination has an OPES supporting Lisp dcapsulation. This is intelligence but: 1. it is not within the network but at the edge 2. the job is to maintain information among call-out servers about OPES status. These hosts are regular hosts, using the dumb network in a standard way (or a dedicated system, up to the operator). If the result is that the user supervisors I propose come up with a route instead of a destination address, this can permit to reduce the load and cost on routers (these routers could be supported by an OPES linked to the ONES, its host managing their tables dynamically). What is of interest is that such an architecture can be implemented without disturbing the network architecture. One could imagine each ISP building its own ONES (or adhering to a consortium) to manage its foreign relations. With all the mutual back-up possibilities such an approach would allow. jfc PS. Due to the positions that a certain number of countries are taking (starting with the USA) there are most probably three priorities to address that will receive an increasing support at IGF, WTO, local laws: multilingualism (not globalisation's internationalisation), multitopology support (permitting multi-tier legal enforcement), user's choice of the routing itinerary (limitting the risks of interception). At 14:35 26/02/2007, Peter Tomsu wrote: >Margaret, > >I could not agree more ! > >Peter > > >On 05.02.2007, at 21:49, Margaret Wasserman wrote: > >> >>[I have not seen this come out on the list yet. Apologies for any >>duplicates.] >> >>Hi All, >> >>On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote: >>>You clearly need to be able to invalidate a network layer handle >>>if the upper layer entity migrates; and then you have to pay the >>>lookup overhead. >> >>I agree. One thing I've been struggling with, though, is whether >>this lookup should happen in the end-node or in the network... >> >>My thoughts on this topic have favored a two-tiered routing >>approach, which would allow us to highly optimize and evolve the >>global routing infrastructure without affecting end-nodes and local networks. >> >>I have been trying to work out the details of an architecture where >>the two end-points of a connection use local end-point addresses to >>refer to each other, while the network uses global locators for routing. >> >>The same, globally unique, centrally allocated (?) IPv6 addresses >>are used by the end-nodes on both ends, but they will only be >>routable within their own local network. Those identifiers are >>translated into globally-routable locators within the network by >>routers at the local/global boundary, and the original end-point >>identifiers are stored in an extension header. >> >>The global locators are _not_ unique, per end-node >>identifiers. They identify (and provide the information needed to >>route to) another border router that is taking responsibility for >>delivering traffic for a particular set of end-node >>addresses. There would a one-to-many mapping from a global locator >>to end-point-addresses, and a one-to-one mapping of an end-point >>address to a global locator. >> >>This is intended to be a tiered routing approach, not an id/loc >>split technology. Both the end-point addresses and the global >>locators have the property of both identifying an entity and >>providing topological information about how to route to it (locally >>in the case of end-point addresses, globally in the case of global locators). >> >>This approach is essentially identical to IP-in-IP tunneling, with >>optimized headers. >> >>This approach has some similarities to NAT, but with several >>differences that would eliminate the problems caused by NAT: >> >>(1) The local address space is unique (not overlapping) and >>centrally allocated (you can tell who owns it). >>(2) State for mapping the local addresses (end-point identifiers) >>to global locators is held in a global system, like global routing >>tables, not held only on local translators. >>(3) The original end-point addresses in the packet remain in the >>packet and are restored to their original location at the other end. >>(3) Nothing inside the outer IP header needs to be translated. >> >>I think that it has several benefits that make it interesting to think about: >> >>(1) It requires no changes to end-nodes. Applications use DNS to >>get end-point identifiers, as they do today. >>(2) Most routers would not have to change, even within the global >>routing domain. They'd just route on the packet as it was >>presented to them. Only boundary routers would need to know about >>this mechanism, and they would only perform the transformation for >>packets addressed directly to them. >>(3) Local traffic would "just work" as it does today -- no extra >>look-ups or translations. >> >>There are still a lot of things that I have to work out before I'll >>be confident that this approach could be used in a scalable and >>useful way, but I think it is something to think about... >> >>A few areas for discussion are: >> >>(1) How are the endpoint addresses mapped to global locators at the >>local/global boundary? How is this mapping information propagated >>and updated when the mapping changes? (This problem is similar to >>the problems faced be routing protocols today.) >>(2) What are the security implications of this approach, and what >>is needed to prevent this from becoming a great way to inject >>apparently local packets and/or do other types of spoofing? >> >>Margaret >> >> >> >>_______________________________________________ >>Architecture-discuss mailing list >>Architecture-discuss@ietf.org >>https://www1.ietf.org/mailman/listinfo/architecture-discuss > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss --=====================_5661015==.ALT Content-Type: text/html; charset="us-ascii" Peter,
I think that OPES could be an elegant solution offering the best of both (no change on the host, etc.). An additional advantage is that the DDDS service to resolve the routing information (whatever the system) could be performed by what I call a ONES (open network extended service). This means that it would be managed by OPES call-out hosts operating as one or several overlaying networks.

Let take Lisp for example, it could be used only if the destination has an OPES supporting Lisp dcapsulation. This is intelligence but:

1. it is not within the network but at the edge

2. the job is to maintain information among call-out servers about OPES status. These hosts are regular hosts, using the dumb network in a standard way (or a dedicated system, up to the operator). If the result is that the user supervisors I propose come up with a route instead of a destination address, this can permit to reduce the load and cost on routers (these routers could be supported by an OPES linked to the ONES, its host managing their tables dynamically).

What is of interest is that such an architecture can be implemented without disturbing the network architecture. One could imagine each ISP building its own ONES (or adhering to a consortium) to manage its foreign relations. With all the mutual back-up possibilities such an approach would allow.

jfc

PS. Due to the positions that a certain number of countries are taking (starting with the USA) there are most probably three priorities to address that will receive an increasing support at IGF, WTO, local laws: multilingualism (not globalisation's internationalisation), multitopology support (permitting multi-tier legal enforcement), user's choice of the routing itinerary (limitting the risks of interception).

At 14:35 26/02/2007, Peter Tomsu wrote:
Margaret,

I could not agree more !

Peter


On 05.02.2007, at 21:49, Margaret Wasserman wrote:


[I have not seen this come out on the list yet.  Apologies for any duplicates.]

Hi All,

On Nov 16, 2006, at 10:20 AM, Brian E Carpenter wrote:
You clearly need to be able to invalidate a network layer handle
if the upper layer entity migrates; and then you have to pay the
lookup overhead.

I agree.  One thing I've been struggling with, though, is whether this lookup should happen in the end-node or in the network...

My thoughts on this topic have favored a two-tiered routing approach, which would allow us to highly optimize and evolve the global routing infrastructure without affecting end-nodes and local networks.

I have been trying to work out the details of an architecture where the two end-points of a connection use local end-point addresses to refer to each other, while the network uses global locators for routing.

The same, globally unique, centrally allocated (?) IPv6 addresses are used by the end-nodes on both ends, but they will only be routable within their own local network.  Those identifiers are translated into globally-routable locators within the network by routers at the local/global boundary, and the original end-point identifiers are stored in an extension header.

The global locators are _not_ unique, per end-node identifiers.  They identify (and provide the information needed to route to) another border router that is taking responsibility for delivering traffic for a particular set of end-node addresses.  There would a one-to-many mapping from a global locator to end-point-addresses, and a one-to-one mapping of an end-point address to a global locator.

This is intended to be a tiered routing approach, not an id/loc split technology.  Both the end-point addresses and the global locators have the property of both identifying an entity and providing topological information about how to route to it (locally in the case of end-point addresses, globally in the case of global locators).

This approach is essentially identical to IP-in-IP tunneling, with optimized headers.

This approach has some similarities to NAT, but with several differences that would eliminate the problems caused by NAT:

(1) The local address space is unique (not overlapping) and centrally allocated (you can tell who owns it).
(2) State for mapping the local addresses (end-point identifiers) to global locators is held in a global system, like global routing tables, not held only on local translators.
(3) The original end-point addresses in the packet remain in the packet and are restored to their original location at the other end.
(3) Nothing inside the outer IP header needs to be translated.

I think that it has several benefits that make it interesting to think about:

(1) It requires no changes to end-nodes.  Applications use DNS to get end-point identifiers, as they do today.
(2) Most routers would not have to change, even within the global routing domain.  They'd just route on the packet as it was presented to them.  Only boundary routers would need to know about this mechanism, and they would only perform the transformation for packets addressed directly to them.
(3) Local traffic would "just work" as it does today -- no extra look-ups or translations.

There are still a lot of things that I have to work out before I'll be confident that this approach could be used in a scalable and useful way, but I think it is something to think about...

A few areas for discussion are:

(1) How are the endpoint addresses mapped to global locators at the local/global boundary?  How is this mapping information propagated and updated when the mapping changes?  (This problem is similar to the problems faced be routing protocols today.)
(2) What are the security implications of this approach, and what is needed to prevent this from becoming a great way to inject apparently local packets and/or do other types of spoofing?

Margaret



_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss
--=====================_5661015==.ALT-- --===============1456867131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1456867131==-- From architecture-discuss-bounces@ietf.org Tue Feb 27 06:16:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM0J3-00084I-WC; Tue, 27 Feb 2007 06:15:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM0J2-00083y-9m; Tue, 27 Feb 2007 06:15:40 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM0J0-0005dp-UE; Tue, 27 Feb 2007 06:15:40 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1RBFWnW025853; Tue, 27 Feb 2007 06:15:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Feb 2007 13:15:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] IRTF RRG: call for participation Thread-Index: AcdZ8eCjmItYfnPKSuecRr29ePGu+wAbo1ug References: From: "Romascanu, Dan \(Dan\)" To: "Tony Li" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Lixia Zhang Subject: [arch-d] RE: [RAM] IRTF RRG: call for participation X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Is this meeting open to everybody, open to the IETF meeting attendees, not open?=20 Dan =20 =20 > -----Original Message----- > From: Tony Li [mailto:tli@cisco.com]=20 > Sent: Tuesday, February 27, 2007 12:01 AM > To: architecture-discuss@ietf.org; ram@ietf.org > Cc: Lixia Zhang > Subject: [RAM] IRTF RRG: call for participation >=20 >=20 > Hi, >=20 > The Routing Research Group of the IRTF will be holding a=20 > one-day seminar in Prague on March 17th to discuss the=20 > architectural issues confronting the Internet. This meeting=20 > will be held in conjunction with, and just prior to, the=20 > upcoming IETF meeting. >=20 > We would like to invite researchers to participate in this=20 > seminar and in the ongoing activities of the RRG. We are=20 > calling for contributions and talks on architectural problem=20 > analysis and proposed alternative routing and addressing=20 > architectures for the Internet. >=20 > Please contact the RRG co-chairs, Lixia Zhang and myself, if=20 > you are interested in giving a presentation. Currently=20 > scheduled talks can be found at=20 > http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If you=20 > are making a presentation, we do ask that your material=20 > (papers, slides, etc.) be made available via the Internet=20 > prior to the seminar. >=20 > Regards, > Lixia & Tony >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 27 09:39:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3Sj-0001fF-JD; Tue, 27 Feb 2007 09:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnut-0002W7-TB; Mon, 26 Feb 2007 17:01:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnuT-0005N1-GS; Mon, 26 Feb 2007 17:01:55 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Feb 2007 14:01:26 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="393840627:sNHT44214854" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1QM1PxU025155; Mon, 26 Feb 2007 14:01:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QM18nP003911; Mon, 26 Feb 2007 14:01:25 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:01:11 -0800 Received: from [171.71.55.245] ([171.71.55.245]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:01:11 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Mon, 26 Feb 2007 14:01:10 -0800 To: architecture-discuss@ietf.org, ram@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 22:01:11.0017 (UTC) FILETIME=[A0074590:01C759F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=941; t=1172527285; x=1173391285; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20IRTF=20RRG=3A=20call=20for=20participation |Sender:=20; bh=Wqm2Avg0KGrTFk/4ToGQBf9kYUbEvuahrinZui7cMiA=; b=PKjBNXHKhYGpEDMT1PyGfR2sF9zASvZWAfpJixC5usPWtQOxOEhnDT2wjvJYVMu6penh4pcE N0J2t/fKnNd5kZeKIneE5N7bO4DtnX6A3ixgHw+dGem/iXcXbDWzC98S; Authentication-Results: sj-dkim-6; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Tue, 27 Feb 2007 09:37:52 -0500 Cc: Lixia Zhang Subject: [arch-d] IRTF RRG: call for participation X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi, The Routing Research Group of the IRTF will be holding a one-day seminar in Prague on March 17th to discuss the architectural issues confronting the Internet. This meeting will be held in conjunction with, and just prior to, the upcoming IETF meeting. We would like to invite researchers to participate in this seminar and in the ongoing activities of the RRG. We are calling for contributions and talks on architectural problem analysis and proposed alternative routing and addressing architectures for the Internet. Please contact the RRG co-chairs, Lixia Zhang and myself, if you are interested in giving a presentation. Currently scheduled talks can be found at http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If you are making a presentation, we do ask that your material (papers, slides, etc.) be made available via the Internet prior to the seminar. Regards, Lixia & Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 27 11:14:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4y3-0003eU-HQ; Tue, 27 Feb 2007 11:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4y1-0003dt-9j; Tue, 27 Feb 2007 11:14:17 -0500 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4xz-0000aV-SN; Tue, 27 Feb 2007 11:14:17 -0500 Received: from [131.179.33.163] (Cs-33-163.CS.UCLA.EDU [131.179.33.163]) by kiwi.cs.ucla.edu (8.13.7+Sun/8.13.7/UCLACS-6.0) with ESMTP id l1RGEBSo016342; Tue, 27 Feb 2007 08:14:11 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lixia Zhang Date: Tue, 27 Feb 2007 08:14:20 -0800 To: "Romascanu, Dan ((Dan))" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Tony Li , ram@ietf.org, architecture-discuss@ietf.org Subject: [arch-d] Re: [RAM] IRTF RRG: call for participation X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Feb 27, 2007, at 3:15 AM, Romascanu, Dan ((Dan)) wrote: > Is this meeting open to everybody, open to the IETF meeting attendees, > not open? > > Dan Yes this RRG meeting is open to everyone. We need the community's joint effort to develop a good architectural solution. We would like to encourage people to register for IETF as IETF resources are being used to provide the room, projector, network access, etc. for this meeting. However for those who do not plan to attend IETF otherwise, it seems unpractical to require them to register for IETF. >> -----Original Message----- >> From: Tony Li [mailto:tli@cisco.com] >> Sent: Tuesday, February 27, 2007 12:01 AM >> To: architecture-discuss@ietf.org; ram@ietf.org >> Cc: Lixia Zhang >> Subject: [RAM] IRTF RRG: call for participation >> >> >> Hi, >> >> The Routing Research Group of the IRTF will be holding a >> one-day seminar in Prague on March 17th to discuss the >> architectural issues confronting the Internet. This meeting >> will be held in conjunction with, and just prior to, the >> upcoming IETF meeting. >> >> We would like to invite researchers to participate in this >> seminar and in the ongoing activities of the RRG. We are >> calling for contributions and talks on architectural problem >> analysis and proposed alternative routing and addressing >> architectures for the Internet. >> >> Please contact the RRG co-chairs, Lixia Zhang and myself, if >> you are interested in giving a presentation. Currently >> scheduled talks can be found at >> http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If you >> are making a presentation, we do ask that your material >> (papers, slides, etc.) be made available via the Internet >> prior to the seminar. >> >> Regards, >> Lixia & Tony >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 27 22:08:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMF8k-0005Iy-CH; Tue, 27 Feb 2007 22:06:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMF8j-0005Ih-23; Tue, 27 Feb 2007 22:06:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMF8g-0006KX-Nj; Tue, 27 Feb 2007 22:06:01 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2007 19:05:57 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="116656252:sNHT45387747" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1S35v0s010796; Tue, 27 Feb 2007 19:05:57 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1S35vUw004002; Tue, 27 Feb 2007 19:05:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 19:05:57 -0800 Received: from [127.0.0.1] ([10.70.237.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 19:05:56 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Markus Stenberg Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Wed, 28 Feb 2007 12:05:48 +0900 To: Lixia Zhang X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Feb 2007 03:05:57.0011 (UTC) FILETIME=[5DBE4630:01C75AE5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1516; t=1172631957; x=1173495957; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mstenber@cisco.com; z=From:=20Markus=20Stenberg=20 |Subject:=20Re=3A=20[arch-d]=20Re=3A=20[RAM]=20IRTF=20RRG=3A=20call=20for =20participation |Sender:=20; bh=wfzejNJGjT7M0vuvLZuiDauGsg2A1Ew14mSNXDCkTI0=; b=iYCs8AHpoVc96Ed8t0GW/4MGQkwf3o/g8xgCmnhjLHrciOZqseYRTlSyjUJydnjwyueoCnF+ /ceNcS3xPw+ud/QRcb7a0LWNzjcOYJC4LzCGBZoBmpx0jvxpVaTFqZqU; Authentication-Results: sj-dkim-2; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ram@ietf.org, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 28.2.2007, at 1.14, Lixia Zhang wrote: > On Feb 27, 2007, at 3:15 AM, Romascanu, Dan ((Dan)) wrote: >> Is this meeting open to everybody, open to the IETF meeting >> attendees, >> not open? >> >> Dan > > Yes this RRG meeting is open to everyone. We need the community's > joint effort to develop a good architectural solution. > We would like to encourage people to register for IETF as IETF > resources are being used to provide the room, projector, network > access, etc. for this meeting. However for those who do not plan > to attend IETF otherwise, it seems unpractical to require them to > register for IETF. This is a general whine. Be prepared. I'd have loved to attend this, because ever since the IEPG in the last IETF, I've encountered discussion about the problem, if not problem itself, during my work. However, announcing something happening in 3 weeks on different continent (for most people) is rather short timeframe - to get cheapest air tickets, you need to book them roughly month in advance, and because I knew I was going to IETF, of course I had booked them bit before that. And then, after reading the announcement, I had the choice of either paying roughly more to attend this one-day show, or not; unfortunately, the not part won. I hope some form of minutes/presentation slides will be available on the net after the event so I can browse them on the Sunday :p Cheers, -Markus _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 27 23:36:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMGVf-0008E8-EA; Tue, 27 Feb 2007 23:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMGVd-0008DU-Vm; Tue, 27 Feb 2007 23:33:45 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMGVc-0000vv-Pq; Tue, 27 Feb 2007 23:33:45 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc13) with SMTP id <2007022804333301300n3hase>; Wed, 28 Feb 2007 04:33:34 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Tue, 27 Feb 2007 20:33:31 -0800 To: Markus Stenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@ietf.org, architecture-discuss@ietf.org, Lixia Zhang X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > I'd have loved to attend this, because ever since the IEPG in the > last IETF, I've encountered discussion about the problem, if not > problem itself, during my work. However, announcing something > happening in 3 weeks on different continent (for most people) is > rather short timeframe - to get cheapest air tickets, you need to > book them roughly month in advance, and because I knew I was going > to IETF, of course I had booked them bit before that. > Sorry. This was originally announced to the RRG mailing list on 1/13/07. Then there was a change of management and that took some time to work out. We'll try to do better next time. Regards, Lixia & Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss